My experience in developing standards is that framework specifications that are not self contained lead to confusion.
I regret when I got back the pen for OAuth 2.0 that I did not merge what became 6750 (bearer tokens) back into 6749. I'm atoning for my sins with OAuth 2.1 which brings bearer tokens back into the core document. While the authors may have a clear understanding of how all the documents fit together, most others will not, and I don't recall where in the document it tells me NOT to use it by itself. As someone sitting on the periphery, I would just use the SD-JWT document for selective disclosure. I've not read SD-JWT VC and at this point in time, have no idea what it adds to SD-JWT. On Mon, Sep 23, 2024 at 10:41 PM Kristina Yasuda <yasudakrist...@gmail.com> wrote: > 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
