[OAUTH-WG] [oauth-token-exchange] Composite Token Design

[Jan Brennenstuhl]

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

[Brian Campbell]

Hi Jan,

I don't think you're missing anything. However, the use of the 'act' claim
to identify the delegate and convey that delegation is happening was an
intentional decision. While delegation is a security sensitive thing, it
often occurs as impersonation with no explicit indication about delegation.
Layering on the delegate info in a claim like this allows for those kinds
of cases to continue working while augmenting the token with data
about the delegate
that can be used for audit or access control (but doesn't have to be).
Which, I guess, is to say that your worries were indeed a design goal of
the document. That may not alleviate those worries but hopefully does
provide some insight into the reasoning behind the current composite token
approach.



On Thu, Feb 23, 2017 at 7:46 AM, Jan Brennenstuhl <

Post by Jan Brennenstuhl
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.
- 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.
- 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
https://www.ietf.org/mailman/listinfo/oauth