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": "..." } }