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

John Bradley <ve7jtb@ve7jtb.com> Mon, 06 July 2015 21:51 UTC

Return-Path: <ve7jtb@ve7jtb.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 1A4651A1A5F for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 14:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o9ksaJsih3Ie for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 14:51:42 -0700 (PDT)
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.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 3858D1A1A6A for <oauth@ietf.org>; Mon, 6 Jul 2015 14:51:41 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so127476417qkh.0 for <oauth@ietf.org>; Mon, 06 Jul 2015 14:51:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=gZ/UlyGzC5RYaQDhBJEFkMMsPMJU+J7KjrHjoaDllWQ=; b=SRVINN+e60yKgyGuvUyJHIRCjJ8C1oxbFcpUHWuUz23NkwfXBQajsSB55DIxwvsnl8 i8Wqn80RO/UqMn9X6J5cwf1RnKOjIK0pf47N1m94WhZ1vzRV/XIb7ukfpWNKYoKm4cHZ D8i4QmlCEa/Cu5kYsSnWitJQ4tvxQB4YEogMdEBZ+qzgFMDRTbi+NiCmOQcof03U88wB 3trgWMa5gusCfb6ey7Qy1pJnGtpdO8LYcgjJGi+z/+t3znRlNtBuUcAPoGCaZq7PpHnS wgRbATdYX6hQFI+X1/0JEuECrpi/P4Jg5Fwp6SR6ia59kf9LE3NRN3Jp0ACtlIq365/r 6mrw==
X-Gm-Message-State: ALoCoQlkcJrD2esaViG8IK8c3aHzznJJq43JMxqg+cmWzERfIQFtjao1NS3P61XNkL8boQnL/mPJ
X-Received: by 10.55.25.12 with SMTP id k12mr1646629qkh.81.1436219500343; Mon, 06 Jul 2015 14:51:40 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.207.194]) by mx.google.com with ESMTPSA id x79sm9987624qha.10.2015.07.06.14.51.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 14:51:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_66D549B1-5173-4D19-ADDC-407D01DE6C77"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BY2PR03MB442D6CB1EB8C2C503710279F5930@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Mon, 6 Jul 2015 18:51:32 -0300
Message-Id: <98C5F0C1-F5BF-4BC8-9C7E-98EEC44007AC@ve7jtb.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> <CA+k3eCTJsLqn88K4qEYJUzoxwAH4boWGsvJZtZi8guvV6C6zSA@mail.gmail.com> <DEAFAD4A-36F8-47D7-813D-35948CDCEA2C@ve7jtb.com> <BY2PR03MB44276C3D04E3FE5AE238298F5930@BY2PR03MB442.namprd03.prod.outlook.com> <CA+k3eCTRK9ND5c2HbDU=3ctZ3J4u3HMA2QHNZfEpwtfcwiLxfQ@mail.gmail.com> <BY2PR03MB442D6CB1EB8C2C503710279F5930@BY2PR03MB442.namprd03.prod.outlook.com>
To: Michael Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/4i0F6sbNH-J_reWZLuB195DHAxY>
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 21:51:48 -0000

Sorry Mike,

I was looking at an earlier version that had them reversed.   I think the wording can be improved but the composite vs delegation semantic is correct now.

However Tony now seems to disagree with that.   I am going to walk away slowly and let you sort out his last post:)

We can discuss further in Prague.

John B.

> On Jul 6, 2015, at 3:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
> Fair enough, Brian.  For clarity, my sense of the action items is that I agreed to do those actions based on feedback at the ad-hoc meeting and then people would review the result – not that everything would be “done” after taking those actions.  I’ll still plan to act on that feedback.
>  
> I’d be glad to sit down with you and others in Prague, Brian, to work out how to make sure your use cases are covered and the draft is as clear as it can be, given its somewhat esoteric subject matter.  Now that JWT and JOSE and the OAuth Assertions specs are done and several others are nearly done, getting back to this is a priority for me.
>  
>                                                             Cheers,
>                                                             -- Mike
>  
> From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
> Sent: Monday, July 06, 2015 11:29 AM
> To: Mike Jones
> Cc: John Bradley; oauth
> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
>  
> Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer).
> 
> The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3> which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link <https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity).  In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3> and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 <https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2> in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. 
> 
> I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive <https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> at the time but little has happened since then.
> 
> Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way.
>  
> 
> 
> 
> 
>  
> 
>  
> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
> It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4.  I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/
> 
> FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are:
>   - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values.
>   - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate.
> 
> I plan to do the first today.  The second is probably more than I'll get done today before the submission cutoff.  I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration.  I'll plan to come into the Prague meeting with a concrete proposal for review.
> 
>                                 Best wishes,
>                                 -- Mike
> 
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] On Behalf Of John Bradley
> Sent: Monday, July 06, 2015 8:13 AM
> To: Brian Campbell
> Cc: oauth
> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
> 
> Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft.
> 
> His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint.
> 
> I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4.
> see https://msdn.microsoft.com/en-us/library/ee748487.aspx <https://msdn.microsoft.com/en-us/library/ee748487.aspx> for the short explanation.
> 
> I think Brian is closer in explaining it.
> 
> In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations.
> I think many times it is how WIF implemented it that people copied.
> 
> It may be better to have new terms that are clear such as impersonation and composite.
> 
> The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics.   There are plusses and minuses to both options.
> 
> Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability.
> 
> There are also issues around how this would work with proof of possession security tokens, both as input and output.
> 
> Perhaps we can make some progress on this in Prague.
> 
> John B.
> 
> 
> 
> 
> > On Jul 6, 2015, at 11:04 AM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
> >
> > 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 <mailto: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 <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>
> > <mailto:sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>>> wrote:
> >
> >     Hi Justin
> >
> >     https://tools.ietf.org/html/draft-richer-oauth-chain-00 <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 <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 <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>
> >                     <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> <mailto: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 <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/ <http://www.cisco.com/>>*
> >
> >                     *Bldg. J, San Jose, USA,*
> >
> >                     *Phone: +1 408 527 9176 <tel:%2B1%20408%20527%209176>
> > <tel:%2B1%20408%20527%209176 <tel:%2B1%20408%20527%209176>>*
> >
> >
> >
> >                     _______________________________________________
> >                     OAuth mailing list
> >                     OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >                     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >
> >             _______________________________________________
> >             OAuth mailing list
> >             OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >             https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >         _______________________________________________
> >         OAuth mailing list
> >         OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >         https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >     _______________________________________________
> >     OAuth mailing list
> >     OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
> >     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>