Clarification on the issuance of multiple credentials with the same Credential Format and Type but different Credential Dataset

[surfnet-niels]

I am trying to figure out how I would be able to issue multiple credentials where only the Credential Dataset is different.
Some usecases from the life of a university student:

• A student has dyslexia and hence has the right to three compensating measures during exams: extra exam time, the use of a laptop, and the use of a spelling checker. The university issues these compensating measures in the form of multiple 'compensating measures' VCs using the institutional user profile page. The student would like to load all of his/her compensating measures into the wallet at once.
• After a succesful exam week, a student has been granted ten OpenBadge VCs which state certain courses were completed succesfully. The university has made the VCs available in the learning platform. The student wants to load all of these into the wallet at once.

I note Draft 12 contained the capability to issue using the batch endpoint, however this capability seems to have been rewritten into a capability to issue multiple credentials of the same Credential Dataset, so in effect 'copies'. Also usefull, but not what I am looking for.

The responses in this issue suggest I could have credentials (types) by just placing additional credential requests, however in my case I have multiple instances of the same credential type, so this does not seem like the way forward?

Any guidance to how I would issue multiple VCs with different a Credential Dataset? I would not like to force my users to having to scan 10 QR codes in a row, that seems rather inefficient. Did I perhaps miss something?

[Sakurann]

Hi, the kind of example you are giving has driven the design on credential_identifiers how to use this parameter differs depending on whether scope of authorization_details in the authorization request, but you will need to support authorization_details.credential_identifiers in the token response.

basically, you would define one credential_configuration_id in the credential issuer metadata but use different credential_identifiers for each of the three compensating measures during exams; or OpenBadge VCs for each of the course.

Does this make more sense?

[muisit]

Hi. Thanks for your response. We have been looking at this implementation in our context of using authorization_code flow and pre-authorised code flow.

This implementation allows the access-token-issuer to tell the Holder for which different credential_identifiers the released access_token is valid.

We run into issues if we are using an external AS. Although a trust relation exists between AS and Issuer, the AS does not know which credentials the Issuer is willing to release to the Holder. It may know the type or scope and prompt the user with the question to authenticate 'in order to receive an OpenBadge' for example, but without a non-spec'ed API between the Issuer and the AS, there is no way for the Issuer to transfer the information about the different credential-data-sets to the external AS (which then transfers this data back to the Issuer through the Holder using the authorization_details attribute).
I conclude from this that this setup would only work in a situation where Issuer and AS are closely linked and maintain the same session state, which is often the case for pre-authorised code flow.

Furthermore, the Holder application is also not able to inform the User in advance, before authentication, which credentials the User may be able to receive. In the current setup, the Holder can only tell the User that it is going to receive an OpenBadge, but it does not know it will receive 10 such OpenBadges, for different courses or achievements.

I have the feeling that the initial Credential Offer needs to be extended to allow the Issuer to specify to the Holder for which credential data sets the Holder can request credentials. This would also remove the need to use the authorization_details for this during authentication with the AS, as this is information which the issuer can link to its own issuer_state and has no bearing on Authentication.
In a pre-authorised code flow, the Issuer can likewise link this to the pre-authorised code grant.

I am very interested to hear your thoughts on this.

[surfnet-niels]

Next to the above use case, I would also like to add recovery as a use case for multiple credentiaal issueance. If students would, after 4 years at the university, loose their wallet and has to fetch all the credentials anew from their institution, I think we would really like them to be able to let the students do so in one action from the perspective of the user.

[jogu]

(chair hat off)

I had a chat with @surfnet-niels about this during EIC.

This ticket seems to have a few different threads of discussion all mixed together.

For clarity this never really worked in older spec versions, as there was no way to signify to the wallet that it needed to use the batch endpoint, and there were all kinds of practical issues with returning multiple credentials with different datasets from the batch endpoint.

As Kristina said above, the way that has been added to the spec to deal with this is the credential_identifiers that are returned from the token endpoint as defined in https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-6.2 - each one of which can identify (e.g.) the OpenBadge VCs for each course. The wallet would then call the credential endpoint for each credential_identifer it receives to get each of the credentials the issuer is willing to provide.

I have the feeling that the initial Credential Offer needs to be extended to allow the Issuer to specify to the Holder for which credential data sets the Holder can request credentials.

I'm not sure I see how adding effectively credential_identifiers to the offer would help - they wouldn't have any meaning to the wallet, and even if it listed (say) that there are 10 credentials, there is no guarantee this is the number of credentials the wallet would actually receive for various reasons, including that there may be a time lag between the offer being sent & actioned, but also that the credential offer isn't tamper proof so can be manipulated by attackers.

We run into issues if we are using an external AS. Although a trust relation exists between AS and Issuer, the AS does not know which credentials the Issuer is willing to release to the Holder. It may know the type or scope and prompt the user with the question to authenticate 'in order to receive an OpenBadge' for example, but without a non-spec'ed API between the Issuer and the AS, there is no way for the Issuer to transfer the information about the different credential-data-sets to the external AS (which then transfers this data back to the Issuer through the Holder using the authorization_details attribute).

I think this is probably where some of the issued are rooted. If there is a separation of concerns like this were an authorization server doing authentication is not strongly related to the issuer, then you run into all kinds of issues as there's no way for the issuer to collect consent from the user for specific credentials to be released. The solution here is that if you want to use an external AS for authentication then you also need an AS that actually does informed consent etc - so what you would effectively have is one AS that is closely linked to the issuer and deals with consent etc, and federates out (using standard protocols like for example OpenID Connect) to the external AS for user authentication.

Are there any cases where that kind of solution doesn't work?