Add section describing use of media types #1055
Conversation
| </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 verifiable-credential vs verifiable+credential this gives us a good way to get aligned
There was a problem hiding this comment.
@msporny has requested to use vc+ld+json elsewhere, which I agree with, but we can leave it like this for now I think.
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
Co-authored-by: Dave Longley <[email protected]>
index.html
Outdated
| <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.
Yikes to this... I might defer this language to a separate PR to avoid blocking this valuable other changes.
proof is NOT required to make a VerifiableCredential... asserting that proof makes a VerifiableCredential implies data integrity proofs as a defacto standard representation / serialization for the core data model.
There was a problem hiding this comment.
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.
Can we remove this paragraph on "proof" ? and move it to an issue to discuss?
There was a problem hiding this comment.
#1060 opened, paragraph removed to refine language
index.html
Outdated
| 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. | ||
| This is also the case if the term is abbreviated in accordance with other specs, such as in `vc+ld+json`. |
There was a problem hiding this comment.
I think it is best to let those "other specs" speak for themselves and not constrain them here.... I feel similarly regarding data integrity proofs.
index.html
Outdated
| the presence of a <a href="#proofs-signatures">proof</a> with the credential. | ||
| This is also the case if the term is abbreviated in accordance with other specs, such as in `vc+ld+json`. | ||
| Use of media type identified as `verifiable` in this way MUST correspond with | ||
| 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 verifiable is correct... I think verifiable-credential is correct.
It would be nice to straw poll on verifiable vs verifiable-credential registration options. Just to see the preferences.
I think there are several folks in favor of registering verifiable+credential+ld+json.
There was a problem hiding this comment.
I think there are several folks in favor of registering
verifiable+credential+ld+json
yes - if we register credential then the + syntax would make likely the most sense
There was a problem hiding this comment.
The registrations have to be complete and independent....
If we register verifiable+credential+ld+json we would have to register credential+ld+json if we wanted to be able to distinguish between bytes.
If WG members persist in asserting that proof is allowed in credential+ld+json I suggest we only register verifiable+credential+ld+json, and that we NOT attempt to define credential+ld+json... since proof will always be allowed (but not required) in verifiable+credential+ld+json....
There was a problem hiding this comment.
If we register
verifiable+credential+ld+jsonwe would have to registercredential+ld+jsonif we wanted to be able to distinguish between bytes.
If we're to register application/verifiable+credential+ld+json, we would have to register application/credential+ld+json because it's required by the RFC which enables multiple + in registered Media Types, whether or not we want to be able to distinguish between bytes.
If we're to register application/verifiable-credential+ld+json, we would not have to register application/credential+ld+json because this is permitted by the RFC which enables multiple + in registered Media Types.
If WG members persist in asserting that
proofis allowed incredential+ld+jsonI suggest we only registerverifiable+credential+ld+json, and that we NOT attempt to definecredential+ld+json... sinceproofwill always be allowed (but not required) inverifiable+credential+ld+json....
Regardless of whether proof is allowed in application/credential+ld+json, if we register application/verifiable+credential+ld+json we must register (which means we must define) application/credential+ld+json because it's required by the RFC which enables multiple + in registered Media Types.
If we "persist" in permitting proof in credential+ld+json, we'll have no need for application/verifiable+credential+ld+json (nor application/verifiable-credential+ld+json) because the questions of whether there's a proof and whether it "proves" the credential comes down to business logic (which may include the application of various cryptomath).
There was a problem hiding this comment.
If we "persist" in permitting proof in credential+ld+json, we'll have no need for application/verifiable+credential+ld+json (nor application/verifiable-credential+ld+json) because the questions of whether there's a proof and whether it "proves" the credential comes down to business logic (which may include the application of various cryptomath).
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.
entity receiving a thing needs to know whether it is required to verify a signature or not. "I will not validate a signature because i don't need to do so for my business, regardless of whether the thing is signed or not" sounds pretty dangerous.
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:
"I will not validate a signature because i don't need to do so for my business, regardless of whether the thing is signed or not" sounds pretty dangerous.
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 alg=none and HMAC flaws in the JOSE stack (that enable the attacker to decide how and what the server checks):
- https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
- https://medium.com/@phosmet/forging-jwt-exploiting-the-none-algorithm-a37d670af54f
- https://cyberpolygon.com/materials/security-of-json-web-tokens-jwt/
- https://www.youtube.com/watch?v=zWVRHK3ykfo
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.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
index.html
Outdated
| <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.
| the presence of a <a href="#proofs-signatures">proof</a> with the credential. | |
| the presence of a <a href="#proofs-signatures">proof</a> with the credential either embedded or external to the credential. |
@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 At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.
There was a problem hiding this comment.
At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.
I feel like this spec text is being disputed by @iherman @TallTed @dlongley @msporny and possibly others.
Media types MAY be registered with more than one suffix appended to
the base subtype name. The suffixes MUST be interpreted as ordered.
Valid media type names containing a structured suffix are built from
right to left (not left to right). Characters on the left-most side
of the left-most "+" in a subtype name specify the base subtype name.
Characters to the right of each "+" in a subtype name denote
additional structured syntax suffixes.
Media types with more than one suffix MUST be registered according to
the procedure defined in [RFC6838]. A new base subtype name MUST
only be registered with suffix combinations that are already
registered in their own right in the Structured Syntax Suffixes
registry (https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml).
While it is possible for a given media type to be assigned additional
names, the use of different names to identify the same media type is
discouraged.
(🔥 let us not register 2 media types that can be used for the "same bytes").
Media types that make use of a named structured syntax SHOULD use the
appropriate registered "+suffix" for that structured syntax when they
are registered. By the same token, media types MUST NOT be given
names incorporating suffixes for structured syntaxes they do not
actually employ. "+suffix" constructs for as-yet unregistered
structured syntaxes SHOULD NOT be used, given the possibility of
conflicts with future suffix definitions.
(🔥 let us make sure things are actually verifiable or credentials).
Based on this comment: #1044 (comment)
VerifiableCredential might contain proof (modified since proof is actually optional in VerifiableCredential.)
VerifiableCredential is a subtype of Credential
processing from right to left...
- is the
credential...json? - is the
credential...ld+json? - is the
credential...verifiable+ld+json? (does this violate the MUST NOT or SHOULD NOT from the RFC?)
Compared to...
- is the
verifiable...json? - is the
verifiable...ld+json? - is the
verifiable...credential+ld+json? (does this violate the MUST NOT or SHOULD NOT from the RFC?)
There was a problem hiding this comment.
At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.
[@OR13] I feel like this spec text is being disputed by @iherman @TallTed @dlongley @msporny and possibly others.
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 proof, is what leads me to believe that you do not see a difference in information between credential and verifiable credential.
There was a problem hiding this comment.
let us not register 2 media types that can be used for the "same bytes"
This is literally what the + syntax does in media types. You can describe the string {} using either application/json OR application/ld+json today. There are numerous other examples with +xml suffixes and others. This subclassing is done on purpose to enable many different use cases.
@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 verifiable-credential+ld+json and the working group will not register credential+ld+json.
PROPOSAL: The 2 media type for vc proposal, the working group will register verifiable+credential+ld+json and the working group will register credential+ld+json.
There was a problem hiding this comment.
@OR13 wrote:
let us not register 2 media types that can be used for the "same bytes"
The notion that you can't have two media types used for exactly the same set of bytes is provably wrong.
For example:
application/octet-stream can be used for any binary data that the server can't determine a more specific media type for, such as application/efi. application/xml can be used for any of the roughly 400+ media types that use XML as their serialization mechanism.
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:
application/verifiable+credential+ld+jsonapplication/credential+ld+jsonapplication/ld+jsonapplication/json
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:
being disputed [@OR13] #1055 (comment) by @iherman @TallTed @dlongley @msporny and possibly others.
@TallTed wrote:
What a strange feeling... as I am not disputing that sentence at all.
Yeah, I'm not disputing that either. You need a external/embedded proof of some kind for the thing to be a verifiable credential.
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 vc+ld+json (where the bikeshedding thereof doesn't need to hold up the decision).
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 vc+ld+json
There was a problem hiding this comment.
I am arguing against registered multiple media types for the same bytes with indistinguishable definitions in our spec.
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 credential proposal, the working group will register credential+ld+json and the working group will not register verifiable+credential+ld+json.
There was a problem hiding this comment.
Let's strip down what we can.
Specifically this part: https://github.com/w3c/vc-data-model/pull/1055/files#r1127041668
^ lets move that to an issue to discuss.
| </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.
| model: `application/credential+ld+json` and `application/verifiable+credential+ld+json`. | |
| model: `application/credential+ld+json` . |
|
Normative, multiple reviews, changes requested and made, Joe's suggestion needs to be merged to pull this in, some editorial changes will be made after the merge, further normative changes might be made based on discussion on the call today, no outstanding objections, merging (in a few hours). |
|
The issue was discussed in a meeting on 2023-03-07
View the transcript1.2. Add section describing use of media types (pr vc-data-model#1055)See github pull request vc-data-model#1055. Brent Zundel: In PR #1055, it adds a section describing the use of media types. There's some conversation, a little back and forth, but in general, this adds some normative guidance around media types in general.. Manu Sporny: Generally supportive of this PR. One of the good things it does, before we were making normative statements in the IANA registration section, that was dicey and this is better. This just talks in general of what's expected of certain media types. I think we can more easily put normative statements in here and there are some arguments around what's testable or not.. Orie Steele: I'm supportive of merging the PR. I'm several others that I'm the author of that I would close and I would move content from them into a new section or open new PRs to do that. Merging this will unblock several PRs that are currently blocked in my opinion.. Brent Zundel: I will note that this PR has been open for a week. I will note that there is one request for changes from TallTed, I believe those changes have been made.. Ted Thibodeau Jr.: I don't think there's anything remaining, this PR makes substantial improvements from what was there before and even if I need to make a new PR to adjust, I'm good.. Joe: How is this related to the single base media type? The language I'm reading doesn't clarify that one of those two is the base media type and one of those should be transformable into the base.. Orie Steele: I don't think this PR addresses what happened at the F2F in Miami, but it opens the door for it. It does mention the base media type by name. I think there are so many other PRs open about this topic of media types that I think it would be better to merge this PR and open a new one that's dedicated to summarizing the outcome from the F2F..
Brent Zundel: This PR creates a media type section, it moves some text from IANA registrations into this section and seeks to begin the normative guidance for use of media types. I think Mike Prorock did a pretty good job of avoiding normative statements -- setting the stage for those without making them so much yet.. Ted Thibodeau Jr.: Yeah, I just want to voice that I've typed a few times now. There was and there often is a substantial push to "make decisions" at a F2F, because theoretically having people in the room means better decisions. I disagree with that that is always the case and I think blind adherence to those sessions can be to the detriment of the spec and all of us.. Joe Andrieu: Politely, I want to push back on that. I think we need to make decisions and move forward. I think as a group we have the base media type
Phillip Long: The way I heard TallTed talking about the issue was relevant to a comment he made in the PR a few days ago. He reminded us that media types aren't actively prescriptive or restrictive. I think adding a media type doesn't preclude us from adding or removing another one later. I think this is better as it moves the text from the IANA registration to the spec. And I think, as Orie said, this frees up more PR work to move forward..
Phillip Long: As long as we're clear that we can add/remove/change media types, this is a good step forward..
Manu Sporny: I think Joe's correct, I think it's totally appropriate to just list the one we decided on in the WG call and we're just having the second media type discussion shortly.. Brent Zundel: Ok, we wouldn't pull it in now, I think it's appropriate for MikeP to see Joe's comments on the PR..
Brent Zundel: I'm not hearing any objections to merging the PR with Joe's change.. |
This is intended to be a work in progress PR to help achieve consensus on the right location for describing requirements and best practices around use of media types with VCs. I believe that this PR should form a basis to close without merging #1014 as the normative language in that PR is probably in the wrong section and does not have consensus. This PR also may provide guidance around how to proceed with #1034
Preview | Diff