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

Brian Campbell <bcampbell@pingidentity.com> Mon, 06 July 2015 14:05 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 5502B1A87BC for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 07:05:10 -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 ChbybcujdtnH for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 07:05:07 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (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 0A3801A87DB for <oauth@ietf.org>; Mon, 6 Jul 2015 07:05:02 -0700 (PDT)
Received: by iecuq6 with SMTP id uq6so113756581iec.2 for <oauth@ietf.org>; Mon, 06 Jul 2015 07:05:01 -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=7LMxN08RmTq72NzCwMBVS/1bhTo+1iwp0vimr4wBIpw=; b=ioSCMHCALIyz6HT5U9jIhIfyhZzjbEvUxy6g8zTQ4quQz8ZxtsVeN1avTvIATZMmEG xB6T+jyj0/kur5skKX7QNZgGR3b/1ggpZNdcGDrqP5gY+XYjpTdoU+vbHq6QYK2DfZAX amOUoFVj1X4lfnVS6Zvqa2eenQiwIPZmNZ2NFkLnEMG4c7O7ZVDySA+WCvL1PkejeTvp wVGxDpmMd4gZGu6NJCfZtQMJEskBG+YhcLhYn/lQNNU3/qGv74d5mf3oQjni838d0Znp z7OOGMpWs4WHX3sQYCGgWaDwEg0DrnI4gEKF4fRmgyMAa/AWYJErJ/W0+4J7EO135xmg b6SQ==
X-Gm-Message-State: ALoCoQkIya8OJKUZZ/dr6zRptbw3hKTuAlXcS/nFOrbaWf4uSm+e1Ckim2R7PAzAS6uuR3i+uBVq
X-Received: by 10.43.19.131 with SMTP id qk3mr36131953icb.15.1436191501339; Mon, 06 Jul 2015 07:05:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 07:04:31 -0700 (PDT)
In-Reply-To: <559A676F.3070008@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> <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com> <559A676F.3070008@gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 6 Jul 2015 08:04:31 -0600
Message-ID: <CA+k3eCTJsLqn88K4qEYJUzoxwAH4boWGsvJZtZi8guvV6C6zSA@mail.gmail.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec517cddc447279051a356423
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/HCSORrPkg3E4qNKUw2l5GYwWXxY>
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: Mon, 06 Jul 2015 14:05:10 -0000

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 <sberyozkin@gmail.com>
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
>
> 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 <sberyozkin@gmail.com
>> <mailto: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
>>                     <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 <mailto: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
>> <tel:%2B1%20408%20527%209176>*
>>
>>
>>
>>                     _______________________________________________
>>                     OAuth mailing list
>>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>