inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt <dick.ha...@gmail.com> wrote:
> I read over the W3C issue but it is not clear to me why using "typ" is an > issue. I do see the issue that there is some possible name collision -- so > perhaps someone does not get their first choice? > Yes and there are some real implications to not getting a first choice. While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. > > A design objective of what became JOSE was to use JSON so that we did not > need to cram a bunch of meta data into a string. It seems a shame how the > "typ" is not really serving its initial purpose. As mentioned, the header > was to let the processor know what to do with the other dot separated > components. As you know, it is processed separately to get other values > such as "alg" and "kid" > > Back to the issue at hand, if "typ" is not a MUST, then please specify > what the other means to use that MUST be present to enable a processor to > distinguish between an sd-jwt and other tokens. > The presence of the "~" will do it. But this sentence again suggests to me that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. > > On Mon, Sep 30, 2024 at 12:11 PM Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> 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.* > > -- _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
