W3C home > Mailing lists > Public > public-credentials@w3.org > November 2018

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

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Mon, 19 Nov 2018 21:58:16 -0700
Message-ID: <CAFBYrUrCTrr_2v+zNjqpGay0a=vCXJbD5pK65ia6zMPqkdU4gQ@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Credentials Community Group <public-credentials@w3.org>
I thought the VC spec defined a data model--with the representation as
JSON-LD or something else as explicitly out of scope. This doesn't seem to
match up with a discussion about how to characterize a file format. Is
there some missing context here that I don't know about?

On Mon, Nov 19, 2018 at 7:19 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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 04:58:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:50 UTC