Pedro, Although the registry could be changed to support the new type format, how is that any different than adding a new grant_type, such as grant_type=token_swap or grant_type=swap?
Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com -----Original Message----- From: Pedro Igor Silva [mailto:psi...@redhat.com] Sent: Thursday, March 26, 2015 5:25 PM To: Bill Mills Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case Couldn't be used a specific type of refresh_token ? Instead of using grant_type=refresh_token use a grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as an extension to refresh token flow ? Regards. Pedro Igor ----- Original Message ----- > From: "Bill Mills" <wmills_92...@yahoo.com> > To: "Donald F. Coffin" <donald.cof...@reminetworks.com>, "Phil Hunt" > <phil.h...@oracle.com> > Cc: oauth@ietf.org > Sent: Thursday, March 26, 2015 6:13:05 PM > Subject: Re: [OAUTH-WG] Token Chaining Use Case > > The RS calling back to the AS won't be confused, the token it gets > would be it's refresh token. I don't see any reason why the AS can't > be smart enough to know that a token that looks like an access token > it issued is usable as a refresh token for limited purposes or downscoping. > > > > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin > <donald.cof...@reminetworks.com> wrote: > > > -1 > Although Justin’s point might be a bit pre-mature as far as a > standards discussion, the more critical reason IMHO is calling the > AS’s /Token endpoint with a grant_type of “refresh_token” but > providing an issued AT rather than an issued refresh_token (RT) will > definitely create a backwards compatibility issue for many implementations. > Best regards, > Don > Donald F. Coffin > Founder/CTO > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > Phone: (949) 636-8571 > Email: donald.cof...@reminetworks.com > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Thursday, March 26, 2015 4:22 PM > To: Bill Mills > Cc: <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Token Chaining Use Case > +1. We all have to change production code when non final specs evolve. > I particularly don't see this as a valid argument at the start of a > standards discussion. > > Phil > > On Mar 26, 2015, at 15:13, Bill Mills < wmills_92...@yahoo.com > wrote: > > > > By definition an access token is becoming a form of refresh token. The > "because my implementation didn't do it that way" isn't convincing me. > On Thursday, March 26, 2015 12:44 PM, Justin Richer < jric...@mit.edu > > > wrote: > Because many implementations (including mine which does support my old > token chaining draft) treat access tokens and refresh tokens > separately in terms of data store and structure. Additionally, the > refresh token is tied to the client and presented by the client. But > in this case it's someone downstream, an RS, presenting the token. So > unlike a refresh token being presented by the one it was issued to, > this token is being presented by someone it was presented to. > The feeling is close, but not quite the same in either development or > assumptions. > -- Justin > / Sent from my phone / > > > -------- Original message -------- > From: Bill Mills < wmills_92...@yahoo.com > > Date: 03/26/2015 2:24 PM (GMT-06:00) > To: Justin Richer < jric...@mit.edu >, "< oauth@ietf.org >" < > oauth@ietf.org > > > Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the > access tokne simply be re-used as a refresh token? Why would it need a > new grant type at all? > On Thursday, March 26, 2015 11:31 AM, 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 > > > > _______________________________________________ > 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
