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

Sergey Beryozkin <sberyozkin@gmail.com> Mon, 06 July 2015 11:33 UTC

Return-Path: <sberyozkin@gmail.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 A24571A010D for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 04:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rh17pQDs23zY for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 04:33:10 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 213771A014E for <oauth@ietf.org>; Mon, 6 Jul 2015 04:33:07 -0700 (PDT)
Received: by wifm2 with SMTP id m2so26787448wif.1 for <oauth@ietf.org>; Mon, 06 Jul 2015 04:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=raMlbkuDj1ceRahXzdLfE6pifM1Q4Py0riJO3Yf2/qw=; b=fwt9s5Hkv5Rssm2UZIAIl/+fwmyB81+5I25VbUNjsKebswLy8VKyxrsVqjKkq6trI8 3GLGpZb0eztt6PWx+RfzCsWC99+5rUdXXcjrbypSCGO43gi+qWwRJr52/bUcJnM8+4Tp 9z3ML66cxuCXv00jcVz8vaNm95xngttZZvTj+vjVnEDJEcRdAXwtDU1Vy7Lbrd0xWnFu MhyXZold0paUoiX+LDRArRyo4QgorzxYzwfFEKYgcO/JLC3e7vZtXFS96I/b1/Vs5hIB s+aSmswiawIAHJjd02652l8MuK9Ole3qRhP7ZdFt+YxU64cA4+pnwD/B/jiqJUfAr7OK odPA==
X-Received: by 10.180.108.142 with SMTP id hk14mr53625031wib.5.1436182385861; Mon, 06 Jul 2015 04:33:05 -0700 (PDT)
Received: from [192.168.2.7] ([89.100.27.122]) by mx.google.com with ESMTPSA id x10sm27637996wjr.25.2015.07.06.04.33.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 04:33:05 -0700 (PDT)
Message-ID: <559A676F.3070008@gmail.com>
Date: Mon, 06 Jul 2015 12:33:03 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Brian Campbell <bcampbell@pingidentity.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>
In-Reply-To: <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Gy3RK5Awl8ULH3mJ-gavpqeJPOk>
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 11:33:12 -0000

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
>
>