using credential_configuration_id in the credential request when scopes are used in the authorization request

[Sakurann]

Currently, Credential Request has two options to specify which credential is being requested: credential_identifier or combination of format and credential format specific credential_definition.

We (Microsoft) are currently implementing VCI and we use scopes and cannot return credential_identifier from the token endpoint (because of the limitations of a big AS we are using), but we found that the performance (especially for the wallet) is better when identifier in the credential_configurations_supported issuer metadata is used in the credential request instead of format/type combination: it saves from comparing the combination of format and type (that is mapped to an identifier anyway) and helps prevent errors. (I think this is also what @pmhsfelix suggested at IIW)

The flow would look like:

• the wallet receives credential offer with an identifier.
• the wallet uses that identifier to look up an entry in credential_configurations_supported issuer metadata
• the wallet uses a scope value in the authorization request
• the wallet uses the same identifier in the credential request

The parameter name should probably be credential_configuration_id which is what is used in RAR. I don't think credential_identifier should be reused because that one has a distinct meaning and purpose.

Credential Request will look pretty simple:

• credential_condifuration_id: REQUIRED. String that identifies a Credential that is being requested to be issued. When credential_identifier was returned from the Token Response, it MUST match the value of this string. Otherwise, it MUST match the value of an identifier in the credentials_supported issuer metadata that the wallet used to look credential being requested within the issuer metadata.

• 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:

  • 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 Section 7.2.1.

• encryption related parameters

(mandating to return credential_identifier from the token response is not an option because some ASs cannot make breaking changes and cannot return credential_identifiers in the Token Endpoint.)

[tlodderstedt]

I would feel more comfortable with the AS issuing the credential identifiers that can be used with the credential issuer. However since that is impossible for MSFT (and perhaps other existing OAuth deployments), adding the credential configuration id to the credential request is the second best option (even though it means to add a third option to specify the credential the wallet wants to obtain).

So I'm supporting this proposal.

[jogu]

I think this is generally a good change to make given the limitations of existing OAuth servers, I do wonder if we actually need to add this as a 3rd option or could remove (or at least discourage the user of) the option where format is passed.

The parameter name should probably be credential_configuration_id which is what is used in RAR. I don't think credential_identifier should be reused because that one has a distinct meaning and purpose

Strongly agree with this.

[babisRoutis]

I also think that it makes sense to replace the combination of format parameter & some format-specific values in the credential request with credential_configuration_id.

Whether the Credential request should contain one of (mutually exclusive) credential_configuration_id and credential_identifier or, alternatively, use a single credential_configuration_id that can carry either identifiers, is perhaps a matter of taste.
Personally, I like the clarity of having two different and mutually exclusive attributes.

Yet the problem for me is not the credential request. Rather it has to do with the way the wallet becomes aware of these credential_identifiers, if any.

Currently, credential_identifiers are communicated via token response, in case there was an authorization request that used authorization_details.

I find this very restrictive.

For starters, in pre-authorized code flow, it is not clear whether the token response can use authorization_details with credential_identifiers (there is not authorization request). If credential_identifiers were added in the a credential offer (for pre-authorized code) then it would be straightforward to support use cases where a holder visits an issuer site and selects to issue one or more credentials of the same type.

[Sakurann]

There is rough consensus that it is a good idea to use credential_configuration_id in the credential request (tho credential_identifiers from the token andpoint are probably preferred...)
so the credential request would look like this:

{
"credential_configuration_id": "org.iso.18013.5.1.mDL",
"proof": {
"proof_type": "cwt",
"cwt": "..."
}
}

[TimoGlastra]

I'm in favour of adding a new credential_configuration_id (or actually renaming credential_identifier) to the credential request. I see two main reasons for this:

• When using the pre-authorized flow, as I understand it now, you can't use the authorization_details, so that means you can't use this approach (please correct me if I'm wrong on this). (I just saw make credential_identifiers mandatory for authorization_details flow #346 which adds support using authorization_details in pre-auth flow)
• This would avoid having to ever use the format and additional type/credential_definition/etc.. to then match it back to an id you offered again on the server. Just using an ID to match it back feels a lot simpler, for probably 99% of the use cases (that I can think of). For vc+sd-jwt this is OK as you can match quite easily on the vct. But for the others it requires comparing the complex structure of the request, which I don't really understand.

I would also be in favour of combining it with the credential_identifier already present. The purpose of this identifier is to point to a specific credential configuration instance id. As they refer to the same id type, I feel like adding another credential_configuration_id will just confuse and complicate the implementations. If the credential_identifiers was used you can only request the issuance of a credential configuration with specific id that was present in those credential_identifiers.

In my head the id connects all the different endpoints and object types, which I now sometimes miss / are only available for specific flows. It would be nice if there is one id value that identifies the credential being issued from beginning to end.

• Issuer metadata -> define credential configurations with id
• offer -> include a subset of these credential configurations ids
• authorization request/token request -> request authorization/token to request credentials based on the credential_configuration_id or scope values
• credential request -> actually request a specific credential_identifier/credential_configuration_id to be issued to you. if authorization returned a subset of credential_identifiers you can only request those. If not, you could still just use credential_identifier (or should probably be renamed to credential_configuration_id) to request issuance of a specific credential. If scopes were used, you can request the credential_configuration_id(s) associated with that scope. If pre-auth was used, you can request any of the ids in the offer.

[babisRoutis]

Currently (draft13) VCI uses in a consistent manner two different terms:

• credential_configuration_id
• credential_identifier

The first is present in issuer's meta-data, credential offer, authorization_details (requested), authorization_details granted
The second is present in authorization_details granted and in credential issuance request.

I feel that the only thing missing is to allow credential_configuration_id to be used in a credential request. In particular,

In case that token response doesn't indicate credential_identifiers a request could be placed (taking @Sakurann example ) as follows:

{
  "credential_configuration_id": "org.iso.18013.5.1.mDL",
  "proof": {
    "proof_type": "cwt",
    "cwt": "..."
  }
}

Whereas in case token endpoint returned one or more credential_identifier

{
  "credential_configuration_id": "dimploma",
  "credential_identifier": "foobar"
  "proof": {
    "proof_type": "jwt",
    "jwt": "..."
  }
}

I think the above would keep clear and consistent the distinction between credential_configuration_id and credential_identifier throughout the issuance process.

[TimoGlastra]

Thanks for the input. I read the part on credential_identifiers again. I mistakenly thought the values for credential_identifiers MUST be credential_configuration_id values that were authorized (with a specific dataset). Now I understand why it should be different parameters.

[jogu]

If I understood this discussion correctly then I think this issue overlaps a lot with #342