Enable CBOR Representation(s) of Verifiable Credentials

[selfissued]

Many parties have already created and deployed ad-hoc CBOR representations of Verifable Credentials. Unfortunately, none of these are standards or standards-track at present.

One of CBOR's obvious advantages over JSON is size. Binary data such as signatures doesn't pay the 33% size inflation that base64url-enoding binary data incurs in JSON.

The DID abstract data model succeeded in enabling CBOR representations. (Yes, the DID working group didn't agree on what CBOR representation to standardize, although that could change in the future.) We should likewise explicitly enable standardization of CBOR Verifiable Credential representations with the Verifiable Credentials Data Model.

[ChristopherA]

Blockchain Commons, and our financial sponsors from the cryptographic wallet & chip industry, have committed to moving to deterministic CBOR.

Why?

• unambiguous encoding
• reasonably compact serialization and easily streams
• works well in constrained environments (such as cryptographic silicon chips)
• extensible
• schema descriptions are not required
• doesn't require arcane ASN.1 descriptions of all forms of data.

There is a more specific comparison with other formats in Appendix E of the IETF spec for CBOR:

https://www.rfc-editor.org/rfc/rfc7049#appendix-E

We've added a few comparison links at "Why CBOR? Why not Protocol Buffers??"

https://github.com/BlockchainCommons/Research/blob/d1e0fae2bfc183ec92f08f3788ae1d03864ee8b9/papers/bcr-2020-005-ur.md#why-cbor-why-not-protocol-buffers

We made this decision some time ago, and we keep being happy with our choice.

Specifically, we are planning to submit this spec for Gordian Envelopes that leverages deterministic CBOR as an IETF Internet-Draft by end of the week:

ABSTRACT: The envelope protocol specifies a format for hierarchical binary data built on CBOR. Envelopes are designed with "smart documents" in mind, and have a number of unique features including easy representation of semantic structures like triples, built-in normalization, a built-in Merkle-like digest tree, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the digest tree or cryptographic signatures that rely on it

https://blockchaincommons.github.io/WIPs-IETF-draft-envelope/draft-mcnally-envelope.html

It adds to CBOR:

• A digest tree
• It is cryptographic ready (as it is built on deterministic CBOR)
• Binary efficiency
• Digest-preserving encryption and elision
• A progressive trust privacy protection architecture
• Semantic structures are optional, but possible, allowing @context, schema, or labeled property graphs approaches.

We have a high-level overview of Gordian Envelops at:

https://www.blockchaincommons.com/introduction/Envelope-Intro/

A more engineering-level introduction at:

https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Envelope-Tech-Intro.md

We have a video playlist starting with a 10m high-level introduction:

https://www.youtube.com/playlist?list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG

We have a reference CLI implementation (written in Swift) available now, and some of our patrons have begun porting libraries to more languages like Kotlin, Typescript, Python, and Blockchain Commons is also committed to porting to Rust as funding allows. Let us know your needs!

For those of you who don't like videos, we have an annotated introduction to our CLI reference implementation that really demonstrates of the power of CBOR with Gordian Envelopes:

https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Transcripts/1-OVERVIEW-TRANSCRIPT.md

We have also written up a number of "use case" documents to demonstrate what is possible using Gordian Envelopes. Specifically, the VC community may find our "Educational Credential" use case interesting:

https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Envelope-Use-Cases-Educational.md

-- Christopher Allen

[OR13]

I'm against "defining W3C Verifiable Credentials data model in CBOR".

I don't believe W3C is the right place to "define a new data model for arbitrary claims in CBOR" especially if there is already plans to do that work at IETF.

(ACDCs and Gordian)

There are also a lot of incompatibilities, and politics between JOSE and COSE which make the idea of doing anything other than securing the W3C Verifiable Credentials Data Model... Not something the W3C is well positioned to accomplish successfully.

I also think that there are several COSE structures that should be supported, and we should avoid locking implementers into CWTs as the only supported format for COSE.

TLDR, as I said at TPAC I am in favor of securing the W3C VC Data Model with JWS, JWT, JWE and COSE...

I'm not in favor of starting from scratch on a new abstract data model.

We're not making any progress meaningfully improving what we are already committed to, it's not a good time to suggest pulling in new work.

[mwherman2000]

What is the best link(s) to a primer on CBOR?

[selfissued]

One other reason CBOR can be a lot more compact than JSON that people not currently using it may not be familiar with: Instead of having to use string member names as JSON requires, like "credentialSubject", numeric member names can be used, including single-byte member names such as 3. Yes, you would have to understand the mapping between "credentialSubject" and 3, but it's a significant savings worth having for some use cases.

[mprorock]

I'm not in favor of starting from scratch on a new abstract data model.

We're not making any progress meaningfully improving what we are already committed to, it's not a good time to suggest pulling in new work.

Agreed - i think timing will be important here - I also think that we should not start from scratch, but should leverage the VC data model as it exists in 1.1 as a starting place.

Hugely supportive of CBOR encoding for VCs and am willing to contribute time to this.

[TallTed]

One other reason CBOR can be a lot more compact than JSON that people not currently using it may not be familiar with: Instead of having to use string member names as JSON requires, like "credentialSubject", numeric member names can be used, including single-byte member names such as 3. Yes, you would have to understand the mapping between "credentialSubject" and 3, but it's a significant savings worth having for some use cases.

Of course, if one is using JSON-LD, one can build an @context for use in their VCs which uses numerics (expressed as strings) or other single-byte member names such as "a", which map to the full URI of their intended identifier. Yes, you would have to understand how @context supplies a mapping between "3" (or "a") and https://w3.org/2018/credentials#credentialSubject, but it's a significant savings worth having for some use cases.

It's funny how many arguments can be applied to neighboring scenarios, eh?

[OR13]

If this WG is going to attempt multiple representations, we will need to develop a shared mental model for how they relate to the core data model, and it should be handled much better than what was done to the DID spec.

I can see one path forward, that I would support, inspired by the work at IETF - https://datatracker.ietf.org/doc/draft-birkholz-rats-corim/

They provide a JSON and CBOR representations.

We could take the existing namespace:

• https://www.w3.org/2018/credentials

For every property in the namespace, add a tag for it, and manage the tags in a centralized registry like (but not equivalent too, aka a new registry):

• https://www.iana.org/assignments/cose/cose.xhtml

Then define lossless bidirectional mappings between JSON and CBOR representations for credential and presentation.

And then define proof formats for VerifiableCredential and VerifiablePresentation for the following cases:

• JWS over a CBOR credential
• COSE Sign over a JSON credential
• JWS over a JSON credential
• COSE Sign over a CBOR credential
• JWT over a JSON credential
• CWT over a CBOR credential

I don't see this recommendation as "altering the core data model".... I see it as defining a mapping from the "core data model" to JSON or CBOR.

I can imagine this going wrong and making things massively worse than they already are today, especially given the current state of the vc-jwt mapping.

I suggest we think of supporting CBOR in this manner as a "stretch goal", and tackle it after we have addressed the obvious flaws related to the current JSON mappings.

If we keep trying to attack the core data model, we are never going to get to FPWD for vc-jwt or fix any of the critical issues with it, and it should perhaps not be targeted for delivery by the WG...

After all, the charter allows us to decide what to focus on... it doesn't guarantee delivery... If vc-jwt is not improved significantly, I believe the WG should decline to publish it as a technical recommendation.

Starting work on CBOR seriously threatens the working groups ability to do a "good job" on the things we have already said we would do, but have yet to show real progress on.

I can't meaningfully contribute to so many work items... Its already a stretch to support the current work items:

• core data model
• data integrity
• jws-2020
• vc-jwt

Let's show progress on eating whats on our plate, before loading up on more sugar.

[dlongley]

We could take the existing namespace:

https://www.w3.org/2018/credentials

For every property in the namespace, add a tag for it...

It's worth noting that CBOR-LD does this programmatically and automatically for any JSON-LD contexts. IOW, it avoids the artisan-approach but still achieves semantic compression. CBOR-LD also already maps to / from the existing model and JSON-LD representation.

[David-Chadwick]

I think the discussion in issue #973
#973 (comment)
is related (perhaps orthogonally) to this issue. Specifically taking a credential, and converting it into a verifiable credential by whatever rules we determine, then does this create a new object (i.e. a verifiable credential in whatever encoding format was determined by the proofing rules) or is it still essentially the same object (i.e. a credential) with some extra crypto data attached to it.
If it is the former, then we can take a credential, in JSON(-LD) format, define rules to turn it into a CBOR VC, and the converse rules will convert it back into the same credential (in JSON(-LD)) that we started with. If it is the latter, then we cannot do this, because we will loose the credential (in JSON(-LD) format) in the VC.
I think (though I could be wrong) that JWT proofs assume the former model whereas JSON-LD proofs assume the latter.

[OR13]

• https://github.com/transmute-industries/vc-cose

Has been discussed, we've talking about how cty and typ can be used to secure content in JSON and CBOR.

[iherman]

The issue was discussed in a meeting on 2023-02-08

• no resolutions were taken

View the transcript

4.1. Enable CBOR Representation(s) of Verifiable Credentials (issue vc-data-model#985)

See github issue vc-data-model#985.

Brent Zundel: enable cbor representations of VCs.
… suggest we should aim for CBOR representation for data model.

Orie Steele: has been proposal for cbor in P.R #1000.
… conversations around content type property in cose and jose. I will add some links.
… looking forward to discuss at f2f.

Manu Sporny: already cbor representations for VCs. Not standardised. Have cbor-ld that will take jsonld VCs and compress.
… not standardised.
… has been used in various pilot programs.
… going into prod.
… strongly suggest we don't pick this up at the moment. Have enough on our plate.
… could provide impl guidlines for cbor.
… instead of creating a new work item.

Brent Zundel: any other comments.

[OR13]

I suggest closing this issue, vc-jwt already covers a cose sign1 scenario for vc+ld+json.

[brentzundel]

closing based on conversation during 2023-04-05 VCWG call

[iherman]

The issue was discussed in a meeting on 2023-04-05

• no resolutions were taken

View the transcript

3.3. Enable CBOR Representation(s) of Verifiable Credentials (issue vc-data-model#985)

See github issue vc-data-model#985.

Brent Zundel: Will assign both to the issue to discuss and move things forward.
… Enable CBOR Representation(s) of Verifiable Credentials.
… Is there someone willing to be assigned to this issue?

Dave Longley: Who would be the closest, based on resolutions made previously?

Oliver Terbu: +1 dave.

Manu Sporny: +1 dave.

Dave Longley: Maybe we should close this.

Joe Andrieu: +1 to close.

Manu Sporny: CBOR is a new work item, we are past feature freeze, close it.

Ivan Herman: Do we want to add another work item for CBOR representation?

Kevin Griffin: +1 to close.

Michael Jones: I concur. With where we are and what we need to do, not willing to add another work item.

Michael Prorock: +1.

Orie Steele: +1 to close.

Ivan Herman: +1 to nuke it.

Michael Jones: Supports closing.

Kevin Dean: CBOR supported in ACDC, so may be covered there.

Brent Zundel: ivan will close it.

[brentzundel]

No objections raised since being marked pending close, closing.