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

Brian Campbell <bcampbell@pingidentity.com> Mon, 06 July 2015 18:29 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 9197B1B2F02 for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 11:29:32 -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 lJnXD0zkiHec for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 11:29:26 -0700 (PDT)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (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 5417C1B2D35 for <oauth@ietf.org>; Mon, 6 Jul 2015 11:29:26 -0700 (PDT)
Received: by ieqy10 with SMTP id y10so119436490ieq.0 for <oauth@ietf.org>; Mon, 06 Jul 2015 11:29:25 -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=8g60lBBmGvhA+YhDT+invGebRmWpXiexJ4+ecAP+UJ0=; b=K8GQqOzVXPTnHGW/zl4YBFIWBTEbF/y59waSKNnp9qthgCFS7t/Im+CAPomnhzQ6WJ j+blItljDTlEreTyLUIcmto68lGLJRdSxAtVCjbODjQP0pxa1Wyxu5+XPu6Nnq4GaVlV iR98JPLfPab1KlaIBh7tGi0C7toXK6OXTQnDlICxQyc3VEVmQGH74MPQ2bOguTx7FytJ 11Af7VhiiHQVgdJptZxYtDWTDsEx7Lwj8sdmWsi0isoBGrbB4mAoJfBhHPpAGhVxRy1f UQMWyht/N+y7JFTeogGtoJyM+kevyqN9ZMH0/n5kJ1FgXIzBrrQbB1kj67kk8BQjS1oQ MVOQ==
X-Gm-Message-State: ALoCoQnywyy0HEjeJM8Z4R7VPE00D8DmNehhMZJ0VhA5pWeAuRrgUEhkzKz4GYw9k0lr3ZrNT9fm
X-Received: by 10.107.128.72 with SMTP id b69mr354832iod.84.1436207365500; Mon, 06 Jul 2015 11:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.64.209 with HTTP; Mon, 6 Jul 2015 11:28:56 -0700 (PDT)
In-Reply-To: <BY2PR03MB44276C3D04E3FE5AE238298F5930@BY2PR03MB442.namprd03.prod.outlook.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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 6 Jul 2015 12:28:56 -0600
Message-ID: <CA+k3eCTRK9ND5c2HbDU=3ctZ3J4u3HMA2QHNZfEpwtfcwiLxfQ@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a113f96d0d880fd051a391502
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/wyVlGSvibF754jurTYVKg812P0o>
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 18:29:32 -0000

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