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

Brian Campbell <bcampbell@pingidentity.com> Wed, 01 July 2015 15:02 UTC

Return-Path: <bcampbell@pingidentity.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 2BA971A8F4D for <oauth@ietfa.amsl.com>; Wed, 1 Jul 2015 08:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 R5LfZekmICU2 for <oauth@ietfa.amsl.com>; Wed, 1 Jul 2015 08:02:11 -0700 (PDT)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895851A9066 for <oauth@ietf.org>; Wed, 1 Jul 2015 07:59:55 -0700 (PDT)
Received: by igcur8 with SMTP id ur8so93577987igc.0 for <oauth@ietf.org>; Wed, 01 Jul 2015 07:59:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YVhjMg0LZjKO3rhsklUzibc0mAJVfCJ/jX+STLerB8Y=; b=ISBa/ThuSyg94AiDjLoaw5NNhBIAFnIDzI1Vk2oXX37YxlqHXR6C2JzOIz/1Lnlw/1 nZ+5kBXCj8LQVonVAnUZ3dH2UeXJJp86UwNKinaN9s/+Ar6iQr3/YN77k9IfBqme6zTx Jy3L+Ei6xDjtqd5ckFS5iW0rYZ9lil/fUQ6K4PnyEAa+oD7NOnB0nj9glsKFIeoUnbse VXnsdJlRtaaqOAt1M/BMAGzCeuP6EvkzncMe+V2Yd+oyG//A8PHPThXxOR5b+EwAN37I OZITan9vF9aoPa48P7N+K5TtR8we7LW6u6sTW7m5Oh19cdCUcb0q6PY4a8j7he+Ys63q vjmA==
X-Gm-Message-State: ALoCoQlNQ/A4+0ifYF0XT1HtYEFNgSq2y50ItQm6YSGcSAQYtjdiHoGl2XXTZONsQmcFEBjx2Unn
X-Received: by 10.107.35.203 with SMTP id j194mr38651250ioj.45.1435762794852; Wed, 01 Jul 2015 07:59:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 07:59:25 -0700 (PDT)
In-Reply-To: <5593E5FD.3050403@gmail.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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 1 Jul 2015 08:59:25 -0600
Message-ID: <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Content-Type: multipart/alternative; boundary=001a114044405eb3a90519d193db
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/HsfbHoMuZtchLDRz0nu80ClIH2I>
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:02:15 -0000

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
>