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

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Aug 2014 08:27:43 -0600

I am very much in favor of the WG pursuing the general concept of an OAuth
Token Exchange.  However, I don't believe this document, in its current
form anyway, is the necessarily the most appropriate starting point as a WG
work item.

I wrote up an I-D, which I'd ask to be considered as alternative or
additional input into the process:
https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/

I don't intend this to be confrontational or "this is better than that"
kind of thing. Producing a draft just seemed like the most straightforward
way to document some initial thoughts on it. I'm more than open to
collaborating on it going forward.

On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi all,
>
> during the IETF #90 OAuth WG meeting, there was strong consensus in
> adopting the "OAuth 2.0 Token Exchange"
> (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG
> work item.
>
> We would now like to verify the outcome of this call for adoption on the
> OAuth WG mailing list. Here is the link to the document:
> http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/
>
> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
> as to the suitability of adopting this document as a WG work item,
> please send mail to the OAuth WG list indicating your opinion (Yes/No).
>
> The confirmation call for adoption will last until August 10, 2014.  If
> you have issues/edits/comments on the document, please send these
> comments along to the list in your response to this Call for Adoption.
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
    <https://www.pingidentity.com/>
Brian Campbell
Distinquished Engineer
  @ [email-masked]   +1 720.317.2061  Connect
with us…   <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> 
<https://plus.google.com/u/0/114266977739397708540> 
<http://www.slideshare.net/PingIdentity> 
<http://flip.it/vjBF7> 
<https://www.pingidentity.com/blogs/>

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Aug 2014 12:58:26 -0400

Thanks for doing that.

I think that this is clearer and extends Mike's draft to be more specific about input and output token types.

It is going to be hard for people to get their heads around this without at-least having some example use-cases and example token input and outputs.

In following this proposed model would code and refresh tokens be considered valid on_behalf_of tokens?
I am guessing that a JWT or SAML 2 assertion clearly can be.

So if for example I wanted a JWT/id_token to use in the assertion flow at a SaaS I would send.

aud = "an identifyer for the SaaS AS (perhaps the token endpoint or issuer uri)
requested_security_token_type = urn:ietf:params:oauth:token-type:jwt  (perhaps something more specific?)
on_behalf_of = (refresh token?)
on_behalf_of_token_type = urn:ietf:params:oauth:token-type:refresh   (yes I just made that up)

So how might sending an act_as token to the token endpoint as part of the request impact the result.
Do you see the act_as interacting with PoP to limit who can present the resulting token. 
Is act_as simply duplicating  the authentication portion of the current assertion profile?

Not having concrete answers at this point is not a problem, but we do need to think all of this through.
I think this document is also useful input.

John B.

On Aug 8, 2014, at 10:27 AM, Brian Campbell <[email-masked]> wrote:

> I am very much in favor of the WG pursuing the general concept of an OAuth Token Exchange.  However, I don't believe this document, in its current form anyway, is the necessarily the most appropriate starting point as a WG work item. 
> 
> I wrote up an I-D, which I'd ask to be considered as alternative or additional input into the process: https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/
> 
> I don't intend this to be confrontational or "this is better than that" kind of thing. Producing a draft just seemed like the most straightforward way to document some initial thoughts on it. I'm more than open to collaborating on it going forward.
> 
> 
> 
> On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig <[email-masked]> wrote:
> Hi all,
> 
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Aug 2014 11:55:16 -0600

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Aug 2014 18:19:05 +0000

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:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, August 08, 2014 10:55 AM
To: John Bradley
Cc: [email-masked]; [email-masked]
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

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Aug 2014 14:49:23 -0400

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

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Aug 2014 08:42:20 -0600

I'd be okay with that as a way forward. Frankly, of course, I'd prefer to
see draft-campbell-oauth-sts as the starting point with Mike and the other
draft-jones-oauth-token-exchange authors added as co-authors. Regardless,
there are elements from both that likely need to end up in the final work
so a consolidation of authors and concepts makes sense.

And yes, there are lots of details that the working group will need to
decide on going forward that we shouldn't get hung up on right now. Though
I believe that deciding if the token endpoint is used for general token
exchange is an important philosophical question that should be answered
first. If the token endpoint is to be used, I strongly belie that this
token exchange should leverage and work within the constructs provided and
defined by OAuth. That's the direction I took with draft-campbell-oauth-sts
and yes that involves overloading the access_token response parameter with
something that's not always strictly an access token. The existing token
endpoint request/response are already rather close to what one might expect
in an STS type exchange. I find there's a nice elegant simplicity to it but
I also see where that discomfort might come from. If there's consensus to
not use/overload the existing stuff, I think it'd be much more appropriate
to define a new endpoint. A lot of syntactic stuff likely falls out from
that decision.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 11 Aug 2014 17:41:24 +0200

Hi Brian,

we should definitely take your work into account and I recall some other
drafts on the same subject being published some time ago as well.

Adding more co-authors to this working group item makes a lot of sense
to me.

Ciao
Hannes

On 08/11/2014 04:42 PM, Brian Campbell wrote:
> I'd be okay with that as a way forward. Frankly, of course, I'd prefer
> to see draft-campbell-oauth-sts as the starting point with Mike and the
> other draft-jones-oauth-token-exchange authors added as co-authors.
> Regardless, there are elements from both that likely need to end up in
> the final work so a consolidation of authors and concepts makes sense.
> 
> decide on going forward that we shouldn't get hung up on right now.
> Though I believe that deciding if the token endpoint is used for general
> token exchange is an important philosophical question that should be
> answered first. If the token endpoint is to be used, I strongly belie
> that this token exchange should leverage and work within the constructs
> provided and defined by OAuth. That's the direction I took with
> draft-campbell-oauth-sts and yes that involves overloading the
> access_token response parameter with something that's not always
> strictly an access token. The existing token endpoint request/response
> are already rather close to what one might expect in an STS type
> exchange. I find there's a nice elegant simplicity to it but I also see
> where that discomfort might come from. If there's consensus to not
> use/overload the existing stuff, I think it'd be much more appropriate

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 11 Aug 2014 16:40:55 +0000

I read the draft and just don’t get it, it overloads some of the basic semantics, I’m not quite sure you get the concept of token exchange, has what you described been deployed ? or even built ?

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, August 11, 2014 7:42 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth Working Group Item

I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense.
And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision.