Thanks for the additional explanation Dick, The explicit typing construct is RECOMMENDED and not a MUST because there exist perfectly legitimate cases where the construct is neither needed nor appropriate. See https://github.com/w3c/vc-jose-cose/issues/282 for one example where, amidst the noise in and around that issue, I'm trying to convince some folks in a different SDO, whom are using both JWT and SD-JWT, that other means of preventing token confusion/substitution are okay too. And probably "better" in many/most respects. And might avoid an impending conflict between the output work of different WGs.
What you said about the "typ" header being intended to help a processor know how to process the rest of the dot separated components with the initial use cases being signed vs encrypted does make some sense on a surface level. But there's no actual construct specified across any of the typ definitions in JWS <https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.9>/JWE <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.11>/JWE <https://datatracker.ietf.org/doc/html/rfc7519#section-5.1> or a media type <https://www.iana.org/assignments/media-types/media-types.xhtml> that distinguishes signed vs encrypted. So, at least in practice, it's not true. I do agree that all this is confusing. And I'm certainly open to realistic ways to make it less confusing. But I firmly believe that going even further in on a awkward and problematic construct of using the 'typ' header inside a thing to declare the media type of that thing which needs to have already been (at least partially) processed to get to the value of that header to say how to process the thing that's already being processed will not help make things less confusing. On Tue, Sep 24, 2024 at 11:18 AM Dick Hardt <dick.ha...@gmail.com> wrote: > Sorry Brian, I'll try again. > > In the current text: > > SD-JWTs are also potentially vulnerable to such confusion attacks, so it > is RECOMMENDED to specify an explicit type by including the typ header > parameter when the SD-JWT is issued, and for Verifiers to check this value. > > > It is only RECOMMENDED to explicitly type. My suggestion is that a SD_JWT > MUST have "typ" in the header, and be specific about what that value is, > and how other applications that require additional typing do it. You sort > of have that with > > When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a > media type name of the format "application/example+sd-jwt" be used, where > "example" is replaced by the identifier for the specific kind of SD-JWT. > > But once again it is a RECOMMENDED and not a MUST -- and it is confusing. > As an implementer, am I allowed to use "application/sd-jwt" or just > "sd-jwt" -- or do I have to come up with my own value for "example". > > Given other threads, it is now clear to me (which it was not earlier) that > the authors view this as a base document that will be built upon in other > documents -- so perhaps you are just giving general guidance here. But as I > expressed in the other thread, I suspect many people will just read this > doc and do what it suggests, hence let's make explicit typing a MUST. > > FWIW: the "typ" header property was intended to help a processor know how > to process the rest of the dot separated components. The initial use cases > being something signed vs encrypted. > > On Tue, Sep 24, 2024 at 5:17 PM Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> I must admit that I'm finding it difficult to fully grasp the points >> you're making on this topic.. As with the other topics, there has been >> extensive discussion about typing and media types[1]. And, while I have my >> own reservations about using something inside a thing to say what the thing >> is and the ascension of that questionable mechanism to "best" practice[2], >> the SD-JWT document explicitly cites and follows the guidance on explicit >> typing[3] from the JWT BCP that bears your name as an author[3']. The >> citing of that very section in asking "Why leave the typing in the header >> to be determined by the application (10.11), and not just be 'sd-jwt' and >> be REQUIRED"[4] seems incongruent and leads me to wonder if maybe there's >> been some misunderstanding and/or miscommunication somewhere in all this. >> >> The document does plan to request registration of an "application/sd-jwt" >> media type to be used wherever media types might be used "indicate that the >> content is an SD-JWT." As such, one could certainly use "typ":"sd-jwt" in a >> SD-JWT header. But I don't see the utility in doing so and feel it would be >> a throwback to the now largely seen as flawed suggestion in JWT that >> "typ":"JWT" be used to say that the JWT is a JWT. >> >> [1] a sampling of such discussions that I think have been referenced >> previously but are relevant nonetheless: >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267 >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327 >> >> [2] one small diatribe on the topic >> >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327#issuecomment-1736438782 >> >> [3] The Explicit Typing section in SD-JWT (10.11) >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-12#section-10.11 >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-explicit-typing> >> >> [3'] RFC 8725 aka BCP 225 aka JSON Web Token Best Current Practices >> https://datatracker.ietf.org/doc/rfc8725/ >> >> [4] SD-JWT architecture feedback received several days after the close of >> WGLC >> https://mailarchive.ietf.org/arch/msg/oauth/412IiUprR9YbXNfEGfSXVVx_pzk/ >> >> [5] Media Type Registration in the draft >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-12#section-13.2 >> >> [6] the "typ" (Type) Header Parameter in JWT >> https://datatracker.ietf.org/doc/html/rfc7519#section-5.1 >> >> On Sun, Sep 22, 2024 at 8:15 AM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> I am trying to make a few points. My reference to the BCP was on the >>> recommendation to do explicit typing. I'm suggesting that the sd-jwt >>> document state that include "typ" is a requirement, and to be explicit in >>> what that value should be. >>> >>> I would suggest that value be "sd-jwt" >>> >>> The "application+" mechanism was already deployed when we wrote the BCP >>> -- too late to change that. But sd-jwt is a new token format and can learn >>> from implementation challenges in the past. >>> >>> >>> >>> On Sat, Sep 21, 2024 at 9:17 PM Michael Jones < >>> michael_b_jo...@hotmail.com> wrote: >>> >>>> Actually, the JWT BCP (which we were both authors of) does not >>>> recommend using a single media type. Rather, it recommends using a >>>> specific media type suffix in the “typ” values >>>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing>: >>>> >>>> When explicit typing is employed for a JWT, it is *RECOMMENDED* that a >>>> media type name of the format "application/example+jwt" be used, where >>>> "example" is replaced by the identifier for the specific kind of JWT. >>>> >>>> >>>> >>>> SD-JWT is doing the same thing, recommending the use of the media type >>>> suffix “+sd-jwt”. >>>> >>>> >>>> >>>> This enables more fine-grained explicit typing. For instance, when >>>> doing explicit typing for an SD-JWT in the Example use case, the “typ” >>>> value would be “example+sd-jwt”. This can then be distinguished from an >>>> SD-JWT for the Other use case, which would use the “typ” value >>>> “other+sd-jwt” – meeting the goal of explicit typing. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* Dick Hardt <dick.ha...@gmail.com> >>>> *Sent:* Saturday, September 21, 2024 9:16 AM >>>> *To:* Daniel Fett <m...@danielfett.de> >>>> *Cc:* oauth@ietf.org; krist...@sfc.keio.ac.jp >>>> *Subject:* [OAUTH-WG] Re: SD-JWT architecture feedback >>>> >>>> >>>> >>>> … >>>> >>>> >>>> >>>> *Explicit Typing* >>>> >>>> Why leave the typing in the header to be determined by the application >>>> (10.11), and not just be 'sd-jwt' and be REQUIRED? >>>> >>>> We had extensive discussions around typing, please refer to the >>>> following issues: >>>> >>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267 >>>> >>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327 >>>> >>>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/345 >>>> >>>> >>>> >>>> Those issues don't really address the point. >>>> >>>> >>>> >>>> Per RFC 8725: JSON Web Token Best Current Practices (rfc-editor.org) >>>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing> -- >>>> the best practice would be to have a single type that would allow a library >>>> to know it is an SD-JWT. If additional context is needed, perhaps that >>>> should be a different header property? >>>> >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-le...@ietf.org >>> >> >> *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._
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
