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

[Orie Steele <[e-mail]>]

[ 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>