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

From: Jan Brennenstuhl <[email-masked]>
Date: Thu, 23 Feb 2017 15:46:22 +0100

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 28 Feb 2017 15:23:07 -0700

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 <
[email-masked]> wrote:

> 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.
>
> 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?
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>