Hello OAuth Working Group,

I’m currently implementing DPoP (RFC 9449) and have encountered a practical
UX challenge related to the way DPoP nonces are issued by authorization
servers.

Per the current standard, when a client sends a DPoP request that requires
a nonce, the authorization server responds with a 400 Bad Request (or 401
Unauthorized from a resource server) including a DPoP-Nonce header and a
use_dpop_nonce error code. The client is then expected to retry the request
with the supplied nonce in the DPoP proof’s nonce claim. IETF
<https://www.ietf.org/rfc/rfc9449.html?utm_source=chatgpt.com>

In many implementations today, this leads to visible error responses in
client logs or user interfaces before the retry occurs. This behavior —
although correct per the spec — sometimes confuses customers or developers
because an error response is served before the nonce exchange completes.

*Questions / Suggestions:*

   1.

   *Is there any recommended best practice for provisioning a nonce outside
   of a 400/401 error response?*
   For example, could a dedicated endpoint be defined for clients to fetch
   the current nonce from the authorization server prior to a token or
   resource request?
   2.

   While the spec allows nonces to be supplied in a 200 OK response header
   instead of via challenge responses, that behavior is optional. If used
   consistently, it could avoid initial error responses entirely. Are there
   guidelines or recommendations on when servers should prefer this 200 OK
   mechanism? IETF
   <https://www.ietf.org/rfc/rfc9449.html?utm_source=chatgpt.com>
   3.

   If introducing an endpoint solely to serve a current nonce is *not*
   advisable for security or protocol correctness reasons, could the group
   clarify the intended UX pattern for nonces in high-frequency or browser
   environments?

We’d appreciate any clarification or guidance the working group can provide.
-- 
Thanks & Regards,
Vijay
Programmer | Cyber Security
Email: [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to