Deterministically Encoded CBOR. Re: Notes on the VCWG Recharering

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
> 
>

Received on Friday, 14 November 2025 10:26:16 UTC