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

Phil Hunt <phil.hunt@oracle.com> Wed, 01 July 2015 15:32 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210761A1A73 for <oauth@ietfa.amsl.com>; Wed, 1 Jul 2015 08:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3q4OZrgo6SK for <oauth@ietfa.amsl.com>; Wed, 1 Jul 2015 08:32:53 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C551A8F51 for <oauth@ietf.org>; Wed, 1 Jul 2015 08:32:51 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t61FWnXR021299 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jul 2015 15:32:49 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t61FWmei027199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jul 2015 15:32:48 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t61FWm87010489; Wed, 1 Jul 2015 15:32:48 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jul 2015 08:32:48 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-6247120C-E105-480F-8055-BF1393EA82CF
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com>
Date: Wed, 1 Jul 2015 08:32:43 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4BCD0A9A-A4A3-44D1-A607-9159DE471002@oracle.com>
References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <BY2PR03MB442205D40E8F1ECD88082F2F5AE0@BY2PR03MB442.namprd03.prod.outlook.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/SGie5YJU16juFCnAYdfQL_CkRt4>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 15:32:56 -0000

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 <bcampbell@pingidentity.com> 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 <sberyozkin@gmail.com> 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:oauth-bounces@ietf.org] *On Behalf Of *Vivek
>>>>>> Biswas
>>>>>> -T (vibiswas - XORIANT CORPORATION at Cisco)
>>>>>> *Sent:* Thursday, June 25, 2015 2:20 PM
>>>>>> *To:* OAuth@ietf.org
>>>>>> *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
>>>>>> 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
>> 
>> _______________________________________________
>> 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