Hi Vijay, UI/UX confusion can be avoided if the client handles errors caused by nonce expiration internally and retries the request without reporting the error to the UI/UX layer. It has already been confirmed that clients can be implemented in a way that allows DPoP nonce updates to be performed seamlessly, without disturbing other layers.
Introducing a dedicated endpoint specifically for issuing DPoP nonces would likely require lengthy discussions, similar to those that occurred when a nonce endpoint was introduced in the OpenID for Verifiable Credential Issuance specification, and would require changes not only to client-side implementations but also to server-side implementations. Given that the DPoP specification has already been finalized as an RFC and its implementability has been demonstrated, it is unlikely that the community would be receptive to revisiting and modifying it. I've written a brief blog post that includes pseudocode illustrating request retry logic in the case of DPoP nonce expiration. Please take a look if you're interested. DPoP Nonce https://darutk.medium.com/dpop-nonce-9787b9d276d1 Best Regards, Taka at Authlete On Mon, Jan 12, 2026 at 10:32 PM vj <[email protected]> wrote: > 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] > -- *Takahiko Kawasaki* Co-Founder [email protected] [image: Authlete] authlete.com <https://www.authlete.com/> |Linkedin <https://www.linkedin.com/company/authlete/>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
