But when you *don't* use the public key to secure more than a single type of application message (unsurprisingly a very common use case), there is no issue. Given that the current document defers to profiles all decisions about which validation claims to require, which is a much more serious likely security concern, I think a default type should be defined, mentioned in security considerations, and its use (or not) can be profiled as appropriate. Thanks, -rohan
On Sun, Sep 22, 2024 at 10:24 AM David Waite <da...@alkaline-solutions.com> wrote: > There are security issues from this however if the public key is used to > secure more than a single type of application message - say a message > normally used to indicate someone is logging out accidentally being > accepted for log-in or as a valid session token on a website. > > In this scenario, you need some way to differentiate the two messages > reliably (across many potential interoperable implementations), and making > them different media types is the best current practice. > > -DW > > On Sep 22, 2024, at 10:52 AM, Rohan Mahy <rohan.m...@gmail.com> wrote: > > > Hi, > If someone defines a new profile application/foobar-audit-system and it > has sd-jwt, jwt, and sd-cwt versions, it seems perfectly reasonable to have > a fine-grained explicit media type application/foobar-audit-system+sd-jwt. > That said, there are times when someone just wants an sd-jwt with an > unspecified profile. In this second case, it makes more sense to me to also > register application/sd-jwt. The implementor should fill in whichever form > they are using in the `typ` header. > > Thanks, > -rohan > > On Sat, Sep 21, 2024 at 12: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 >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
