Credential attribute for images/photos

[cvarjao]

Context

Issuing credentials with photo attribute(s)

Problem

How a holder/wallet app knows that an attribute is an image element and render the attribute as an image.

Solutions

1. Adopt attribute value convention convention based on data scheme. Wallet apps can easily identify if a value starts with data:
   Note: This is a generic approach that could work for any type of rich content (Image, Document/File)
2. Introduce an attribute name suffix (_img) convention (like _dateint).
   Note: Just the "_img" doesn't tell the type of image (e.g.: JPEG, PNG, etc)
3. OCA bundle is required for that sort of formatting, and when OCA is not provided by the attribute value will be presented in a not so nice manner.

Notes

• What is the user/holder experience expectation when/if an OCA bundle is NOT provided?

Reference

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs

[swcurran]

Is the basic idea that we have a convention for attribute naming, similar to the “_dateint”, for images, and use a data URL to get the rest of the information about the format? Something like “_img”?

Any other details to convey in the RFC?

[TimoGlastra]

For AnonCreds there's the credential preview mime type that can be used, although I'm a fan of looking at an approach to do it within the credential, as that means you're not dependant on didcomm protocol data to have this information

[swcurran]

FYI -- the data URL is IETF RFC 2397.

I think this fits best as an Aries RFC, with implications for the OCA Bundle approach as well. However, we have to agree on the best approach from @cvarjao 's ideas (above), or any other approach.

• Simply putting data:... in the raw attribute value means there is an overhead for every attribute of every credential -- checking the data on receipt (sniffing the value) before processing/displaying on a screen. It has the advantage of being useful for other than just images, as any mime/type can be used in the URL scheme.
• Requiring the issuer to name the attribute with a specific suffix _img is ugly, but makes detection before display easy. It (more or less) eliminates the opportunity to use data for any other purpose.

To be discussed on the Aries Working Group call on 2023.03.29.

[swcurran]

Discussed at the Aries Working Group call on 2023.03.29. Agreement to proceed with an RFC that proposes to use approach 1 (use data:... URL to hold the image) and 3 (OCA) only, and to not bother with using the _img suffix. As pointed out by Warren Gallagher, the overhead of "sniffing" the data value for data: is the same as the overhead for sniffing the attribute type for the suffix _img, so that is a wash. There are other ways to convey an image that might be explored (and others are welcome to do so) such as via a hashlink as the attribute data value, or by using Credential Supplements with the attribute holding data to indicate the supplement, but the basic approach proposed here is the easiest and most straight forward approach for immediate implementation. This and other solutions are not mutually exclusive.

Action is for @swcurran to propose an RFC that outlines the approach.

An interesting issue is raised in combining the use of a data: URL with OCA, as the OCA bundle could also contain the MIME type and encoding (or not) that is in the data attribute itself. Issue #21 opened against the OCA Specification to ask for suggestions on handling that.