- From: Daniel Hardman <daniel.hardman@evernym.com>
- Date: Mon, 19 Nov 2018 21:58:16 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAFBYrUrCTrr_2v+zNjqpGay0a=vCXJbD5pK65ia6zMPqkdU4gQ@mail.gmail.com>
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