[OAUTH-WG] Re: [SPICE] Re: Re: [media-types] Re: Request for registering media types and structured suffixes defined by W3C VCWG candidate recommendations

[Brian Campbell <[e-mail]>]

Just to comment on the indirect comment about essentially squatting on a
high value subtypes:

The authors of draft-ietf-oauth-sd-jwt-vc
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/> (and the WG
on behalf of whose rough consensus the work endeavors to represent) have no
intent or interest in requesting registration of "application/vc".

While the anticipated request for "application/vc+sd-jwt" was modeled
loosely after existing media types like application/at+jwt
<https://www.iana.org/assignments/media-types/application/at+jwt> and
application/dpop+jwt
<https://www.iana.org/assignments/media-types/application/dpop+jwt> where a
relatively short value is useful and the part to the left of the suffix
doesn't have any oblivious utility standing on its own.

Furthermore, up until rather recently, the W3C VCWG was aspiring to
register the following, for which there was no prospective conflict.

application/vc+ld+json
application/vp+ld+json
application/vc+ld+json+jwt
application/vp+ld+json+jwt
application/vc+ld+json+sd-jwt
application/vp+ld+json+sd-jwt
application/vc+ld+json+cose
application/vp+ld+json+cose
+ld+json+jwt
+json+jwt
+ld+json+sd-jwt
+json+sd-jwt
+ld+json+cose
+json+cose

On Fri, Jun 21, 2024 at 1:41 PM Orie Steele <[e-mail]>
wrote:

> [ 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 <
> [e-mail]> 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 <
>> [e-mail]> 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 <bcampbell=[e-mail]>
>>> *Sent:* Thursday, June 20, 2024 1:19 PM
>>> *To:* Orie Steele <[e-mail]>
>>> *Cc:* [e-mail]; oauth <[e-mail]>
>>> *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 <[e-mail]>
>>> 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 <[e-mail]>
>>> wrote:
>>>
>>> On Mon, Jun 10, 2024 at 10:22 AM Alexey Melnikov
>>> <[e-mail]> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> *ORIE STEELE *Chief Technology Officer
>>> www.transmute.industries
>>>
>>> <https://transmute.industries/>
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>
>>> *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>
> --
> SPICE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 
_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._