Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

[Mike Jones <[e-mail]>]

First, I’ll say that I appreciate Brian also working on this topic.  This is important for many multi-actor use cases and it would be good for OAuth to develop a standard in this area.  I also agree with the discussion on the list that having some use case descriptions and concrete examples could help developers know how to do token exchange in an interoperable way.  We should do that going forward.

I just skimmed through Brian’s document.  I agree with the thrust of a lot of.  Much of it is equivalent to parts of draft-jones-oauth-token-exchange – albeit with different syntax.  However, it seems to be missing the ability to represent statements about who is eligible to act for who, as is enabled by http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01#section-4.  Also, I’m not sure I’m comfortable overloading the access_token Token Endpoint response to convey the returned security token, since in the general case, the security token is not an access token.  All of those are the kinds of details that the working group will get to decide on, so I’m not all that hung up on them right now.

As a way forward, I’d actually propose that we accept draft-jones-oauth-token-exchange as a starting point for the working group document – as the hum in Toronto seemed to say that we would – but that we add Brian as a co-author of it.  I’m comfortable working with Brian as a co-editor and we have a good track record of doing productive work together – including the nearly finished OAuth Assertions specifications.

I’d also privately communicated to Brian that I see my current document as a starting point for the work and not something in final form and that I’d be happy to work with him to make sure that his use cases are accommodated and that it’s clear to developers how and when to use token exchange.

                                                            Best wishes,
                                                            -- Mike

From: OAuth [mailto:[e-mail]] On Behalf Of Brian Campbell
Sent: Friday, August 08, 2014 10:55 AM
To: John Bradley
Cc: [e-mail]; [e-mail]
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think.
Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT & SAML too. The last paragraph of http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to state that the scope of the doc is only the framework for exchange and that the "syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope."  What constitutes a valid token will depend on the deployment or additional profiling.

"So how might sending an act_as token to the token endpoint as part of the request impact the result." -> in general I was thinking it'd result in an azp claim or something like that in the returned token.

"Do you see the act_as interacting with PoP to limit who can present the resulting token. " -> Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this.

"Is act_as simply duplicating the authentication portion of the current assertion profile?" -> there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with
draft-jones-oauth-token-exchange<http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/> to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though.

"Not having concrete answers at this point is not a problem, but we do need to think all of this through." -> agree

"I think this document is also useful input." -> thanks