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.

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.

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.

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

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.

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.

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.

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