Hi Rifaat,
Yes, we are aware of that work but got the feedback that at least some people were not that happy with the idea of introducing a dedicated/special nonce endpoint in OAuth. As far as I recall that was also the feedback at IETF 119 where this draft was discussed? As a side note: OpenID4VCI also went a similar route and introduced a dedicated nonce endpoint: https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#name-nonce-endpoint. Best Regards, Christian Von: Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> Gesendet: 05 April 2025 21:57 An: Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org> Cc: oauth <oauth@ietf.org> Betreff: [OAUTH-WG] Re: Nonce fetching mechanism for Attestation-Based Client Authentication Giuseppe and Orie have a draft that might be relevant to this discussion, as it describes a dedicated nonce endpoint: https://www.ietf.org/archive/id/draft-demarco-oauth-nonce-endpoint-00.html Regards, Rifaat On Sat, Apr 5, 2025 at 11:16 AM Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org <mailto:40gmx...@dmarc.ietf.org> > wrote: Hi All, We had a discussion about a nonce fetching mechanism for the Attestation-Based Client Authentication draft at the IETF 122 session. Since we didn’t really reach a consensus there, we’d like to continue the discussion on the mailing list. To summarize the problem briefly: The draft specifies a proof of possession that optionally signs over a server-provided nonce to guarantee freshness of said proof of possession. Since we expect this specification to be used in some contexts where creating a PoP might be expensive (e.g., require a user interaction), we were searching for a mechanism where the nonce is not provided via an error (as is the case for DPoP - which would often require the generation of 2 PoPs), but in a way that guarantees that we have a fresh nonce before creating a PoP. We were thinking about either * a dedicated nonce endpoint (within the scope of an AS or RS) * or a mechanism to explicitly ask for a nonce in a request to an existing OAuth endpoint (e.g., the PAR endpoint). After some discussion at OAuth Security Workshop, we proposed to use a dedicated header to signal a request for a new nonce. This could work at any existing OAuth endpoint that wishes to use an attestation-based client authentication. Brian rightfully mentioned that only adding one header field and completely changing the behaviour of said endpoint does not sound like a good idea and proposed to use a different HTTP method. Brian initially proposed HEAD and after some more discussion we ended with an OPTIONS request as the seemingly best idea. The idea as currently document in the draft is to use an OPTIONS request with a specific header field to request a nonce. The current proposal would mean that for a request to a PAR endpoint 1. The client discovers via metadata that the PAR endpoint requires attestation-based client authentication with a nonce 2. The client sends an OPTIONS request: OPTIONS /as/par HTTP/1.1 Host: as.example.com <http://as.example.com> attestation-nonce-request: true 3. The client receives a nonce in the response: HTTP/1.1 200 OK Host: as.example.com <http://as.example.com> attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ 4. The client does the “real” request to the PAR endpoint including the client authentication (via header fields): POST /as/par HTTP/1.1 Host: as.example.com <http://as.example.com> Content-Type: application/x-www-form-urlencoded OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC… OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI… response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org <http://2Fclient.example.org> %2Fcb &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge_method=S256&scope=account-information At the IETF 122 session, Filip voiced concerns that since OPTIONS is used for CORS preflight requests, it would mean that at least for frontend clients, this mechanism would result in several OPTIONS requests. For JavaScript clients, the CORS preflight requests cannot be used or modified and the client would then manually create another OPTIONS request to get the nonce. >From a simple OPTIONS (preflight) and POST requests (normal request to PAR), >we would get to OPTIONS (preflight), OPTIONS (nonce fetch), OPTIONS (preflight), POST requests. We tried to capture those concerns in this issue: https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/102 and would like to pick that discussion up again to find some consensus what the best option would be to for a nonce request. Would people be more comfortable if we instead point to an endpoint that can be used to request a nonce (dedicated endpoint that could for example, be discoverable via metadata), or is it fine to cause more requests and we should move ahead with the current variant based on OPTIONS? Best Regards, Christian, Paul, Tobias _______________________________________________ OAuth mailing list -- oauth@ietf.org <mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org <mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
