Evolution of the nonce fetching

[paulbastian]

After many discussions over the last months and especially OSW 2025, in -05 we introduced explicit nonce fetching using HTTP OPTIONS. On the mailing list and IETF 122 we got feedback that this may not be the best approach (#102), so here is another proposal how to advance the mechanisms for explicit nonce fetching in this draft:

• remove the HTTP OPTIONS mechanism
• introduce a new, dedicated nonce/challenge endpoint, that enables explicit nonce/challenge fetching
  • usage of the endpoint is optional, alternative being jti
• we would add implementation and security consideration to compare three approaches
  • 1. jti approach (client chosen random), AS needs to cache seen jti values in a sliding time window for replay protection -> this provides freshness and replay protection
  • 2. challenge/nonce endpoint with self-contained nonces containing server-chosen timestamp -> this provides freshness but no replay protection within the accepted time window
  • 3. challenge/nonce endpoint with some kind of binding to the session between AS and client -> this provides freshness and replay protection

The motivation behind this is that other approaches seem complicated and did not lead us to success, while OpenID4VCI already defines a nonce endpoint for the Credential Issuer. Therefore AS nonce endpoint may fit nicely to this concept with little overhead.

Moreover, this would enable us to optionally provide DPoP nonces over this new nonce/challenge endpoint, which seem to present significant challenges for some architectures.

WDYT?

[tplooker]

Generally supportive of this proposal, I have some seperate questions about the issue with the HTTP OPTIONS mechanism we have currently which I've documented in #102 but all other aspects of the proposal im aligned with.

[mcguinness]

Sharing more as FYI as most folks probably have not seen but there is example in production today of new challenge endpoint with Apple SSO Platform extension.

IdPs need to implement this endpoint so Apple devices can sign an assertion with the nonce and registered device key (https://developer.apple.com/documentation/authenticationservices/authentication-process) for login to the Apple Device

[c2bo]

Thanks for the link @mcguinness! From a quick google search, it seems that the approach is also in use by Microsoft/Entra (so not only Apple)?

They overload the token endpoint with a new grant_type called "srv_challenge" to request a challenge which would be an alternative to the http method currently proposed and very similar to our first proposal (which was header based instead of a grant type) from what I understand.
edit: I guess overload is not the fully correct description - it would also allow for a dedicated endpoint, so both options are covered by that (overload existing endpoint and provide in different endpoint)

That would leave us with these general options seen/discussed so far:

• no server provided challenge - use JTI
• server provided challenge by overloading existing endpoints
  • grant_type=srv_challenge
  • header (but people didn't like this one, so maybe let's ignore it?)
  • http method (there was also pushback, so maybe also ignore?)
• server provided challenge by different endpoint

IMHO, we should support at least 2 of those: JTI and some kind of server provided challenge. My current feeling would be that it might be reasonable to allow for all 3 models (since they also have differences in terms of deployment)?

[c2bo]

I am not sure if I really like overloading the grant_type, but I guess that is a different discussion (and it also seems better than a header)