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

[John Bradley <[e-mail]>]

OK so act_as if not sent is implicitly the requestor perhaps authenticated by the endpoint in the normal OAuth way.

If the if the requestor is acting like a proxy as in the Token Agent case the act_as would indicate the identity of the client making the request to the Token Agent so that the resulting token can include that identity as the AZA.

I think that logic holds together.  

In that case, if the resulting token is PoP,  then the party identified by the act_as's  public key would go in the resulting token.  

That may actually be reversed from the WS-Trust usage, but that is something else to dig into in the WG.

I think working on this along side of the PoP drafts will help prevent possible conflicts and confusions.

We should accept Mikes draft or both of these as a starting point.

John B.


On Aug 8, 2014, at 1:55 PM, Brian Campbell <[e-mail]> wrote:

> 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 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
>