Re: Deterministically Encoded CBOR. Re: Notes on the VCWG Recharering

Hi Wolf,

If you take a peek at https://www.w3.org/TR/vc-overview/#complete_example you will find an example of the CBOR/COSE version of VC:

/ cose-sign1 / 18([
   / protected / << {
     / alg / 1 : -35 / ES384 /
   } >>,
   / unprotected / {
   },
   / payload / h'7b224063...74227d7d',  / The VC is buried here... /
   / signature / h'e63f0753...345cef72'
])

This is IMO an awkward solution, not using the power of Deterministically Encoded CBOR.  No wonder the EU Digital Identity Wallet architects didn't consider CBOR/COSE as a viable alternative to JSON/JOSE.

What will happen on the deterministic side of things is (with respect to IETF standardization), anybody's guess.

Anders

Alternative solution using Deterministically Encoded CBOR:

1010(["https://www.w3.org/ns/credentials/v2", {
   "id": "https://university.example/Credential123",
   "type": ["VerifiableCredential", "ExampleAlumniCredential"],
   "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
   "validFrom": "2010-01-01T00:00:00Z",
   "credentialSchema": {
     "id": "https://university.example/Credential123-schema-credential",
     "type": "JsonSchemaCredential"
   },
   "credentialStatus": {
     "id": "https://university.example/statuslist#123456",
     "type": "BitstringStatusListEntry",
     "statusPurpose": "revocation",
     "statusListIndex": "123456",
     "statusListCredential": "https://university.example/CredentialStatusList"
   },
   "credentialSubject": {
     "id": "https://www.example.org/persons/pat",
     "name": "Pat",
     "alumniOf": {
       "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
       "name": "Example University"
     }
   },
   simple(99): {
     1: -19,
     3: "did:key:zDnaebqoqws4XdZtTpo9R8gXRkLvCb8ErU46tbYarE7YWcdYz",
     6: h'd5a33ba7ad07870a2b5cf9750b19aae7c678fdc79cc261462ed842a9b8f5a40f10d98a3d42e728dd6b6895023676cc11224927edf8cea210802aa330982a2a03'
   }
}])

On 2025-11-16 11:47, Wolf McNally wrote:
> Hi Ivan, Anders, and VCWG,
> 
> Jumping in because Anders’ note touches directly on work I’m co‑authoring in the IETF CBOR WG.
> 
> By way of introduction: I’m one of the authors of “dCBOR: Deterministic CBOR” (draft-mcnally-deterministic-cbor). I maintain the Rust and Swift dCBOR libraries; other contributors maintain interoperable implementations in TypeScript/JavaScript and other languages.
> 
> https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-15.html

> https://crates.io/crates/dcbor

> 
> Where the CBOR WG actually is
> 
> Anders wrote:
> 
>  > Since the IETF seems to be stuck (2Y+ and counting) with defending current set of tools and techniques primarily targeted at constrained systems, I wonder if maybe the W3C would be a better place for a deterministic encoding specification?
> 
>  From inside the CBOR WG, that’s not what’s happening.
> 
> The WG chairs have deliberately *parked* the earlier CDE document (draft-ietf-cbor-cde) because it did not reach rough consensus. At the same time, they kicked off a new line of work: “CBOR Serialization and Determinism,” which defines a small set of well‑specified serializations (general, ordinary, deterministic) and cleans up the determinism story for RFC 8949 as a whole.
> 
> https://www.ietf.org/archive/id/draft-lundblade-cbor-serialization-03.html

> 
> In parallel, dCBOR is a narrowing profile on top of deterministically encoded CBOR. It doesn’t fork CBOR; it tightens it in the ways you actually need for crypto:
> 
> - definite lengths only
> - preferred serialization only
> - bytewise lexicographic map key order, no duplicate keys
> - numeric reduction (2 and 2.0 encode the same way)
> - a single quiet NaN representation
> - only false/true/null as simple values
> - NFC‑normalized text strings
> - a CBOR tag and CDDL operators so you can declare “this is dCBOR” both in schemas and on the wire
> 
> Although the CBOR WG is still refining the *baseline* definition of deterministic serialization in the new serialization draft, the dCBOR narrowing rules themselves have been stable for quite some time, with both reference and several third-party implementations, including the official CBOR playground:
> 
> https://cbor.me

> 
> The problem space dCBOR is addressing is exactly the one the VC/Data Integrity ecosystem cares about:
> 
> - multi‑language deployments where some environments only have an IEEE‑754 double (JavaScript/TypeScript) and others have various numeric types (e.g., Rust’s i32, f64, etc.)
> - signatures where 10, 10.0, and 10.00 must not give three different hashes
> - avoiding foot‑guns around NaN encodings, undefined vs null, and different Unicode normal forms
> 
> So the same dCBOR data can be signed and verified consistently by a JS wallet, a Rust verifier, and a Swift mobile app.
> 
> At Blockchain Commons we’re already using dCBOR as the deterministic foundation for Gordian Envelope, a dCBOR‑based “smart document” architecture. Envelopes are Merkle-like digest trees, and application‑level data is required to be dCBOR in the leaf positions. So the rules I’m describing here are not theoretical; they’re being exercised today in use cases where security, privacy, and interoperability matter.
> 
> https://datatracker.ietf.org/doc/draft-mcnally-envelope/

> https://developer.blockchaincommons.com/envelope/

> 
> If the WG wants to add CBOR‑based cryptosuites, the natural analogue is *not* for W3C to define its own independent “deterministic CBOR” from scratch. We already have:
> 
> - RFC 8949 defining the CBOR data model and deterministically encoded CBOR
> - an IETF draft that refines the serialization side, including deterministic serialization, for all CBOR
> - an IETF draft (dCBOR) that narrows deterministically encoded CBOR into a stable profile explicitly designed for signatures and hashes.
> 
> That is very similar to what you’ve already done with JCS and RDFC‑1.0 on the JSON side: the byte‑level canonicalization lives in the underlying syntax/serialization community, and VC cryptosuites build on top of that.
> 
> Given all that, I would strongly recommend against W3C defining its own, separate “deterministic CBOR” specification. If the VC WG standardizes a W3C‑local deterministic CBOR that doesn’t match what the CBOR community is converging on, we’ll simply get multiple incompatible “deterministic CBORs” in the wild. That hurts everyone who wants CBOR tools and libraries to be reusable across use cases.
> 
> Conversely, if W3C references the IETF work, you get:
> 
> - a determinism story that’s aligned with the rest of the CBOR ecosystem,
> - reuse of generic tooling,
> - and the ability to feed requirements back into the CBOR WG where the base format is being actively maintained.
> 
> If the WG wants to explore CBOR‑based cryptosuites for VCs, my suggestion would be:
> 
> 1. Keep the data integrity / proof model work where it belongs, in W3C.
> 2. For the underlying binary canonicalization, normatively reference:
>     - RFC 8949 (CBOR)
>     - the CBOR serialization/determinism draft (for the definition of “deterministic serialization”)
>     - draft-mcnally-deterministic-cbor (dCBOR) as the deterministic profile to use for signable CBOR data.
> 3. Define VC cryptosuites that say “serialize the input as dCBOR, then sign with COSE/etc.” in the same spirit as the existing JSON/JCS suites.
> 
> That path keeps the layering clean: CBOR and determinism live where CBOR is being worked on, while the VC WG focuses on the credential and proof model and can rely on stable, well‑reviewed building blocks.
> 
> My calendar link is below if anyone in the W3C would like to schedule some time to go over our work in more detail.
> 
> ~ Wolf
> 
> 🐺
> *Wolf McNally, Lead Researcher*
> *Blockchain Commons
> *
> https://calendly.com/wolfmcnally

> 
>> From: *Anders Rundgren* <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> Date: Fri, Nov 14, 2025 at 2:26 AM
>> Subject: Deterministically Encoded CBOR. Re: Notes on the VCWG Recharering
>> To: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>, W3C VC Working Group <public-vc-wg@w3.org <mailto:public-vc-wg@w3.org>>
>>
>>
>> Hi Ivan et. al.
>>
>> When looking into https://www.w3.org/TR/vc-overview/#cryptosuites <https://www.w3.org/TR/vc-overview/#cryptosuites> I noted two canonicalization schemes, including RFC 8785 that I'm the primary author of.
>>
>> Although RFC 8785 certainly works, it has not gained much traction, which is why I have turned to deterministically encoded CBOR that has does not come with crippling limitations (I-JSON).  Unlike RFC 8785, deterministic encoding would in high-end CBOR tools be the only mode.  Together with Object Oriented APIs, such tools would make cryptographic solutions easier and still more flexible.  Here is a simple example using a tentative Embedded Signature scheme:
>>
>> 1010(["https://example.com/my-signed-object <https://example.com/my-signed-object>", {
>>    1: "Hello signed world!",
>>    2: [4.7, true, h'012345'],
>>    simple(99): {    # Reserved label for the Enveloped Signature container
>>      1: -19,    # COSE Ed25519 signature
>>      4: {       # COSE Ed25519 key container
>>        1: 1,
>>        -1: 6,
>>        -2: h'fe49acf5b92b6e923594f2e83368f680ac924be93cf533aecaf802e37757f8c9'
>>      },
>>      6: h'b023bf2a7bc0b0d679a9e50abe4b03e17adc2d03bed53381602013bef98937a3f236d911caeb0e19ffe6a1e84ffdd1108f126443f06a320e6c1fcf5e9b46c10b'
>>    }
>> }])
>>
>> Compared to JOSE/COSE solutions, deterministically encoded CBOR
>> - enables top-level object-identifiers that are included in the signature
>> - supports header data and payload in clear, signed in one go
>>
>> Since the IETF seems to be stuck (2Y+ and counting) with defending current set of tools and techniques primarily targeted at constrained systems, I wonder if maybe the W3C would be a better place for a deterministic encoding specification?
>>
>> Regards,
>> Anders
>> https://datatracker.ietf.org/meeting/123/materials/slides-123-dispatch-cborcore-json-challenger-00 <https://datatracker.ietf.org/meeting/123/materials/slides-123-dispatch-cborcore-json-challenger-00>
>> https://www.ietf.org/archive/id/draft-rundgren-cbor-core-16.html <https://www.ietf.org/archive/id/draft-rundgren-cbor-core-16.html>
>> https://cyberphone.github.io/doc/defensive-publications/partial-encryption-full-signature.pdf <https://cyberphone.github.io/doc/defensive-publications/partial-encryption-full-signature.pdf>
>>
>>
>> On 2025-11-14 08:31, Ivan Herman wrote:
>> > Hi everyone,
>> >
>> > This mail is from your friendly charter facilitator:-)
>> >
>> > I have just scanned through the rechartering discussion at TPAC[1] and, although there is no formal resolution, the minutes say:
>> >
>> >  > Brent Zundel: No one is saying that we should not recharter. So let's move forward with that.
>> >
>> > The good news is that there is already an unofficial start at [2]: this text was originally drafted by Manu, but I hijacked it from him and added my own grains of salt. I propose we could/should start with that text.
>> >
>> > As you can see, the deliverable section[2] is already quite detailed. Putting aside, for a moment, §3.2: §3.1 includes some specs that are either waiting for completion/implementation or are already on the way. They are obvious. The rest of that section, as well as §3.3, are references to the new specs discussed on the call. The list is not complete: there is no trace of the document referred to by Phil, nor there is a reference to SM3/SM4. Also, the division of new work between those listed in §3.1 (documents that we commit to bring to Rec) and §3.3 (documents that we do not commit as rec yet, but we do it if there is enough maturation during the life of the WG); it is a matter of setting priorities and be careful about commitments. It is up to the WG to get an agreement on that division, i.e., what goes well; the current list was mostly my personal and possibly ill-informed assessment.
>> >
>> > Coming back go recurring item, i.e., everybody's favorites: "class 4" items. The current text in the scope section refers to the maintenance restrictions regarding class 4. That text has been taken over from the current maintenance WG charter. On the other hand, §3.2 lists all current recommendations as deliverables but with new versions (e.g., 2.1) which also implies that they have different short names. It is important to realize that, per process, a new version/short name means that, formally speaking, the document starts fresh on its journey from a first public working draft to a Rec, which means that /no prior restriction on the document is valid/. Put it simply: if we essentially agree on the content of §3.2, then the reference of to class 4 restrictions become moot, and we can blissfully forget about it for now; all changes should happen in the new documents. (The class 4 restrictions are irrelevant for the new documents, like the render methods, for the same reason.)
>> > Bottom line: if we agree with the current structure, then the text in [4] can simply be removed from the charter. (I am happy to make that change right away if we agree.)
>> >
>> > The way forward? We should "officialize" the new charter development as soon as possible. In practice this means that [2] moves to a w3c github repo and we continue the discussions there. In parallel, we start an official strategy team review, and we also notify the AC that we started that work. This means that three parallel reviewing process would happen: the WG, the strategy team (mostly the horizontal reviews) and, possibly, informal comments from the AC. It is in our interest to start that as soon as possible.
>> >
>> > To make that step the WG should agree to move on. This does */not/* mean that the WG members agree on all details of the charter text; it only means that we agree on the general directions in there. Personally, I would love to make that step before the Xmas holidays (knowing that many of you will be concentrating on jet-lag issues combined with Thanksgiving next week and I will be out on family program on the first week of December).
>> >
>> > In the meantime, get the issues/PRs coming!
>> >
>> > Safe journey home for those who were in Kobe (and I am sorry I couldn't be there),
>> >
>> > Cheers
>> >
>> > Ivan
>> >
>> >
>> > [1] https://w3c.github.io/vc-wg/minutes/2025-11-14-f2f.html#429b <https://w3c.github.io/vc-wg/minutes/2025-11-14-f2f.html#429b> <https://w3c.github.io/vc-wg/minutes/2025-11-14-f2f.html#429b <https://w3c.github.io/vc-wg/minutes/2025-11-14-f2f.html#429b>>
>> > [2] https://iherman.github.io/vc-charter-2026/ <https://iherman.github.io/vc-charter-2026/> <https://iherman.github.io/vc-charter-2026/ <https://iherman.github.io/vc-charter-2026/>>
>> > [3] https://iherman.github.io/vc-charter-2026/#deliverables <https://iherman.github.io/vc-charter-2026/#deliverables> <https://iherman.github.io/vc-charter-2026/#deliverables <https://iherman.github.io/vc-charter-2026/#deliverables>>
>> > [4] https://iherman.github.io/vc-charter-2026/#deliverables:~:text=%2C%20ensuring%20that%20no%20Class%204%20changes%20are%20introduced%20except%20as%20needed%20to%20address%20any%20serious%20security%20issues%20that%20arise <https://iherman.github.io/vc-charter-2026/#deliverables:~:text=%2C%20ensuring%20that%20no%20Class%204%20changes%20are%20introduced%20except%20as%20needed%20to%20address%20any%20serious%20security%20issues%20that%20arise>.
>> >
>> > ----
>> > Ivan Herman, W3C
>> > Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>> > mobile: +33 6 52 46 00 43
>> >
>> >
>>
>

Received on Sunday, 16 November 2025 14:43:28 UTC