Re: [Cbor] Deterministic CBOR as a possible DISPATCH item

[Christopher Allen <[e-mail]>]

On Mon, Mar 6, 2023 at 10:23 AM Laurence Lundblade
<[e-mail]> wrote:
>the blanket statement that “deterministic CBOR encoding is required for (all) signing (in the known world)”.

That is not the statement we desire to make.

That being said, it has some truth under it — I've been struggling
over the past 6 years with challenges in various W3C communities and
WGs about using JWT vs. using a graph format, (the original being
signed RDF, and the latest version being JSON-LD). It has surfaced not
only in the Verifiable Credentials 1.0 standard (ratified in 2019 and
modified in 2022), and the Decentralized Identifier standard (ratified
last year). It continues to be a challenge in the discussions toward a
VC 2.0 spec just this month.

Though the problems in the W3C attempts to compromise between these
approaches are many, one clue to one of the sources of the larger
problem is your statement:

On Mon, Mar 6, 2023 at 10:23 AM Laurence Lundblade
<[e-mail]> wrote:
> The signature scheme here could be anything that can carry a payload

Including the payload causes can cause a host of problems. Keeping
copies of the payload around in its original structure is difficult,
in particular in constrained environments, and also when the verifier
has a different model for the data than the issuer, for instance, one
of the multiple graph data forms vs JWTs lists of pairs.

Another issue is that some business processes require multiple
signers, and this means that the payload is often duplicated many
times as each signer adds to the chain. There are ways around this but
they cause additional challenges.

There are also privacy and correlation issues with keeping payloads
around. Often a signed statement has personal data beyond what is
relevant to the business process. GDPR demands we discard that
information. Beyond the GDPR requirements, the correlation risks that
various parties are advocating to avoid in VC & DIDs require complex
zk-* proposals, such as BBS+ proofs, that also have an impact on
choices when canonicalizing the payload (and the schema).

Another issue with payload is the requirement by some parties to
conform to some form of schema. When should the schema be signed too?
Is it also a correlation risk?

As a co-author and invited expert to these W3C standards, I signed off
on the final specs despite reservations about the canonicalization
compromise proposed by both of the two broadest-deployed solutions,
partly because I could not offer an alternative. Stewing on it for a
couple of years led to Gordian Envelope architecture on top of dCBOR
efforts to minimize those problems.

There have been a number of important parties in the W3C over the last
year that are uncomfortable with the JWT/JSON-LD compromise for
various credentials and certificate formats, and have suggest that the
answer might be in CBOR. Combined with the constraints of dCBOR, I
think them looking to adopt IETF CBOR as a base makes sense (even for
those who don't want to use Gordian Envelope).

Related, when I asked around very early on for a review of the Gordian
Envelope spec among my former IETF colleagues (I was editor of the TLS
1.0 spec in the 90s), the almost universal response was "why not just
use JSON?". It is too hard to explain to them how hard it is to
canonicalize JSON based what happened when W3C tried to integrate JWT.
Almost all of my colleagues also say have never really have looked at
the CBOR spec, and written it off. I think this is unfortunate, as I
believe it will be the underlying data format for privacy-focused
security in the future.

-- Christopher Allen