Should status be a JWT header?

[awoie]

The topic concerns the status JWT claim specifically, but more broadly, we should discuss how to handle security-critical extensions (new claims or headers) not covered by our specification. At the IETF, someone mentioned supporting other status methods (e.g., based on ZKPs) in the future.

Should we allow the issuer to express that a verifier should fail validation if, for example, somebody uses a different status method than the one specified by SD-JWT VC, which is not understood? This is a specific example, but the same applies to other similar security-critical extensions, so we are not purely talking about premature optimization such as in the case of the status method.

1. Before you say that unknown JWT claims and headers should be ignored, and this is a policy validation decision, keep in mind that we already require the processing of the status claim in SD-JWT VC. I believe the same ability might have to be granted to ecosystem-specific status-like JWT claims or headers too.

2. I realize that it is hard to understand what falls into this category of security-critical extensions. In my opinion, it is important that policy decisions are out of the scope of SD-JWT VC. One approach would be to limit it to JWT claims and headers related to validating the Issuer-signed JWT or the KB-JWT. status processing is part of SD-JWT VC validation at the moment.

3. Now, how to express this? We already have a tool in JOSE that allows us to express security-critical extensions that must be understood by verifiers, which is the crit JWT header. But crit is limited to include only JWT headers, not JWT claims. Consequently, a new status method would need to be referenced in the crit header. This also has the consequence that the new header cannot be selectively disclosed and remains sticky. This is an SD-JWT limitation, and I'm not saying we should necessarily change that.

4. This made me think whether the status claim should be put into the JWT header since it would be more consistent with how extensibility might work in the future and because it is actually not wanted that the status is omitted.

5. Alternatively, we could introduce a crit-like JWT claim or define crit as a JWT claim and allow the crit claim to include JWT claims.

Some references below...

SD-JWT does not allow JWT headers to be selectively disclosed.

RFC 7519 says in section 9.2 Validating a JWT:

Verify that the resulting JOSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood.

RFC 7519 says in section 4 JWT claims:

However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.

[bc-pi]

With oauth-wg/draft-ietf-oauth-status-list#90 the -01 draft-ietf-oauth-status-list attempts to allow for supporting other status methods within the status claim. Which somewhat addresses the specific example cited in this issue.

[awoie]

I'm closing this issue since status claim has an extensibility mechanism. The crit topic might be subject to another issue.