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.coffin@reminetworks.com

-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@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_92105@yahoo.com>
> To: "Donald F. Coffin" <donald.coffin@reminetworks.com>, "Phil Hunt" 
> <phil.hunt@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.coffin@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.coffin@reminetworks.com
> From: Phil Hunt [mailto:phil.hunt@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_92105@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 < jricher@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_92105@yahoo.com >
> Date: 03/26/2015 2:24 PM (GMT-06:00)
> To: Justin Richer < jricher@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 < jricher@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
>