Is VCI applicable in case holder is entitled multiple VCs of the same `credential_configuration_id`?

[babisRoutis]

I am trying to figure out whether (and how) VCI could cover the following case:

• A wallet holder is entitled to be issued multiple VCs of the same type & format (same credential_configuration_id)
• Each of these multiple VCs (of the same configuration id) corresponds to a different claim set. That is they are multiple not because of using different binding keys.
• Wallet holder should be able, during issuance, to choose which VCs (in terms of some kind of id)

For instance, think of a journey where a citizen is visiting a government site that allows him/her to choose one or more birth certificates for himself and/or his/her children.

I think that this would be a pretty common case, since not all VCs have the semantic of PID or mDL.

To my understanding, currently there is no way passing the information of those ids to the wallet, which I think is crucial for two reasons:

• In case of authorization code flow, will allow wallet to place a detailed authorization request (using RAR)
• In case of pre-authorized code, wallet will know beforehand how many issuance requests should assemble and place them either one-by-one or in batch.

Of course, VCI lately introduced the credential_id but I am not sure if it is relevant in my case. Even if it is, the array of credential_ids is being returned to the wallet from token end_point, which perhaps

• couples the token endpoint with the (business) logic of the credential issuer.
• it unclear whether can be used with pre-authorized code (in the absence of an authorization request)

I was wondering whether VCI misses an array of credential_identifier from credential offer.

For instance, something like the example bellow, where credential_configuration_ids instead of containing an array of credential_configuration_ids is an object where each key is a credential_configuration_id pointing to an array of ids.

{
    "credential_issuer" : "...",
    "credential_configuration_ids" : {
        "example_credential_configuration_id" : ["id1", "id2"],
        
    },
    "grants" : {
        
    }
}

[Sakurann]

I think your use-case can be solved by defining credentials_configurations_supported objects with same format&type combination but different credential_configuration_id. credential_configuration_id needs to be unique per credential.

[babisRoutis]

I think your use-case can be solved by defining credentials_configurations_supported objects with same format&type combination but different credential_configuration_id. credential_configuration_id needs to be unique per credential.

Thanks Kristina. I think that this is not going to work. Each credential_configuration_id has to be present to issuer meta-data which means that is static information.

In my case, a have a single credential type (representing by a single credential_configuration_id) but different values for the claimset. All of them, can be issued to the same holder.

Let me provide another example. Imagine that there is a VC representing a certificate for a real estate issued by some kind of notary service. A wallet holder may posses multiple such properties. To my understanding VCI doesn't allow to place a credential offer with the list of the properties of the holder.

[jogu]

Is VCI applicable in case holder is entitled multiple VCs of the same credential_configuration_id?

Yes, it is.

Even if it is, the array of credential_ids is being returned to the wallet from token end_point, which perhaps

• couples the token endpoint with the (business) logic of the credential issuer.

I don't follow how this is business logic in the credential. The authorization server needs to collect user consent as to which credentials the user is authorizing release of (in the authorization code flow). The token endpoint is a part of the authorization server, and hence knows if (say) birth certificates have been released for both the parent and their child.

• it unclear whether can be used with pre-authorized code (in the absence of an authorization request)

This is being discussed on https://github.com/openid/OpenID4VCI/issues/242 - I believe the conclusion is this is possible, but we do need to make that clearer in the specification.

If we make that clarification under https://github.com/openid/OpenID4VCI/issues/242 is there anything from this issue that is still unsolved?

[babisRoutis]

Is VCI applicable in case holder is entitled multiple VCs of the same credential_configuration_id?

Yes, it is.

Even if it is, the array of credential_ids is being returned to the wallet from token end_point, which perhaps

• couples the token endpoint with the (business) logic of the credential issuer.

I don't follow how this is business logic in the credential. The authorization server needs to collect user consent as to which credentials the user is authorizing release of (in the authorization code flow). The token endpoint is a part of the authorization server, and hence knows if (say) birth certificates have been released for both the parent and their child.

• it unclear whether can be used with pre-authorized code (in the absence of an authorization request)

This is being discussed on #242 - I believe the conclusion is this is possible, but we do need to make that clearer in the specification.

If we make that clarification under #242 is there anything from this issue that is still unsolved?

@jogu Joseph thanks for your feedback.

So, to sum up:

In case we have a holder that is entitled to more that one credential instances (those instance share the same credential_configuration_id, the same claim types/attributes, but different claim values) it is the credentials_identifiers array that conveys to the wallet those multiple instances, regardless of the grant type (authorization code or pre-authorized code).

If the above is true, then this issue can be considered as tackled.

PS: Indeed, it would be very helpful to include in the spec the clarification of #242. As a clarification I consider your comment

[Sakurann]

closing since this is true:

In case we have a holder that is entitled to more that one credential instances (those instance share the same credential_configuration_id, the same claim types/attributes, but different claim values) it is the credentials_identifiers array that conveys to the wallet those multiple instances, regardless of the grant type (authorization code or pre-authorized code).