Nonce Endpoint

[dzarras]

Quoting various parts of the latest Editor's Draft from OpenId 4 VCI.

A Credential Issuer that requires c_nonce values to be incorporated into proofs in the Credential Request MUST offer a Nonce Endpoint using the nonce_endpoint Credential Issuer Metadata parameter.

A request for a nonce is made by sending an HTTP POST request to the URL provided in the nonce_endpoint Credential Issuer Metadata parameter. e.g.:

POST /nonce HTTP/1.1
Host: credential-issuer.example.com
Content-Length: 0

The Credential Issuer provides a nonce value in the HTTP response with a 2xx status code in the message body of the HTTP response using the application/json media. e.g.:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "c_nonce": "wKI4LT17ac15ES9bw8ac4",
  "c_nonce_expires_in": 120
}

The proof(s) in the proof or proofs parameter of a Credential Request MUST incorporate the Credential Issuer Identifier (audience), and optionally a c_nonce value generated by the Credential Issuer to allow the Credential Issuer to detect replay. The initial c_nonce value can be returned in a Nonce Response, or in a Credential Error Response. To validate a key proof, the Credential Issuer MUST ensure among others that if the server had previously provided a c_nonce, the nonce in the key proof matches the server-provided c_nonce value.

Credential Response can be immediate or deferred and can contain one or more Credentials with the same Credential Configuration and Credential Dataset depending on the Credential Request. Credential response MAY contain a c_nonce parameter containing a nonce to be used to create a proof of possession of key material when requesting a Credential. When received, the Wallet MUST use this nonce value for its subsequent Credential Requests until the Credential Issuer provides a fresh nonce.

For errors related to the Credential Request's proof of possession, the error code invalid_proof is to be used. This error code indicates the proof or proofs parameter in the Credential Request is invalid: (1) if both fields are missing, or (2) both are present simultaneously, or (3) one of the provided key proofs is invalid, or (4) if a c_nonce was previously provided and at least one of the key proofs is not linked to a valid c_nonce value.

The Credential Issuer MAY provide the Client with a c_nonce in a Credential Error Response using invalid_proof error code if the Credential Issuer Metadata contains proof_types_supported indicating a key proof is required for the requested Credential. Depending on the Credential Issuer policy, this occurs if they receive a Credential Request without a c_nonce or with an invalid c_nonce value included in the proof(s) in the proof or proofs parameter.

If the Credential Issuer Metadata contains a nonce_endpoint and a proof_types_supported indicating a key proof is required for the requested Credential and the Client does not have a valid c_nonce, the Client MUST obtain a c_nonce value from the nonce_endpoint and send a Credential Request that contains a proof or proofs parameter that includes a c_nonce value. It is the Credential Issuer policy whether a c_nonce value is required in the key proofs.

If the Client received a c_nonce, the c_nonce value MUST be incorporated in the respective parameter in the proof or proofs object in a Credential Request.

Notes/Considerations

1. A Credential Issuer that requires c_nonce values to be incorporated in proofs, MUST provide a Nonce Endpoint.
2. Nonce Endpoint is UNPROTECTED. As a result Nonce values generated by the Nonce Endpoint cannot be bound to a specific Access Token. This is contrary to the Security Considerations provided by the specification to avoid Proof Replay attacks.
3. Α Credential Issuer MAY provide the Client with a c_nonce value in a Credential Error Response using invalid_proof error code. If no c_nonce value is provided then the Client must use the Nonce Endpoint to acquire a new c_nonce value.
4. A Credential Issuer MAY provide the Client with a refreshed c_nonce value in a Credential Response using c_nonce and c_nonce_expires_in parameters.
5. Interactions with the Credential Issuer increase. For instance, what does it mean for a Client to receive a Credential Response that doesn't contain a c_nonce parameter? Is the previous c_nonce value still active, or does the Client have to use the Nonce Endpoint to verify the validity of the c_nonce value it currently has?
6. If a Client makes multiple calls to the Nonce Endpoint, how many unique values should the Nonce Endpoint return? Does it return a new Nonce value with each invocation? Given that Nonce values cannot be bound to an Access Token, the Nonce Endpoint doesn't have the ability to revoke previously issued Nonce values.
7. Can a Client include different c_nonce values in each Proof of Possession of the proofs parameter of a Credential Request? Does a Client have to use the same c_nonce value for all the proofs provided in a Credential Request?

Overall the introduction of the Nonce Endpoint seems to further complicate interactions with the Credential Issuer. It seems that a Client must always check the Nonce Endpoint to verify whether the c_nonce value it has is still valid, before any other interaction with the Credential Issuer. Previously if a Client had to refresh its c_nonce value, a Credential Error Response would always contain the refreshed c_nonce value.

[babisRoutis]

@dzarras Please add a milestone for draft 15

[babisRoutis]

1. A Credential Issuer that requires `c_nonce` values to be incorporated in proofs, MUST provide a Nonce Endpoint.

Two key points

• a credential issuer may or may not require proofs for a given credential configuration
• if proofs are required, credential issuer may or may not require c_nonce

2. Nonce Endpoint is UNPROTECTED. As a result Nonce values generated by the Nonce Endpoint cannot be bound to a specific Access Token. This is contrary to the Security Considerations provided by the specification to avoid Proof
   Replay attacks.

Perhaps not. Check here

3. Α Credential Issuer MAY provide the Client with a `c_nonce` value in a Credential Error Response using
   `invalid_proof` error code. If no `c_nonce` value is provided then the Client must use the Nonce Endpoint to acquire a
   new `c_nonce` value.

4. A Credential Issuer MAY provide the Client with a refreshed `c_nonce` value in a Credential Response using
   `c_nonce` and `c_nonce_expires_in` parameters.

5. Interactions with the Credential Issuer increase. For instance, what does it mean for a Client to receive a
   Credential Response that doesn't contain a `c_nonce` parameter? Is the previous `c_nonce` value still active, or does
   the Client have to use the Nonce Endpoint to verify the validity of the `c_nonce` value it currently has?

6. If a Client makes multiple calls to the Nonce Endpoint, how many unique values should the Nonce Endpoint return? Does it return a new Nonce value with each invocation? Given that Nonce values cannot be bound to an Access Token, the Nonce Endpoint doesn't have the ability to revoke previously issued Nonce values.

• The nonce endpoint returns a unique / new value with every call.
• A Nonce is not revocable.
• Nonce values provided by the new endpoint doesn't have to be stored by their issuer. Please check here where a proposal for self-authenticating nonce values is made.

7. Can a Client include different `c_nonce` values in each Proof of Possession of the `proofs` parameter of a Credential Request? Does a Client have to use the same `c_nonce` value for all the `proofs` provided in a Credential Request?

A credential request can use at most a single c_nonce, regardless if the request is for a single credential or a batch