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

Hi Anders,

Let me see if I understand your proposal correctly. The ECDSA/EDDSA cryptosuites have both a similar structure. Take the credential, which is in JSON (more specifically, JSON-LD). This piece of JSON is canonicalized, resulting in a message that is cryptographically signed; this signature is then "embedded" to the original credential to make it "verifiable". The canonicalization step uses, in the current spec, JCS or RCH. The latter is an RDF based canonicalization, which isn't relevant for this discussion. Your proposal is to add? replace? JCS with a third alternative which is a deterministically encoded CBOR (i.e., a canonical CBOR encoding of the credential). Also, again if my understanding is correct, such a deterministically encoded CBOR is not (yet?) available as a standard (and it seems to be subject to discussions, see the rest of the thread) and your proposal also includes that W3C would specify that version of CBOR, together with its inclusion into the VC securing process (or as a separate specification).

The reason why I got confused is that, later in the thread, you refer to [1] which indeed includes a CBOR encoding of a credential, but explicitly referring to the JOSE-COSE approach to securing VC, which is a different "branch" in our family of specifications (see [2]). JOSE-COSE is, specification-wise, "disjoint" from ECDSA or EDDSA. In other words, it is irrelevant to your original proposal (or my understanding thereof).

If my understanding is indeed correct, it raises a number of issues for me (which are not necessarily technical):

- Experts/editors of the ECDSA/EDDSA suites should tell whether such a CBOR based canonicalization would indeed bring a significant improvement to the current approaches. Frankly, I do not know, it is not in my technical expertise.

- Your proposal includes the creation of a specific W3C standard for the deterministic encoding of CBOR. I believe that would be a real problem. Defining a variant of CBOR has never been the subject of W3C specifications (as far as I know, that is); CBOR has always been in the realm of IETF. Taking up such a work at W3C could be seen as "hijacking" a topic from a sister organization, a move that I do not believe W3C should do. Such a stable reference should come from IETF. Until that is available, I do not think that inclusion of that technology into a W3C specification is acceptable.

- Your proposal means a significant change and/or addition to the ECDSA/EDDSA cryptosuites. Which is fine, but following the work modes of this WG it would require prior incubation, implementation experiences, etc., before it could be accepted as a new work item. It would also require a separate and explicit mention in the upcoming charter (which is the subject of this thread!) and I am not sure whether it is at the level of maturity where we could do that. Having said that, it may be theoretically possible to include it in the section of "tentative" deliverables (see §3.3 of the charter proposal[3]), but even that would require a satisfactory answer to my previous issues.

- My final point is very practical. This email thread is on the important practicalities of the chartering process. I would personally prefer such proposals and discussions to happen on the GitHub repository of the charter[4] rather than as part of this thread. This would help to keep things properly separated, and also provide an easier reference for the upcoming W3C AC vote for the charter when the time comes. Could you move this thread to an issie in the repository? Or, alternatively, is it o.k. if I do this?

Sincerely

Ivan


[1] https://www.w3.org/TR/vc-overview/#complete_example
[2] https://www.w3.org/TR/vc-overview/#overall
[3] https://iherman.github.io/vc-charter-2026/#deliverables
[4] https://github.com/iherman/vc-charter-2026/issues


> On 14 Nov 2025, at 11:26, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Hi Ivan et. al.
> 
> When looking into 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", {
>  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://www.ietf.org/archive/id/draft-rundgren-cbor-core-16.html
> 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>
>> [2] 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>
>> [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.
>> ----
>> Ivan Herman, W3C
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +33 6 52 46 00 43
> 


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43