Okay, so I'm definitely missing the value. We want to make sure *user A is authorized to access user B's data* in a *resource server RS*. Either:
1. The *resource server RS* needs to have a priori knowledge *that user A is allowed to access user B's data* 2. Or user A needs to a have a token that contains user B as the subject In (1) we don't need to add any additional handling, this is the current path where authorization is being handled directly by the resource server. So let's take a look at (2). Is the AS required to ensure that the subject of the authorization is actually allowed to access user B's data? - In the case that the AS allows any user X to nest user B, then the resource server RS needs to *check that user A is allowed to access user B's data*. But this is already (1). So this solution doesn't offer any value. And further we would be opening up a pit failure creating tokens with any subject and only restricting them based on a new claim which not everyone will understand/process correctly. - So let's assume that the AS already knows and validates whether *user A is allowed to access user B's data* (suspect, since the AS likely doesn't include such granular RS access control understanding, but let's gloss over this) The nested claim in the token doesn't have any value to the resource server RS, because it doesn't know whether user A is allowed to access that data or not, it knows that the subject is B and B is allowed to access that data, and that's all it should care about. Since it delegated the decision to the AS and the AS knows, *then a token with subject B must be allowed to access user B's data, irrespective of the data in the nested claim*. Therefore, it doesn't provide any concrete value for authorization, and using that nested subject assuming it has meaning would contradict what the AS means. And further not every AS will follow this, opening another pit of failure. But does it provide any value? *Definitely*. Services can log and record the use of these authorization tokens in a resource first-class auditing approach. When asked "who accessed this data" The answer should be *user A* even though the subject of the token is *user B. * Which means, while not outlined in the draft, the conclusion is we are adding this functionality to *improve audit trails and NOT for authorization*. If we agree on that, then we can focus on improving how we expose this data. In that case, we might call this *Chained JWTs,* *Rescoping JWTs, *or even potentially *JWT delegation audit trail*. And as long as we make it clear that this should never be used for authorization, we avoid the pit of failures I've mentioned above. And here's the third pitfall, it's frequently brought up about privacy, potentially the last thing that resource owners want is that more details about them are included into the access token being passed to resource servers which aren't necessary for the authorization itself. For instance adding the audit trail, may encourage AS to introduce personal information into this object based on where the user originated from enabling clients to abuse this information. I subscribe to the Resource Owner RO only wanting to expose the relevant information for an AS to tell a resource server if it should grant access and nothing more. (This of course is from the AS' perspective only, nothing here limits further decisions the RS can/should take based on its own context). Limiting the scope to *audit trails *would be a great option in general, except that we don't solve multi-party authorization. For instance, it is common, especially in the crypto space, to need multiple signatories before enabling access. And perhaps we are taking some inspiration from that, the trouble is here, we would need the JWT to contain both (all) signatures not just the audit trail to be of value. So I would recommend we scope the draft to either solve *multi-party* problems (which is what is actually hinted to me by *multi-subject*) OR to add an *audit trail* to JWTs. On Tue, Jun 14, 2022 at 9:47 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > Yes to both questions. > > On Tue, Jun 14, 2022 at 2:22 PM Warren Parad <wpa...@rhosys.ch> wrote: > >> 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
