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 <michael.jo...@microsoft.com> wrote: > I’ll start by saying that if you compare > https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, > 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 [mailto:jric...@mit.edu] > *Sent:* Tuesday, July 07, 2015 4:47 PM > *To:* Mike Jones > *Cc:* Brian Campbell; <oauth@ietf.org> > > *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 <michael.jo...@microsoft.com> > wrote: > > > > As just updated <http://self-issued.info/?p=1412>, I believe that the > working group token exchange draft > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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 [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *On > Behalf Of *Brian Campbell > *Sent:* Thursday, March 26, 2015 3:15 PM > *To:* Justin Richer > *Cc:* <oauth@ietf.org> > *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 > http://tools.ietf.org/html/draft-campbell-oauth-sts-02 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 <jric...@mit.edu> 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 > JWT > > > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
