Hi Watson,
Sorry for the late response. I would fully agree that challenge would be the
better term here and there is a bit of ambiguity for the term nonce in OAuth
imho.
While a nonce generally speaking would usually mean a random input, in the
context of OAuth, it is afaik interpreted as an opaque challenge that should be
sufficiently random (so it cannot be guessed). A nonce in this context could
just be a server-signed/HMACed JWT containing things like the server time when
the nonce was generated for which the term challenge would probably be a better
fit - If I recall correctly, that behaviour/usage is also explained in the DPoP
spec.
See current IANA definition:
Claim Name: nonce
Claim Description: Value used to associate a Client session with an ID Token
(MAY also be used for nonce values in other applications of JWTs)
Best Regards,
Christian
From: <>Watson Ladd <watsonbl...@gmail.com>
Date: Sunday, 6. April 2025 at 02:27
To: Christian Bormann <chris.borm...@gmx.de>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Nonce fetching mechanism for Attestation-Based Client
Authentication
On Sat, Apr 5, 2025, 8:17 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.
I alas haven't had a chance to watch all the discussion even now so forgive me
if I'm being redundant. What you want is not a nonce for a few reasons:
1:nonces can be predictable. Ideally we'd bind the proof of possession to the
one who needs it to prevent an attacker relaying the request or issuing one for
the same predicted value.
2: we probably want some degree of licenses
3: counting is hard in big systems
All of this makes me think we just want to sign a server provided challenge
with some rules on construction rather than specifically a nonce.
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
The client discovers via metadata that the PAR endpoint requires
attestation-based client authentication with a nonce
The client sends an OPTIONS request:
OPTIONS /as/par HTTP/1.1
Host: as.example.com <http://as.example.com/>
attestation-nonce-request: true
The client receives a nonce in the response:
HTTP/1.1 200 OK
Host: as.example.com <http://as.example.com/>
attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ
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
