Open fmarino-ipzs opened 1 month ago
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?
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.
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.
thanks again for the support.
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.
Given a credential type, a CI may issue
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:
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?
In the latest draft (14), the parameter
credential_identifier(s)
was introduced.credential_configuration_id
is REQUIRED in theauthorization_details
.authorization_details
is supported with the same parameters as the authorization request.credential_identifier(s)
is introduced in addition tocredential_configuration_id
, both REQUIRED inauthorization_details
when theformat
parameter is not present.credential_identifier
is REQUIRED when obtaining anauthorization_detail
of typeopenid_credential
.We are somewhat confused about the relationship between
credential_configuration_id
andcredential_identifier(s)
. Additionally, whilecredential_configuration_id
is clearly mapped in the metadata of the credential issuer, we didn't understand howcredential_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 withcredential_configuration_id
(and withscope
as well), and how to use it?