RFC 0036 and 0037: remove mime-type and encoding from previews?

[dhh1128]

I'm concerned about the use of mime-type and encoding in previews. The vast majority of properties in credentials should be scalar values (strings or integers or floats or dates). There are no mime types for such things, AFAIK (text/plain is given as a default value; do any other values make sense?). So having a property named mime-type doesn't make sense to me. I'm not sure that encoding makes any sense, either. We don't give any meaningful guidance about values for the property, other than to say that its default is null. If we mean encoding in the way that Indy means it, do we need to say that?

@sklump @swcurran @kdenhartog

[sklump]

These came about from the solution for JIRA IS-1281, where Mr. Daniel Hardman was interested in passing large binary objects as credential values.

MIME TYPE:
The holder proposing a new credential for a photo, for example, can use this mechanism to submit an encoded photo, but the issuer needs to be able to interpret it: is it a BMP? A JPEG? A PNG? An SVG? Etc?

Similarly, in negotiating with a prover proposing a binary attribute, the verifier must be able to render it (e.g., a picture for facial recognition) to judge its applicability.

As is, MIME type defaults to text/plain; implementations that don't use it can leave it out.

ENCODING
To be 7-bit safe in passing binary data as an attribute value over the wire (and/or to allow for copy/paste), it ought to be encoded in some way. Typically, this would be base64. It could however be base58, base85, base32, uuencode, etc. The recipient has to be certain how to reconstitute the original.

As is, encoding defaults to no encoding; implementations that don't use it can leave it out..

OPTIONS
If we are going to scrap the work we did in fulfillment of JIRA IS-1281, we can take out the metadata from both Aries#0036 and Aries#0037. Say the word and I will propose it.

[dhh1128]

That's funny that I'm being so inconsistent. Good catch. :-)

I don't want to scrap the work you did on embedded photos and such in credentials. It was a wonderful contribution. We need it.

However, I do think the preview as currently structured isn't modeling the issue correctly. The need seems to be:

1. Tell someone what values are going to be used for certain fields, if the interaction proceeds.
2. Give a person enough metadata about each field that it can be rendered correctly if the preview is shown to a human being.

Most fields in credentials are going to be numbers, strings, or dates--not embedded photos. So adding a mime type and encoding for all attributes, just to cover the corner case of embedded photos, doesn't seem right. A number is not compatible with the MIME type "text/plain", so that's not an acceptable default, either.

What if we did something like this:

• The two required values for each field in the preview array are name and value. For most ordinary fields, these are the only two properties that appear in the preview.
• We keep mime-type as an optional field, but we drop encoding. Encoding is always base64 if the mime-type is something other than text/*, or in other words, we only use mime-type when a string is the base64-encoded version of some other form of data. The default value when mime-type is not specified is not text/plain, but rather null.
• The datatype of each field should be derivable from the schema, so we don't need any metadata to tell us that a string is an ISO 8601 date versus plain text versus an email, etc.

[sklump]

I have submitted another PR with implicit encoding by MIME type for #36 and #37.

[kdenhartog]

I see the PR for this has gone through. Can we close this issue now?

[dhh1128]

Yup.