Hey Donald, I see your point. And yes, they are no really different.
However, I think this is pretty much about refreshing tokens. I understand that in this case the refresh token is not presented by its owner but someone downstream. But you are kind of refreshing a previously issued token. And maybe using a specific grant_type when refreshing can help to handle this case differently considering all its particularities. Regards. Pedro Igor ----- Original Message ----- > From: "Donald F. Coffin" <donald.cof...@reminetworks.com> > To: "Pedro Igor Silva" <psi...@redhat.com>, "Bill Mills" > <wmills_92...@yahoo.com> > Cc: "Phil Hunt" <phil.h...@oracle.com>, oauth@ietf.org > Sent: Thursday, March 26, 2015 6:29:41 PM > Subject: RE: [OAUTH-WG] Token Chaining Use Case > > 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
