Clarification on credential_identifier(s) parameter

[fmarino-ipzs]

In the latest draft (14), the parameter credential_identifier(s) was introduced.

• In the authorization request, only credential_configuration_id is REQUIRED in the authorization_details.
• In the token request, authorization_details is supported with the same parameters as the authorization request.
• In the token response, credential_identifier(s) is introduced in addition to credential_configuration_id, both REQUIRED in authorization_details when the format parameter is not present.
• In the credential request, only credential_identifier is REQUIRED when obtaining an authorization_detail of type openid_credential.

We are somewhat confused about the relationship between credential_configuration_id and credential_identifier(s). Additionally, while credential_configuration_id is clearly mapped in the metadata of the credential issuer, we didn't understand how credential_identifier(s) is mapped within the metadata.

Probably we are missing something, could you please explain the meaning of the credential_identifier(s) parameter, the relationship with credential_configuration_id (and with scope as well), and how to use it?

[jogu]

Additionally, while credential_configuration_id is clearly mapped in the metadata of the credential issuer, we didn't understand how credential_identifier(s) is mapped within the metadata.

credential_identifiers are not in the meta data.

Probably we are missing something, could you please explain the meaning of the credential_identifier(s) parameter, the relationship with credential_configuration_id (and with scope as well), and how to use it?

A credential identifier represents the combination of a credential configuration and a credential data set.

To explain it another way, imagine a credential issuer is issuing passports, and the end user is authorised to hold passports for themselves and their two children.

The issuer would list a single passport in their issuer metadata, perhaps with credential_configuration_id "iso-passport".

When the end user requests "iso-password" using authorization_details they will get back 3 credential_identifers - perhaps "passport-john", "passport-cindy", "password-sarah".

They would then call the credential endpoint 3 times, one for each of "passport-john", "passport-cindy", "password-sarah".

Does that help?

[fmarino-ipzs]

Thank you @jogu for the clarification, now it is more clear the meaning and the scope of the parameter. I have still a couple of questions.

1. following your example:

To explain it another way, imagine a credential issuer is issuing passports, and the end user is authorised to hold passports for themselves and their two children.

as far as I understand, you are assuming that the CI knows in advance that the user is authorised to hold passports for their children as well. A privacy preserving approach could require that the CI knows anything about the User ex ante. In some cases a CI required some other Credentials in order to authorize the User to request a specific credential_identifier. Probably, the CI should know which credential_identifier the user wants to obtain during the authorization phase.

2. Why do you introduce a new parameter and not use the scope parameter for doing this? Is there any technical reason? It seams to me that using scope parameter in combination with credential_configuration_id could solve your use case easily, but probably I'm missing something.

thanks again for the support.

[jogu]

as far as I understand, you are assuming that the CI knows in advance that the user is authorised to hold passports for their children as well. A privacy preserving approach could require that the CI knows anything about the User ex ante. In some cases a CI required some other Credentials in order to authorize the User to request a specific credential_identifier. Probably, the CI should know which credential_identifier the user wants to obtain during the authorization phase.

If we stick with the passport example (and I can only really comment on the UK as that is the country I am familiar with), then yes, what you say it true - but actually this is situation in the pre-digital-credentials world as well. When you apply for the childs passport in the UK, my understanding is that it is issued to a parent, not to the child. So the issuer of passport inherently knows who is authorised to hold that child's passport, at least at the time it is issued.

But this is all really out of scope of VCI - what we know in VCI is that a user can be sent to the issuer's nominated oauth server, will have some interactions with that server, and at the end of those interactions will be granted access to 0 or more credentials belonging to 0 or more natural persons / legal entities. If the issuer only ever wants to return credentials that are directly linked to the end-user requesting them, that's a policy decision for the issuer - VCI just supports the flexibility for the issuer to make either decision.

Why do you introduce a new parameter and not use the scope parameter for doing this? Is there any technical reason? It seams to me that using scope parameter in combination with credential_configuration_id could solve your use case easily, but probably I'm missing something.

scopes are not really "per-user", and although you could definitely invent scopes that are ("passport:john", "passport:cindy" etc) it's not a great solution and this kind of unnatural/complicated use of scopes is the reason why https://datatracker.ietf.org/doc/html/rfc9396 was invented as a way to communicate this data in a structured way.

[fmarino-ipzs]

Given a credential type, a CI may issue

• 1..n credential instances (e.g. eprescription use case)
• to 1..n subject (children, delegation use cases)

I see the benefits of having credential_identifiers for handling the first case, while the second case probably would require an authorization step. In this case the scope parameter could be for example 'children' or 'delegation'.

Regarding the first case I see 2 options:

1. The user select one or more credential instances directly through the UI of the CI. This should be done in the authorization phase as we have the redirect.
2. The user is informed that the CI has 1 or more credential instances at the token response with the current credential_identifiers param (btw I suggest to rename (credential_instances?) it in order to avoid confusion with credential id). In this case the UI is provided by the Wallet Instance.

I think that both options could be enabled but, in order to make able the user to clearly understand which credential instance is going to obtain the only credential identifier is not enough. We probably need some additional information such as a human readable description that the Wallet Instance could prompt to the user. WDYT?

[babisRoutis]

Regarding the first case I see 2 options:

1. The user select one or more credential instances directly through the UI of the CI. This should be done in the authorization phase as we have the redirect.

2. The user is informed that the CI has 1 or more credential instances at the token response with the current credential_identifiers param (btw I suggest to rename (`credential_instances`?) it in order to avoid confusion with credential id). In this case the UI is provided by the Wallet Instance.

Dear @fmarino-ipzs

IMHO, there are several business use cases where credential_identifier(s) are pertinent. I think though that only the first option is viable for such issuance flows, exactly because it allows the holder to peek specific instances, or to put it differently, to authorize the issuance of specific instances.

To my understanding there are threes ways to implement this, with the following credential offers:

1. Using per-authorized code grant
2. Using authorization code grant and no issuer_state
3. Using authorization code grant and issuer_state

(1)

• Holder visits a site that allows the holder to choose specific credential instances. It is assumed that this site is able to authenticate the user and "knows" to which credential instances his/she is entitled.
• This site, interacts with the authorization server (and the credential issuer) to request for a credential offer (passing in the credential_identifiers selected). This interaction is not part of the VCI.

(2)

• Holder while visiting the authorization endpoint has to choose for specific credential identifiers.
• This requires a custom authorization screen/flow from the authorization server, which should not only authenticate the user but allow him to properly authorize the issuance. In turn, this means that it is the authorization server that should know to which credential instances the user is entitled to.

(3)

• That's almost identical to (1) with the exception that holder has to authenticate to the authorization server.

In summary, if you accept that a credential offer mainly conveys credential_configuration_id(s) and not credential_identifier(s), then it seems natural that the the choice of specific credential_identifiers can occur during authorization or pre-authorization.