Define and add crit JWT claim to issuer-signed JWT

[awoie]

To make sure that implementers can provide proper tooling to allow others to develop use cases, without prior knowledge of future security-related JWT claims, we should use crit claim to allow an issuer to indicate which of the JWT claims a verifier has to process or validate.

[danielfett]

I think this makes sense. I'd like to hear what @bc-pi thinks about this.

(Internal note: As discussed, we need to note that crit affects the technical validity of the token, not any business-process related evaluation. E.g., you can't define a field stateless_person, define it as crit and expect the receiver to do useful things with this.)

[bc-pi]

For better or worse crit is defined as a JOSE header parameter https://www.rfc-editor.org/rfc/rfc7519#section-2 and not a JWT claim. For something like a crit JWT claim to be legitimately useful and relied upon, it really needed to have been defined in the base JWT spec. Defining it after the fact leaves a paradoxical situation where the extension claim has to be understood and processed in order to know what extension claims have to be understood and processed. I'm not convinced that defining a critical JWT claim at this point and in this document is a good idea.

Off hand, this feels like the kind of thing (what claims are required and what meaning they have security related or otherwise) that would be a part of a particular 'type' (or whatever it might end up being named) definition.

Or future security-related things could also be placed in the JWS header and use the crit header to indicate their criticality.

[danielfett]

Thanks! It seems that for now, we should rely on the types to define such things.

[awoie]

Agree with @bc-pi, verifiers will need to look at the particular type anyways and all possible "special " attributes that are used within the type.

[bc-pi]

TIL that OpenID Federation has aspirations for a crit JWT claim https://bitbucket.org/openid/connect/pull-requests/682 which I think is similarly problematic.

[selfissued]

I agree with Brian that it's too late to define a crit claim that everyone must understand for all JWTs. That said, it's not too late to define one that particular profiles of JWTs can opt into using and requiring support for. That's what the Federation definition does.

[selfissued]

There's a nuance missing in the discussion above. Looking at the typ to determine the profile, then using the profile will tell you what the claims are specified for use in that kind of JWT. But if the profile wants to enable extensibility with must-be-understood claims after the profile is defined, the profile needs to include a mandatory-to-understand crit claim.

[awoie]

I also added some thoughts in this issue #192 since this one is closed.

I like the idea of having something like crit but specific to SD-JWT VC triggered by the typ. Assuming we get consensus on this mechanism, my understanding is now that we would need to define a new claim with similar semantic as crit but for JWT claims.