[media-types] Re: [IANA #1382956] application/vc+jwt r egistration request

As the registration of the "+sd-jwt" structured suffix approaches reality
(maybe)
https://mailarchive.ietf.org/arch/msg/oauth/o_-_w7tUpeSPKB_FYbvuXNSFMrY/ I
will reiterate the concern about the "application/vp+sd-jwt" media type
request that is expected to follow. As I said before/below, the number of
different ways to do things and the resulting multitude of media types in
vc-jose-cose is confusing and unnecessarily fragmenting. Particularly
egregious on the confusing and unnecessary front, however, is the use of
SD-JWT as a container for presentation where there is no need for the
SD-JWT capabilities. Unless substantial changes have been made to the
document that provide a legitimate justification for the
"application/vp+sd-jwt" media type, and I don't see any indication that
that's the case, it should not be added to the media type registry.


On Thu, Nov 21, 2024 at 6:39 AM Brian Campbell <[email protected]>
wrote:

> The conversations at IETF were indeed worthwhile and rough consensus was
> reached within the OAuth WG for changing the base subtype used in SD-JWT
> VC. The draft was updated last week with that change
> https://mailarchive.ietf.org/arch/msg/oauth/spU3vinrmafUIDKO_NQKAV_4Cf8/
>
> That change obviates contention over the "application/vc+sd-jwt" media
> type. Thanks to everyone who contributed to reaching a resolution.
>
> While I continue to have concerns about what seem to be differing
> standards of document maturity requirements for IETF registrations vs
> external ones[0], I have no real reason to further request delay in the
> registration of this and the related media types[1]. Maybe it's obvious but
> I'll say it here anyway for the record - I therefore withdraw my prior
> request to hold off on these registrations (originally made here[2]).
>
> Because there has been a lot of concern about developer confusion
> expressed in this thread, I feel compelled to say that I find the
> "application/vp+sd-jwt" media type in the vc-jose-cose[3] document to be
> extremely confusing. I am sort of a developer and reasonably versed in the
> types of things at question here. I find the number of different ways to do
> things and the resulting multitude of media types in vc-jose-cose confusing
> and unnecessarily fragmenting. The "vp+sd-jwt" part being particularly
> problematic as I cannot envision any legitimate reason for  "Securing
> JSON-LD Verifiable Presentations with SD-JWT." The only rationale I've been
> given is something about the importance of conformance to the Verifiable
> Credentials Data Model v2.0[4], which isn't an actual explanation at all. I
> would strongly suggest that some consideration or treatment be given to
> this, even removal of the whole "vp+sd-jwt" part, before the "+sd-jwt"
> media type registration request(s) are made based on the vc-jose-cose
> document[3].
>
>
>
> [0] An issue in the 6838bis github referring back to the mailing list
> https://github.com/ietf-wg-mediaman/6838bis/issues/8
>
> [1] four of the six media types from vc-jose-cose[3]
>
> https://mailarchive.ietf.org/arch/msg/media-types/zcbXcySVO7Np8KRG5K1aeiReFEI/
>
> https://mailarchive.ietf.org/arch/msg/media-types/k5a7qovXKVcemgY9CN2HP2h6raw/
>
> https://mailarchive.ietf.org/arch/msg/media-types/1ohq2ERJ9C3ov_xQP4r2rC9qS5Y/
>
> https://mailarchive.ietf.org/arch/msg/media-types/zAZvD8m3mdWxHHVYt1mx20KgZD4/
>
> [2] prior message from me to the media types list
>
> https://mailarchive.ietf.org/arch/msg/media-types/NCGLbdn_hQyprAJgxpnjc06RAsc/
>
> [3] vc-jose-cose draft
> https://www.w3.org/TR/vc-jose-cose/
>
> [4] VCDM 2.0 draft
> https://www.w3.org/TR/vc-data-model-2.0/
>
>
>
> On Sun, Oct 27, 2024 at 11:22 PM Gabe Cohen <[email protected]> wrote:
>
>> Darrel,
>>
>> I agree with your assessment—both conversations seem worthwhile.
>>
>> The sooner we resolve this the better. In this case, having conversations
>> at IETF seems worth the wait, as there is a path to avoid an appeal. If an
>> appeal is unavoidable, having clarity after the group’s discussion is also
>> worthwhile.
>>
>> Have fun in Dublin,
>> Gabe
>>
>> On Sun, Oct 27, 2024 at 4:00 PM Darrel Miller <[email protected]> wrote:
>>
>>> Hey folks,
>>>
>>> Just to clarify my request to have a conversation at IETF 121 with
>>> people from the OAuth WG.  The VCWG have made it clear that they wish to
>>> pursue their registration requests and have no desire to amend previous
>>> registrations.  The VCWG followed process for the previous registrations
>>> and I approved them.  I have been asked to approve the new ones.
>>>
>>> Brian raised a concern about these additional registrations as there is
>>> a naming conflict over the base subtype.
>>>
>>> From my perspective I see two paths forward at this point. Either the
>>> OAuth WG find an alternative base subtype they are happy with, or they
>>> appeal the existing registrations.
>>>
>>> If the OAuth WG feel like these application/vp and application/vc should
>>> not have been registered it is absolutely their right to appeal that
>>> decision.  I approved based on the information that I had at the time and
>>> was unaware of a lack of cross SDO consensus.  The ability to appeal is
>>> absolutely designed for situations like this and as a DE I fully support
>>> someone using the appeals process if they feel like a DE has made a wrong
>>> decision.
>>>
>>> However, I would like to further explore the possibility of the OAuth WG
>>> using a different sub base type, so as to avoid the appeal process if
>>> possible.  That does seem like a conversation that is appropriate for IETF
>>> 121.
>>>
>>> I have no desire for this to be a conversation about obtaining consensus
>>> across the two working groups.  IETF 121 does not seem like the right
>>> place, nor am I the right person to mediate that conversation.  I just want
>>> to have a conversation about the media types being proposed in the IETF
>>> drafts that use the "vc" base subtype.
>>>
>>> Deb, the issue you raise about the disparity between processes for IETF
>>> vs Non-IETF specifications does feel like a topic for the mediaman agenda.
>>>
>>> Darrel
>>>
>>> _________________________________
>>>
>>> _______
>>> From: Deb Cooley <[email protected]>
>>> Sent: Sunday, October 27, 2024 10:47 AM
>>> To: Manu Sporny
>>> Cc: Brian Campbell; Daniel Fett; Darrel Miller;
>>> [email protected]; Kristina Yasuda; Orie
>>> Steele; [email protected]; Murray Kucherawy
>>> Subject: Re: [media-types] Re: [IANA #1382956] application/vc+jwt
>>> registration request
>>>
>>> I was actually hoping to discuss the disparity in what is required for
>>> non-IETF (draft specification) vs IETF (RFC) for a media type
>>> registration.  I’m sure there are ways to game the system, but I’d
>>> (personally) like to avoid that.
>>>
>>> Deb
>>>
>>> > On Oct 27, 2024, at 10:07 AM, Manu Sporny <[email protected]>
>>> wrote:
>>> >
>>> > On Sun, Oct 27, 2024 at 8:35 AM Brian Campbell wrote:
>>> >> I can also attend mediaman and plan to do so (5th session Tuesday at
>>> 18:00 for those playing along at home). But it's only one hour and I don't
>>> know that there's sufficient agenda time available. So something additional
>>> might be good to plan for.
>>> >
>>> > Yes, I agree. We are in this position due to a breakdown of consensus
>>> > between the W3C VCWG and the IETF OAuth WG (not that either of those
>>> > groups are expected to be a part of the consensus process of the other
>>> > group). Digging our way out of this is unlikely to be accomplished
>>> > during an IETF meeting with packed agendas.
>>> >
>>> > As Brian has alluded to in previous posts, the problem here is more
>>> > fundamental than media types. That many of those involved won't be at
>>> > IETF, and therefore their concerns won't be shared, is an issue. While
>>> > the VCWG Chair speaks for the group, it might benefit the OAuth WG to
>>> > hear from other parties that they have not heard from before to
>>> > understand the depth of the issue.
>>> >
>>> > All that to say, perhaps we should have the concerned parties attend a
>>> > virtual session or two after IETF to ensure the topic is given the
>>> > dedicated time it needs to achieve a long-lasting resolution.
>>> >
>>> > -- 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]
>>>
>>

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

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]