I think I'm slightly confused by this part: > `credential_identifier` parameter replaces `format` and any other Credential format specific parameters Doesn't that mean the wallet doesn't know which credential_identifier is associated with what format?

```suggestion { "type": "openid_credential", "credentials_supported_identifier": "UniversityDegreeCredential", "c_instance_identifiers": [ "CivilEngineeringDegree-2023", "ElectricalEngineeringDegree-2023" ] ```

```suggestion * `c_instance_identifier`: REQUIRED when `c_instance_identifier` was returned from the Token Response. MUST NOT be used otherwise. JSON string that identifies a Credential that is being requested to be issued. When this parameter is used, the `format` parameter and any other Credential format specific set of parameters such as those defined in (#format_profiles) MUST NOT be present. ```

```suggestion * `authorization_details`: REQUIRED when `authorization_details` parameter is used to request issuance of a certain Credential type as defined in (#authorization-details). MUST NOT be used otherwise. A JSON array of objects as defined in Section 7 of [@!RFC9396]. This specification defines the following parameter to be used with authorization details type `openid_credential` in the Token Response: ```

```suggestion * `deferred_credential_endpoint`: OPTIONAL. URL of the Credential Issuer's Deferred Credential Endpoint. This URL MUST use the `https` scheme and MAY contain port, path, and query parameter components. If omitted, the Credential Issuer does not support the Deferred Credential Endpoint. * `credential_response_encryption_alg_values_supported`: OPTIONAL. Array containing a list of the JWE [@!RFC7516] encryption algorithms (`alg` values) [@!RFC7518] supported by the Credential and/or Batch Credential Endpoint to encode the Credential or Batch Credential Response in a JWT [@!RFC7519]. * `credential_response_encryption_enc_values_supported`: OPTIONAL. Array containing a list of the JWE [@!RFC7516] encryption algorithms (`enc` values) [@!RFC7518] supported by the Credential and/or Batch Credential Endpoint to encode the Credential or Batch Credential Response in a JWT [@!RFC7519]. ```

```suggestion * `credential_encryption_jwk`: OPTIONAL. An object containing a single public key as a JWK used for encrypting the Credential Response. ```

```suggestion * `c_instance_identifier`: REQUIRED when `c_instance_identifier` was returned from the Token Response. String that identifies a Credential that is being requested to be issued. When this parameter is used, the `format` parameter and any other Credential format specific set of parameters such as those defined in (#format_profiles) MUST NOT be present. ```

```suggestion * `proof_type`: REQUIRED. String denoting the key proof type. The value of this claim determines other claims in the key proof object and its respective processing rules. Key proof types defined in this specification can be found in (#proof_types). ```

```suggestion * `proof`: OPTIONAL. Object containing the proof of possession of the cryptographic key material the issued Credential would be bound to. The `proof` object MUST contain a following claim: ```

Data type is missing. ```suggestion * `format`: REQUIRED when the `c_instance_identifier` was not returned from the Token Response. String that determines the format of the Credential to be issued, which may determine the type and any other information related to the Credential to be issued. Credential Format Profiles consisting of the Credential format specific set of parameters are defined in (#format_profiles). When this parameter is used, `c_instance_identifier` parameter MUST NOT be present. ```

```suggestion * `authorization_details`: REQUIRED when `authorization_details` parameter is used to request issuance of a certain Credential type as defined in (#authorization-details). An array of objects as defined in Section 7 of [@!RFC9396]. This specification defines the following parameter to be used with authorization details type `openid_credential` in the Token Response: * `c_instance_identifiers`: OPTIONAL. Array of strings that each uniquely identify a Credential instance that can be issued using Access Token returned in this response. Each Credential instance is a unique Credential described using the same entry in the `credentials_supported` Credential Issuer metadata, but can contain different claim values or different subset of claims within the claimset identified by the Credential type. This parameter can also be used to simplify the Credential Request, since as defined in (#credential_request) `c_instance_identifier` parameter replaces `format` and any other Credential format specific parameters in the Credential Request. When received, the Wallet MUST use these values together with an Access Token in the subsequent Credential Request(s). ```

```suggestion * `c_nonce`: OPTIONAL. String containing a nonce to be used when creating a proof of possession of the key proof (see (#credential_request)). When received, the Wallet MUST use this nonce value for its subsequent requests until the Credential Issuer provides a fresh nonce. ```

```suggestion * `format`: REQUIRED. String representing the format in which the Credential is requested to be issued. This Credential format identifier determines further claims in the authorization details object specifically used to identify the Credential type to be issued. This specification defines Credential Format Profiles in (#format_profiles). ```

```suggestion * `type` REQUIRED. String that determines the authorization details type. MUST be set to `openid_credential` for the purpose of this specification. ```

Maybe it would be good to find a different word instead of "credential type" to describe an entry in the `credentials_supported` Credential Issuer metadata. The terms feels too overloaded. How about "credential description" or "credential definition"?

```suggestion Below is a non-normative example of an Authorization Request provided by the Wallet to the Authorization Server using the scope `university-degree-jwt` and in response to an HTTP 302 redirect. The line wraps within the values are intended for display purposes only: ```

Detail: I'm not 100% comfortable with the `instance_identifier` naming, namely because: - The credential was not yet created (that will only happen after a credential request), so there isn't yet an instance, right? - Also, this identifier may be confused with the `callback_id` from https://github.com/openid/OpenID4VCI/pull/70/files, which is described as `A JSON string identifying an issued Credential`. Would `credential_request_identifier`(or an abbreviation of it) be a better name , since it provides an identifier to request a specific thing on the credential request.

Detail: since `c_instance_identifiers` is already inside an `authorization_details` item with type=`openid_credential`, perhaps we can drop the `c_` prefix. The same for the credential request parameter. The `c_` prefix was important if the parameter was a top-level one in the token response.

I missed the discussion on this last week and I have a hard time following this description. Can you please attempt to introduce the concept or mental model behind "instances" of credentials before diving into the definition of the parameter?

```suggestion * `proof`: OPTIONAL. JSON object containing proof of possession of the cryptographic key material the issued Credential SHALL be bound to. The `proof` object MUST contain a following claim: ```

```suggestion The following is a non-normative example of an object comprising `credentials_supported` parameter for a Credential in JWT VC format (JSON encoding). ```

```suggestion * `credential_response_encryption_alg`: OPTIONAL. JWE [@!RFC7516] `alg` algorithm [@!RFC7518] REQUIRED for encrypting Credential and/or Batch Credential Responses. If omitted, no encryption is intended to be performed. When the `credential_response_encryption_alg` is present, the `credential_encryption_jwk` MUST be present. ```

```suggestion * `c_identifier`: REQUIRED if `c_identifier` was returned from the Token Response. JSON string that identifies a Credential that is being requested to be issued. It MUST be present if the Credential Issuer returned `c_identifiers` parameter in the Token Response. When this parameter is used, the `format` parameter and any other Credential format specific set of parameters such as those defined in (#format_profiles) MUST NOT be present. ```

```suggestion * `proof_type`: REQUIRED. JSON string identifying the cryptographic key proof type. The value of this claim determines other claims in the cryptographic key proof object and its respective processing rules. Cryptographic key proof types defined in this specification can be found in (#proof_types). ```

```suggestion * `proof`: OPTIONAL. JSON object containing proof of possession of the cryptographic key material the issued Credential shall be bound to. The `proof` object MUST contain a following claim: ```

```suggestion * `format`: REQUIRED when the `c_identifier` was not returned from the Token Response. This parameter determines the format of the Credential to be issued, which may determine the type and any other information related to the Credential to be issued. Credential Format Profiles consisting of the Credential format specific set of parameters are defined in (#format_profiles). When this parameter is used, `c_identifier` parameter MUST NOT be present. ```

```suggestion Below is a non-normative example of a Token Response when the `scope` parameter was used to request the issuance of a certain Credential type: ```

```suggestion * `c_identifiers`: OPTIONAL. JSON array of JSON strings that each identify a Credential that can be issued using Access Token returned in this response. This parameter is used to uniquely identify a Credential beyond the combination of Credential format and type. For example, when Credential Issuer is issuing Credentials of the same type, but with different subset of claims. This parameter MUST be used when `authorization_details` parameter is used in the Authorization Request to request Credential type of a Credential that is being uniquely identified. When received, the Wallet MUST use these values together with an Access Token in the subsequent Credential Request(s). ```

```suggestion * `c_identifiers`: OPTIONAL. JSON array of JSON strings that each identify a Credential that can be issued using Access Token returned in this response. This parameter is used to uniquely identify a Credential beyond the combination of Credential format and type. For example, when the Credential Issuer is issuing Credentials of the same type, but with different subset of claims. This parameter MUST be used when the `scope` parameter is used in the Authorization Request to request the type of a Credential that is being uniquely identified. When received, the Wallet MUST use these values together with an Access Token in the subsequent Credential Request(s). ```

```suggestion * `authorization_details`: REQUIRED when `authorization_details` parameter is used for requesting the issuance of a certain Credential type, as defined in (#authorization-details). A JSON array of objects as defined in Section 7 of [@!RFC9396]. In addition to the parameters received from the Wallet, the AS MAY return the following parameter: ```

```suggestion * `c_identifiers`: OPTIONAL. JSON array of JSON strings that each identify a Credential that can be issued using Access Token returned in this response. This parameter is used to uniquely identify a Credential beyond the combination of Credential format and type. For example, when the Credential Issuer issues Credentials of the same type but with different subset of claims. This parameter MUST be used when `scope` parameter is used in the Authorization Request to request Credential type of a Credential that is being uniquely identified. When received, the Wallet MUST use these values together with an Access Token in the subsequent Credential Request(s). ```

```suggestion * `c_nonce_expires_in`: OPTIONAL. JSON integer corresponding to the number of seconds beyond which the `c_nonce` MUST be intended as expired, and then not valid anymore, after the time of its issuance. ```

```suggestion * `c_nonce`: OPTIONAL. JSON string containing a nonce to be used to create a proof of possession of the cryptographic key material used 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. ```

```suggestion Below is a non-normative example of an Authorization Request provided by the Wallet to the Authorization Server using the scope `UniversityDegree_JWT` and in response to an HTTP 302 redirect. The line wraps within the values are intended for display purposes only: ```

```suggestion If the Credential Issuer metadata contains an `authorization_server` property, it is RECOMMENDED to use a `resource` parameter [@!RFC8707] whose value is the Credential Issuer's identifier value; this allows the AS to differentiate Credential Issuers. ```

```suggestion * Any further parameters characterizing the type of the Credential to be issued are intended as RECOMMENDED. These parameters are specific to the credential format profile, some of which are defined in (#format_profiles). ```

```suggestion * `format`: REQUIRED if `identifier` was not returned from the Token Response. Format of the Credential to be issued. This Credential format identifier determines further parameters required to determine the type and (optionally) the content of the credential to be issued. Credential Format Profiles consisting of the Credential format specific set of parameters are defined in (#format_profiles). When this parameter is used, `identifier` parameter MUST NOT be present. ```

```suggestion * `authorization_details`: REQUIRED when `authorization_details` parameter was used to request issuance of a certain Credential type as defined in (#authorization-details). A JSON array of objects as defined in Section 7 of [@!RFC9396]. In addition to the parameters received from the Wallet, the AS MAY return the following parameter: ```

I wonder if an identifier should also be allowed in the offer credentials object, as a way to precisely specify the credential to issue. Use case: - Training company has a web site where users can see the completed training courses. - For each course (e.g. `AERO-123-FluidMechanics-II-2023`), user can require a credential, which requires some sort of payment. - After payment transaction is completed, web site presents an offer as a QR code. This offer exactly identifies the credentials that the user can request (e.g. `AERO-123-FluidMechanics-II-2023`). - User scans QR code with wallet, authenticates, consents on a screen that only shows `AERO-123-FluidMechanics-II-2023` credential information (no need for the user to select anything), and finally gets an issued credential. The use of an identifier would allow an offer to be much more precise in the credential that is being offered. The identifier could be carried in the authorization request's `authorization_details` object.

Detail: `identifiers` seems a too broad term to be used as a token response top-level parameter. Perhaps use `c_identifiers` instead, similarly to what we do with nonces (parameter is named `c_nonce`). In contrast, using `identifier` inside an `authorization_details` is fine because its meaning is scoped to `"type": "openid_credential"`.

If I'm understanding this correctly, the second case above means: - Fetching the issuer metadata. - Locating a `credentials_supported` entry in that metadata that _matches_ the offer's `credentials` entry. If so, this requires defining the concept of matching between an offer `credentials` entry and a metadata `credentials_supported` entry. Is this matching a strict non-shallow comparison of JSON objects, excluding the `scope` property? Somehow related, an issuer may want to offer credentials that don't appear in the metadata, namely because they are very context specific. Example: an university offers hundreds of courses and is able to issue individual credentials for each completed course. Instead of having all these different credentials in its metadata, it can generate user specific offer objects (e.g. on a portal page), with only the credentials for the courses completed by the user. Given the above, wouldn't it be simpler to also include an optional `scope` in the offer's `credentials` entry object?

`scope` is not a credential issuer metadata parameter. ```suggestion When the Wallet does not know which scope value to use to request issuance of a certain credential, it can discover the available `scope` values in the `credentials_supported` Credential Issuer metadata parameter defined in (#credential-metadata-object). When the flow starts with a Credential Offer, the Wallet can use the information in it as following: ```

The current definition does not include the `display` and other properties defined in (#credential-metadata-object) — is that intentional?

```suggestion * `credentials`: REQUIRED. A JSON array, where every entry is a JSON string or a JSON object describing a credential the Wallet may request. If the entry is a string, the string value MUST be one of the `scope` values included in a `credentials_supported` Credential Issuer metadata parameter as defined in (#credential-metadata-object). When processing, the Wallet MUST resolve this string value to the respective object. If the entry is an object, the object contains the data related to a certain credential type. Each object contains the following parameters: ``` This `may` is not normative.

I think we only have this one example using scopes now - it would be great to have examples for the other options too (so 3 in total I think? one with scope, one with authorization_details, one with identifiers)

Not sure this parameter should be mutual exclusive with all additional parameters used to determine the type of credentials as this data was already passed in the authorization request.

A wallet could use `scope` and `authorization_details` in the same request. So the language should be along the lines of "this array contains the credentials that can be requested based on the scope values passed to the authorization request". This means `identifiers` and `authorization_details/identifiers` can turn up in the same token response.