Add display metadata to the CredentialResponse

[leecam]

When receiving a credential from the Credential Endpoint we'd like an Issuer to be able to provide optional "card art" and a description.

For example an CredentialResponse maybe extended as follows:

{
    "display": [
        {
             "locale": "en-US",
             "name": "Lee's Tribank Card"
             "description": "5423 4343 2334 XXXX"
             "logo": {
                    "uri": "data:image/png;base64,F00==",
                    "alt_text": "credit card image"
             },
        }
    ]
    "credentials": [
    {
      "credential": "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L"
    }
  ]
}

This allows the wallet to display the credential with personalized cardart and descriptions in a standardized way, regardless of credential format or doctype. See this screenshot for an example of customized logo, title and description.

[c2bo]

That would mean that display information inside the credential response would overrule the generic display information inside the issuer metadata if I understand correctly?

[javereec]

Good idea. Some thoughts:

• It very likely that this information would be useful beyond this point (display in wallet, in a presentation flow). Doing it this way would probably mean that this information would be retained (... and passed on?)
• If this is just for this interaction, I feel there needs to be a link between this and the format specific display metadata (from the issuer metadata).

[nemqe]

In general not against the idea but have some questions/thoughts:

• Would we do full override where we do not even look at the structure in the issuer medatada, or would we do partial overlays where we merge the returned structure with the one in the issuer medatada (we only replace the background image but logo should be the default one)
• Would we deliver the full set of display data with regards to the locale or just parts. If we deliver the 'en-US' locale and the user changes the locale on their device what would be the cardart displayed to the user, and could the user request the cardart for the new locale, or would we always send all locales to the wallet. Even in the case where we send all of the currently known locales how would the user/wallet fetch a new locale that has been added (edge case)
• Would we need mechanisms to update this personalized cardart in case of mistakes or changes in branding

[timbl-ont]

Another option is to include attribute values, from the credential, to overlay on top of the card view in the credential display metadata. The background_image could be an SVG with parameterized values, if precise layout was required.

[fkj]

After doing pilot testing we have run into a similar problem with the UX. For end users it is difficult to successfully select the correct credential instance when they have more than one of the same credential type, since the display name is always the same. One example is people who have multiple addresses and have one credential to prove that they live at each place (this is useful for fraud prevention).

In the pilot, the wallet developers have resorted to hard-coding extraction of the values of "well-known" claims (e.g. street_address) to display next to the display name of the credential. But this solution does not scale very well.

Another option is to include attribute values, from the credential, to overlay on top of the card view in the credential display metadata. The background_image could be an SVG with parameterized values, if precise layout was required.

I think this would be a good solution, since it lets the issuer determine how to display the information in the claims (and especially which information not to display). It would be useful to generalize it to the name and description as well so issuers don't have to define a background_image.

[Sakurann]

PR #500 makes this much easier

[Sakurann]

suggested mechanism would be to send credential_configurations object introduced in PR #500 as-is in the Credential Response

[fkj]

My understanding of the proposed mechanism is that sending a credential_metadata object in the Credential Response would override the definitions in the Credential Issuer Metadata. As I see it, that would more or less solve the problem while keeping the work of defining the look of the credential with the issuer (where it belongs in my opinion) and not with the wallet.

What might be missing is a mechanism for updating the values in the credential_metadata object. As mentioned above, this would be very useful for e.g. branding changes. It should be explicit when wallets are expected to retrieve images from URLs, i.e. periodically or just on issuance?

I think there may be some privacy issues with allowing credential instance-specific URLs for logos and background images. To customize e.g. a credit card with name, the issuer would have to generate an image URL for each instance of the credential and these should probably be secured somehow (or it should be very clear that they must not contain PII/secrets). It should also be a requirement that the wallet does not present the URLs to a verifier, as this would allow the issuer to detect where the credential is used if the verifier then retrieves the instance-specific image.

[jogu]

As discussed on yesterday's working group call - as we're very close to WGLC last call for VCI 1.0, and there's no PR / implementation experience for this, and as it can be added as a non-breaking extension in 1.1 - moving this to 1.1.

[paulbastian]

notes from IIW discussion:

• never released to the Verifier, only for display purposes to the user
• should have the same structure as issuer metadata, but have a different parameter name to clearly distinguish
• favored solution as described in this issue: credential format agnostic, overwrites generic descriptions form Issuer metadata
• allow additional fields other than display, that could be provided alongside the credential
• allow update of auxiliary about credential?
  • Credential Request needs to make it clear that display data update only is requested
  • separate feature
• Lee to propose a PR for auxialiry per-credential metadata for Credential Response
• some other optimzations for static metadata exist, e.g. light/dark mode logo

[TimoGlastra]

How will this work in combination with vct metadata?

Should a wallet generally use this order for display in the wallet (1. Is highest priority):

1. Credential response metadata
2. VCT metadata
3. Credential issuer metadata

[c2bo]

How will this work in combination with vct metadata?

Should a wallet generally use this order for display in the wallet (1. Is highest priority):

1. Credential response metadata
2. VCT metadata
3. Credential issuer metadata

I think this is he order we had originally discussed and makes sense imho - basically define that response metadata overwrites Credential defined metadata overwrites credential issuer metadata