OpenID4VCI

OpenID4VCI copied to clipboard

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1964

Original Reporter: KristinaYasuda

[updated 9/29/2023 by @Sakurann] There are use-cases when the wallet wants to obtain only parts of the issuer metadata - to be precise, only relevant entries in the credentials_supported array. For example, when the wallet wants to obtain a credentials_supported array entry of only a specific language, or a specific identifier (issue #77).

One way to do it is for the wallet to obtain an entire Credential Issuer Metadata and search within it, but this can be error prone, or credential issuer metadata can be very big because every single credential has display properties in 50+ languages (our implementation has this requirement) or the logo for each of the localized credential is a different data uri.

It would be beneficial to have an option for the wallet to tell the credential issuer which credentials_supported entry to include when fetching the credential issuer metadata. For the language, as has been discussed in this issue, Accept-Language header seems to be a way forward. For the identifier (or scope, conditional to issue #77), one option would be to use query, something like https://example-issuer.com/.well-known/openid-credential-issuer?c_identifier=university_degree_computer_science.

Imported from AB/Connect bitbucket - Original Commenter: sloops77

yes - if i understand this correctly it also means that result can be cached by the wallet

Imported from AB/Connect bitbucket - Original Commenter: pedro-felix

• Would this mechanism also be applied when retrieving the issuer metadata (and not an offer)?
• Are you considering something such as the Accept-Language HTTP request header (https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.5)?

‌

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

yes, Accept-Language HTTP request header would work!

I would like to understand what complexity is solved on the wallet end by this proposal and how much additional complexity it causes on the issuer end. The current approach can be implemented by the issuer just publishing a static JSON file. I guess this is no longer possible if we adopt this proposal. I would also like to know the exact feature set being requested: so far selection by language and selection by identifier is mentioned.

• identifier: seems to be trivial, however it is related to one top level element in the whole file. How is the issuer supposed to handle the other top level element, like credential_endpoint or credential_response_encryption_alg_values_supported.
• language: that's related to the display sub members of the credential metadata object and the credential_definition. What is the expected outcome? Shall all the other data be omitted?