Explain motivation for a nonce endpoint

[randomstuff]

After reading the document, it's not clear what is the use of this nonce and when and why you would need to request a nonce from the nonce endpoint.

The abstract references RFC6749 but the only mention of a nonce in RFC6749 is a non-normative example about an expired OAuth-HTTP-MAC draft.

[peppelinux]

This draft proposes creating a general-purpose endpoint to issue nonces for various purposes and audiences. This endpoint could be accessible to both public users and internal domains of the AS or other entities. This decision depends on how the nonce endpoints are integrated into the IT infrastructure.

[randomstuff]

Yes, but maybe an example of a precise use case would make it clear. Why wouldn't I use a locally generated 160 bit random number using a secure random source? Why would the AS need to encrypt (sign? MAC?) the nonce instead of generating a 160 bit random number using a secure random source? (Why is it not a /dev/urandom as a service ?) If the AS is encrypted (signed? MACed?) does anyone need to decrypt (check the signature? check this MAC?) and how?

[peppelinux]

good points that produces good clarifications, thank you. I put some sparse notes to keep the conversation going, therefore we can decide if something interesting can be further expandend and included in the current specs

• locally generated is not a microservice resource, the purpose of this specification is to create a general purpose endpoint
• encrypted to allow the AS to inspect a payload and recognize if it is the issuer. There can be also audiences and scopes within the payload, making the nonce artifact more powerful for interop purposes
• the one that decrypt the nonce is the one that shares the same private key of the nonce issuer, therefore these two entities/endpoints should be hosted in the same domain (and/or be part of the same cluster). There are cases that using appropriate audiences and scopes within the nonce payload we are able to prevent replay attacks using a local storage, without a shared storage between many microservice. This scales better because makes a stateless layer for the nonce validation and reduces the burden of the shared storage

the purpose of this specification is to have conversation like this one and also evaluate the differences between local/shared storage, stateless/statefull approces and jti vs the nonce in general

[peppelinux]

another example about the scope of this individual draft is to map the intrinsic value of the nonce, and all the assumptions we have/had about it

in particular, there are some evidence around the specs, that show that the nonce could be used more than once.

From this evidence I'm considering the existence of the "Nonce Paradox" that demonstrates that the nonce, that per definition means "No more than Once" would became a Monce establishing that it could be used "More than once".

"The Monce Paradox", therefore, should be further explored in IETF, OpenID foundation, ISO and any other standardization body, where the constraints of uniqueness of the nonce appears to be broken.

here, for instance, I want to report the definition of nonce taken from the NIST's glossary
https://csrc.nist.gov/glossary/term/nonce

Specifications Defining Or Referencing Nonces

• RFC 6749 (The OAuth 2.0 Authorization Framework)
• https://datatracker.ietf.org/doc/html/rfc6704
• https://datatracker.ietf.org/doc/rfc8954/
• https://datatracker.ietf.org/doc/rfc3310/ (with some limitations)
• rfc3261

Specifications Apparently Defining Monces

• OpenID4VCI, see: clarifications about the uniqueness of the c_nonce value openid/OpenID4VCI#325 (comment)