Add section describing use of media types #1055
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -3409,6 +3409,45 @@ <h3>Syntactic Sugar</h3> | |||||
| </section> | ||||||
|
|
||||||
| </section> | ||||||
| <section> | ||||||
| <h3>Media Types</h3> | ||||||
|
|
||||||
| <p> | ||||||
| Media types as defined in [[RFC6838]] serve a useful purpose with verifiable | ||||||
| credentials, especially regarding identification of a particular syntax | ||||||
| that is in use with a verifiable credential. | ||||||
| </p> | ||||||
| <p> | ||||||
| Syntaxes SHOULD be identified by a media type, and certain conventions as | ||||||
| outlined in this section SHOULD be followed when defining or using media types | ||||||
| with verifiable credentials. | ||||||
| </p> | ||||||
| <p> | ||||||
| Any media types associated with the core data model are listed in the section on | ||||||
| <a href="#iana-considerations">IANA Considerations</a> for registration with IANA. | ||||||
| </p> | ||||||
| <p> | ||||||
| When defining a media type for use with verifiable credentials — for instance, in a | ||||||
| specification that defines a specific syntax — use of the term `verifiable` implies | ||||||
| the presence of a <a href="#proofs-signatures">proof</a> with the credential. | ||||||
|
There was a problem hiding this comment.
Suggested change
@OR13 note that i linked directly to the section that calls out both embedded AND external proofs intentionally here. perhaps some additional language as in this suggestion would help edit: to quote spec text i linked to There was a problem hiding this comment.
I feel like this spec text is being disputed by @iherman @TallTed @dlongley @msporny and possibly others.
(🔥 let us not register 2 media types that can be used for the "same bytes").
(🔥 let us make sure things are actually verifiable or credentials). Based on this comment: #1044 (comment)
processing from right to left...
Compared to...
There was a problem hiding this comment.
What a strange feeling... as I am not disputing that sentence at all. I cannot make heads or tails of the remainder of your comment. Maybe try writing full sentences, including what brought you to quote the chunks of draft and ratified RFCs? A reminder: "Classes" and "Types" do not require Media Types to be defined and useful. A "tiger" is a subtype of "cat", which is a subtype of "mammal", etc. None of these have Media Types, but they are all useful descriptors. A "CompactDisc" is disjoint from "CassetteTape" and both are disjoint from "VinylLP", but all are subtypes of "Audio Recording Media", so all might be considered Media Types ... but this typing is not handled by RFC nor IANA. There was a problem hiding this comment. @TallTed The line of argument you have here: #1055 (comment) Regarding There was a problem hiding this comment.
This is literally what the @TallTed has done an excellent job in various threads explaining these rules -- but I fear there continue to be some misunderstandings. There was a problem hiding this comment. Given the comment from @TallTed #1055 (comment) , then I would suggest we amend the proposals to be the following: PROPOSAL: The 1 media type for vc proposal, the working group will register PROPOSAL: The 2 media type for vc proposal, the working group will register There was a problem hiding this comment. @OR13 wrote:
The notion that you can't have two media types used for exactly the same set of bytes is provably wrong. For example:
In addition, we have the whole concept of structured syntax suffixes. I didn't understand how they worked until just a few years ago, and I can see that others in these threads on media types still don't understand how they work, which is resulting in some unworkable proposals/statements being put forward. Structured Syntax Suffixes are one of those rarely talked about/understood things about media types. They say for EXACTLY THE SAME SET OF BYTES, you can serve and interpret those bytes as:
So, four media types can be used for exactly the same set of bytes. This was established at IETF/IANA long ago, and is now being further documented because people are still confused about the point above. @OR13 wrote:
Yeah, I'm not disputing that either. You need a external/embedded proof of some kind for the thing to be a I would be a +1 for the first proposal directly above this comment (initially proposed by @OR13 and then refined outlined by @andresuribe87), with the caveat that the name of the media type is There was a problem hiding this comment. @msporny I'm not arguing you can't have different media types for the same bytes.... I am arguing against registered multiple media types for the same bytes with indistinguishable definitions in our spec. +1 to There was a problem hiding this comment.
The first question should be whether there's value in having the second media type, whether or not it is a supertype of the type we're primarily focused on. If there is such value (as I believe there is), then if it is a supertype (as I believe it is), I think we should register both, or only the supertype. (If it were a subtype, we might not register it, but there would be good reason to speak of it and to suggest a media type for it.) Remember that media types are not actively restrictive nor actively prescriptive in most applications, but are primarily hints about how to process the bytes within the resource labeled with that media type. In the world of the web, they're helpful for various tools to make known to a web server what form of resource those tools prefer such that the server can provide that, if available. (See RFC2295, among others.) It's perfectly valid for my super app to process resources of every media type in exactly the same way, if users of my super app find value in what my app outputs based on those inputs. There was a problem hiding this comment. @TallTed does this 3rd proposal capture your alternate single registration proposal? : PROPOSAL: The 1 media type for |
||||||
| This also applies when the term is abbreviated, as in other specifications, | ||||||
| such as in the [[VC-JWT]] specification's use of `vc+ld+json`. | ||||||
| Use of media types identified as `verifiable` in this way MUST correspond to | ||||||
| the use of one or more proofs with the credential. | ||||||
|
There was a problem hiding this comment. I get the intention here, but I don't think It would be nice to straw poll on I think there are several folks in favor of registering There was a problem hiding this comment.
yes - if we register There was a problem hiding this comment. The registrations have to be complete and independent.... If we register If WG members persist in asserting that There was a problem hiding this comment.
If we're to register If we're to register
Regardless of whether If we "persist" in permitting There was a problem hiding this comment.
this is exactly why putting proof in the credential and leaving a decision whether to validate a signature or not to a technical layer but to a business layer does not make sense to me. There was a problem hiding this comment. Whether to check a signature or not is always a business/application rules decision -- and one that you need to configure ahead of time in your software, before you receive anything from a party that might be an attacker. An attacker will just tell you not to check the signature. Media types don't solve this problem. Also, there are also plenty of applications that don't need to check signatures -- like simple JSON viewers. It would be a pretty significant annoyance to a developer if they weren't able to even see some JSON to do some debugging because a signature checker had to be run ahead of time and it was failing. There was a problem hiding this comment. @Sakurann wrote:
Allowing the attacker to pick when/how the receiver checks the signature, such as by triggering off of media type, is what is dangerous. The approach being described in the "trigger certain types of checking based on media type" approach is analogous to the
This isn't about technical layer vs. business layer... this is all "security layer" stuff, and the more you enable an attacker to pick the parameters for checking (such as via media type), the greater the attack surface. This PR is a better direction than the previous media type PRs because it allows us to spell out those rules/expectations regardless of media type... which is the right thing to do, IMHO. |
||||||
| </p> | ||||||
| <p> | ||||||
| Use of the term `credential` in a media type related to a syntax of verifiable | ||||||
| credentials <i>without</i> the corresponding use of `verifiable` as described above <i>does not</i> | ||||||
| imply the presence of a proof with the <a href="#dfn-credential">credential</a>. | ||||||
| </p> | ||||||
| <p> | ||||||
| At the time of this writing, there are two media types associated with the core data | ||||||
| model: `application/credential+ld+json` and `application/verifiable+credential+ld+json`. | ||||||
|
There was a problem hiding this comment. Notably, we haven't actually defined the latter one yet, but this is just an informative thing that can be changed as needed. There was a problem hiding this comment. exactly - especially given the discussion on #1034 re There was a problem hiding this comment. @msporny has requested to use There was a problem hiding this comment.
Suggested change
|
||||||
| Other specifications such as [[VC-JWT]] define additional media types as may be | ||||||
| required to allow for proper interpretation of the syntax of verifiable credentials | ||||||
| encoded in the syntax described by the respective specification. | ||||||
| </p> | ||||||
| </section> | ||||||
|
|
||||||
| <section> | ||||||
| <h3>Proof Formats</h3> | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yikes to this... I might defer this language to a separate PR to avoid blocking this valuable other changes.
proofis NOT required to make aVerifiableCredential... asserting thatproofmakes aVerifiableCredentialimplies data integrity proofs as a defacto standard representation / serialization for the core data model.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah - this is one reason why i wanted this as a draft first - we do i think want to note that some cryptographic proof is there, not necessarily that it is in the credential as an embedded proof (as it often is not) but that it should be present according to the securing method in use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this paragraph on "proof" ? and move it to an issue to discuss?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#1060 opened, paragraph removed to refine language