Summary of the Gordian Developer Meeting 2023-03-01

[shannona]

Gordian Developers Meeting

2023-03-01

This is a summary of a meeting held on March 1, 2023 for the Gordian Developer Community. An archive is available as YouTube Video, also available as MP3 Audio. The overview slideshow and dCBOR slideshow are also available in GitHub. See our meetings directory for a complete list of meetings.

Blockchain Commons introduced itself as an organization focused on self-sovereign control of assets. It introduced the Gordian Meetings for Developers to jointly expand and use the Gordian specs to create interoperable, secure, compassionate infrastructure.

This year's goals? dCBOR libraries, Gordian Envelope deployment, CSR, and ultimately CKM.

Today? Community Channels, UR Interoperability Success, dCBOR Community Review, Crypto-Request for Signing, and Next Month's Priorities.

Community Channels

The Gordian Developer Community will have virtual meetings, always the first Wednesday of the month, though the time might iterate for Asia & Europe.

There are also Signal, GitHub Discussions, and an announcements list.

See: http://www.blockchaincommons.com/subscribe.html for them all

UR Interoperability Successes

Many people are supporting UR.

The whole chart is here:
https://github.com/BlockchainCommons/Gordian-Developer-Community#urs

(Send us PRs if you have any updates!)

The community may want to create a spec for health checks, since it's already being done for a few people.

dCBOR

Blockchain Commons thinks CBOR has a lot of advantages. They've produced libraries for Rust & Swift, plus a command verifier called dCBOR-CLI.

A presentation was offered by Wolf McNally on Deterministic CBOR.

Blockchain Commons choose CBOR because it's binary, concise, compact, self-describing, good in constrained environments, platform/language agnostic, standardized as IETF RFC, and (optionally) DETERMINISTIC. Determinism is important to eliminate choices for how to serialize particular data: the same data should always appear in the exact form, even from different agents. The requirements of dCBOR per RFC8949 were discussed. The goal is to eliminate choices for developers!

Blockchain Commons finds deterministic encoding essential for cryptographic "smart documents" such as Gordian Envelopes and feels that enforcing opinionated best practices is even better.

Because there weren't any dCBOR focused libraries, Blockchain Commons has written two of them, one for Swift and one Rust. Their intent is to make it impossible to write non deterministic CBOR and an error to read it. They also include some specific decisions about things that were optional in the RFC, such as how to encode certain floating-point values. They also include diagnostic notation that will be annotated with provided names for tags, and there's validation when decoding or extracting. (Blockchain Commons tries to create libraries that they'd want to use!)

These libraries should make it easier for other developers to use dCBOR (and harder for them to make mistakes) and are also being built into Blockchain Commons' own libraries, such as Gordian Envelope.

Currently the dCBOR libraries are in Community Review, which is a phase prior to Security Review. So Blockchain Commons is asking for people to test them: to make sure they work, that APIs are what people need, and that APIs are sufficiently idiomatic yet consistent. They are looking for comments, Issues, and/or PRs.

After the Community Review, the goal is to get a community-supported Security Review.

Future work is planned for Kotlin and Python.

Signing with Bitcoin Keys

There was a lot of discussion on signing this Winter, so Blockchain Commons coordinated a group on this topic last Friday and came up with an example of how to do so using Gordian Envelope.

It demonstrates how to pass a signing request back and forth to a Cold Card using crypto-requests formatted as Gordian Envelopes. The result is cryptographically strong structures that can be elided or encrypted or signed as desirable.

This example can be found at:
https://github.com/BlockchainCommons/BCSwiftExampleSigner

The goal of the demo was to show how easy it is to incorporate Envelope into your workflow; it doesn't necessarily show the complexity of a full workflow. For example, it's still single-round-trip and there's a desire to extend this to multidevice & multi-party processes.

Next Month Priorities

Blockchain's priorities:

• Envelope for Rust
• Update Envelope to SHA256
• Present Envelope at IETF
• Demo of Crypto-envelope CSR-SSKR

Other members have things coming up too, including SSKR for constrained JavaCard and a QR demo of legacy Bitcoin signing.

Final Notes

If you're going to store things, Blockchain Commons encourages using an Envelope, because it can back up other info. It helps to futureproof to allow restoring a lot of other things.

[ChristopherA]

I've separated out @wolfmcnally's "Deterministic CBOR (dCBOR)" presentation on its own.

• YouTube Video
• Presentation Slides PDF
• MP3 Audio
• Abstract & Transcript of Audio