Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 01 Jul 2015 11:35:28 +0100

Hmm... perhaps the clue is in the draft title, token-exchange, so may be 
it is a case of the given access token ("on_behalf_of" or "act_as" 
claim) being used to request a new security token. One can only guess 
though, does not seem like the authors are keen to answer the newbie 
questions...

Cheers, Sergey

On 30/06/15 13:38, Sergey Beryozkin wrote:
> Hi,
> Can you please explain what is the difference between On-Behalf-Of
> semantics described in the draft-ietf-oauth-token-exchange-01 and the
> implicit On-Behalf-Of semantics a client OAuth2 token possesses ?
>
> For example, draft-ietf-oauth-token-exchange-01 mentions:
>
> "Whereas, with on-behalf-of semantics, principal A still has its own
> identity separate from B and it is explicitly understood that while B
> may have delegated its rights to A, any actions taken are being taken by
> A and not B. In a sense, A is an agent for B."
>
> This is a typical case with the authorization code flow where a client
> application acts on-behalf-of the user who authorized this application ?
>
> Sorry if I'm missing something
>
> Cheers, Sergey
> On 25/06/15 22:28, Mike Jones wrote:
>> That’s what
>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about.
>>
>>                                                                  Cheers,
>>
>>                                                                  -- Mike
>>
>> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Vivek Biswas
>> -T (vibiswas - XORIANT CORPORATION at Cisco)
>> *Sent:* Thursday, June 25, 2015 2:20 PM
>> *To:* [email-masked]
>> *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case
>>
>> Hi All,
>>
>>    I am looking to solve a use-case similar to WS-Security On-Behalf-Of
>> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980>
>>
>> with OAuth JWT Token.
>>
>>    Is there a standard claim which we can define within the OAuth JWT
>> which denote the On-behalf-of User.
>>
>> For e.g., a Customer Representative trying to create token on behalf of
>> a customer and trying to execute services specific for that specific
>> customer.
>>
>> Regards,
>>
>> Vivek Biswas,
>> CISSP
>>
>> *Cisco Systems, Inc <http://www.cisco.com/>*
>>
>> *Bldg. J, San Jose, USA,*
>>
>> *Phone: +1 408 527 9176*
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 01 Jul 2015 08:18:05 -0400

As it's written right now, it's a translation of some WS-* concepts into 
JWT format. It's not really OAuth-y (since the client has to understand 
the token format along with everyone else, and according to the authors 
the artifacts might not even be "OAuth tokens"), and that's my main 
issue with the document. Years ago, I proposed an OAuth-based token swap 
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just 
like the rest of OAuth. I've proposed to the authors of the current 
draft that it should incorporate both semantic (using JWT) and syntactic 
(using a simple token-agnostic grant) token swap mechanisms, and that 
the two could be easily compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
> Hmm... perhaps the clue is in the draft title, token-exchange, so may 
> be it is a case of the given access token ("on_behalf_of" or "act_as"

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 01 Jul 2015 14:07:09 +0100

Hi Justin

https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier 
to read, that I can tell for sure, at least it is obvious why a given 
entity (RS1) may want to exchange the current token provided by a client 
for a new token. Definitely easily implementable...

One thing I'm not sure in the draft-richer-oauth-chain-00 about is on 
behalf of whose entity RS1 will be acting once it starts accessing RS2, 
On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is 
On Behalf Of RO + Act As Client ? The last one seems most logical to me...

Thanks, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Jul 2015 08:59:25 -0600

One problem, I think, with token exchange is that it can be really simple
(token in and token out) and really complicated (client X wants a token
that says user A is doing something on behalf of user B) at the same time.

I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an
attempt to simplify things and express what I envisioned as an OAuth based
token exchange framework. Though it likely only muddied the waters :)

On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <[email-masked]>
wrote:

> Hi Justin
>
> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to
> read, that I can tell for sure, at least it is obvious why a given entity
> (RS1) may want to exchange the current token provided by a client for a new
> token. Definitely easily implementable...
>
> behalf of whose entity RS1 will be acting once it starts accessing RS2, On
> Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On
> Behalf Of RO + Act As Client ? The last one seems most logical to me...
>
> Thanks, Sergey
>
>
>>>>> <
>>>>> http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980
>>>>> >
>>>>>
>>>>>
>>>>> with OAuth JWT Token.
>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Jul 2015 08:32:43 -0700

After putting out the original proposal, I am not totally sure we need it. In many cases we architected around the issue. 
https://tools.ietf.org/html/draft-hunt-oauth-chain-01

Question is token swap for cross domain chaining? Shouldn't in domain servers be acting on internal policy mechanisms? Is there an interop need for the internal case?

I conclude this is a primarily a cross domain case that could also be used in internally. But internal is not the driver. 

Based on the number of submissions, this seems to be a 1% case that everyone has. Unfortunately that means we keep downgrading its priority. 

Phil

> On Jul 1, 2015, at 07:59, Brian Campbell <[email-masked]> wrote:
> 
> One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. 
> 
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) 
> 
>> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <[email-masked]> wrote:
>> Hi Justin
>> 
>> https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable...
>> 
>> One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me...
>> 
>> Thanks, Sergey
>> 
>>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 1 Jul 2015 18:00:19 +0000

Not quite, the actual tokens are still opaque, the requestor is just asking for a token exchange , the requestor can specify the requested token type it's up to the server to determine the actual token it will delever

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, July 1, 2015 5:18 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be "OAuth tokens"), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap
mechanism:

This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:
>> may have delegated its rights to A, any actions taken are being taken 
>> by A and not B. In a sense, A is an agent for B."
>>
>> This is a typical case with the authorization code flow where a 
>> client application acts on-behalf-of the user who authorized this application ?
>>
>>> That's what
>>> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Vivek 
>>> Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)
>>> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust
>>> -1.4-errata01-os-complete.html#_Toc325658980>
>>>
>>>
>>> with OAuth JWT Token.
>>>
>>>    Is there a standard claim which we can define within the OAuth 
>>> JWT which denote the On-behalf-of User.
>>>
>>> For e.g., a Customer Representative trying to create token on behalf 
>>> of a customer and trying to execute services specific for that 
>>> specific customer.
>>>
>>> Regards,
>>>
>>> Vivek Biswas,
>>> CISSP
>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 06 Jul 2015 12:33:03 +0100

Hi Brian

I've read the text, I like it is still pure OAuth2, with few extra 
parameters added to the access token request, and a key response 
property being 'access_token' as opposed to 'security_access_token' as 
in the draft-ietf-oauth-token-exchange-01.
It appears draft-campbell-oauth-sts-01 can cover a 
draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
property being an original client token but not 100% sure given 
draft-richer-oauth-chain-00 covers a specific case.

One thing I'm not sure about is what is the purpose of specifying a 
security_token_type of the returned access token

Thanks, Sergey

On 01/07/15 15:59, Brian Campbell wrote:
> One problem, I think, with token exchange is that it can be really
> simple (token in and token out) and really complicated (client X wants a
> token that says user A is doing something on behalf of user B) at the
> same time.
>
> I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
> an attempt to simplify things and express what I envisioned as an OAuth
> based token exchange framework. Though it likely only muddied the waters :)
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Justin
>
>     https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
>     easier to read, that I can tell for sure, at least it is obvious why
>     a given entity (RS1) may want to exchange the current token provided
>     by a client for a new token. Definitely easily implementable...
>
>     One thing I'm not sure in the draft-richer-oauth-chain-00 about is
>     on behalf of whose entity RS1 will be acting once it starts
>     accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
>     Client), or may be it is On Behalf Of RO + Act As Client ? The last
>     one seems most logical to me...
>
>     Thanks, Sergey
>
>
>                 semantics described in the
>                 draft-ietf-oauth-token-exchange-01 and the
>                     https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01
>                     is
>                     about.
>
>                     Cheers,
>
>                     -- Mike
>
>                     *From:*OAuth [mailto:[email-masked]
>                     <mailto:[email-masked]>] *On Behalf Of *Vivek
>                     Biswas
>                     *To:* [email-masked] <mailto:[email-masked]>
>                     *Phone: +1 408 527 9176 <tel:%2B1%20408%20527%209176>*
>
>
>
>                     [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 6 Jul 2015 08:04:31 -0600

Thanks Sergey,

The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0
and thus hopefully familiar to developers and easy to understand and
implement (especially from the client side). It's also intended to be
flexible in order to accommodate a variety of use-cases including the
chaining type cases that Justin's draft covers.

Specifying a security_token_type of the returned token is just a way of
providing more info to the client about the token (i.e. is this a JWT or a
SAML token or something else) via a URI. It's not always needed but in STS
style cases the tokens are not always opaque to the client and the
parameter just provides info about the returned token.

On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <[email-masked]>
wrote:

> parameters added to the access token request, and a key response property
> being 'access_token' as opposed to 'security_access_token' as in the
> draft-ietf-oauth-token-exchange-01.

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Jul 2015 12:12:34 -0300

Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft.
 
His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint.

I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4.
see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation.

I think Brian is closer in explaining it.

In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations.
I think many times it is how WIF implemented it that people copied.

It may be better to have new terms that are clear such as impersonation and composite.

The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics.   There are plusses and minuses to both options.

Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability.

There are also issues around how this would work with proof of possession security tokens, both as input and output.

Perhaps we can make some progress on this in Prague.

John B.

> On Jul 6, 2015, at 11:04 AM, Brian Campbell <[email-masked]> wrote:
> 
> Thanks Sergey, 
> 
> The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. 
> 
> Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token.  
> 
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <[email-masked]> wrote:
> Hi Brian
> 
> I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01.
> It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case.
> 
> One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token
> 
> Thanks, Sergey
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Jul 2015 16:33:45 +0000

It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4.  I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/

FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are:
  - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values.
  - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate.

I plan to do the first today.  The second is probably more than I'll get done today before the submission cutoff.  I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration.  I'll plan to come into the Prague meeting with a concrete proposal for review.

				Best wishes,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

John B.

> simple (token in and token out) and really complicated (client X wants 
> a token that says user A is doing something on behalf of user B) at 
> the same time.
> 
> an attempt to simplify things and express what I envisioned as an 
> OAuth based token exchange framework. Though it likely only muddied 
> the waters :)
> 
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1
> .4-errata01-os-complete.html#_Toc325658980>
> 
> 
>                     with OAuth JWT Token.
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 6 Jul 2015 10:01:41 -0700

I agree. Changing the terms helps get us out of the perpetual confusion around ActAs and OnBehalfOf.

I like the idea of “impersonation” and “composite” instead.

Phil

@independentid
www.independentid.com
[email-masked]

> On Jul 6, 2015, at 8:12 AM, John Bradley <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 6 Jul 2015 12:28:56 -0600

Stating specific action items resulting from the ad-hoc meeting in Dallas
like that suggests some clear consensus was reached, which is not at all
the case. As I recall, several of us argued past one another for an hour or
so and decided to adjourn in order to go to the bar (okay, and dinner too -
but mostly beer).

The impression about reversal of terms, I think, comes from the text in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
which hurts my head a little every-time I read it but does seems to confuse
things. The MSDN link
<https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is much
more to the point than WS-Trust (I don't believe WS-Trust can be pointed to
as a model of clarity).  In the draft I wrote, I tried to take Mike's text
and clarify a distinction between impersonation and delegation with
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and
then also be very explicit about act-as vs. on-behalf-of in the parameter
definitions at
https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a
manor that was consistent with WS-Trust and the MSDN explanation. I could
see value in breaking with that shaky legacy and using new terms too. But I
get the point of trying to keep with the old also and potential for even
more confusing by using new terms.

I wrote draft-campbell-oauth-sts last year in response to the call for
adoption of jones-oauth-token-exchange (thread from the archive
<https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>).
Though I didn't try and stand in the way and indicated a willingness to
collaborate on things. With the expectation, of course, that the details
would differ from the -00s and -01s as work progressed. Folks seemed generally
amenable to that
<https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at the
time but little has happened since then.

Phil's earlier point about the priory of this getting pushed down has some
truth to it. But I still believe it's something that can provide a lot of
value in standardizing, if we do so in a reasonable way.

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <[email-masked]>
wrote:

> It would surprise me if on-behalf-of and act-as were reversed with respect
> WS-Trust, because the explanations of the terms came directly from WS-Trust
> 1.4.  I also think the chances of us reducing confusion by inventing new
> terminology, rather than adding to it, would not be in our favor. :-/
>
>   - Further integrating the mechanism into the existing OAuth ecosystem -
> allowing use of access tokens or refresh tokens when appropriate.
>
> I plan to do the first today.  The second is probably more than I'll get
> done today before the submission cutoff.  I agree with John that it would
> be useful to have discussions on this in Prague on the best way to achieve
> this further integration.  I'll plan to come into the Prague meeting with a
> concrete proposal for review.
>
>                                 Best wishes,
>                                 -- Mike
>
> In fairness because WS-Trust originally only had On-Behalf-Of the naming
> and what people put in tokens is a bit muddled in many implementations.
> The WG needs to decide if this is going to be an entirely new endpoint,
> free of the Token endpoint semantics.   There are plusses and minuses to
> both options.
>
> Also while it is nice to be pure and talk about abstract security tokens,
> it would be good to give some guidance on what a composite security token
> would look like for interoperability.
>
> There are also issues around how this would work with proof of possession
> security tokens, both as input and output.
>

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Jul 2015 15:45:52 -0300

Mike,

I have pointed this out several times.  I understand that you disagree. 

The WS-Trust spec is not as clear as it could be.  I included the MSDN note explaining how WIF interprets it.
> https://msdn.microsoft.com/en-us/library/ee748487.aspx

Given that there seems to be differing opinions on the semantics beyond just me, can we agree that the terms are not as clear as one would hope?

I may be wrong, but I suspect that I am not the only one.  

We can discuss it at the F2F.

John B.
> On Jul 6, 2015, at 1:33 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 6 Jul 2015 18:48:46 +0000

Fair enough, Brian.  For clarity, my sense of the action items is that I agreed to do those actions based on feedback at the ad-hoc meeting and then people would review the result – not that everything would be “done” after taking those actions.  I’ll still plan to act on that feedback.

I’d be glad to sit down with you and others in Prague, Brian, to work out how to make sure your use cases are covered and the draft is as clear as it can be, given its somewhat esoteric subject matter.  Now that JWT and JOSE and the OAuth Assertions specs are done and several others are nearly done, getting back to this is a priority for me.

                                                            Cheers,
                                                            -- Mike

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, July 06, 2015 11:29 AM
To: Mike Jones
Cc: John Bradley; oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer).
The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link<https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity).  In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms.
I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive<https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that<https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at the time but little has happened since then.
Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way.

On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4.  I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/

                                Best wishes,
                                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

John B.

> On Jul 6, 2015, at 11:04 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>
> Thanks Sergey,
>
> On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Brian
>
> On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Justin
>
>                     *From:*OAuth [mailto:[email-masked]<mailto:[email-masked]>
>                     <mailto:[email-masked]<mailto:[email-masked]>>] *On Behalf Of *Vivek
>                     Biswas
>                     *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>                     *Phone: +1 408 527 9176<tel:%2B1%20408%20527%209176>
> <tel:%2B1%20408%20527%209176>*
>
>
>
>                     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 6 Jul 2015 20:43:26 +0000

The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation)  feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account.

WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf”  allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access.

Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows.

Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox.

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

                                Best wishes,
                                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Jul 2015 18:18:37 -0300

I keep providing links to MS documentation that leads one to a different conclusion for WIF.
https://msdn.microsoft.com/en-us/library/ee748487.aspx <https://msdn.microsoft.com/en-us/library/ee748487.aspx> and https://msdn.microsoft.com/en-us/library/ee517269.aspx
An ActAs RST element indicates that the requestor wants a token that contains claims about two distinct entities: the requestor, and an external entity represented by the token in the ActAs element.

An OnBehalfOf RST element indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the OnBehalfOf element.

That reflects my understanding that prior to WS-Trust 1.4 OnBehalfOf was impersonation and in WS-Trust 1.4 was added to provide the composite assertion.

The JBOS docs and examples are also consistent with this https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scenario
Or these: https://thilinamb.wordpress.com/2009/08/21/identity-delegation-in-ws-trust-1-4/
                http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identity-foundation-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirected=true
                https://www.netiq.com/documentation/netiqaccessmanager4/identityserverhelp/data/ws-trust_usecases.html

Given that you were one of the authors, you are as close to authoritative as one could get.   

However as far as I can tell there is some confusion that needs to be resolved. 

I agree we need the functionality of the two, and I don’t really care what they are called as long as we are not confusing developers.

John B.

> On Jul 6, 2015, at 5:43 PM, Anthony Nadalin <[email-masked]> wrote:
> 
> Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows.  <>
>  
> The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3> which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link <https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity).  In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3> and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2> in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. 
> 
> I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive <https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at the time but little has happened since then.
> 
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx <https://msdn.microsoft.com/en-us/library/ee748487.aspx> for the short explanation.
> 
> > On Jul 6, 2015, at 11:04 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Thanks Sergey,
> >
> > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Brian
> >
> > I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01> in
> > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >     Hi Justin
> >
> >     https://tools.ietf.org/html/draft-richer-oauth-chain-00 <https://tools.ietf.org/html/draft-richer-oauth-chain-00> is much
> >         https://tools.ietf.org/html/draft-richer-oauth-chain-00 <https://tools.ietf.org/html/draft-richer-oauth-chain-00>
> >
> >                     https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01>
> >                     is
> >                     about.
> >
> >                     Cheers,
> >
> >                     -- Mike
> >
> >                     *From:*OAuth [mailto:[email-masked] <mailto:[email-masked]>
> >                     <mailto:[email-masked] <mailto:[email-masked]>>] *On Behalf Of *Vivek
> >                     Biswas
> >                     *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1 <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1>
> >                     *Cisco Systems, Inc <http://www.cisco.com/ <http://www.cisco.com/>>*
> >
> >                     *Phone: +1 408 527 9176 <tel:%2B1%20408%20527%209176>
> > <tel:%2B1%20408%20527%209176 <tel:%2B1%20408%20527%209176>>*
> >
> >
> >
> >                     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >
> >             [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >             https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >         https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 6 Jul 2015 14:20:55 -0700

I think the original reasoning was sound, but the fact that so many remain confused is good reason to go to new vocab.

We could still have clarifying text that impersonate/composite is xxx and yyy in kerberos etc. 

Phil

> On Jul 6, 2015, at 13:43, Anthony Nadalin <[email-masked]> wrote:
> 
> The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity).  In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms.
> 
> I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that at the time but little has happened since then.
> 
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Mon, 6 Jul 2015 15:32:48 -0600

A natural usage of act-as or impersonation
<http://www.oxforddictionaries.com/us/definition/american_english/impersonate>
would suggest, to many people anyway, that the way you just used the terms
is reversed. The bold text below from
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3
uses 'impersonates' and "on-behalf-of" contrary to what you just wrote
about Windows Kerb. That's where the assertion that the draft has them
reversed from de facto usage in WS-Trust. Those semantics are not only one
open issue that needs to be resolved, however, even if they occupy most of
the discussion.

1.3.  On-Behalf-Of vs. Impersonation Semantics

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, *with*
*   on-behalf-of semantics, principal A still has its own identity*
*   separate from B and it is explicitly understood that while B may have*
*   delegated its rights to A, any actions taken are being taken by A and*
*   not B. In a sense, A is an agent for B.*

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  *When principal A*
*   impersonates principal B, then in so far as any entity receiving*
*   Claims is concerned, they are actually dealing with B. *It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.

On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin <[email-masked]>
wrote:

>  The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition
> (impersonation)  feature as this enables an account to impersonate another
> account for the purpose of providing access to resources. In a typical
> scenario, the impersonating account would be a service account assigned to
> a web application or the computer account of a web server. The impersonated
> account would be a user account requiring access to resources (e.g. data in
> an SQL database) via a web application. In this scenario, SQL server would
> be accessed by the impersonating (service account) account, however access
> would be under the context of the impersonated (user) account.
>
>
>
> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained Delegation
> feature, which lets you limit the back-end services for which a front-end
> service can request tickets on behalf of another user. “OnBehalfOf”  allows
> a selected services on a server can be granted for access by the
> impersonating account, whilst other services on the same server, or
> services on other servers are denied for access.
>
>
>
> Maybe someone can summarize why they think the text for ActAs and
> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have
> not seen a clear explanation other than John saying that Brian knows and
> Brian saying John knows.
>
>
>
> Our usage and use cases are based upon the deployed services of WS-Trust
> and Kerberos support in Windows (workstation and server) and Xbox.
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, July 6, 2015 11:29 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* oauth <[email-masked]>
>
> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case
>
>
>
> <https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is
> much more to the point than WS-Trust (I don't believe WS-Trust can be
> pointed to as a model of clarity).  In the draft I wrote, I tried to take
> Mike's text and clarify a distinction between impersonation and delegation
> with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3
> and then also be very explicit about act-as vs. on-behalf-of in the
> parameter definitions at
> <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at
> the time but little has happened since then.
>
> >                     *Phone: +1 408 527 9176
> > <tel:%2B1%20408%20527%209176 <%2B1%20408%20527%209176>>*
> >
> >
> >

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Jul 2015 18:51:32 -0300

Sorry Mike,

I was looking at an earlier version that had them reversed.   I think the wording can be improved but the composite vs delegation semantic is correct now.

However Tony now seems to disagree with that.   I am going to walk away slowly and let you sort out his last post:)

We can discuss further in Prague.

John B.

> On Jul 6, 2015, at 3:48 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 6 Jul 2015 21:56:01 +0000

What is written in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and the text that describes the Windows Kerberos support for Protocol Transition and Constrained Delegation are in alignment not sure what make you think they are not.

If you are trying to describe different features than Windows Kerberos Protocol Transition/Constrained Delegation that then I would agree that the text may not be correct but then again it would not be describing the Windows Kerberos Protocol Transition/Constrained Delegation. The way you have the text describes different set use case then what the feature of  https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 describes.

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, July 6, 2015 2:33 PM
To: Anthony Nadalin <[email-masked]>
Cc: Mike Jones <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

A natural usage of act-as or impersonation<http://www.oxforddictionaries.com/us/definition/american_english/impersonate> would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and "on-behalf-of" contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion.

   When principal A acts on behalf of principal B, A is given all the
   rights that B has within some defined rights context.  Whereas, with
   on-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A and
   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.

On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation)  feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account.

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Monday, July 6, 2015 11:29 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>

                                Best wishes,
                                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Monday, July 06, 2015 8:13 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

John B.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 6 Jul 2015 15:59:05 -0600

That doesn't even make sense.

On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin <[email-masked]>
wrote:

>  What is written in
> and the text that describes the Windows Kerberos support for Protocol
> Transition and Constrained Delegation are in alignment not sure what make
> you think they are not.
>
>
>
> If you are trying to describe different features than Windows Kerberos Protocol
> Transition/Constrained Delegation that then I would agree that the text
> may not be correct but then again it would not be describing the Windows
> Kerberos Protocol Transition/Constrained Delegation. The way you have the
> text describes different set use case then what the feature of
> describes.
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Monday, July 6, 2015 2:33 PM
> *To:* Anthony Nadalin <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; oauth <[email-masked]>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 06 Jul 2015 20:03:59 -0400

+1 for this. Let's learn from the mistakes of the past instead of 
repeating them. "We've always done it this way" is a really, really poor 
reason for doing something.

  -- Justin

On 7/6/2015 5:20 PM, Phil Hunt wrote:
> I think the original reasoning was sound, but the fact that so many 
> remain confused is good reason to go to new vocab.
>
> On Jul 6, 2015, at 13:43, Anthony Nadalin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> (impersonation)  feature as this enables an account to impersonate 
>> another account for the purpose of providing access to resources. In 
>> a typical scenario, the impersonating account would be a service 
>> account assigned to a web application or the computer account of a 
>> web server. The impersonated account would be a user account 
>> requiring access to resources (e.g. data in an SQL database) via a 
>> web application. In this scenario, SQL server would be accessed by 
>> the impersonating (service account) account, however access would be 
>> under the context of the impersonated (user) account.
>>
>> WS-Trust “OnBehalfOf”  mimics the Windows Kerberos Constrained 
>> Delegation feature, which lets you limit the back-end services for 
>> which a front-end service can request tickets on behalf of another 
>> user. “OnBehalfOf”  allows a selected services on a server can be 
>> granted for access by the impersonating account, whilst other 
>> services on the same server, or services on other servers are denied 
>> for access.
>>
>> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I 
>> have not seen a clear explanation other than John saying that Brian 
>> knows and Brian saying John knows.
>>
>> Our usage and use cases are based upon the deployed services of 
>> WS-Trust and Kerberos support in Windows (workstation and server) and 
>> Xbox.
>>
>> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Brian 
>> Campbell
>> *To:* Mike Jones <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>> Stating specific action items resulting from the ad-hoc meeting in 
>> Dallas like that suggests some clear consensus was reached, which is 
>> not at all the case. As I recall, several of us argued past one 
>> another for an hour or so and decided to adjourn in order to go to 
>> the bar (okay, and dinner too - but mostly beer).
>>
>> which hurts my head a little every-time I read it but does seems to 
>> confuse things. The MSDN link 
>> pointed to as a model of clarity).  In the draft I wrote, I tried to 
>> take Mike's text and clarify a distinction between impersonation and 
>> delegation with 
>> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 
>> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in 
>> a manor that was consistent with WS-Trust and the MSDN explanation. I 
>> could see value in breaking with that shaky legacy and using new 
>> terms too. But I get the point of trying to keep with the old also 
>> and potential for even more confusing by using new terms.
>>
>> I wrote draft-campbell-oauth-sts last year in response to the call 
>> for adoption of jones-oauth-token-exchange (thread from the archive 
>> Though I didn't try and stand in the way and indicated a willingness 
>> to collaborate on things. With the expectation, of course, that the 
>> details would differ from the -00s and -01s as work progressed. Folks 
>> seemed generally amenable to that 
>> <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> 
>> at the time but little has happened since then.
>>
>> Phil's earlier point about the priory of this getting pushed down has 
>> some truth to it. But I still believe it's something that can provide 
>> a lot of value in standardizing, if we do so in a reasonable way.
>>
>>
>>
>> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     It would surprise me if on-behalf-of and act-as were reversed
>>     with respect WS-Trust, because the explanations of the terms came
>>     directly from WS-Trust 1.4.  I also think the chances of us
>>     reducing confusion by inventing new terminology, rather than
>>     adding to it, would not be in our favor. :-/
>>
>>       - Further integrating the mechanism into the existing OAuth
>>     ecosystem - allowing use of access tokens or refresh tokens when
>>     appropriate.
>>
>>     I plan to do the first today.  The second is probably more than
>>     I'll get done today before the submission cutoff.  I agree with
>>     John that it would be useful to have discussions on this in
>>     Prague on the best way to achieve this further integration. I'll
>>     plan to come into the Prague meeting with a concrete proposal for
>>     review.
>>
>>                                     Best wishes,
>>                                     -- Mike
>>
>>
>>     From: OAuth [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of John Bradley
>>     I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf
>>     and ActAs reversed compared to WS-Trust 1.4.
>>     In fairness because WS-Trust originally only had On-Behalf-Of the
>>     naming and what people put in tokens is a bit muddled in many
>>     implementations.
>>     The WG needs to decide if this is going to be an entirely new
>>     endpoint, free of the Token endpoint semantics.   There are
>>     plusses and minuses to both options.
>>
>>     Also while it is nice to be pure and talk about abstract security
>>     tokens, it would be good to give some guidance on what a
>>     composite security token would look like for interoperability.
>>
>>     There are also issues around how this would work with proof of
>>     possession security tokens, both as input and output.
>>
>>     > On Jul 6, 2015, at 11:04 AM, Brian Campbell
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>     >
>>     > Thanks Sergey,
>>     >
>>     > The goal of draft-campbell-oauth-sts was to be consistent with
>>     OAuth 2.0 and thus hopefully familiar to developers and easy to
>>     understand and implement (especially from the client side). It's
>>     also intended to be flexible in order to accommodate a variety of
>>     use-cases including the chaining type cases that Justin's draft
>>     covers.
>>     >
>>     > Specifying a security_token_type of the returned token is just
>>     a way of providing more info to the client about the token (i.e.
>>     is this a JWT or a SAML token or something else) via a URI. It's
>>     not always needed but in STS style cases the tokens are not
>>     always opaque to the client and the parameter just provides info
>>     about the returned token.
>>     >
>>     > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     > Hi Brian
>>     >
>>     > I've read the text, I like it is still pure OAuth2, with few
>>     extra parameters added to the access token request, and a key
>>     response property being 'access_token' as opposed to
>>     'security_access_token' as in the draft-ietf-oauth-token-exchange-01.
>>     draft-richer-oauth-chain-00 case with the on_behalf_of (and/or
>>     act_as ?) property being an original client token but not 100%
>>     sure given draft-richer-oauth-chain-00 covers a specific case.
>>     >
>>     > I put forth
>>     https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
>>     > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin
>>     <[email-masked] <mailto:[email-masked]>
>>     >         JWT format. It's not really OAuth-y (since the client
>>     has to
>>     >         understand
>>     >         the token format along with everyone else, and
>>     according to the
>>     >         authors
>>     >         issue with the document. Years ago, I proposed an
>>     OAuth-based
>>     >         token swap
>>     >         mechanism:
>>     >
>>     >         draft that it should incorporate both semantic (using
>>     JWT) and
>>     >         syntactic
>>     >         (using a simple token-agnostic grant) token swap
>>     mechanisms, and
>>     >         that
>>     >             be it is a case of the given access token
>>     ("on_behalf_of" or
>>     >             "act_as"
>>     >             claim) being used to request a new security token.
>>     One can
>>     >             only guess
>>     >             though, does not seem like the authors are keen to
>>     answer
>>     >             the newbie
>>     >             questions...
>>     >
>>     >             Cheers, Sergey
>>     >
>>     >
>>     >                 Can you please explain what is the difference
>>     between
>>     >                 On-Behalf-Of
>>     >                 implicit On-Behalf-Of semantics a client OAuth2
>>     token
>>     >                 possesses ?
>>     >
>>     >                 "Whereas, with on-behalf-of semantics,
>>     principal A still
>>     >                 has its own
>>     >                 identity separate from B and it is explicitly
>>     understood
>>     >                 that while B
>>     >                 may have delegated its rights to A, any actions
>>     taken
>>     >                 are being taken by
>>     >                 This is a typical case with the authorization
>>     code flow
>>     >                 where a client
>>     >                 application acts on-behalf-of the user who
>>     authorized
>>     >                 this application ?
>>     >
>>     <mailto:[email-masked]>
>>     >                     <mailto:[email-masked]
>>     <mailto:[email-masked]>>] *On Behalf Of *Vivek
>>     >                     Biswas
>>     <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>
>>     >                     *Subject:* [OAUTH-WG] JWT Token on-behalf
>>     of Use
>>     > case
>>     >
>>     >                     Hi All,
>>     >
>>     >                         Is there a standard claim which we can
>>     define
>>     >                     within the OAuth JWT
>>     >                     For e.g., a Customer Representative trying
>>     to create
>>     >                     token on behalf of
>>     >                     a customer and trying to execute services
>>     specific
>>     >                     for that specific
>>     >                     customer.
>>     >
>>     >                     Regards,
>>     >
>>     >                     Vivek Biswas,
>>     >                     CISSP
>>     >
>>     <tel:%2B1%20408%20527%209176>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Jul 2015 15:18:46 -0400

Speaking as someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand
the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.

This may be a case where new terminology is worthwhile if you can find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Jul 2015 15:43:29 -0400

I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus on that
approach in this thread at all.

Could we see presentations on Mike's draft and Brian's?  Justin, do you
agree that Brian's draft covers the use case in our draft as was implied in
this thread?

I'd like to see a discussion guided by the chairs to see if we can find a
go-forward plan.  There seems to be differing opinions and maybe a pull
towards simpler approaches that extend Oauth.

Thank you.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Jul 2015 15:44:00 -0400

> agree that Brian's draft covers the use case in our draft as was implied in
s/our/your/ :-)

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Jul 2015 15:51:32 -0400

Kathleen,

I agree that Brian’s approach covers the use case that drove my original draft and effectively subsumes my approach.

My standing contention with the document as it stands is and has always been that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I would love to see a productive conversation on this front.

 — Justin

> On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all.
> 
> Could we see presentations on Mike's draft and Brian's?  Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread?  
> 
> I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan.  There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth.
> 
> Thank you.
> 
> On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Jul 2015 19:59:04 +0000

I’ll write a note later today describing how the just-published update that makes the Token Exchange draft token-type agnostic also enables it to be used in fully “OAuthy” cases – where some of the tokens used are OAuth access tokens or refresh tokens.

(Right now I’m writing up the changes made to draft-ietf-oauth-proof-of-possession, then will get to the JWK Thumbprint and Token Exchange write-ups…)

                                                                Cheers,
                                                                -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, July 07, 2015 12:52 PM
To: Kathleen Moriarty
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Kathleen,

 — Justin

On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Thank you.

On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman <[email-masked]<mailto:[email-masked]>> wrote:

--

Best regards,
Kathleen