Re: [OAUTH-WG] Token Chaining Use Case

Brian Campbell <> Wed, 08 July 2015 19:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C768F1A1EF7 for <>; Wed, 8 Jul 2015 12:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qV_JRMmD3o8h for <>; Wed, 8 Jul 2015 12:33:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C4471A1EFC for <>; Wed, 8 Jul 2015 12:33:40 -0700 (PDT)
Received: by iebmu5 with SMTP id mu5so162264391ieb.1 for <>; Wed, 08 Jul 2015 12:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jLLr8H513aIGlpXanFsh2q3Y0+1FGj2138jY9glSTGk=; b=UMXLYJyuLtcxbPqoNwsjQN3YKahCbGG5vm9SfsNURcRf7XHJC0xv0kPGiM7/snt5jn z8uxQirrvhPgrFs/6F0rlkS3UNRUenGqPnjozprR8pIEyBg5w4s15aqTMQyFfjoFQy2f xs46xwuaQ+qXxn2+/4YJ3mcGe6yomGbRjTXfk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jLLr8H513aIGlpXanFsh2q3Y0+1FGj2138jY9glSTGk=; b=VzzTECA1HjuJQSZ7V9bpCV2wyFjcsGSBjkRvtLVG5KLee0vlS+jkHVa/CH66PT+yXT 0V9w2aKr44o3wJRUQJf+4BWOam4exiBq+OpJpC2drBBxGT2dwLG4TW9xind14Oh11dw0 YBVwqUh1nSEIRsZMm5vK7bqN296n9doKw1R2J5AqB1I3rE6JQ6RP8kRVU/jAmqyd2ioT rp0o4ltA9pjTFS2TpwV5oev2gZcsvLaflKMP9wZQxU9JoOtugPZhh9HNKdlIkXVFhIgV MmpxwL6keNs1a1jubMVmkfnSmUx9b6BfjGeZ9L34mtZawLAsEbmK50iD4LWSdpt7n3QR dWOA==
X-Gm-Message-State: ALoCoQn64wdzvZyy3jO1/uUxsxQR28cqPeL2142KzvoNLemuVLRMKed26rmhuWXFoe0x3R2JtWND
X-Received: by with SMTP id w129mr5828368iod.52.1436384019149; Wed, 08 Jul 2015 12:33:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Jul 2015 12:33:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Brian Campbell <>
Date: Wed, 8 Jul 2015 13:33:09 -0600
Message-ID: <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary=001a113ffdbc39151a051a623773
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2015 19:33:45 -0000

There is a lot in common, yes. Fundamentally we're working to address the
same needs, which should lead to some commonality. But I was also trying to
be conciliatory in the work I did and make a good faith effort at
establishing some commonality from which collaborative work could move
forward. In retrospect I should probably have just outright opposed the
adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying
to work with you would be more effective than working against you. At the
time you seemed amenable to that and even proposed co-editing with. Hannes
followed that indicating support for adding other co-authors (he didn't say
it but kind of implied perhaps Justin and/or Phil based on prior related
work). Since that time, however, there's been little willingness to
consider changes to the draft (other than very trivial items). And Tony was
added as a co-author, which to me (and I suspect many others) signals a
complete lack of willingness to actually collaborate towards a solution
that's acceptable to more than one contingent.

There are differences in the drafts too. I won't list them all here but did
want to call out that, contrary to what you said, the request in my draft
is made up of regular old HTTP form-urlencoded POST parameters. Which is a
simplification and efficiently improvement that seems to be preferred.

On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones <>

>  I’ll start by saying that if you compare
> and
> unsurprisingly, you’ll find a lot in common.  Both have requests and
> responses formatted using JSON objects, both have input and output tokens,
> both have security token type parameters describing their corresponding
> inputs and outputs.  Both can convey act_as and on_behalf_of tokens.  And
> despite what was written below, both define a new grant_type value that is
> used to make this new kind of request at the Token Endpoint.
> The primary thing that Brian’s draft is missing semantically is the
> ability for the requester to sign the set of input parameters.  This is
> critical to establishing proper trust to enable the exchange to occur in
> many use cases.  That’s why the WG draft uses a JWT as the request – so a
> signature can be applied to the request, when appropriate.  (And when it’s
> not needed, “alg”: “none” can be used.)
> Justin, you’re right that the current WG draft doesn’t have a separate
> “input token” request parameter.  In the current draft, the (optionally)
> signed request **is** the input token.  Thinking some more about the
> token chaining use case you’re interested in, I see why you want to have
> that token to be a separate element in the request.  I believe the best way
> to accomplish that is to add an optional claim to the request that would
> contain that token.  (I think the closest equivalent in Brian’s draft is
> the possibility of using an access token or assertion as the client
> authentication mechanism, possibly passing it as defined in RFC 6750,
> although the draft doesn’t say that.)  Passing the input token as a claim
> lets it be part of the signed request.
> It’s completely up to us when using a different grant_type to define what
> the input and output parameters when using that grant_type are.  (RFC 6749
> already has different sets, depending upon the grant_type used.)  I
> personally find it cleaner to return the output security token that may not
> be an access token in a “security_token” parameter rather than repurposing
> the “access_token” parameter to hold something that’s not an access token,
> but now we’re more discussing syntax than semantics.  Still, if something
> is different, it’s probably less error prone to use a different syntax for
> it.
> I’m sympathetic to your comment about Nat’s signed requests draft, except
> that the requests that draft specifies are requests to the interactive
> Authorization Endpoint, whereas the requests we’re dealing with here are
> requests to the non-interactive Token Endpoint.  Still, thinking of the
> Token Exchange requests as signed requests to the Token Endpoint, just like
> Nat’s draft makes signed requests to the Authorization Endpoint, is
> probably a good unifying mental framework for all of us to consider
> applying to this problem space.
>                                                                 Best
> wishes,
>                                                                 -- Mike
> *From:* Justin Richer []
> *Sent:* Tuesday, July 07, 2015 4:47 PM
> *To:* Mike Jones
> *Cc:* Brian Campbell; <>
> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
> This approach is not a good fit for my use cases, and it’s still not
>  OAuth-y at all. It requires a specially-formed security assertion on the
> way in, which the client must understand and generate. I still can’t take
> an arbitrary token I’ve been handed by someone else and pass it off to be
> pushed forward. The new “*_type” parameters seem to merely kick the can
> down the road instead of addressing the problems with the current
> specification.
> I think that Brian’s approach works much better. It unrolls important
> parameters, properly uses the token endpoint, and allows for arbitrarily
> formatted input tokens.
> When combined with Nat’s draft that specifies how to perform all generic
> OAuth requests as JWTs (or even some of the upcoming PoP work if we ever do
> that), you’ve pretty much got the draft below but with much more
> flexibility and power.
>  — Justin
>  On Jul 7, 2015, at 6:51 PM, Mike Jones <>
> wrote:
> As just updated <>, I believe that the
> working group token exchange draft
> can now
> also serve the “OAuthy” token exchange use cases, such as Justin and Phil’s
> token chaining use case, as well as support general token exchange,
> including exchange of JWT and SAML tokens.  The mechanism would be the same
> one that Brian suggested below – defining security token type values for
> OAuth 2.0 access tokens and refresh tokens – enabling them to be used as
> inputs and outputs in any of the token exchanges.
> For instance, by using “access token” as the input security token type,
> providing new scope values, and using “access token” as the output security
> token type, token chaining is achieved.
> Now, a question for the working group…  What should the security token
> type values for access token and refresh token be?  Two different choices
> seem to make sense.
> (1)  Use the values “access_token” and “refresh_token”, which are used in
> RFC 6749 token response values.
> (2)  Define new URNs for this usage, such as
> urn:ietf:params:oauth:token-type:access-token and
> urn:ietf:params:oauth:token-type:refresh-token.
> I’d personally be fine just using the short names in (1).
> If people agree with this approach, we can document this usage in the -03
> draft and publish it as soon as the submission tool reopens Monday morning
> during IETF 93.
>                                                                 -- Mike
> *From:* OAuth [ <>] *On
> Behalf Of *Brian Campbell
> *Sent:* Thursday, March 26, 2015 3:15 PM
> *To:* Justin Richer
> *Cc:* <>
> *Subject:* Re: [OAUTH-WG] Token Chaining Use Case
> This kind of token exchange might involve exchanges other than swapping an
> AT for another AT (and downscoping it). It might be an AT for a structured
> JWT specifically targeted at one of the the particular services that the
> original RS needs to call. Or an AT might be exchanged for a SAML assertion
> to use with legacy SOAP serveries.  A good general token exchange mechanism
> enables lots of variations of cases like the one Justin mentioned. And
> more. In fact, I think downscoping might be a minority use case where what
> token exchange is often need for is translating tokens from what you have
> into what the resource you need to call can deal with.
> There need to be ways for the caller to tell the AS about the token it's
> asking for - by type or by the address/identifier of where it'll be used.
> There needs to be ways for the caller to authenticate to the AS. And there
> needs to be some way of expressing this delegation thing (though I'm still
> not totally convinced it couldn't be just the token is about the
> user/principal and the caller/client of the exchange is who is being
> delegated to).
> I realize few (approaching zero) people have or are going to read it but I
> have endeavored to cover all these things in the
> draft. It's an
> early draft so not without it some rough edges but can provide some
> guidance on what is needed and offers some protocol syntax for expressing
> it. I believe Justin's use case would be covered by it (defining a specific
> token type URI for an OAuth access token issued by the AS in question might
> be needed) as are many others.
> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer <> wrote:
> As requested after last night’s informal meeting, here is the token
> chaining use case that I want to see represented in the token swap draft.
> [ Client ]  ->   [ A ] -> [ B ] -> [ C ]
> An OAuth client gets an access token AT1, just like it always would, with
> scopes [A, B, C] in order to call service A, which requires all three
> scopes. Service A (an RS) accepts this token since it has its scope, and
> then needs to call service B in turn, which requires scopes [B, C]. It
> could just re-send the token it got in, AT1, but that would give the
> downstream RS the ability to call services with scope [ A ] and it should
> not be allowed to do that. To limit exposure, service A calls a token swap
> at the AS to create AT2 with scopes [ B, C ], effectively acting as an
> OAuth client requesting a downscoped token based on AT1. Service A then
> acts as an OAuth client to call service B, now acting as an RS to service
> A’s client, and can fulfill the request. And it’s turtles all the way down:
> Service B can also call service C, and now B acts as a client, requesting
> AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This
> prevents C from being able to call B or A, both of which would have been
> available if AT1 had been passed around. Note that service A or the Client
> can also request a downscoped token with [ C ] to call service C directly
> as well, and C doesn’t have to care how it got there.
> In other words, it lets the client software be very, very dumb. It doesn’t
> have to do any special processing, doesn’t have to know what’s in the
> token, it just follows the recipe of “I got a token, I get another token
> based on this to call someone else”. It’s also analogous to the refresh
> token flow, but with access tokens going in and out. I’ve deployed this
> setup several times in different service deployments. Even though there is
> a performance hit in the additional round trips (as Phil brought up in
> another thread), in these cases the desire to have the tokens hold least
> privilege access rights (smallest set of scopes per service) outweighed any
> performance hit (which was shown to be rather small in practice).
> What I want is for the token swap draft to define or use a mechanism that
> allows us to do this. I think we can do that pretty easily by adjusting the
> token swap syntax and language, and explicitly calling out the semantic
> processing portion (the current core of the document) for what it is: a way
> for a token issuer to communicate to a token service specific actions. At a
> high level, the spec would be something like:
> 1. How to swap a token at an AS
>   1. Send a request to the token endpoint with a new grant type, and a
> token (of any type/format/flavor) on the way in
>   2. Get back a new token in a token response
> 2. Communicating act as / on behalf of semantics via a JWT assertion
>   1. How to create (as an AS/RS/client/other issuer) a JWT with act-as
> semantics
>   2. What to do (as an AS/RS) with a JWT with act-as semantics
>   3. How to create a JWT with on-behalf-of semeantics
>   4. What to do with a JWT with on-behalf-of-semantics
>   5. How to possibly represent these semantics with something other than a
> Section 2 uses the syntax from section 1. Other applications, like the one
> I laid out above, can use the syntax from section 1 as well. This works for
> structured, unstructured, self-generated, cross-domain, within-domain, and
> other tokens.
>  — Justin
> _______________________________________________
> OAuth mailing list