Protect the nonce endpoint

[andprian]

Having this endpoint unprotected is not a good idea:

• If the Issuer returns the same nonce every time this makes the nonce publicly available to anyone, which makes it completely useless. Moreover, clause 7.2 states that "This value MUST be unpredictable." so I am not sure if it is therefore required to have a new nonce with every call.
• If the Issuer returns a different nonce with every call this makes it an attack vector because the nonce database would grow continuously and the service could be vulnerable to a DoS. This would also make it difficult to search for a nonce when receiving it in the credential request.

This endpoint should be protected with the access token that the wallet just obtained, just like the credential endpoint. Thus, the nonce would be also linked to a specific wallet which would make it simple for the Issuer to match the nonce when receiving it in the subsequent credential request.

Also, it would make more sense for this endpoint to implement a GET method instead of a POST.

[c2bo]

There was some discussion on this in the prior issue/PR: #404

[bc-pi]

Also some discussion in #381 - in particular this part #381 (comment) about GET vs POST and #381 (comment) on protection of the endpoint.

[oriolcanades]

My 2 cents. I checked the comments in #381 and the current OID4VCI draft. If the only way to use a nonce endpoint—where a fresh c_nonce value can be obtained—is for proof of possession of key material in a subsequent request to the Credential Endpoint, and this call is always made after the Token request, then why don’t we secure the nonce endpoint? Are there other use cases where we need a nonce before acquiring the Token?

[andprian]

@oriolcanades I do not see the need to ask for a nonce if you don't have a previously obtained access token.

[Fethbita]

I also agree that the nonce endpoint must be protected. What was this WG (#381 (comment)) discussion about?

[Sakurann]

WG discussion:

• nonce endpoint does not mean an exponentially growing nonce data bases (mechanisms can be self-contained nonces or fully fledged database or etc.)
• nonce is used only for the freshness according to the requirement to the servers (which can be very strict) as opposed to being unique to a session. better name would have been "challenge" (probably ship has sailed.. )
• can't protect nonce endpoint with a sender-constrained access token with DPoP since that would require a nonce
• for the above reasons, rough consensus is still that there is no need to protect this endpoint
  closing in a week unless objections

[andprian]

I am not sure I understand the reasons described.

nonce endpoint does not mean an exponentially growing nonce data bases (mechanisms can be self-contained nonces or fully fledged database or etc.)

How would your nonce database keep a reasonable size with self-contained nonces?

nonce is used only for the freshness according to the requirement to the servers (which can be very strict) as opposed to being unique to a session. better name would have been "challenge" (probably ship has sailed.. )

Do you mean the purpose of the nonce is not to prevent reply attacks?

can't protect nonce endpoint with a sender-constrained access token with DPoP since that would require a nonce

Sender-constrained access tokens are not mandatory in all cases, are they? Besides, the nonce is marked as optional in a DPoP in RFC 9449

Overall, do you agree we should return a different nonce for each call to the endpoint?

[jogu]

I am not sure I understand the reasons described.

nonce endpoint does not mean an exponentially growing nonce data bases (mechanisms can be self-contained nonces or fully fledged database or etc.)

How would your nonce database keep a reasonable size with self-contained nonces?

Why would you need a nonce database if you have self-contained nonces? The point of self-contained nonces is that you don't need to record them in a database :)

nonce is used only for the freshness according to the requirement to the servers (which can be very strict) as opposed to being unique to a session. better name would have been "challenge" (probably ship has sailed.. )

Do you mean the purpose of the nonce is not to prevent reply attacks?

This depends on your definition of a replay attack. The nonce at least limits the time window for replay attacks. The requirement for freshness means that, e.g., an attacker cannot pre-generate key proofs.

can't protect nonce endpoint with a sender-constrained access token with DPoP since that would require a nonce

Sender-constrained access tokens are not mandatory in all cases, are they? Besides, the nonce is marked as optional in a DPoP in RFC 9449

Overall, do you agree we should return a different nonce for each call to the endpoint?

This is not agreed. You can return a different nonce if you want, but it is fine to return the same nonce, and there is already text in the spec ( https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-12.5 ) that I hope makes clear that nonces are not single use:

A Wallet can continue using a given nonce until it either expires or is rejected by the Credential Issuer. The Credential Issuer determines how frequently a particular nonce can be used. Servers MUST establish a clear policy on whether the same key proof can be reused and for how long, or if each Credential Request requires a new key proof.

I agree that the "unpredictable" point you raise in your initial comment is unclear, I opened a PR to add various clarity about nonces, including trying to clarify that they're a challenge rather than a nonce as was discussed in #496 : #525

[andprian]

I have to admit that I do not understand the strategy here. The spec does not mandate any constraint for the nonce. Currently it is allowed to be a fixed value, publicly available to everyone calling the endpoint and possibly for an unlimited period of time. Then why have a nonce in the first place?