Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove c_nonce and c_nonce_expires_in from credential endpoint response #404

Merged
merged 8 commits into from
Nov 5, 2024
4 changes: 1 addition & 3 deletions examples/credential_response_jwt_vc_json.txt
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,5 @@ Cache-Control: no-store
MSJ9.z5vgMTK1nfizNCg5N-niCOL3WUIAL7nXy-nGhDZYO_-PNGeE-0djCpW
AMH8fD8eWSID5PfkPBYkx_dfLJnQ7NA"
}
],
"c_nonce": "fGFF7UkhLa",
"c_nonce_expires_in": 86400
]
}
4 changes: 1 addition & 3 deletions examples/credential_response_ldp_vc.txt
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,5 @@ Cache-Control: no-store
}
}
}
],
"c_nonce": "fGFF7UkhLa",
"c_nonce_expires_in": 86400
]
}
40 changes: 4 additions & 36 deletions openid-4-verifiable-credential-issuance-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -812,7 +812,7 @@ The `proof_type` parameter is an extension point that enables the use of differe

The proof(s) in the `proof` or `proofs` parameter 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 way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element.

The initial `c_nonce` value can be returned in a Nonce Response as defined in (#nonce-response), or in a Credential Error Response as defined in (#issuer-provided-nonce).
The initial `c_nonce` value can be returned in a Nonce Response as defined in (#nonce-response).
paulbastian marked this conversation as resolved.
Show resolved Hide resolved

Additional Credential Request parameters MAY be defined and used.
The Credential Issuer MUST ignore any unrecognized parameters.
Expand Down Expand Up @@ -1016,8 +1016,6 @@ The following parameters are used in the JSON-encoded Credential Response body:
* `credentials`: OPTIONAL. Contains an array of one or more issued Credentials. It MUST NOT be used if the `transaction_id` parameter is present. The elements of the array MUST be objects. This specification defines the following parameters to be used inside this object:
* `credential`: REQUIRED. Contains one issued Credential. It MAY be a string or an object, depending on the Credential Format. See Appendix A for the Credential Format-specific encoding requirements.
* `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet.
* `c_nonce`: OPTIONAL. String containing a nonce to be used to create a proof of possession of key material when requesting a Credential (see (#credential-request)). When received, the Wallet MUST use this nonce value for its subsequent Credential Requests until the Credential Issuer provides a fresh nonce.
* `c_nonce_expires_in`: OPTIONAL. Number denoting the lifetime in seconds of the `c_nonce`.
* `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present.

The format of the Credential in the Credential Response is determined by the value of the `format` parameter specified in the Credential Request.
Expand All @@ -1041,9 +1039,7 @@ Cache-Control: no-store
{
"credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
}
],
"c_nonce": "fGFF7UkhLa",
"c_nonce_expires_in": 86400
]
}
```

Expand All @@ -1062,8 +1058,6 @@ Content-Type: application/json
"credential": "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy"
}
],
"c_nonce": "fGFF7UkhLa",
"c_nonce_expires_in": 86400,
"notification_id": "3fwe98js"
}
```
Expand All @@ -1076,9 +1070,7 @@ Content-Type: application/json
Cache-Control: no-store

{
"transaction_id": "8xLOxBtZp8",
"c_nonce": "wlbQc6pCJp",
"c_nonce_expires_in": 86400
"transaction_id": "8xLOxBtZp8"
}
```

Expand All @@ -1100,7 +1092,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b
* `invalid_credential_request`: The Credential Request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, or is otherwise malformed.
* `unsupported_credential_type`: Requested Credential type is not supported.
* `unsupported_credential_format`: Requested Credential Format is not supported.
* `invalid_proof`: 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 (refer to (#issuer-provided-nonce)).
* `invalid_proof`: 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 (refer to (#nonce-response)).
mickrau marked this conversation as resolved.
Show resolved Hide resolved
* `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters.
* `credential_request_denied`: The Credential Request has not been accepted by the Credential Issuer.
* `error_description`: OPTIONAL. The `error_description` parameter MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the Client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`.
Expand All @@ -1119,30 +1111,6 @@ Cache-Control: no-store
}
```

### Credential Issuer Provided Nonce {#issuer-provided-nonce}

The Credential Issuer MAY provide the Client with a `c_nonce` as defined in (#credential-response) in a Credential Error Response using `invalid_proof` error code defined in (#credential-error-response) 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 or not 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.

Below is a non-normative example of a Credential Response when the Credential Issuer is requesting a Wallet to provide in a subsequent Credential Request a key proof that is bound to a `c_nonce`:

```
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
"error": "invalid_proof"
"error_description":
"Credential Issuer requires key proof to be bound to a Credential Issuer provided nonce.",
"c_nonce": "8YE9hCnyV2",
"c_nonce_expires_in": 86400
}
```

# Deferred Credential Endpoint {#deferred-credential-issuance}

This endpoint is used to issue one or more Credentials previously requested at the Credential Endpoint in cases where the Credential Issuer was not able to immediately issue this Credential. Support for this endpoint is OPTIONAL.
Expand Down