Re: Canonicalization: VC-JWT is the URDNA2015 of JWTs.

Inline:

On Wed, Dec 14, 2022 at 11:45 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

>
> On 14/12/2022 16:48, Orie Steele wrote:
>
> 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 agree.
>
>
> 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.
>
> I agree that the current transformations are wrong and should be removed.
> Adding a proof to a credential should not alter the contents of the
> credential or the credential metadata. (the same is true for a
> presentation). So we should redefine VC-JWT to say which headers must be
> there, which are optional, and which new claims (vc or vp) must be added to
> the body of the JWT.
>
>
>
> 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,
>
> Agreed, this is the right approach
>
>
> and by promoting the relevant "proof metadata" parameters to the JWT
> header.
>
> The proof metadata parameters should not be defined in the VCDM, but in
> each spec that describes the particular proof format. So there should be no
> concept of "promotion".
>
>
> I agree, I am referring to how "securing the VCDM with JWT", might make
use of this:

https://www.rfc-editor.org/rfc/rfc7519#section-5.3

My understanding is that this can be applied even in the case that the
claims are not present in the payload.

So for example, if you were issuing a CWT Vaccination credential, and the
payload was detached, you could still have `iss` in the header, and not in
the payload.




>
> 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.
>
> totally agree
>
>
>
> 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.
>
> the issuer property is an important property of the credential metadata so
> should remain in the VCDM.
>
> The issuer of the VC-JWT could be an entirely different entity. For example
>
> University X is the issuer of the degree credential to a subject Y.
>
> The VC-JWT is digitally signed by the national university funding council
> (e.g. JISC in the UK) so that in terms of the trust model, all UK degree
> VCs are issued by a single trusted authority. In this case JISC is
> verifying by its own (trusted) procedures that University X is a genuine
> awarder of UK degrees.
>
>
> I agree, I think that having the issuer and `iss` be potentially different
is the kind of useful optionality that we get by having cleaner
separation of concerns.

It's also valuable when building bridges between legacy and modern systems,
such as X.509 and DIDs.

>
> 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.
>
> I disagree. Since JWTs are a standard token format for proofing JSON
> structures, then we can still keep VC-JWTs as a standard format for
> verifiable credentials (but with a re-vamped description of how it works).
>
>
> I think you are agreeing by rephrasing.

If the VCWG profiles JWT properly, we can keep JWT as a supported security
format for a JSON representation.

If the VCWG treats "JWT / CWT as a data model", we close this door for
every other representation.


> ... 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 need a generic model for creating proofs in any format, for turning
> credentials into verifiable credentials, and JWTs will be one of many.
>
>
> I agree, I think we should consider support for data models even outside
of IETF (JOSE/COSE)...

Google has some relevant cryptography for securing protocol buffers and
Apple and Google have also worked on supporting mDoc, which relies on COSE,
but not CWT.

Overfitting to JWT puts the VCWG in a fight between tech giants where we
might end up as collateral damage, (similar to how Bitcoin / ION caused
the DID WG a lot more pain than was probably justified)


>
> 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.
>
> Agreed
>
> Kind regards
>
> David
>
>
> Regards,
>
> OS
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>
>

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

<https://www.transmute.industries>