[ as an individual ] Adding SPICE since I anticipate this will be relevant to application/vc(?)+cwt, verifiable credential with or without selective disclosure, using CBOR Web Tokens - https://datatracker.ietf.org/doc/html/draft-prorock-spice-cose-sd-cwt
On Fri, Jun 21, 2024 at 12:33 PM Brian Campbell <[email protected]> wrote: > With respect to application/vc+sd-jwt, I hope you'd agree that an IETF > SD-JWT VC and an SD-JWT with a payload conforming to the VCDM 2.0 are > distinctly different things and that it'd be wholly inappropriate to use > the same media type to represent them. > The mandatory JSON members are different. I think it's obvious that they should be different media types. However, I will note that `application/vc` has a subtype, so the confusion exists regardless of what suffixes you append. Is it inappropriate to use the same "subtype" for formats controlled by different standards organizations? I believe that the OAuth working group has received this feedback before. It's been blogged about: https://www.cyberforge.com/battle-for-the-brand/ It's also been discussed in the minutes of the W3C VCWG, although I won't be able to provide references, I am sure they exist. During the SPICE chartering process, the term "digital credential" was chosen instead, to side step this problem. OpenID Foundation created a working group called "digital credentials protocols": https://openid.net/wg/digital-credentials-protocols/ OpenID has specifications that move W3C VCs, ISO mDocs, and other digital credential formats that include the words "Verifiable Credential". https://openid.net/sg/openid4vc/ W3C Web Incubation Community Group has: https://wicg.github.io/digital-credentials/ This issue tracks the possible changes on the W3C side: https://github.com/w3c/vc-jose-cose/pull/279 OAuth might consider the following alternative media types in the same spirit: - application/dc+sd-jwt ( digital credential in sd jwt format ) - application/ic+sd-jwt ( internet credential in sd jwt format ) - application/vc-json+sd-jwt (verifiable credential in json using sd jwt format) Or perhaps even reuse some of the framing from eat media types: https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-media-type-07#name-application-eat-ucsjson-reg - application/vc-cs+sd-jwt ( verifiable credential claim set using sd jwt ) Then later, if protocols wish to convey an sd-jwt claim set over an authenticated channel, like HTTPS, or in MLS, or with HPKE, etc..., instead of through a signed object, they could do as eat does: - application/vc-ucs+json ( verifiable credential unsigned claim set using json ) I think the term "verifiable credential" (VC) is an industry term like "internet of things" (IoT), or "web3"... and registration requests for media types that look like this: application/web3 application/iot application/cloud application/credential application/schema Might all be rejected, since they are essentially squatting on a high value subtype. Elsewhere in the IETF, such as in YANG, we prefix namespace registrations with IETF to resolve this kind of issue, for example: urn:ietf:params:xml:ns:yang:ietf-restconf So perhaps in the spirit in which Brian originally suggested: - application/w3c-vc+sd-jwt We might also consider: - application/ietf-vc+sd-jwt Although I think Brian's suggestions here makes more sense, especially for the W3C to consider: https://github.com/w3c/vc-jose-cose/pull/279#issuecomment-2183160606 > As far application/vp+sd-jwt goes, I don't personally see a reasonable > justification for the existence of using SD-JWT to secure verifiable > presentations conforming to the VCDM 2.0. > The justification can be found here: - https://w3c.github.io/vc-data-model/#verifiable-presentations - https://w3c.github.io/vc-data-model/#dfn-verifiable-presentation - https://w3c.github.io/vc-data-model/#json-ld As a general comment, the W3C VCWG sees value in "Holders" providing structured data about a collection of credentials presented, in addition to providing the credentials. This ends up feeling like an envelope containing loose paper, sticky notes, and other envelopes. It gives you a lot of flexibility, but also a lot of different ways to solve the same problems. But that's a digression that I don't have the energy or motivation to > further try to convince the W3C VC WG about. The concept isn't relevant in > the IETF SD-JWT VC context though so there's nothing to do with respect to > having it work for both. > I agree. > > On Thu, Jun 20, 2024 at 4:08 PM Michael Jones <[email protected]> > wrote: > >> It’s my hope that the registrations of application/vc+sd-jwt and >> application/vp+sd-jwt will be able to be done in a way that works for both >> VC-JOSE-COSE and SD-JWT-VC. As I see it, that should be an attainable goal >> and one that the interested parties should work together towards. >> >> >> >> -- Mike >> >> >> >> *From:* Brian Campbell <[email protected]> >> *Sent:* Thursday, June 20, 2024 1:19 PM >> *To:* Orie Steele <[email protected]> >> *Cc:* [email protected]; oauth <[email protected]> >> *Subject:* [OAUTH-WG] Re: [media-types] Re: Request for registering >> media types and structured suffixes defined by W3C VCWG candidate >> recommendations >> >> >> >> Thanks for pointing out the potential dependencies and collisions on the >> horizon. As a co-author on a couple of the documents mentioned and a >> general media type novice, I have a couple of observations and questions. >> >> >> >> The >> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ >> document does plan to request registration of a "+sd-jwt" structured syntax >> suffix. I believe (hope is perhaps a better word) that the draft is nearing >> WGLC and it could all happen this year. >> >> >> >> The https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ >> document, which builds on the aforementioned document, plans on requesting >> registration of an "application/vc+sd-jwt" media type. That draft is less >> mature overall and not expected to be "finished" anytime soon. However, the >> "application/vc+sd-jwt" media type is already being used in implementations >> as well as downstream specifications and profiles. >> >> >> >> Would it be useful in avoidance of dependencies to request early or >> provisional registration of that structured syntax suffix and media type? >> Please forgive my ignorance of the process but is early or provisional >> registration even possible? >> >> >> >> >> >> On Mon, Jun 10, 2024 at 10:58 AM Orie Steele <[email protected]> >> wrote: >> >> [ as an individual ] >> >> +sd-jwt is requested to be registered in this document: >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-08#name-structured-syntax-suffix-re >> >> +cwt is requested to registered in this document: >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-media-type-07#name-cwt-structured-syntax-suffi >> >> Both drafts are still work in progress, but for the W3C Verifiable >> Credentials use case, only +sd-jwt might be relevant, since +cwt is for >> claimsets that are CBOR maps where the map keys come from >> https://www.iana.org/assignments/cwt/cwt.xhtml >> >> Based on the comments I've seen here, I would expect to see requests for >> the following: >> >> application/vc >> application/vc+jwt >> application/vc+cose >> application/vc+sd-jwt (depends on the draft above) >> >> application/vp >> application/vp+jwt >> application/vp+cose >> application/vp+sd-jwt (depends on the draft above) >> >> Perhaps it is worth asking now if application/vc+sd-jwt will be rejected, >> since it is currently already being requested here: >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-03#name-application-vcsd-jwt >> >> Including OAuth for awareness. >> >> Regards, >> >> OS >> >> >> >> On Mon, Jun 10, 2024 at 10:33 AM Manu Sporny <[email protected]> >> wrote: >> >> On Mon, Jun 10, 2024 at 10:22 AM Alexey Melnikov >> <[email protected]> wrote: >> > Yes, I can confirm that the registration is currently denied due to >> > unclear rules about multiple structured suffixes, as well as lack of any >> > conlusion on how to proceed on the mailing list. >> >> Thank you, Alexey, much appreciated, that helps the VCWG move forward. >> >> We'll update our specs and send in another set of registrations that >> will fall more in line w/ the current accepted practices at IANA. >> >> -- manu >> >> -- >> Manu Sporny - https://www.linkedin.com/in/manusporny/ >> Founder/CEO - Digital Bazaar, Inc. >> https://www.digitalbazaar.com/ >> >> _______________________________________________ >> media-types mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> >> >> -- >> >> >> >> >> *ORIE STEELE *Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries/> >> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
