Hi WG,
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
<https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/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
o usage of the endpoint is optional, alternative being jti
* we would add implementation and security consideration to compare
three approaches
o
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
o
2. challenge/nonce endpoint with self-contained nonces
containing server-chosen timestamp -> this provides
freshness but no replay protection within the accepted time
window
o
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? Please discuss here or in the Github issue:
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/110
Best regards,
Paul+Christian
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
