Re: Content-type and/or file extension for Verifiable Credentials and Verifiable Presentations

On 11/19/2018 05:56 PM, David Elie Raymond Christophe Ammouial wrote:
> I believe this is one or one of my first emails to the list, so I
> hope I’m not breaking any group rule or best practice. :)

Not at all, welcome to the group, David. :)

... and with such an excellent first question to the community...

> I wonder what the adequate content type and extension for a
> Verifiable Credential or a Verifiable Presentation using JSON
> serialisation would be. I’m working on software that understands and
> emits VCs. I looked through recent threads but couldn’t find any
> related discussion – I apologise if there is one and I missed it.

We've discussed this here and there, but with no firm decision yet. Let
me try and give some background wrt. where we are with this question at
the moment.

For those of you that aren't familiar with content types (also known as
MIME Types) on the Web, every "type" of file is typically given a
content type. For example, a text file is "text/plain" an HTML file is
"text/html" and a JPEG file is "image/jpeg".

Content Types are useful when browsers ask a web server for a resource.
For example, when fetching "https://example.com/about" a browser may ask
for "text/html" (which may be a fancy page with images, music, etc.),
while an assistive device for someone with a vision and hearing
disability may ask for "text/plain"... which is just the text with none
of the distracting images, etc.

Translating this into the world of Verifiable Credentials, it may be
useful for there to be a human-readable web page expressing a verifiable
credential (such as a bike for sale - https://example.com/sale/bike-123)
and a machine readable data file expressing the same thing (a bike for
sale). How would a machine request the Verifiable Credential associated
with that web page?

There are two approaches contemplated at the moment.

The first is to embed the JSON-LD version of the Verifiable Credential
in the HTML web page (this is how schema.org works - 150 million+
domains do this today).

The second is to allow the client to content negotiate with the server,
which you'd need a content type for Verifiable Credentials in order for
that to work.

> We can always use “application/json” and probably a “.json”
> extension for files, but it might make sense to register something
> more precise with IANA, such as “application/vc+json” and
> “.credential”.

The current content type for JSON-LD is "application/ld+json"... and
frankly, that's all you need because JSON-LD has a more decentralized
and dynamic typing system than the IANA registry. You could use a
".jsonld" extension and be done, no more specific extensions required to
the IANA registry with all of the benefits of a new content type.

We could also create a subtype, so "application/ld+json+vc" ... but that
content type is a bit weird... it really should be
"application/ld+vc+json", but that expression would break the typical
hierarchical way applications search for content subtypes. Putting that
aside, we could create a new subtype and register it in IANA.

I've heard a few arguments against content negotiation, but none that
have really resonated. Don't know if there are any on this mailing list
are anti-Content Negotiation.

Another complication is the current JWT vs. LD-Proofs discussion we're
having, where the top level encoding could differ wildly for JWTs vs.
LD-Proofs vs. ZKPs.

> Another aspect of the question is whether VCs and VPs should share
> the same content type and only differ from their “@type” property, or
> use separate ones.

Yes, another good question. That is, do we do something like
"application/ld+json+vc" and ".vc" or "application/ld+json+vp" and ".vp"
... or just the first one.

Again, not many have strongly asserted needing something beyond
"application/ld+json" and ".jsonld".

I should mention that the Verifiable Credentials spec goes into feature
freeze soon, so the window to add something more specific is slowly closing.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Tuesday, 20 November 2018 02:17:49 UTC