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

[Phil Hunt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> 
>> 
>>> On 01/07/15 13:18, Justin Richer wrote:
>>> 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"
>>>> 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:[e-mail]] *On Behalf Of *Vivek
>>>>>> Biswas
>>>>>> -T (vibiswas - XORIANT CORPORATION at Cisco)
>>>>>> *Sent:* Thursday, June 25, 2015 2:20 PM
>>>>>> *To:* [e-mail]
>>>>>> *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: [phone]*
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth