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
