Canonicalization: VC-JWT is the URDNA2015 of JWTs.

Friends,

I believe that transforming data before and after signing and verifying is
a mistake, and will lead to severe interoperability and security issues.

I believe that VC-JWT is currently implementing a form of canonicalization
/ transformations that, even if it were to be drastically improved,
would still be harmful.

Here are some refreshers on this topic.

- https://en.wikipedia.org/wiki/Canonicalization
-
https://www.cisa.gov/uscert/bsi/articles/knowledge/coding-practices/ensure-input-properly-canonicalized
- https://en.wikipedia.org/wiki/Graph_canonization

Several months ago, I implemented another version of vc-jwt, that attempted
to resolve these issues by replicating claims from the JWT claim set to the
header.

https://github.com/transmute-industries/verifiable-credentials

VC-JWT could be made consistent with the three approaches taken above, by
treating the "credential content" as the claim set,
and by promoting the relevant "proof metadata" parameters to the JWT header.

A future VC-CWT could do the same, but rely on securing a content type of
`application/credential+cbor`.

As I mentioned at TPAC, our goal should be to make the VC Data Model easy
to use and interoperable with W3C and IETF standards.

The working group should avoid "reinventing" IETF standards such as JWT /
CWT.

The working group should also avoid "making IETF / IANA the core data
model"... since that is essentially already an option, that is what you get
when you use a vanilla JWT.

I'd also like to share some of the feedback we got when chartering the
SCITT WG at IETF:

https://mailarchive.ietf.org/arch/msg/scitt/EPz6i2X84TSKkwehRVq6mUpWeaU/

> I think it's important to focus the efforts of this group on work that
can be feasibly accomplished. To that end, I think we ought to make sure
that we shape the protocol and architecture to work with different identity
formats (as needed for different deployments), but not discuss anything
else about how those identities are obtained, validated, etc. As a point of
comparison, TLS basically punts on how X.509 certificates are
authenticated, and I think we ought to do the same thing here.

There are a few points here that are relevant:

1. It's important to focus a WG on what can feasibly be accomplished...
Doing a bad job at "a lot" is way worse than doing a great job at "a
little".
2. W3C Verifiable Credentials are not limited to one identity format, so we
should avoid making assumptions in the core data model that are biased by
or derived from an identity format, for example X.509 or OIDC.

Here is another point of feedback we got, that can be interpreted more
generally as a criticism of JWT and CWT, not specifically VC-JWT.

https://mailarchive.ietf.org/arch/msg/scitt/x6xlPoNvOaS6WfZA1U7Tg6B0-zY/

> In order to validate the signature, with VCs (and JWT in general) you
have to reach into the payload (and decode it) to extract the issuer (the
DID) in order to discover the public key used to sign. In our model, we
separate those layers more strictly, *where the issuer is part of the
signature envelope header* and *you don't have to reach into the payload to
validate the signature*. That's how we stay payload agnostic in SCITT.
Whether that's the best strategy is another question, but it seems cleaner
to do it that way in my opinion.

In my opinion, the approach taken in SCITT is superior to JWT / CWT for
cases where you have a widely diverse set of payloads ( which is the case
for software supply chain artifacts, and I believe is also the case for W3C
Verifiable Credentials ).

There are a lot of similarities between W3C Credentials and software supply
chain artifacts secured with SCITT at IETF.

The most obvious one is that both use cases are meant to cover a very
diverse set of data structures and details, where registering every single
term in say:

https://www.iana.org/assignments/cwt/cwt.xhtml

Is likely not a path to success... because of the need to be clear on
terminology, and the "cost" of registering in CBOR ( where small tags are
worth more ).

It is true, we could register all the *required*  terms from the core data
model, but this would introduce near duplicates into the IETF registries...

I believe this approach would be harmful both to W3C and IETF.

I believe the working group should strongly consider withdrawing the VC-JWT
work item, and instead focus on profiling JWS and COSE Sign1 to secure a
generic JSON data model.

... alternatively, we should consider directly addressing the "long term
vision" for JWT / CWT based verifiable credentials holistically,
potentially even from a green field perspective.

I believe that in the case the WG does produce a *JWT profile*, it would be
good to design it from the ground up,
based on WG consensus, as opposed to continuing to work through the current
version which appears to lack working group consensus on several critical
areas.

We're having a similar greenfield conversation on this issue, so I feel
it's wise for the working group to be consistent in addressing lack of
consensus:

https://github.com/w3c/vc-data-model/issues/947

There does not appear to be consensus on what the data model is, so there
cannot be consensus on how best to secure it.

Potentially this represents an opportunity for the working group to fix
both issues in a superior manner.

Regards,

OS

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>