RFC 0780 -- Use Data URLs for Images and More in Credential Attributes #780
Conversation
Signed-off-by: Stephen Curran <swcurran@gmail.com>
| an attribute holding a JSON data structure with an array of values may not | ||
| easily be displayed. | ||
|
|
||
| ## Rationale and alternatives |
There was a problem hiding this comment.
Is this something that may be standardized and encouraged at the anoncreds level? This is already a common pattern for W3C credentials I believe, and with anoncreds / credentials becoming more separated from the exchange layer it allows credentials to be interoperable across exchange protocols.
Aries defined a way in the issue credential protocol to add mime types in the credential preview, but now that anoncreds is usable outside of Aries, it makes sense to add a native way to do this in the AnonCreds spec maybe?
There was a problem hiding this comment.
In writing this, I was trying to keep this approach independent of the VC format. AnonCreds does not care if you use this. AnonCreds will detect the attribute raw value is a string, and create the encoded value corresponding to the string. As such, I don’t think it is helpful to do this down at the VC format level. If anything, this is a business level issue and so higher in the stack — hences at the Aries community (RFC) level.
There was a problem hiding this comment.
Also — this has nothing to do with Credential Preview. This is putting the MIME type into the attribute itself.
There was a problem hiding this comment.
In writing this, I was trying to keep this approach independent of the VC format
i think my point is that it may be more useful to standardize the approach on the VC format level, rather than the exchange level. A credential may be exchanged over numerous exchange protocols, but it will always be same credential.
Also — this has nothing to do with Credential Preview
I used the credential preview as an example, it's the current way to exchange the mime-type for attributes (and not so ideal, as it's only available when using didcomm as the exchange). Standardizing using the data URL in credential values means it can also be used outside of didcomm as the exchange (which is an advantage over using the credential preview), however it still isn't standardized outside of DIDComm for e.g. AnonCreds (not sure if there's anything standardized for w3c vcs, but it's common practice to use data urls I think).
There was a problem hiding this comment.
I (weakly) disagree that this is a "credentials data model" type issue -- AnonCreds/W3C Spec. Those specs are agnostic to the data formats in applications. This is a higher level concern -- how the VCs are used in applications. For example, in the W3C Data Model, this might be part of the JSON-LD context information for an attribute. Likewise, this might also be described in OCA Bundles.
I see the argument and would not object to those specs adding a note encouraging the use of Data URLs, but I still think it is appropriate for the Aries community to say "Issuers MAY use these in credentials, and holders and verifiers should be prepared to process them."
|
Discussed on the Aries Working Group call on 2023.06.28 and there was agreement to merge. @TelegramSam @TimoGlastra @dhh1128 -- could one of you please approve? |
This PR is a new RFC proposing that verifiable credential issuers of attributes that contain or than strings and numbers use Data URLs (IETF Standard 2397) to convey to Holders and Verifiers the MIME Type and encoding of the attribute. This is particular useful for use cases of photos in attributes, and for attributes that hold a JSON data structure, such as an array of values.