Definitively distinguishing SD-JWT

[andrewwhitehead]

Considering an SD-JWT-aware processor that also processes non-SD JWTs, there seem to be multiple ways to determine whether SD processing should be performed and I wonder if this needs clarification.

• If the typ contains an sd-jwt component, ie. it is SD-JWT or myapp+sd-jwt+json or application/sd-jwt, then I believe the credential MUST be assumed to be SD-JWT. In the compact serialization, should the absence of a tilde make the input invalid?

• If the compact serialization contains a tilde and the typ is ambiguous/unknown: should SD-JWT be assumed? What if the prover adds a tilde to the end of a traditional JWT? In that case it is unlikely that the JWT contains _sd, _sd_alg, or ... claims, but not impossible either.

Apologies if this is covered and I missed it.

[Sakurann]

If you are trying to separate normal JWT with SD-JWT,

• look at the factors external to the credential, such as HTTP content-type, or credential format identifiers in the OpenID4VC protocols to distinguish
• if no such factors exist, whether there is a tilde after first three dot-separated strings is a way to distinguish

we would not recommend using typ JOSE header because by the time you get it, you need to have already done JWT or SD-JWT specific processing

[Sakurann]

If you are talking about distinguishing SD-JWT with and without selectively disclosable claims, those do not need to be separated because they can be processed using the same processor. (I wasn't sure what exactly you meant by non-SD JWTs so to be sure)

[andrewwhitehead]

I spoke to Torsten a bit about this yesterday.

I think my issue is mainly with a hostile prover, who does not have to send the correct content-type (if there is a place to put one) and can change the token. If the holder strips off any disclosures, the trailing tilde, and optional KB-JWT, the result is still a valid JWT and the signature would verify, although the token might have some strange claims such as _sd and {"...": hash}. Conversely, the holder could take a traditional JWT and add a tilde, potentially triggering SD-JWT processing (although I can't see any concrete risk here).

For me, the best way to resolve this ambiguity would be to modify the signing procedure for an SD-JWT such that the signature would NOT match that of a corresponding JWT, likely by adding something to the plaintext, thus requiring the verifier to be informed about which type of token they are processing.

Otherwise, I believe that adding a standard claim in the SD-JWT protected header could help prevent confusion ("_sd": true for example).

[Sakurann]

hostile prover cannot change the typ value in the header of an issuer-signed JWT, so if the issuer issued it with "typ": "sd+jwt", the verifier will be able to detect it.