The reason why section 10.11 recommends JWT type to be defined by the use-case is because SD-JWT specification is not meant only for one kind of use-case/architecture. SD-JWT document does not define a stand alone credential format for issuer-holder-verifier model, SD-JWT VC document is intended to serve that purpose. Theoretically, SD-JWT could be used with any other JWTs (such as ID Tokens, Access Tokens, JARM JWTs, etc.) which have their own typing. So giving SD-JWT construct itself an explicit type is not very helpful (though still defined for the cases where no example+sd-jwt media type is defined), and might even become the source of the confusion if developers start using a type defined in the SD-JWT document instead of a type defined in documents like SD-JWT VC.
This is why the SD-JWT draft already defined both application/sd-jwt and +sd-jwt Structured Syntax for use-cases like application/vc+sd-jwt in SD-JWT VC, and if I am interpreting the thread correctly, sounds like that is a good balance and is the way to go. Hope this helps, Kristina On Sun, Sep 22, 2024 at 7:40 PM Rohan Mahy <rohan.m...@gmail.com> wrote: > 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
