Audacious Presentations

[OR13]

Consider a hypothetical API for verifying an SD-JWT with Key Binding.

These examples are inspired by https://github.com/panva/jose/blob/main/docs/functions/jwt_verify.jwtVerify.md

verified = verify<TokenType>(token: string, publicKey, { aud, nonce })

when token contains KBT, there are 2 payloads that could have the aud and nonce claims.

An API that addressed this possible confusion would look like:

verified = verify<TokenType>(token: string, issuerPublicKey, { 
  issuerSignedJwt: { aud, nonce },  // assume cnf: { jwk }
  keyBindingToken: { aud, nonce }   // assume uses cnf
)

The problem is SD-JWT has 2 tokens, so the aud and nonce claims have 2 places to check.

If the idea of matching an expected nonce is confusing, focus only on the audience bit.

The issuer commits a credential to a specific audience, and the holder commits their key binding token to a specific audience.

A verifier would want to check that both values are "acceptable", and "acceptable" could mean the same or different.

This is compounded by aud being allowed to be an array or string.

If an API was exposed that looked like this:

verified = verify<TokenType>(fnard: string, issuerPublicKey, { aud, nonce })
)

I think it would be clear that the aud and nonce were checks on the key binding token, not on the issuer token.

[OR13]

Here is a longer form description of this challenge, with some additional background on who we encountered it, and recommendations for specifications that build on SD-JWT.

https://github.com/transmute-industries/audacious-presentations

[tlodderstedt]

Can you please shed some light on what you would use the 'aud' and 'nonce' in the sd-jwt for and why the verifier should consider them during validation of the presentation? In my opinion, it should look onto aud and nonce in the kb jwt only as those bind the presentation to it (aud) and the respective presentation transaction (nonce).

[OR13]

Can you please shed some light on what you would use the 'aud' and 'nonce' in the sd-jwt for and why the verifier should consider them during validation of the presentation?

• https://learn.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview#validate-claims

I would expect aud and nonce in an SD-JWT (the issuer signed JWT) to have the same semantics as a JWT.

Or I would expect new claims to be introduced to avoid confusion.

In the case of aud being present in the issuer signed JWT, I would expect the verifier to throw an error when the KBT contained A DIFFERENT aud.

Un the case of nonce being present in the issuer signed JWT, I would expect the verifier to throw an error when the KBT contained the SAME nonce.

This would be just forwarding the traditional binding from the 2 party model to the 3 party model.

Having established these basics, I would then specify some example cases for where audience might be different.

For example, when talking to a verifier front end, with a separate relying backend, similar to the RATS architecture:

https://datatracker.ietf.org/doc/html/rfc9334#section-3

[danielfett]

Can you please shed some light on what you would use the 'aud' and 'nonce' in the sd-jwt for and why the verifier should consider them during validation of the presentation?

* https://learn.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview#validate-claims

I would expect aud and nonce in an SD-JWT (the issuer signed JWT) to have the same semantics as a JWT.

Why would these be useful in a multi-use JWT like the issuer-signed part?

[OR13]

issuer -> sd token bound to verifier backend (issuer signed JWT.... aud: verifier-backend)

->

holder -> sd token with key binding bound to verifier front end (key binding token.... aud: verifier-frontend)

[danielfett]

issuer -> sd token bound to verifier backend

My confusion comes from the assumption that in most cases, the issuer wouldn't even know the verifier, let alone a nonce. So I wouldn't expect aud and nonce in the issuer-signed part at all.

[OR13]

So I wouldn't expect aud and nonce in the issuer-signed part at all.

A verifier MUST NOT error, when issuer signed JWT contains aud and nonce claims?

I think this is the default behavior.

In specs that build on SD-JWT, they could say this, if they wanted to further avoid confusion.

Would you recommend application/vc+ld+json and application/vp+ld+json should never have aud and nonce present, and we could add a SHOULD NOT or MUST NOT to the W3C spec.

[Sakurann]

A verifier MUST NOT error, when issuer signed JWT contains aud and nonce claims?

It might, if that's the security posture in that ecosystem/application. but this is not a general rule applicable to all sd-jwts. For example, if access token is an sd-jwt, it is very likely aud will be required (ex. https://datatracker.ietf.org/doc/html/rfc9068#section-2.2).

In specs that build on SD-JWT, they could say this, if they wanted to further avoid confusion.

As you say, this topic probably belongs more in specs such as sd-jwt vc, but for the reasons above, I am not sure there is a one-fits-all-verifiers/use-cases kind of guidance here that should go into an sd-jwt spec. https://drafts.oauth.net/oauth-selective-disclosure-jwt/draft-ietf-oauth-selective-disclosure-jwt.html#section-11.8 is what sd-jwt spec gives as a guidance.

[OR13]

This PR is also relevant: https://github.com/w3c/vc-data-model/pull/1379/files#r1422822545

[OR13]

Related to the IdentityCredential... https://github.com/WICG/identity-credential/issues/7

I assume the nonce / aud for this API is binding to KBT and not the Issuer signed JWT.

Perhaps the best way to close the issue in this repo is to just add some text saying:

"nonce and aud" can be present in the Issuer Signed JWT, and they can be the same or different from the KBT.... its up to the verifier to decide if they tamper protected claims supplied are acceptable and valid per their own policies.

It is recommended that specifications that build on SD-JWT comment on aud and nonce and give guidance related to the usage of SD-JWT.

[bc-pi]

I'm not entirely convinced anything is needed in the SD-JWT draft itself. The Issuer-signed JWT is ultimately just a JWT and can have whatever claims a JWT might have and is subject to the normal JWT validation. https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html#section-5.1-3.6 and https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html#section-8.1-4.6 attempt to convey content and validation respectively. But it's also kind of implicit in the whole thing.

I do think it'd be relatively unusual for the Issuer-signed JWT to have an aud or nonce but, if present, they'd need to be validated per RFC7519 and whatever application profile respectively.