I submitted a new version of the draft to reflect the focus on Multi-Subject JWT: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
I would appreciate any feedback on this. Regards, Rifaat On Thu, Feb 18, 2021 at 7:26 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > When I started working on the Nested JWT draft, I had a specific use case > in mind (I no longer care about that initial use case). > https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt > > I then dropped the ball on the Nested JWT draft, but every now and then I > get some feedback, mainly offline, from different people about more use > cases that clearly indicate that there is a need for a way to represent > multiple subjects in one JWT. > > The following is a high level summary of these use cases: > > > 1. > > Primary subject with secondary authority subject > > A primary subject with a related secondary subject that has authority over > the primary subject, e.g. Child/Parent, Pet/Owner. > > In this case, both JWTs would be issued by the same issuer. > > > 1. > > Delegation of authority > > A primary subject delegates authority over a resource to a secondary > subject who acts on behalf of the primary subject. > > https://tools.ietf.org/html/rfc8693 > > In this case, both JWTs would be issued by the same issuer. > > > 1. > > Multiple primary subjects > > Two primary related subjects e.g. a married couple > > https://www.w3.org/TR/vc-data-model/#credential-subject > > In this case, both JWTs would be issued by the same issuer. > > > 1. > > Replaced primary subject > > A primary subject becomes a secondary subject and replaced with a new > primary subject. > > For example, > > - > > An original called number replaced with a retargeted number. > > https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09 > > > - > > A number of network intermediaries that each become the primary > subject when receiving a message from a previous network element. > > https://networkservicemesh.io/ > > In this case, the original JWT would be issued by one issuer and included > as a nested JWT, while the enclosing JWT would be issued by a new issuer > that has manipulated the original received message. > > > 1. > > Supporting JWTs > > One primary JWT with supporting JWT > > https://github.com/martinpaljak/jose/blob/main/README.md > > > *Question*: > Is the WG interested in working on such a mechanism? > If yes, are there any more use cases that need to be addressed? > Are there use cases that require more than two subjects? > > Regards, > Rifaat (no hats) > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
