Comments (11)
I maintain my position that application/sd-jwt
should be considered akin to application/zip
, and application/vc+ld+json
should be a result (not the result; an application/sd-jwt
may contain various other subtypes of application/json
) of extracting the content of an application/sd-jwt
just as text/plain
or image/png
or example/example
might be the result of unzipping an application/zip
.
ZIPs don't get subtyped based on their content; neither should SD-JWTs.
from vc-data-model.
As I wrote at https://mailarchive.ietf.org/arch/msg/oauth/vDitVdgDfL4ZXzPdvquoCj_fYbY/, I believe it would be better to update our registrations to prohibit the use of media type parameters, to increase the likelihood of interoperability.
from vc-data-model.
My understanding is that media type [multiple-]suffixes are for signalling subclasses (more restricted expressions of a flexible syntax) that do not have to be used or understood by more general consumers of the flexible syntax. By way of example:
For the media type: application/square+rectangle+shape
, each of the following consumers could expect to parse / use data associated with it:
- Square consumers
- Rectangle consumers
- Shape consumers
This is fundamentally different from a media type such as this (which I consider erroneous usage):
application/note+envelope+mailtruck
Whereby "Note consumers" and "Envelope consumers" would be unable to consume this payload -- and only "Mailtruck consumers" could.
In my view, using media type [multiple-]suffixes is not for use cases that involve wrapping a data format in another wrapper that changes its syntax / general structure, etc. (aka "an envelope").
from vc-data-model.
Nothing needs multiple suffixes, they are hints for specific processors (such as browsers) to provide a better experience than downloading a file... that makes them a nice to have imo.
https://www.w3.org/TR/activitystreams-core/#media-type
application/activity+json; profile="https://www.w3.org/ns/activitystreams"
application/ld+json; profile="https://www.w3.org/ns/activitystreams"
application/vc
this would be a media type for conformant documents? (compact JSON-LD).
application/vc+sd-jwt
this would be a media type for a specific form of conformant document (SD-JWT secured JSON-LD payload.
from vc-data-model.
I agree with @selfissued.
Implementers ignore media type parameters a non-trivial amount of the time. They are mauled by middle-boxes in unexpected ways (usually removed). We used them for JSON-LD, which was (IMHO) a mistake that optimized on the belief that implementers would get it right most of the time (they didn't). Use of media type parameters is always well intentioned by specification authors, and then botched by a non-trivial number of implementers.
I might be ok with saying that people can use them (but cringe at the possibility), and suggesting how to use them, but we shouldn't specify algorithms and write software that counts on their proper usage.
from vc-data-model.
@jyasskin wrote:
multiple suffixes ... it sounds like that draft is having trouble getting to consensus over in the IETF.
I'm the (reluctant) Editor of that specification. It's taking longer than any of us would like, but we're down to one issue: whether or not all suffixes in a chain of structured suffixes need to be registered (via concrete specs), needs to be registered (but some can be a no-op), or not be registered (which received objections during IETF 118). The IETF MEDIAMAN Chair would like to take it to IETF WGLC before/during IETF 119.
Might it speed things up to use the application/vc and application/vc+sd-jwt media types instead, and avoid waiting for the MEDIAMAN WG to figure out multiple suffixes?
We don't have to wait for MEDIAMAN to figure out multiple suffixes. DID Core went to REC w/ this note: https://www.w3.org/TR/did-core/#application-did-ld-json ... we can do the same here. BUT, I expect we won't have to this time based on all of the effort that's gone into suffixes since DID Core v1.1.
The +ld+json bit of those media types isn't doing much work. It could tell a generic JSON or JSON-LD processor that they could give better debugging output by rendering in those formats, but they won't be able to parse the VC.
It's doing important work, namely:
- Signalling to JSON environments that the format can be parsed, linted, highlighted, stored, retrieved, and utilized using general JSON tooling.
- Signalling that RDF toolchains that understand JSON-LD can merge the information into knowledge graphs and other forms of RDF databases.
- Providing the pathway for
[application/vc+ld+cbor](https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jul/att-0004/Introduction_to_CBOR-LD.pdf)
, which is deployed in production today and expected to be standardized over the coming years at W3C.
All that said, I do acknowledge that we have a problem w/ application/vc+ld+json+sd-jwt
... namely that it seems like we're going to have to register +json+sd-jwt
and +ld+json+sd-jwt
to avoid objections from at least one of the Media Type maintainers. Exactly what we say for those registrations is still a bit up in the air... or we might just say "forget it!" and register application/vc+sd-jwt
as an expression of the data model in VCDM that is secured using SD-JWT and not take advantage of structured suffixes (because we couldn't get consensus at IETF to do the easier thing and not have to register every structured suffix variation under the sun).
Do you find any of the arguments above compelling @jyasskin?
from vc-data-model.
I don't mean to take a strong stance here; just wanted to make sure the WG still wants them.
On application/vc+ld+json+sd-jwt
, does the +sd-jwt
part imply the +json
part, or could you have +somethingelse+sd-jwt
? Reading https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html, I think the content does always have to be JSON. So maybe the media type should be application/vc+ld+sd-jwt
.
from vc-data-model.
Note that application/zip
can contain multiple resources, while I believe application/sd-jwt
can only contain one. application/gzip
/+gzip
or application/zstd
/+zstd
would be a better comparison (even though gzip can also technically also contain multiple subfiles; nobody uses it that way). I'm not taking a position on whether +gzip
and +zstd
were good ideas.
(+zip
is also a registered structured suffix, but as far as I can tell, that suffix doesn't mean "a zip is extractable to get the format named before it"; it's "this format also happens to be usable as a .zip", like +json
, +der
, etc.)
from vc-data-model.
The issue was discussed in a meeting on 2023-12-06
- no resolutions were taken
View the transcript
2.7. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)
See github issue vc-data-model#1364.
Orie Steele: I would suggest keeping this issue open. We need to know if our registration will be accepted or not.
Brent Zundel: I'm interpreting that as before CR.
Ted Thibodeau Jr.: There's nothing prohibiting making registrations with multiple suffixes. The question is about how those are going to be interpreted.
from vc-data-model.
The issue was discussed in a meeting on 2023-12-13
- no resolutions were taken
View the transcript
2.5. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)
See github issue vc-data-model#1364.
Brent Zundel: do VCs still need media types with multiple suffixes.
… short answer is yes.
… comments on this? seems we are ready to close this issue.
Manu Sporny: I think we still need media types with multiple suffixes.
… the only thing that is in question now are the media types for the securing formats such as jose-cose.
… I think I agree with the existing media type registration requests.
Ted Thibodeau Jr.: yes, pretty strongly, application/sd-jwt.
Manu Sporny: this group will need to decide what media types to request.
… ted, please open your PR before the next IETF meeting.
… if we fail to get into last call again, everything will be very sad.
Dave Longley: +1 to Manu's position, I think Ted is right but relying on Ted.
Ted Thibodeau Jr.: doing my best to get it done this week.
Brent Zundel: any other IETF PRs we want to discuss?
… labeling pending close, we think we need what we currently request.
from vc-data-model.
Related Issues (20)
- Authorized Presenters HOT 22
- Add mechanism to cryptographically secure non-credential VP properties (contexts etc) HOT 9
- Improve Verification Algorithms section HOT 4
- Request profile parameter from `application/vc` HOT 11
- Clarify section on verifiable credential graph HOT 13
- Clarify the domain and range of the `verifiablePresentation.verifiableCredential` property HOT 7
- Bug in the context file? HOT 7
- Specify guarantees that all securing mechanisms must provide. HOT 10
- Remove repetition of normative statements in verification algorithm HOT 4
- Separate verification from validation in verification algorithm HOT 5
- Rewrite verification algorithm in a way that does not cause layer violations HOT 9
- Update algorithms section to normatively depend on the INFRA specification HOT 6
- Allow extensions to ProblemDetails object HOT 5
- Specify that it is important to validate the `issuer` value HOT 8
- Specify what kind of processing is safe on a returned document HOT 21
- Ensure `credentialStatus` `id` field is optional HOT 5
- Verifying a VC should return the same credential regardless of the verification method HOT 3
- Clarify embedded proof extension point HOT 3
- phrasing and/or punctuation for input "inputBytes or inputDocument and inputMediaType" needs work HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vc-data-model.