2024 Q1 Blockchain Commons Report
In the first quarter of 2024, Blockchain Commons continued its work on specifications, updated some of its references, and did new research on constrained devices, provenance, and identity.
Specifications
- dCBOR
- Hashed Data Elision
- FROST
Specification Docs
- Multipart UR Implementation Guide
- Request & Response Implementation Guide
- Updated Research List
Reference Releases
- Gordian SeedTool 1.6
- Gordian Server 1.1
- Rust Crates Updates
Constrained Devices Research
- JavaCards
no_stdin Rust
Provenance Research
- C2PA
- Source Code Provenance
Identity Research
- eIDAS Dangers
- Identity Dangers
The Future
Specifications
One of Blockchain Commons biggest priorities is producing interoperable specifications that can be used by principals in the digital asset & identity field to create apps and hardware devices that support independence, privacy, resilience, and openness for users. In Q1, we worked to advance some of our specifications into true standards and also interacted with standards being developed by the rest of the field.
dCBOR. Our Internet-Draft for Decentralized CBOR (dCBOR) went through drafts 6, 7, and 8 this quarter. CBOR expert Carten Bormann joined us as a co-author and we continued to make tweaks based on expertise from the CBOR community, most recently revising how we defined leaves (“enclosed CBOR”). dCBOR is crucial for deterministic data formats such as Gordian Envelope because it ensures that data is always encoded in the same way, no matter when or where the encoding is done. We have high hopes that dCBOR will be an IETF standard soon.
Hashed Data Elision. We previously authored an Internet-Draft for Gordian Envelope, which we’ve continued to update in connection with our dCBOR updates. We’ve been getting less traction here, so we supplemented it this quarter with a problem statement on Deterministic Hashed Data Elision Internet-Draft. We also presented on hashed data elision at IETF 119 Dispatch. Our core premise was that privacy and human-rights needs are not well supported in IETF standards. We believe that hashed data elision (including Gordian Envelope) should be used as an easy method to address those needs. Unfortunately, the IETF hasn’t been strong on privacy concerns. Previous RFCs on Privacy and Humans Rights Considerations are mere recommendations with no weight. The bottom line seems to be that unless an existing protocol expresses a desire for privacy standards, there’s no place for hashed data elision in the IETF, though the IRTF, which focuses on “Research” instead of “Engineering”, might be a home for it.
FROST. FROST, a threshold scheme for Schnorr signatures, originated with a paper in 2020. We’ve been looking forward to its deployment in wallets because of its improved resilience and privacy, plus other advantages such as being able to change thresholds offline. See our FROST page and Layperson’s introduction to Schnorr for some foundational info. In the last six months, we’ve been doing our share to help FROST become a reality. In Q4, we held an implementer’s round table to allow people working on FROST to talk to each other. This quarter, one of those implementers, Jesse Posner, gave a presentation at our most recent Gordian Developers meeting to help to introduce developers to the powers of Schnorr and FROST. Dare we say: winter is coming? At least, FROST is.
Be sure to also check out our January Gordian Developers Meeting with its focus on the “Multi-Part Implementation Guide for URs” and our February Gordian Developers Meeting with its Gordian SeedTool 1.6 demo, and be sure to sign up for the Gordian Developer announcements list or Signal channel so that you can hear about the demos or talks at future meetings.
|
|
|
| January | February | FROST |
Specification Docs
We want to make sure that our specifications are easily adaptable, especially to developers who might want to implement them. As a result, in Q1, we added two new implementation guides and revised how we flag the status of our specifications.
Multipart UR Implementation Guide. Multipart Uniform Resources (MURs) are Blockchain Commons’ biggest success because they allow for the interoperable and efficient creation of Animated QRs. They’ve been adopted by over a dozen wallets, mainly to pass PSBTs, but they can also pass other large data sets over an airgap: we’ve even tested megabytes! (video link). The pioneering MUR developers based their implementations on our reference code. This quarter we supplemented that with a MUR Implementation Guide that still focuses on our code, but offers explanations of how MURs work and precise instructions on how to make them work for you. Also see our January Gordian Developers Meeting for a walk-through of the Implementation Guide.
Request & Response Implementation Guide. The heart of Gordian Envelope is its ability to elide information while still allowing both certification and verification of that data. That’s the Hashed Data Elision concept that we presented at IETF. However, Gordian Envelope has much more functionality than just hashed data elision, including literal functions, which can be used in a request-response system where one interoperable system asks for something and another provides it. Our request/response docs were spread across a variety of smaller docs such as the Expressions Research doc and our source code, so we conslidated it all into a single Gordian Transport Protocol Implementation Guide, which describes the layers that build up to GTP and how to do requests and responses with Gordian Envelope. As for why you might want to, our new Improving Multisigs with Request/Reponse document presents an important case study on the usage of this system: it makes very difficult processes, like creating a multisig with multiple devices, much more accessiblem by reducing decision, research, and human-initiated actions, and thus much more likely to be used.
Updated Research List. All of our specifications can be found in our Research list. Since we have specifications at a variety of levels of development, from pure investigation on our part to implementation by multiple partners, we introduced a status listing that tells developers exactly how mature each specification is.
Reference Releases
Specifications are just one step in creating interoperability. We also produce reference apps and libraries that demonstrate how to use our specifications and how to incorporate best practices.
Gordian SeedTool 1.6. Our top reference app has long been Gordian SeedTool, which demonstrates specifications like Gordian Envelope, SSKR, and URs as well as best practices for safe and resilient digital-asset holding. We’ve been working on version 1.6 for a long time, but it’s now finally out, through GitHub and the Apple App Store. It includes updates to our newest specifications, new best-practices for UIs, and integration of Tezos assets.
Gordian Server 1.1. Our oldest supported reference app is Gordian Server, a Macintosh app that installs, maintains, and run Bitcoin Core. It demonstrates our Quick Connect URI, but more importantly it shows off some of our architectural fundamentals, such as maintaining partitioned services that are separated from each other by a TorGap. The new 1.1.0 release of Gordian Server updates for Apple’s native Arm64 (M1+) chips and also works with newer version of Bitcoin Core, up to and including the newly released Bitcoin Core 26.1. It also contains a major update that’s been a few years coming that replaces the older RPC password files with the much more secure rpcauth system. (Thanks to Peter Denton for this update and check out his Fully Noded for a wallet that integrates with Gordian Server!)
Rust Crate Updates. Over recent quarters, we converted our fundamental crypto libraries to Rust. We are continuing to keep them updated with our newest specifications and continuing to polish them, such as our recent work on bc-envelope-rust to streamline the API and reduce calls to clone().
Constrained Devices Research
Specifications, reference apps, and reference libraries represent some of our more mature work, but we’re also constantly researching other fields that might improve the management and usage of digital assets and identity online. One of our fields of research recently has been on constrained devices.
JavaCards. Could we hold assets or private keys on NFCs or JavaCards? We’ve discussed the topic at some of our recent Gordian meetings and have a Signal group dedicated to the topic, which you’re welcome to join. We’re hoping to do more with it in 2024.
no_std in Rust. Our Rust crate for bc-dcbor-rust now supports no_std. The no_std crate attribute allows Rust code to run on embedded systems and other constrained environments that don’t have access to the standard library. This means that dCBOR can now be used to serialize and deserialize data in firmware for IoT devices, microcontrollers, and smart cards. It’s another step forward in our support of constrained environments.
Provenance Research
How can you validate the provenance of data or identity? This is a natural expansion of our work with Gordian Envelope, which allows validation of data even when it’s been elided, so it’s been another source of research in the last quarter.
C2PA. We have joined the Coalition for Content Provenance and Authenticity (C2PA, which is focused on developing standards for certifying the provenance of media content. We’ve talked with them some about Gordian Envelope as a possible tool for this purpose.
Source-Code Provenance. We’ve long been thinking about source-code provenance and the validation of software developers, going back to our support for Joe Andrieu’s Amira Use Case, which grew out of RWOT5. Our software release use cases discuss many of the issues and how to resolve them with Gordian Envelope. More recently, we’ve been investigating SSH signing, which is now supported at GitHub. We’re working on a doc of best practices and also an SSH tool that will link up the envelope-cli with ssh-keygen. We’ve got a working prototype and expect to be able to talk more about the project, and the issues with software-release provenance, next quarter.
Identity Research
Work on identity, ultimately stemming from Christopher Allen’s “Path to Self-Sovereign Identity”, and continued work on DIDs and VCs at Rebooting the Web of Trust, was one of the things that got Blockchain Commons going in the first place. However, our partners and patrons have all been focused more on digital assets, so that’s where most of our work has been concentrated over the last five years. Nonetheless, we keep our foot in the identity pond, particularly for some of our Advocacy work.
eIDAS Dangers. Late in 2023, Christopher published an article on “The Dangers of eIDAS”, which is Europe’s new European Digital Identity regulation. Unfortunately, besides having some deeply flawed security models, it also ignores many of the dangers of the past.
Identity Dangers. What are those dangers? That’s the topic of “Foremembrance”, a book that Christopher been working on for a few years that remembers how overidentification led to genocide during World War II. On March 27, which is Foremembrance Day, Christopher gave a talk on the topic on Twitter. The YouTube video and the presentation are both available.
The Future
Many of these topics will continue onward, especially our more research-focused projects, such as our look at SSH signing and software provenance. We’re also hoping to do some major work with one or more of our partners to turn many of our specifications into deployed reality.
Our next Gordian Meeting, on May 1st, will have another feature presentation: Dan Gould will talk about PayJoin.
Finally, our advocacy is heating up again as the Wyoming legislature prepares for its meetings in May through September. We are engaged in discussions and early agenda setting with the co-chairs of the Wyoming Select Committe on Blockchain. We are hoping to see topics such as digital attestations from the Secretary of State, best practices for data minimization, and duties of care and best practices for digital identity on the agenda, as well as topics that we’ve pushed in the past such as Wyoming eResidency.
Blockchain Commons needs funding to continue its work as an architect for interoperable specifications and a central forum for their discussion because many of our funding sources dried up due to the economic conditions of recent years. If you’re a developer, please consider becoming a Benefactor to lend your name to our efforts, and if you’re a company, especially one using our work, please consider becoming a Sustaining Sponsor. We’re also open to working with partners on special projects that are open-source and aligned with our objectives, or that accelerate the deployment of our specs in your products. If sponsorship or a special project interest you, please drop us a line for more information.
We have further been seeking grants to continue our work. If you have the inside track on any grants that you think would be well-aligned with our work, or just want to make suggestions, again drop us a line.
Blockchain Commons is literally a commons: we are producing work that we hope is useful for the rest of the community, some of which is now widely deployed. But, the name might have been too apt, because the Tragedy of the Commons has long said that public resources of this sort are depleted. Help us replenish our resources to make sure the Commons continues!