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.