RFC 0453 - Support credential gallery images

[mickrau]

Motivation

Digital credentials are usually presented as images in the holder's (mobile) wallet. But so far there is no interoperable mechanism how these gallery images can be shared by the issuer to the other parties. There are some proprietary implementations that partly use the mediator for this.

In our opinion this is an important feature which greatly enhances the user experience, therefore should be part of the Issue Credential Protocol 2.0 (RFC 0453). This would eliminate the need for a central image server and would give the flexibility to add user-specific content to the image (i.e holder's name).

Our proposal:

Add an optional embedded attachment credential_images~attach to both the offer-credential message and the issue-credential message. This ensures that for each credential type, including those without an offer-credential message, the image can be displayed as early as possibly. There could be different types or dimensions of the credential image in this array.

Open questions:

• Should dimensions of credential images be fixed?
• Should we define/restrict the set of supported mime types?
• There are potentially other types of attachments that are linked to an issuance process (i.e. PDF copy, issuance invoice, instructions for user-driven revocation). How should these attachments be transfered to the holder?
• Is it desired that images attached to offer-credential or issue-credential messages can be different?

Message Format

Message Format (offer-credential):

{
    "@type": "https://didcomm.org/issue-credential/%VER/offer-credential",
    "@id": "<uuid of offer message>",
    "replacement_id": "<issuer unique id>",
    "comment": "<some comment>",
    "credential_preview": <json-ld object>,
    "formats" : [..],
    "offers~attach": [..],
    "credential_images~attach": [
        {
            "@id": "credential-image-0",
            "mime-type": "image/png",
            "data": {
                "base64": "<bytes for base64>"
            }
        }
    ]
}

Message Format (issue-credential):

{
    "@type": "https://didcomm.org/issue-credential/%VER/issue-credential",
    "@id": "<uuid of issue message>",
    "replacement_id": "<issuer unique id>",
    "comment": "<some comment>",
    "formats" : [..],
    "credentials~attach": [..],
    "credential_images~attach": [
        {
            "@id": "credential-image-0",
            "mime-type": "image/png",
            "data": {
                "base64": "<bytes for base64>"
            }
        }
    ]
}

[smithbk]

Why not include an image as a well-known attribute name in the credential offer? The value of this well-know attribute name could be a hash and the URL which is used to download the image, or the actual image itself.

[swcurran]

@smithbk -- that is viable using proposed attachment by using the link form of the attachment decorator.

[llorllale]

My notes from our convo on this call:

• malicious issuer may impersonate another issuer by offering images that closely resemble the real issuer's
• some debate about whether the proposal's intention is for actual user data be included in the credential image "preview"

[llorllale]

IMO we should make it clear that this is a proposal for "credential previews" or "visual examples" of how the final issued credential would look like, and that we are not proposing issuing credentials as images (image/png)

[llorllale]

Can the issuer influence how the credential is rendered in the user's wallet after issuance? RFC 013 Overlays

[TelegramSam]

Notes from WG 20201104

• link to image, instead of including it?
• specify that the image should never be presented or transferred to a verifier
• collisions between images for different credentials, intentional or accidental.
• image size? show alternatives? links to assets of different sizes?
  • example in authy 2 factor app - defaults when not present
• allow user to augment or override the displayed image
• when issuing multiples, which images goes with which?
• Overlays (Paul's work)
• single image - matches whichever format chosen by the holder.

[ntsbs]

Regarding the questions from WG 20201104, @mickrau and I will try to attend the next WG, we watched the discussion and wanted to make some things more clear:

We do not intend to send this credential preview to verifiers.

• Why not include an image as a well-known attribute name in the credential offer?

  • This would be represented as a embed attachment, defined in RFC-0017

• Should user data be included in the credential data preview?

  • It should be optionally, since it would improve the recognition of some credentials
  • For example, some VCs which are based on well-known offline credential like passports can be easily recognized if their preview resembles the offline version

• Link to image, instead of including it?

  • It would be good to have both options
  • Linking makes the message itself smaller, which could be favored by the issuer
  • But including the binary image will enable the issuer to attach images without a hosted service

• Are collisions between images for different credentials intentional or accidental?

  • Depends on the issuer's credentials
  • Collision could be possible but should be minimized, otherwise the reason for credential previews from an UX side wouldn't make sense

• Image size? show alternatives? links to assets of different sizes?

  • We could require a minimum or default image size
  • Templates could be an option (see future work)

• Allow user to augment or override the displayed image?

  • Could be a feature an Agent would offer, but probably nothing we have to define in an RFC

• When issuing multiples, which images goes with which?

  • From RFC-0453: The arrays are provided to support the issuing of different credential formats (e.g. ZKP, JSON-LD JWT, or other) containing the same data (claims). The arrays are not to be used for issuing credentials with different claims.
  • Our understanding is that one credential-issue or credential-offer message will only represent one credential, just in different formats, therefore an attached credential image will only be associated with the offere/issued credential

What we see as work for the future:

• Common picture for verifiers to recognize credentials in proofs (recreate an image base on the credential data?)
• Templates for common credentials (e.g. Google Pay for Passes)
• Overlays with layout definitions per schema