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

Manu Sporny wrote:
> Not at all, welcome to the group, David. :)

Thanks!


> Content Types are useful when browsers ask a web server for a resource.

Content negotiation is indeed one nice feature of Content Types.

Another one is content subscription. For instance in mobile or desktop
environments, certain applications may subscribe to certain content
types and thus request to be called whenever a resource with that
content type is to be opened.

As a simpler feature, content detection may also enable applications
to inform the user of the purpose of a given file, although the file name
itself ought to be a good source of information as well.

> 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).

Microformats are great indeed and are probably a nice format for
distribution of VCs and VPs, although I haven't seem too many examples
of that in the specs and the discussions -- most example use JSON-LD
as a transport format.

> 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.

Agreed.

> 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 would have said "application/vc+ld+json", since it seems that extension
of existing types is done from the left, e.g. "application/json" extends as
"application/ld+json". I'm not quite familiar with that bit of the process
though, so maybe having more than two words as subtype is not allowed
at all. At any rate, extending another type requires registration just like
creating a completely new type.

> 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.

I would say that is independent. As I see it, the scope of this discussion
is simply which content-type is adequate for the JSON-LD serialisation
of VCs. That doesn't dictate anything about VCs expressed in a different
format, as those would call for a different content type (if applicable at
all), just like in the example you mentioned of selecting text/plain or
text/html for the same semantic content.

Thanks.
--
David
https://www.w3.org/users/103593

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

Received on Tuesday, 20 November 2018 04:38:18 UTC