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?