Is it helpful to challenge this implementation? (and is this email thread the right place to do it?)
On Tue, Jun 14, 2022 at 5:27 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > It is a Nested JWT with at least *two related subjects*, one in the > enclosed JWT and another in the enclosing JWT. > Having said that, I do not have a strong opinion on the name and we could > potentially change it to a name that more accurately reflects the scope of > the document, if needed. > > The justification for this is that in a number of use cases there is a > need for both JWTs to be present, to allow the resource server to apply > authorization based on who requested the access to the resource and on > behalf of who is the request. For example, a parent ordering medication for > their child. There are other use cases described in the document. > > Regards, > Rifaat > > > > > On Tue, Jun 14, 2022 at 11:09 AM Warren Parad <wpa...@rhosys.ch> wrote: > >> After reading the draft I also have some concerns. This still isn't >> multi-subject, right? As there is only one subject, there just happens to >> be a new claim with additional information in it. I'm still behind on the >> justification for creating this, as at first glance, either the user got an >> access token on behalf of the other user to access their resources or they >> are impersonating the other user. So I'm not totally sure I understand the >> immediate value/problem statement, but that could be discussed separately. >> >> There's still only one subject, right? I would recommend that >> `multi-subject` be removed from the draft name. For instance, why not: >> >> - Nested Subject JWT Claims >> >> Or maybe we want to talk about the value: >> >> - Delegating Authorization using Nested Subject Claims in JWTs >> >> >> >> On Tue, Jun 14, 2022 at 5:05 PM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >>> Hi Dick, >>> >>> The initial scope of the document was very limited to extending the >>> existing Nested JWT to allow the enclosing JWT to have its own claims. >>> Since then, it was clear that there are many use cases that need such a >>> mechanism that requires more than just a simple nesting of JWTs. That's the >>> reason I changed the name, to reflect the larger scope of this document. >>> >>> I do not mind changing the name, if it makes sense. >>> Would changing the name to Multi-Subject Nested JWT help address your >>> concern? >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> On Tue, Jun 14, 2022 at 10:46 AM Dick Hardt <dick.ha...@gmail.com> >>> wrote: >>> >>>> Hi Rifaat >>>> >>>> I'm suspecting there was a conversation on changing the name to >>>> multi-subject JWT. Would you provide a pointer or short summary? >>>> >>>> I find the name concerning as I am looking at a very different concept >>>> that would also be considered a multi-subject JWT. >>>> >>>> >>>> My use case is where user accounts have been merged, and the issuer has >>>> multiple "sub" claims for the same user and would like to include all the >>>> values in the JWT to signal to the RP that the accounts have been merged. >>>> >>>> I was considering calling it "aka" and it would be an array of >>>> identifiers. "aka" => Also Known As >>>> >>>> /Dick >>>> >>>> On Tue, Jun 14, 2022 at 5:25 AM Rifaat Shekh-Yusef < >>>> rifaat.s.i...@gmail.com> wrote: >>>> >>>>> I have just submitted an updated version of the *Multi-Subject JWT* >>>>> draft (formerly known as Nested JWT) with more details. >>>>> I would appreciate any reviews and feedback on this version. >>>>> https://datatracker.ietf.org/doc/html/draft-yusef-oauth-nested-jwt >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
