Thanks for the detailed feedback, Warren!
Yes, auditing is the obvious benefit that is one of the motivations for
this work, but I agree that it should be explicitly stated.
But, it is not limited to auditing. For example, in the telephony call
redirection case described in section 2.2.1,
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
Yes to both questions.
On Tue, Jun 14, 2022 at 2:22 PM Warren Parad 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
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
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
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
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
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
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
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
