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 < jan.brennenst...@zalando.de> wrote: > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
