Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Brian Campbell]

Perhaps I’m just in a minority that lacks the intellectual prowess to
really understand the WS* specifications but, to me anyway, saying
that it’s clearly defined there is standing on very shaky ground.

When I read §1.3 of draft-jones-oauth-token-exchange-00[0], it sure
sounded to me like it was describing the result of an On-Behalf-Of
request as retuning a composite token with claims about both principal
A and B saying, "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.” Whereas the MS FAQ[1] suggests that such
a composite token is requested using ActAs, “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.” And an OnBehalfOf
request is for a token with claims about only one thing, “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."

John mentioned to me some time ago that he thought the use of the
terms was reversed in draft-jones-oauth-token-exchange-00 vs WS-Trust.
I didn’t believe him (as usual) so I went internet searching to try
and find something to prove him wrong. However, I quickly found what I
described in the previous paragraph, which was enough to suggest he
was at least partially correct. That’s what I was referring to in my
ordinal message on this thread and I apologize if this has been a
unnecessary distraction. I understand it was just a -00 version of an
individual draft. I was only trying to point out an area that I
thought was confusing with the hoped that it could be clarified.

I do think there’s potentially a lot of utility in a token exchange
protocol and I’d be interested in contributing in some way. But, to me
anyway, this draft feels a lot like WS-Trust getting a makeover with
JWT/JSON and kind of being bolted onto the Token Endpoint. When I
think about OAuth Token Exchange I envision something more aligned
with, and utilizing the constructs provided by, OAuth 2.0 while also
being something that is similarly friendly to developers on the client
side.

[0] http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-1.3
[1] http://msdn.microsoft.com/en-us/library/ee748487.aspx

On Thu, Jul 3, 2014 at 4:09 PM, John Bradley  wrote:
> This is the first time this draft has come up on the list so people coming
> up to speed is to be expected.
>
> In WS-Trust the security tokens are not tied to a single representation.
>
> /wst:RequestSecurityToken/wst14:ActAs
>
> This OTPIONAL element indicates that the requested token is expected to
> contain information about the identity represented by the content of this
> element and the token requestor intends to use the returned token to act as
> this identity. The identity that the requestor wants to act-as is specified
> by placing a security token or  element within
> the  element.
>
>
> Is clear that the resulting token contains information about the identity
> represented by the security token passed as the content of the ActAs element
> and that the requester wants to act-as is that identity.
>
> Depending on the resulting security token that may be represented
> differently.   Nothing explicitly states that the identity of the requester
> is in the resulting token, however when SAML tokens are used it typically is
> represented along with the identity to act-as.
>
> OnBehalfOf being older was treated as a proxy type request On-Behalf-Of the
> initial subject resulting in a token for the Original subject that may have
> been used by another party such as the requester.
>
> So Sec 1.3 may be trying to describe composite tokens vs single subject
> tokens that may be beyond the scope of those token independent parameters in
> WS-Trust.
>
> It is probably fair to say that from the way those parameters are
> implemented for SAML tokens in many if not all STS the description seems
> backwards.
>
> Having something that describes how the output token varies based on input
> for typical token types might help make it more concrete for people.
>
> John B.
>
> On Jul 3, 2014, at 5:55 PM, Anthony Nadalin  wrote:
>
> ActAs the returned token is expected to be represented by the identity
> described by this parameter
> OnBehalfOf the request is being made by the identity described by this
> parameter
>
> These terms have been pretty clearly defined in the WS specifications, I
> don’t understand the confusion. If section 1.3 is confusing, I’m OK with
> dropping this
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Brad

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[John Bradley]

This is the first time this draft has come up on the list so people coming up 
to speed is to be expected.

In WS-Trust the security tokens are not tied to a single representation.  
/wst:RequestSecurityToken/wst14:ActAs
This OTPIONAL element indicates that the requested token is expected to contain 
information about the identity represented by the content of this element and 
the token requestor intends to use the returned token to act as this identity. 
The identity that the requestor wants to act-as is specified by placing a 
security token or  element within the 
 element.


Is clear that the resulting token contains information about the identity 
represented by the security token passed as the content of the ActAs element 
and that the requester wants to act-as is that identity.

Depending on the resulting security token that may be represented differently.  
 Nothing explicitly states that the identity of the requester is in the 
resulting token, however when SAML tokens are used it typically is represented 
along with the identity to act-as.   

OnBehalfOf being older was treated as a proxy type request On-Behalf-Of the 
initial subject resulting in a token for the Original subject that may have 
been used by another party such as the requester.

So Sec 1.3 may be trying to describe composite tokens vs single subject tokens 
that may be beyond the scope of those token independent parameters in WS-Trust.

It is probably fair to say that from the way those parameters are implemented 
for SAML tokens in many if not all STS the description seems backwards.

Having something that describes how the output token varies based on input for 
typical token types might help make it more concrete for people.

John B.

On Jul 3, 2014, at 5:55 PM, Anthony Nadalin  wrote:

> ActAs the returned token is expected to be represented by the identity 
> described by this parameter
> OnBehalfOf the request is being made by the identity described by this 
> parameter
>  
> These terms have been pretty clearly defined in the WS specifications, I 
> don’t understand the confusion. If section 1.3 is confusing, I’m OK with 
> dropping this
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Thursday, July 3, 2014 2:44 PM
> To: Phil Hunt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>  
> I pointed out a problem with the non normative text in sec 1.3 to Mike off 
> list quite a while go.
>  
> 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.
>  
> OnBehalfOf  "indicates that the requestor is making the request on behalf of 
> another." and returns a security token to the requestor that contains a 
> single set of claims.
>  
> ActAs provides a security token/ assertion about subject A in a request from 
> Requester B and the response is a composite token that has Requester B as the 
> subject but also includes claims about subject A.
>  
> See MS FAQ to clarify this  popular question 
> http://msdn.microsoft.com/en-us/library/ee748487.aspx
>  
> I think this is what Brian was trying to get at. 
>  
> If we can't all agree on the semantics of OnBehalfOf (It has been around for 
> a long time) then we have a problem and should pick different terms.
>  
> The normative text is correct, however sec 2.2 adds an optional "actor" claim 
> to the initial JWT that is to be presented as the value of  on_behalf_of in 
> the request.  That is an addition to the WS-Trust text and took me several 
> reads to understand that it is not a element in the JWT response. 
>  
> I offered to help with the spec as I think it is useful.  The semantics are 
> tricky for people to understand so I was not all that concerned that the 
> first draft was not perfect.  
>  
> I suspect some concrete examples will help.
>  
> John B.
>  
> On Jul 3, 2014, at 3:51 PM, Phil Hunt  wr

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

ActAs the returned token is expected to be represented by the identity 
described by this parameter
OnBehalfOf the request is being made by the identity described by this parameter

These terms have been pretty clearly defined in the WS specifications, I don't 
understand the confusion. If section 1.3 is confusing, I'm OK with dropping this

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 3, 2014 2:44 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I pointed out a problem with the non normative text in sec 1.3 to Mike off list 
quite a while go.

1.3<http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00#section-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.

OnBehalfOf  "indicates that the requestor is making the request on behalf of 
another." and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at.

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional "actor" claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response.

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:


I suspect it lines up. But Brian's point may still be relevant. There is *long* 
standing confusion of the terms (because many of have different english 
interpretation than WS-Trust). Might be time for new terms?

Impersonate (or even personate) vs. delegate ?

Those terms differentiate between impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Jul 3, 2014, at 12:20 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


I'm lost too, as when I wrote this, I explicitly modelled it after WS-Trust.  
If there's a concrete discrepancy you can point out, that would be great.

FYI, I do plan to refresh this draft too allow for a more flexible trust model 
shortly.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I'm lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your d

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[John Bradley]

I pointed out a problem with the non normative text in sec 1.3 to Mike off list 
quite a while go.

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.

OnBehalfOf  "indicates that the requestor is making the request on behalf of 
another." and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at. 

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional "actor" claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response. 

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.  

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt  wrote:

> I suspect it lines up. But Brian’s point may still be relevant. There is 
> *long* standing confusion of the terms (because many of have different 
> english interpretation than WS-Trust). Might be time for new terms?
> 
> Impersonate (or even personate) vs. delegate ?
> 
> Those terms differentiate between impersonating a whole person vs. having 
> delegate or scoped authority to act for someone.
> 
> Sorry if this is an old discussion.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Jul 3, 2014, at 12:20 PM, Mike Jones  wrote:
> 
>> I’m lost too, as when I wrote this, I explicitly modelled it after WS-Trust. 
>>  If there’s a concrete discrepancy you can point out, that would be great.
>>  
>> FYI, I do plan to refresh this draft too allow for a more flexible trust 
>> model shortly.
>>  
>> -- Mike
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
>> Sent: Thursday, July 03, 2014 12:04 PM
>> To: Brian Campbell
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>>  
>> I’m lost, the terms defined in the oauth token-exchange draft are the same 
>> terms defined in ws-trust and have the same definitions
>>  
>> From: Brian Campbell [mailto:bcampb...@pingidentity.com] 
>> Sent: Thursday, July 3, 2014 12:02 PM
>> To: Anthony Nadalin
>> Cc: Vladimir Dzhuvinov; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>>  
>> And I was suggesting that OAuth token exchange align with the WS-Trust 
>> definitions or maybe even define totally new terms. But not use the same 
>> terms to mean different things.
>>  
>> 
>> On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin  
>> wrote:
>> The explanation of on-behalf-Of and ActAs are correct in the document as 
>> defined by WS-Trust, this may not be your desire or understanding but that 
>> is how WS-Trust implementations should work
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
>> Sent: Thursday, July 3, 2014 11:44 AM
>> To: Vladimir Dzhuvinov
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>>  
>> FWIW, I am very interested in the general concept of a lightweight or OAuth 
>> based token exchange mechanism. However, despite some

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Brian Campbell]

I don't think they do line up, at least not they way I read text from
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html and
http://msdn.microsoft.com/en-us/library
and /ee748487.aspx <http://msdn.microsoft.com/en-us/library/ee748487.aspx>
and *http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
<http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00>*

Indecently, Bradely was the guy that suggested to me that the definitions
are reversed so I'm guessing he reads it the same way.

But Tony and Mike are authors of the two specs respectively in question so,
if they say that the definitions are aligned, they must be right.

As Phil said, there is a lot of historical confusion about the terms and I
think this conversation only underscores that confusion. A clean break with
new terms might be the way to go.



On Thu, Jul 3, 2014 at 1:51 PM, Phil Hunt  wrote:

> I suspect it lines up. But Brian’s point may still be relevant. There is
> *long* standing confusion of the terms (because many of have different
> english interpretation than WS-Trust). Might be time for new terms?
>
> Impersonate (or even personate) vs. delegate ?
>
> Those terms differentiate between impersonating a whole person vs. having
> delegate or scoped authority to act for someone.
>
> Sorry if this is an old discussion.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Jul 3, 2014, at 12:20 PM, Mike Jones 
> wrote:
>
>  I’m lost too, as when I wrote this, I explicitly modelled it after
> WS-Trust.  If there’s a concrete discrepancy you can point out, that would
> be great.
>
>
>
> FYI, I do plan to refresh this draft too allow for a more flexible trust
> model shortly.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Anthony Nadalin
> *Sent:* Thursday, July 03, 2014 12:04 PM
> *To:* Brian Campbell
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>
>
>
> I’m lost, the terms defined in the oauth token-exchange draft are the same
> terms defined in ws-trust and have the same definitions
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com
> ]
> *Sent:* Thursday, July 3, 2014 12:02 PM
> *To:* Anthony Nadalin
> *Cc:* Vladimir Dzhuvinov; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>
>
>
> And I was suggesting that OAuth token exchange align with the WS-Trust
> definitions or maybe even define totally new terms. But not use the same
> terms to mean different things.
>
>
>
> On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
> wrote:
>
>  The explanation of on-behalf-Of and ActAs are correct in the document as
> defined by WS-Trust, this may not be your desire or understanding but that
> is how WS-Trust implementations should work
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 3, 2014 11:44 AM
> *To:* Vladimir Dzhuvinov
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>
>
>
> FWIW, I am very interested in the general concept of a lightweight or
> OAuth based token exchange mechanism. However, despite some distaste for
> the protocol, our existing WS-Trust functionality has proven to be "good
> enough" for most use-cases, which seems to prevent work on token exchange
> from getting any real priority.
>
> I have a few thoughts on
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
> been meaning to write down but haven't yet, so this seems like as good a
> time as any.
>
> I would really like to see a simpler request model that doesn't require
> the request to be JWT encoded.
>
> The draft mentions the potential confusion around On-Behalf-Of vs.
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the
> use of Act-As and On-Behalf-Of seem to be reversed from how they are
> defined in WS-Trust
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS
> FAQ <http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less
> confusing wording). They should probably be aligned with that prior work to
> avoid further confusion. Or maybe making a clean break and introducing new
> terms would be better.
>
> I don't think the security_token_request grant type value is strictly
> legal per RFC 6749. The ABNF at
> http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but
> according to http://tools.ietf.org/html/rfc6749#section-4.5 extension
> gr

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Phil Hunt]

I suspect it lines up. But Brian’s point may still be relevant. There is *long* 
standing confusion of the terms (because many of have different english 
interpretation than WS-Trust). Might be time for new terms?

Impersonate (or even personate) vs. delegate ?

Those terms differentiate between impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Jul 3, 2014, at 12:20 PM, Mike Jones  wrote:

> I’m lost too, as when I wrote this, I explicitly modelled it after WS-Trust.  
> If there’s a concrete discrepancy you can point out, that would be great.
>  
> FYI, I do plan to refresh this draft too allow for a more flexible trust 
> model shortly.
>  
> -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Thursday, July 03, 2014 12:04 PM
> To: Brian Campbell
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>  
> I’m lost, the terms defined in the oauth token-exchange draft are the same 
> terms defined in ws-trust and have the same definitions
>  
> From: Brian Campbell [mailto:bcampb...@pingidentity.com] 
> Sent: Thursday, July 3, 2014 12:02 PM
> To: Anthony Nadalin
> Cc: Vladimir Dzhuvinov; oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>  
> And I was suggesting that OAuth token exchange align with the WS-Trust 
> definitions or maybe even define totally new terms. But not use the same 
> terms to mean different things.
>  
> 
> On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin  
> wrote:
> The explanation of on-behalf-Of and ActAs are correct in the document as 
> defined by WS-Trust, this may not be your desire or understanding but that is 
> how WS-Trust implementations should work
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, July 3, 2014 11:44 AM
> To: Vladimir Dzhuvinov
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>  
> FWIW, I am very interested in the general concept of a lightweight or OAuth 
> based token exchange mechanism. However, despite some distaste for the 
> protocol, our existing WS-Trust functionality has proven to be "good enough" 
> for most use-cases, which seems to prevent work on token exchange from 
> getting any real priority.
> 
> I have a few thoughts on 
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've 
> been meaning to write down but haven't yet, so this seems like as good a time 
> as any.
> 
> I would really like to see a simpler request model that doesn't require the 
> request to be JWT encoded.
> 
> The draft mentions the potential confusion around On-Behalf-Of vs. 
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
> of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
> WS-Trust (this MS FAQ has less confusing wording). They should probably be 
> aligned with that prior work to avoid further confusion. Or maybe making a 
> clean break and introducing new terms would be better.
> 
> I don't think the security_token_request grant type value is strictly legal 
> per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 
> would allow it but according to 
> http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an 
> absolute URI as the grant type value (there's no grant type registry so the 
> URI is the only means of preventing collision).
> 
>  
> 
>  
> 
>  
> 
>  
> 
> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov  
> wrote:
> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
> 
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
> 
> Thanks,
> 
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
> 
> ___
> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Mike Jones]

I’m lost too, as when I wrote this, I explicitly modelled it after WS-Trust.  
If there’s a concrete discrepancy you can point out, that would be great.

FYI, I do plan to refresh this draft too allow for a more flexible trust model 
shortly.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I’m lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be "good enough" 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS 
FAQ<http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

I’m lost, the terms defined in the oauth token-exchange draft are the same 
terms defined in ws-trust and have the same definitions

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, July 3, 2014 12:02 PM
To: Anthony Nadalin
Cc: Vladimir Dzhuvinov; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust 
definitions or maybe even define totally new terms. But not use the same terms 
to mean different things.

On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be "good enough" 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS 
FAQ<http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Brian Campbell]

And I was suggesting that OAuth token exchange align with the WS-Trust
definitions or maybe even define totally new terms. But not use the same
terms to mean different things.


On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin 
wrote:

>  The explanation of on-behalf-Of and ActAs are correct in the document as
> defined by WS-Trust, this may not be your desire or understanding but that
> is how WS-Trust implementations should work
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 3, 2014 11:44 AM
> *To:* Vladimir Dzhuvinov
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00
>
>
>
> FWIW, I am very interested in the general concept of a lightweight or
> OAuth based token exchange mechanism. However, despite some distaste for
> the protocol, our existing WS-Trust functionality has proven to be "good
> enough" for most use-cases, which seems to prevent work on token exchange
> from getting any real priority.
>
> I have a few thoughts on
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
> been meaning to write down but haven't yet, so this seems like as good a
> time as any.
>
> I would really like to see a simpler request model that doesn't require
> the request to be JWT encoded.
>
> The draft mentions the potential confusion around On-Behalf-Of vs.
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the
> use of Act-As and On-Behalf-Of seem to be reversed from how they are
> defined in WS-Trust
> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS
> FAQ <http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less
> confusing wording). They should probably be aligned with that prior work to
> avoid further confusion. Or maybe making a clean break and introducing new
> terms would be better.
>
> I don't think the security_token_request grant type value is strictly
> legal per RFC 6749. The ABNF at
> http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but
> according to http://tools.ietf.org/html/rfc6749#section-4.5 extension
> grants need an absolute URI as the grant type value (there's no grant type
> registry so the URI is the only means of preventing collision).
>
>
>
>
>
>
>
>
>
>
> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
>
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
>
> Thanks,
>
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
>
> ___
> 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

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Anthony Nadalin]

The explanation of on-behalf-Of and ActAs are correct in the document as 
defined by WS-Trust, this may not be your desire or understanding but that is 
how WS-Trust implementations should work

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 3, 2014 11:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth 
based token exchange mechanism. However, despite some distaste for the 
protocol, our existing WS-Trust functionality has proven to be "good enough" 
for most use-cases, which seems to prevent work on token exchange from getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html> (this MS 
FAQ<http://msdn.microsoft.com/en-us/library/ee748487.aspx> has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).






On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

[Brian Campbell]

FWIW, I am very interested in the general concept of a lightweight or OAuth
based token exchange mechanism. However, despite some distaste for the
protocol, our existing WS-Trust functionality has proven to be "good
enough" for most use-cases, which seems to prevent work on token exchange
from getting any real priority.

I have a few thoughts on
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
been meaning to write down but haven't yet, so this seems like as good a
time as any.

I would really like to see a simpler request model that doesn't require the
request to be JWT encoded.

The draft mentions the potential confusion around On-Behalf-Of vs.
Impersonation Semantics. And it is confusing (to me anyway). In fact, the
use of Act-As and On-Behalf-Of seem to be reversed from how they are
defined in WS-Trust
 (this MS FAQ
 has less confusing
wording). They should probably be aligned with that prior work to avoid
further confusion. Or maybe making a clean break and introducing new terms
would be better.

I don't think the security_token_request grant type value is strictly legal
per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10
would allow it but according to
http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an
absolute URI as the grant type value (there's no grant type registry so the
URI is the only means of preventing collision).










On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov  wrote:

> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
>
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
>
> Thanks,
>
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
>
> ___
> 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

[OAUTH-WG] draft-jones-oauth-token-exchange-00

[Vladimir Dzhuvinov]

Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
-- 
Vladimir Dzhuvinov 
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth