Merge branch 'main' into pb/keyattestation

examples/credential_request_iso_mdl.json

@@ -0,0 +1,8 @@
+{
+  "format": "mso_mdoc",
+  "doctype": "org.iso.18013.5.1.mDL",
+  "proof": {
+    "proof_type": "jwt",
+    "jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM"
+  }
+}

examples/credential_response_jwt_vc_json.txt

@@ -39,7 +39,5 @@ Cache-Control: no-store
       nQIKAIuwQIbg37dwlNr8D6_2YUQtDTVQCq-ZsjcXxHagGC_VIZtd7RpR8OvB
       zTBHVwrBRD-_RzoV2Ofg"
     }
-  ],
-  "c_nonce": "fGFF7UkhLa",
-  "c_nonce_expires_in": 86400
+  ]
 }

examples/credential_response_ldp_vc.txt

@@ -34,7 +34,5 @@ Cache-Control: no-store
         }
       }
     }
-  ],
-  "c_nonce": "fGFF7UkhLa",
-  "c_nonce_expires_in": 86400
+  ]
 }

openid-4-verifiable-credential-issuance-1_0.md

@@ -730,7 +730,7 @@ Cache-Control: no-store
 
 # Nonce Endpoint {#nonce-endpoint}
 
-This endpoint allows a Client to acquire a fresh `c_nonce` value without the overhead of a full Credential Request. A Credential Issuer that requires `c_nonce` values to be incorporated into proofs in the Credential Request (see (#credential-request)) MUST offer a Nonce Endpoint.
+This endpoint allows a Client to acquire a fresh `c_nonce` value. A Credential Issuer that requires `c_nonce` values to be incorporated into proofs in the Credential Request (see (#credential-request)) MUST offer a Nonce Endpoint.
 
 The `nonce_endpoint` Credential Issuer Metadata parameter, as defined in (#credential-issuer-parameters), contains the URL of the Credential Issuer's Nonce Endpoint.
 
@@ -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 `c_nonce` value can be retrieved from the Nonce Endpoint as defined in (#nonce-endpoint).
 
 Additional Credential Request parameters MAY be defined and used.
 The Credential Issuer MUST ignore any unrecognized parameters.
@@ -1041,8 +1041,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.
@@ -1066,9 +1064,7 @@ Cache-Control: no-store
     {
       "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
     }
-  ],
-  "c_nonce": "fGFF7UkhLa",
-  "c_nonce_expires_in": 86400
+  ]
 }
 ```
 
@@ -1087,8 +1083,6 @@ Content-Type: application/json
       "credential": "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy"
     }
   ],
-  "c_nonce": "fGFF7UkhLa",
-  "c_nonce_expires_in": 86400,
   "notification_id": "3fwe98js"
 }
 ```
@@ -1101,9 +1095,7 @@ Content-Type: application/json
 Cache-Control: no-store
 
 {
-  "transaction_id": "8xLOxBtZp8",
-  "c_nonce": "wlbQc6pCJp",
-  "c_nonce_expires_in": 86400  
+  "transaction_id": "8xLOxBtZp8"
 }
 ```
 
@@ -1125,7 +1117,8 @@ 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 at least one of the key proofs does not contain a `c_nonce` value (refer to (#nonce-response)).
+  * `invalid_nonce`: The `proof` or `proofs` parameter in the Credential Request uses an invalid nonce: at least one of the key proofs contains an invalid `c_nonce` value. The wallet should retrieve a new `c_nonce` value (refer to (#nonce-endpoint)).
   * `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`.
@@ -1144,30 +1137,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.
@@ -2242,12 +2211,11 @@ The following is a non-normative example of an authorization details object with
 
 The following additional parameters are defined for Credential Requests and this Credential Format.  
 
-* `doctype`: REQUIRED when the `format` parameter is present in the Credential Request. It MUST NOT be used otherwise. It is a string as defined in (#server-metadata-mso-mdoc). The Credential issued by the Credential Issuer MUST contain at least the values listed in this claim.
-* `claims`: OPTIONAL. Object as defined in (#server-metadata-mso-mdoc).
+* `doctype`: REQUIRED when the `format` parameter is present in the Credential Request. It MUST NOT be used otherwise. It is a string as defined in (#server-metadata-mso-mdoc).
 
 The following is a non-normative example of a Credential Request with Credential Format `mso_mdoc`:
 
-<{{examples/credential_request_iso_mdl_with_claims.json}}
+<{{examples/credential_request_iso_mdl.json}}
 
 ### Credential Response
 
@@ -2301,7 +2269,6 @@ The following is a non-normative example of an authorization details object with
 The following additional parameters are defined for Credential Requests and this Credential Format.
 
 * `vct`: REQUIRED when the `format` parameter is present in the Credential Request. It MUST NOT be used otherwise. It is a string as defined in (#server-metadata-sd-jwt-vc). This claim contains the type value of the Credential that the Wallet requests the Credential Issuer to issue.
-* `claims`: OPTIONAL. An object as defined in (#server-metadata-sd-jwt-vc).
 
 The following is a non-normative example of a Credential Request with Credential Format `vc+sd-jwt`.
 
@@ -2588,11 +2555,13 @@ The technology described in this specification was made available from contribut
 
    -15
 
+   * remove `claims` parameter from ISO mdoc and SD-JWT VC Credential Request
    * credential response always returns an array when not returning a transaction_id with the option for additional meta-data
    * deferred credential response always returns an array (same as credential response)
    * notification_id is now used for an issuance flow that can contain more than one credential
-   * Fixed #375: Enabled non-breaking extensibility.
-   * Fixed #239: Completed IANA Considerations section.
+   * Fixed #375: Enabled non-breaking extensibility
+   * removes `c_nonce` and `c_nonce_expires_in` from the Credential Error Response
+   * Fixed #239: Completed IANA Considerations section
    * add key attestation as additional information in a proof of possesion and new proof type
 
    -14