Hey everyone,
Let me shortly introduce myself - My name is Jan, I do IAM at Zalando SE.
I am writing, because I like to get a better understanding of the reasoning
behind a fundamental conceptual decision that was made in the
oauth-token-exchange draft.
The draft describes one possible design of a composite token: an 'act' claim in
a representee token, meaning that a regular principal token gives the
information about a possible delegate/ agent a piggyback.
In my eyes, this is not quite intuitive nor the most secure solution as:
the current approach cloaks the true nature of the delegation as the actual
actor is not represented by/ in the primary token,
the current approach would be entirely transparent for old/ legacy systems
which do not know about a possible act claim. Those applications, would support
delegation simply because they do not know any better. For them, the intended
delegation would look like a true impersonation.
As delegation usually is a highly security sensitive thing to do, I personally
would prefer the probably more secure approach of defining a primary agent
token with a nested representee token/ information. This would lead to systems
not just silently supporting delegation (without knowing about it). They would
need to explicitly support the spec if they want to support delegation.
My questions now are:
am I missing something here,
do you share my worries,
what are the actual reasons for the current composite token design?
Would be great if you could provide some background info on why you chose to
follow the current approach.
Thanks, Jan
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
