[OAUTH-WG] Re: Question: Improving DPoP Nonce Provisioning Without ERROR Responses

[Takahiko Kawasaki <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
*Takahiko Kawasaki*
Co-Founder
[e-mail]
[image: Authlete]
authlete.com <https://www.authlete.com/> |Linkedin
<https://www.linkedin.com/company/authlete/>