Summary of Gordian Developer Meeting September 6, 2023

[shannona]

IETF Results

dCBOR

Blockchain Commons Presented dCBOR

Lots of support & robust discussion of deterministic CBOR in group

• The remaining debate is how we structure this in abstract layers.
• In CBOR, there are some guidelines, but not a lot is normative

dCBOR is CBOR

• But a dCBOR specific codec is strict about what it reads and writes
• A lot of focus on Numeric Reduction
• And this is incorporated into Gordian Envelope stack

See dCBOR I-D.

Envelope

Great feedback from IETF 117.

But resulted in breaking change for Envelope

• So we were issued CBOR tag 200 for Envelope
• But also reduced number of tags we needed!
• We would like to migrate away from 300-400 tags we originally used, but there are some uses in field right now

What resulted is a very tight definition of "Envelope Core" with single tag

More complex/cryptographic stuff is moved to docs controlled by Blockchain Commons & uses higher IANA numbers (or known values), which are used on a first-come, first-use basis. See BCR-2023 docs in our Research repo for these extensions, such as BCR2023-004, which talks about symmetric encryption in Envelopes.

Our use of crypto is OPINIONATED, but additional types of crypto could be added as new tags as needed.

Attachments for Envelope

A major new extension for Envelopes!

Developers want to be able to incorporate their own data into Envelopes

• We did this with Attachments
• BCR-2023-006

You can add anything to an Envelope,

• But we want things to be highly INTEROPERABLE
• And DISCOVERABLE
• So we introduced Attachments

An attachments has a required vendor description and an optional conformsTo.

Can even have multiple attachments (as long as they're not 100% identical!)

Question about having a big string value in conformsTo: assertion.

An alternative might be supporting CBOR's media types in attachments.

See:

• https://datatracker.ietf.org/doc/html/rfc8152#section-16.10
• https://www.iana.org/assignments/core-parameters/core-parameters.xhtml
• https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats

Registering a Known Value might be another way to do this, which would be more the "Envelope" way to do things, ensuring the conformance info is short and deterministic

But this first iteration is simple and straightforward, intended to allow interoperability of seeds among developers, preserving as much metadata as possible.

Our new doc demonstrates the interoperability of attachments among our tools.

This could be private data (used only by a single manufacturer to share data among their own apps) or public (used for full interoperability)

Output Descriptors for Seeds

Because Envelopes are unconstrained, we have prepared research doc BCR-2023-007 that constrains/defines how to place Bitcoin Output Descriptors in Envelopes

After initially trying to describe it with CBOR tags, we eventually settled on a format that reuses classic text descriptions.

• We couldn't lock down tags with IANA
• And we were aware of issues with unusual descriptors, miniscript, etc

Easy to support just THIS format, even if you don't support the entire Envelope stack.

Some discussion of inefficiency due to use of text, such as the fact that it uses base58.

• And this is relevant for some constrained environments, such as writing to NFCs

We would love to have two wallet companies working together to agree on a compact format!

Our reference apps now allow the pasting of output descriptors, for example in Gordian Seed Tool, which is even validates to ensure that the descriptor is from the seed!

These reference docs are intended to give our partners interested in our specs something to test against!

• And they help us to learn what our partners might need!

Older Specs

Questions on what to do with older specs, such as crypto-output

• Issue that they use tags that we now know IANA will not give us
• But some people see value in them!
• Because among things they are standardized

If we wanted to put out a version 2.0, we'd just need to convert to higher tags

• and adding any other info needed

We need to investigate this particularly for crypto-output specifically, for descriptors!

• One of the issues is how to compress the xpub

[THIS MIGHT BE A TOPIC FOR A NEXT MEETING]

Developer Web Pages

We have developer web pages at developer.blockchaincommons.com.

Covers 11 different Blockchain Commons specifications, and includes use cases, test vectors, FAQs, and docs.

If we don't have what you need, let us know!

YAML Format for Disclosing Docs (Orie)

This comes out of Transmute's work in securing supply chains.

• Often, data is supplied in big pipes of data
• Without concern for UX
• A very different experience than personal credentials!

One of the concepts shared between them is Selective Disclosure

• So format of JSON with Selective Disclosure has developed

Basic approach:
https://github.com/danielfett/sd-jwt/blob/main/tests/testcases/array_recursive_sd_some_disclosed/specification.yml

Example of JSON payload:
https://github.com/w3c/vc-jose-cose-test-suite/blob/main/testcases/secured-vc-jwt-sd/spec.yaml

But there's growing use of YAML to represent CBOR

Example:
https://github.com/transmute-industries/vc-jwt-sd/blob/5b757dd6d6f74072ea810128d939aa7e68d4fb4b/test/sd-cwt-prototype/e2e.test.ts

Uses "!sd" tag

• Annotates YAML to allow automated encoding in a selectively disclosable way

Could we similarly use YAML to create Envelope and/or CBOR?

• A data format that could go to CBOR Diagnostic
• But be more human-readable!
• And YAML is increasingly widely used
• CBOR & YAML could be a good pairing!
• For BC, is there a YAML version of Gordian Diagnostic?

Rust Libraries in Community Review

Our crypto-stack is in Rust, they're our first Rust libraries.

So we really need Community review!

Work on Third-Party UR Development in Kotlin (Thunderbiscuit)

https://github.com/kotlin-bitcoin-tools/ur

Issues with implementation:

• UR spec broken up among multiple Research Papers
  • So we really need to consolidate UR material as WIP
  • (We currently suggest building up UR docs using unit tests.)
• Some specific Kotlin/Java issues

We should flag "trusted" libraries