Clarify relationship bx securing mechanisms and media types #1107
Conversation
…sms and media types Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
brentzundel
requested review from
msporny,
OR13,
selfissued,
decentralgabe and
awoie
as code owners
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
index.html
Outdated
| mechanism. It describes an object that is securable. Other specifications | ||
| defining media types that begin with `application/vc+` SHOULD NOT define those | ||
| media types to imply any particular securing mechanism. |
There was a problem hiding this comment.
I had to read this last sentence a number of times and I'm still not sure I understand what it's saying.
I think it's saying: "This core spec doesn't imply a securing mechanism, and other media types shouldn't imply a securing mechanism either"...
IOW, "that other thing might have proof and experimentalSecuringMechanism and be wrapped in a CWT (or any combination thereof), so... you can't presume any of those things... you're just going to have to verify it using your own checks to see if it truly is verifiable, and then validate it to make sure it meets your business requirements."
I don't know how to say that more succinctly... once we have confirmation on the intent, we can probably go from there.
As an aside, it sounds like we're starting to collect: "Normative statements for specification authors that are authoring other specifications that contain transformation rules to application/vc+ld+json."
There was a problem hiding this comment.
I agree, I would remove this:
Other specifications
defining media types that begin with `application/vc+` SHOULD NOT define those
media types to imply any particular securing mechanism.
A general statement about media types here might be:
Implementers are advised not to assume veracity or security of content regardless of the media type used to communicate it. A validation process needs to be applied to confirm integrity, media types should not be trusted, or assumed to be secure without confirming by some validation process.
There was a problem hiding this comment.
This has been refactored in 0d5dbd9
index.html
Outdated
| media type. Media types that allow for transformation into | ||
| `application/vc+ld+json` SHOULD begin with `application/vc+`. |
There was a problem hiding this comment.
I think this is good. I was wondering if we should say anything at all about this... the upside of not saying something is that other media types like application/foo could have a section about transformation into a VC w/o having to register two media types; application/foo and application/vc+foo... maybe the argument there is that the thing that's important is the transformation rules, not the media type? Does differentiating it via a new media type always help?
I'm fine w/ the text above for now, and it is a SHOULD so, people that are working on application/foo can choose to ignore it because they're concerned about media type proliferation. If they ignore the advice, my expectation is that we'd still add them to the VC Specifications Directory.
To be clear, this isn't a change request, just noting thoughts hoping others will engage in a discussion on the benefits/drawbacks of the specification requirement.
There was a problem hiding this comment.
I'm a bit concerned that talking this way about application/vc+ suggests that there's a single way to deal with any and all such media types, though the way to deal with a media type is most simply determined by the outer edges of the media type -- e.g., application/vc+ld+json is most simply handled as application/json, not as application/vc+.
There was a problem hiding this comment.
This has been refactored in 0d5dbd9
There was a problem hiding this comment.
I think we should remove or refactor this sentence:
https://github.com/w3c/vc-data-model/pull/1107/files#r1180475199
The rest of the PR looks to be in pretty good shape.
This has been refactored in 0d5dbd9 |
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
Co-authored-by: Andres Uribe <andresuribe87@gmail.com>
|
@OR13 please re-review and let me know if you would like any more changes |
|
Waiting on review by @OR13 to merge. |
| @@ -3404,6 +3397,13 @@ <h3>Media Types</h3> | |||
| those other syntaxes to be transformed to the `application/vc+ld+json` | |||
| media type. | |||
| </p> | |||
| <p> | |||
| The media type `application/vc+ld+json` does not imply any particular securing | |||
There was a problem hiding this comment.
Not sure this is true, it implies at least the possibility of DataIntegrityProof based on the current normative requirements regarding proof and @context.
There was a problem hiding this comment.
The language suggested in this PR is an attempt to clarify that in spite of the requirement to include a specific @context, and in spite of that @context containing references to a specific securing mechanism, no specific securing mechanism should be assumed. Just because the @context points to data integrity doesn't mean the data has been secured.
Happy for further suggestions on how to better communicate that here.
index.html
Outdated
| mechanism. It describes an object that is securable, but a securing mechanism | ||
| needs to be applied to enable verification of integrity. This also applies to | ||
| media types that allow for transformation into `application/vc+ld+json`. Do not |
There was a problem hiding this comment.
| mechanism. It describes an object that is securable, but a securing mechanism | |
| needs to be applied to enable verification of integrity. This also applies to | |
| media types that allow for transformation into `application/vc+ld+json`. Do not | |
| mechanism. Do not |
There was a problem hiding this comment.
"It describes an object that is securable, but a securing mechanism needs to be applied to enable verification of integrity." This sentence hurts... and I think we are doing a better job of addressing it in:
There was a problem hiding this comment.
I have reworked that sentence in an attempt to make it less painful in 1e350e3
There was a problem hiding this comment.
I agree with the intention of the PR, but I think it does not reflect the current normative requirements and their interpretation by developers.
This paragraph seems to contradict existing requirements.
Perhaps a smaller paragraph can be made compatible with the existing requirements, and we can adjust / add more, if we are able to reach consensus on the related open PRs.
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
|
The issue was discussed in a meeting on 2023-05-10
View the transcript1.5. Clarify relationship bx securing mechanisms and media types (pr vc-data-model#1107)See github pull request vc-data-model#1107. Manu Sporny: PR 1107 - topic clarifying relationship between securing mechanisms and media types. Orie Steele: needs to review recent changes. |
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This PR attempts to add some clarity around the relationship between securing mechanisms and media types.
It primarily uses language suggested in Issue #1065.
It adds that media types defined that allow for transformation into application/vc+ld+json should begin with application/vc+
It states that application/vc+ld+json does not imply any securing mechanism
it states that other media types should not imply any securing mechanism
I removes the note about Issue #1065
fixes #1065
Preview | Diff