Authorization Details Using Credential Descriptions for improved multi-credential UX
There are cases where Users have multiple instances of the same credential type (e.g., multiple diplomas, thousands of invoices, others).
The current OAuth framework enables the user interaction using the Authorization Endpoint, making the AS able to authenticate the User and implement some sort of UI to engage the User in selection/consent/any other meaningful required user action.
This current approach may show some UX downsides, since every AS should implement on their own the UI to get the proper User authorizations before issuing the Access Token.
To make the User able to navigate and select the credential desidered for issuance, an alternative approach is proposed below.
The current OpenID4VCI specification supports multiple credentials of the same type through the credential_identifiers array in the authorization_details object included within the Token Response. The credential_identifiers array only provides opaque identifiers without meaningful descriptions for Users.
However, according to the current openid4vci specs, by using the current authorization_details object:
- Users cannot make informed decisions about which credentials to request without understanding what each identifier represents
- Wallets cannot provide meaningful information to users about available Credentials, therefore Wallet cannot make the Users able to decide how to use the Access Token and for which Credential
These limits can be overcome introducing a descriptor object, as shown in the example below.
{
"authorization_details": [
{
"type": "openid_credential",
"credential_configuration_id": "dc_sd_jwt_Education_degree",
"credential_identifiers": [
"education_degree_unibo_2017_l31_informatica",
"education_degree_unibo_2019_lm18_informatica",
"education_degree_unibo_2022_phd_informatica"
],
"credential_identifiers_descriptions": [
{
"identifier": "education_degree_unibo_2017_l31_informatica",
"title": "Bachelor's Degree in Computer Science",
"description": "University of Bologna, 2017",
"issuance_date": "2017-07-15",
"additional_metadata": {
"university": "University of Bologna",
"faculty": "Computer Science",
"level": "L31"
}
},
{
"identifier": "education_degree_unibo_2019_lm18_informatica",
"title": "Master's Degree in Computer Science",
"description": "University of Bologna, 2019",
"issuance_date": "2019-10-20",
"additional_metadata": {
"university": "University of Bologna",
"faculty": "Computer Science",
"level": "LM18"
}
},
{
"identifier": "education_degree_unibo_2022_phd_informatica",
"title": "PhD in Computer Science",
"description": "University of Bologna, 2022",
"issuance_date": "2022-03-10",
"additional_metadata": {
"university": "University of Bologna",
"faculty": "Computer Science",
"level": "PhD"
}
}
]
}
]
}
Using some sort of credential_identifiers_descriptions object we enables the Wallet to inform the User about how to use the Access Token and the User would therefore be able to decide which Credential to request, keeping the full control of the Access Token. This approach aims to reduce the reliance on external webviews for User interaction and aims to improve the UX with disabilities through Wallet native UI controls.
Further notes and remarks:
- The
credential_identifiers_descriptionsfield should be optional. - Existing implementations without descriptions continue to work
- A gradual adoption path for both credential issuers and wallet solution is possible
- Considering data minimization principles, descriptions should not contain sensitive personal information