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> 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 > > attestation-nonce-request: true > > 3. The client receives a nonce in the response: > > HTTP/1.1 200 OK > > Host: 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 > > 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%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 > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
