[OAUTH-WG] Publication has been requested for draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hannes Tschofenig has requested publication of draft-ietf-oauth-spop-10 as 
Proposed Standard on behalf of the OAUTH working group.

Please verify the document's state at 
http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

AS already has the problem of checking requested scopes, this doesn't change 
that.
In fact an AS could issue a new "refresh token" in return for the presented one 
(which is the user/app AT) that's limited to be used by the RS as a client.
If one of the things we want is the ability to have the AS return N access 
tokens, one for each scope allowing the RS to make a single round trip request 
to the AS for all of the more limited scope tokens, then a new grant type is in 
fact needed.

 


 On Thursday, March 26, 2015 3:33 PM, Donald F. Coffin 
 wrote:
   

 #yiv7149031579 #yiv7149031579 -- _filtered #yiv7149031579 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv7149031579 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7149031579 
{font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv7149031579 
{panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv7149031579 #yiv7149031579 
p.yiv7149031579MsoNormal, #yiv7149031579 li.yiv7149031579MsoNormal, 
#yiv7149031579 div.yiv7149031579MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 a:link, 
#yiv7149031579 span.yiv7149031579MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv7149031579 a:visited, #yiv7149031579 
span.yiv7149031579MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv7149031579 
p.yiv7149031579msonormal, #yiv7149031579 li.yiv7149031579msonormal, 
#yiv7149031579 div.yiv7149031579msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
p.yiv7149031579msolistparagraph, #yiv7149031579 
li.yiv7149031579msolistparagraph, #yiv7149031579 
div.yiv7149031579msolistparagraph 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
p.yiv7149031579msochpdefault, #yiv7149031579 li.yiv7149031579msochpdefault, 
#yiv7149031579 div.yiv7149031579msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
p.yiv7149031579msonormal1, #yiv7149031579 li.yiv7149031579msonormal1, 
#yiv7149031579 div.yiv7149031579msonormal1 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
p.yiv7149031579msochpdefault1, #yiv7149031579 li.yiv7149031579msochpdefault1, 
#yiv7149031579 div.yiv7149031579msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
span.yiv7149031579msohyperlink {}#yiv7149031579 
span.yiv7149031579msohyperlinkfollowed {}#yiv7149031579 
span.yiv7149031579msohyperlink1 {}#yiv7149031579 
span.yiv7149031579msohyperlinkfollowed1 {}#yiv7149031579 
span.yiv7149031579emailstyle171 {}#yiv7149031579 span.yiv7149031579emailstyle27 
{}#yiv7149031579 p.yiv7149031579msonormal2, #yiv7149031579 
li.yiv7149031579msonormal2, #yiv7149031579 div.yiv7149031579msonormal2 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 
span.yiv7149031579msohyperlink2 
{color:blue;text-decoration:underline;}#yiv7149031579 
span.yiv7149031579msohyperlinkfollowed2 
{color:purple;text-decoration:underline;}#yiv7149031579 
p.yiv7149031579msolistparagraph1, #yiv7149031579 
li.yiv7149031579msolistparagraph1, #yiv7149031579 
div.yiv7149031579msolistparagraph1 
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579
 p.yiv7149031579msochpdefault2, #yiv7149031579 li.yiv7149031579msochpdefault2, 
#yiv7149031579 div.yiv7149031579msochpdefault2 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv7149031579 
p.yiv7149031579msonormal11, #yiv7149031579 li.yiv7149031579msonormal11, 
#yiv7149031579 div.yiv7149031579msonormal11 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7149031579 
span.yiv7149031579msohyperlink11 
{color:blue;text-decoration:underline;}#yiv7149031579 
span.yiv7149031579msohyperlinkfollowed11 
{color:purple;text-decoration:underline;}#yiv7149031579 
span.yiv7149031579emailstyle1711 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv7149031579 p.yiv7149031579msochpdefault11, #yiv7149031579 
li.yiv7149031579msochpdefault11, #yiv7149031579 
div.yiv7149031579msochpdefault11 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv7149031579 
span.yiv7149031579emailstyle271 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv7149031579 span.yiv7149031579EmailStyle39 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv7149031579 .yiv7149031579MsoChpDefault {font-size:10.0pt;} _filtered 
#yiv7149031579 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7149031579 
div.yiv7149031579WordSection1 {}#yiv7149031579 Bill,  Thanks for the 
clarification.  How do you propose the AS deal with the following RFC6749 
Section 6. Refreshing an Access Token requirement?  ScopeOPTIONAL.  The scope 
of the access request as described by Section 3.3.  The requested scope MUST 
NOT include any scope not originally granted by the resource owner, and if 
omitted is treated as equal to the scope or

Re: [OAUTH-WG] Token Chaining Use Case

[Donald F. Coffin]

Bill,

 

Thanks for the clarification.

 

How do you propose the AS deal with the following RFC6749 Section 6. Refreshing 
an Access Token requirement?

 

Scope

OPTIONAL.  The scope of the access request as described by Section 3.3.  The 
requested scope MUST NOT include any scope not originally granted by the 
resource owner, and if omitted is treated as equal to the scope originally 
granted by the resource owner.

 

The authorization server MAY issue a new refresh token, in which case the 
client MUST discard the old refresh token and replace it with the new refresh 
token.  The authorization server MAY revoke the old refresh token after issuing 
a new refresh token to the client.  If a new refresh token is issued, the 
refresh scope MUST be identical to that of the refresh token included by the 
client in the request.

 

Since the RS is attempting to obtain a new AT, what happens to the old AT that 
was submitted as a refresh_token, should the AS issue a new refresh_token, 
which it is allowed to do as stated above?  Since this was really an AT, 
doesn’t this mean the RS and issuing AS will be required to REVOKE the AT?  If 
the AS is not the AS that issued the original AT and there is no scope= value 
in the request, how does it ensure the request isn’t asking for more access 
than was granted by the granting AS?

 

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: Bill Mills [mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 6:04 PM
To: Bill Mills; Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case

 

 

Again, I don't think requiring a call out to an internal token reissuer is a 
general solution.  That said...

 

The RS calls the token endpoint treating the AT as a refresh token in all cases 
and using the refresh_token grant type.  Desired scope is specified by the RS.  
It's not in spec if there are derivative internal scopes not in the original 
scope list though.  This doesn't support internal scopes for partitioning that 
the AS doesn't know about.

 

An internal AS providing chaining would need to understand the AT just as the 
RS does, and treat it as a refresh token.

 

-bill

 

On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin 
mailto:donald.cof...@reminetworks.com> > wrote:

 

Bill,

 

Can you clarify your thoughts on the following:

 

* What AS endpoint does the RS call and how does it present the AT he 
received?

* What is the grant_type value the RS use in the above endpoint request?

* What does the AS do if the AT was issued by another AS (which is 
possible using Justin’s use case)?

 

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: Bill Mills [mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org  
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 
mailto: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: mailto: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 mailto: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 mailto:jric...@mit.edu> > wr

Re: [OAUTH-WG] Token Chaining Use Case

[Brian Campbell]

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  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

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

Again, I don't think requiring a call out to an internal token reissuer is a 
general solution.  That said...
The RS calls the token endpoint treating the AT as a refresh token in all cases 
and using the refresh_token grant type.  Desired scope is specified by the RS.  
It's not in spec if there are derivative internal scopes not in the original 
scope list though.  This doesn't support internal scopes for partitioning that 
the AS doesn't know about. 
An internal AS providing chaining would need to understand the AT just as the 
RS does, and treat it as a refresh token.
-bill
 On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin 
 wrote:
   

 #yiv8232628268 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 
4;}#yiv8232628268 filtered {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 
0;}#yiv8232628268 filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268 
filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8232628268 
filtered {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268 
filtered {panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv8232628268 
p.yiv8232628268MsoNormal, #yiv8232628268 li.yiv8232628268MsoNormal, 
#yiv8232628268 div.yiv8232628268MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 a:link, 
#yiv8232628268 span.yiv8232628268MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8232628268 a:visited, #yiv8232628268 
span.yiv8232628268MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8232628268 
p.yiv8232628268MsoListParagraph, #yiv8232628268 
li.yiv8232628268MsoListParagraph, #yiv8232628268 
div.yiv8232628268MsoListParagraph 
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268
 p.yiv8232628268msonormal, #yiv8232628268 li.yiv8232628268msonormal, 
#yiv8232628268 div.yiv8232628268msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268 
p.yiv8232628268msochpdefault, #yiv8232628268 li.yiv8232628268msochpdefault, 
#yiv8232628268 div.yiv8232628268msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268 
span.yiv8232628268msohyperlink {}#yiv8232628268 
span.yiv8232628268msohyperlinkfollowed {}#yiv8232628268 
span.yiv8232628268emailstyle17 {}#yiv8232628268 p.yiv8232628268msonormal1, 
#yiv8232628268 li.yiv8232628268msonormal1, #yiv8232628268 
div.yiv8232628268msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 
span.yiv8232628268msohyperlink1 
{color:blue;text-decoration:underline;}#yiv8232628268 
span.yiv8232628268msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv8232628268 
span.yiv8232628268emailstyle171 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv8232628268 p.yiv8232628268msochpdefault1, #yiv8232628268 
li.yiv8232628268msochpdefault1, #yiv8232628268 div.yiv8232628268msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv8232628268 
span.yiv8232628268EmailStyle27 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv8232628268 .yiv8232628268MsoChpDefault 
{font-size:10.0pt;}#yiv8232628268 filtered {margin:1.0in 1.0in 1.0in 
1.0in;}#yiv8232628268 div.yiv8232628268WordSection1 {}#yiv8232628268 filtered 
{}#yiv8232628268 filtered {font-family:Symbol;}#yiv8232628268 filtered 
{}#yiv8232628268 filtered {font-family:Wingdings;}#yiv8232628268 filtered 
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered 
{font-family:Wingdings;}#yiv8232628268 filtered 
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered 
{font-family:Wingdings;}#yiv8232628268 ol {margin-bottom:0in;}#yiv8232628268 ul 
{margin-bottom:0in;}#yiv8232628268 Bill,  Can you clarify your thoughts on the 
following:  · What AS endpoint does the RS call and how does it present 
the AT he received?

· What is the grant_type value the RS use in the above endpoint request?

· What does the AS do if the AT was issued by another AS (which is 
possible using Justin’s use case)?  Best regards,DonDonald F. CoffinFounder/CTO 
 REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221  Phone: 
 (949) 636-8571Email:   donald.cof...@reminetworks.com  From: Bill Mills 
[mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
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  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 gran

Re: [OAUTH-WG] Token Chaining Use Case

[Pedro Igor Silva]

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" 
> To: "Pedro Igor Silva" , "Bill Mills" 
> 
> Cc: "Phil Hunt" , 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" 
> > To: "Donald F. Coffin" , "Phil Hunt"
> > 
> > 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
> >  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: 
> > 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 

Re: [OAUTH-WG] Token Chaining Use Case

[Donald F. Coffin]

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" 
> To: "Donald F. Coffin" , "Phil Hunt" 
> 
> 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 
>  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: 
> 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 
> h

Re: [OAUTH-WG] Token Chaining Use Case

[Pedro Igor Silva]

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" 
> To: "Donald F. Coffin" , "Phil Hunt" 
> 
> 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
>  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: 
> 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 perform

Re: [OAUTH-WG] Token Chaining Use Case

[Donald F. Coffin]

Bill,

 

Can you clarify your thoughts on the following:

 

* What AS endpoint does the RS call and how does it present the AT he 
received?



* What is the grant_type value the RS use in the above endpoint request?



* What does the AS do if the AT was issued by another AS (which is 
possible using Justin’s use case)?

 

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: Bill Mills [mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
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 
mailto: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: mailto: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 mailto: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 mailto: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 mailto:wmills_92...@yahoo.com> > 
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer mailto:jric...@mit.edu> >, "mailto:oauth@ietf.org> >" mailto: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 mailto: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 word

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

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 
 wrote:
   

 #yiv0625374937 #yiv0625374937 -- _filtered #yiv0625374937 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0625374937 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0625374937 
{font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 
{panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv0625374937 #yiv0625374937 
p.yiv0625374937MsoNormal, #yiv0625374937 li.yiv0625374937MsoNormal, 
#yiv0625374937 div.yiv0625374937MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0625374937 a:link, 
#yiv0625374937 span.yiv0625374937MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0625374937 a:visited, #yiv0625374937 
span.yiv0625374937MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0625374937 
span.yiv0625374937EmailStyle17 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv0625374937 .yiv0625374937MsoChpDefault {font-size:10.0pt;} _filtered 
#yiv0625374937 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0625374937 
div.yiv0625374937WordSection1 {}#yiv0625374937 -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,DonDonald F. CoffinFounder/CTO  REMI 
Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221  Phone:  
(949) 636-8571Email:   donald.cof...@reminetworks.com  From: Phil Hunt 
[mailto:phil.h...@oracle.com] 
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: 
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  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  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  
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer , ""  
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  
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 

Re: [OAUTH-WG] Token Chaining Use Case

[Donald F. Coffin]

-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: 
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 mailto: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 mailto: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 mailto:wmills_92...@yahoo.com> > 
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer mailto:jric...@mit.edu> >, "mailto:oauth@ietf.org> >" mailto: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 mailto: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 endpoi

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

Requiring a round trip to the AS is going to have a huge headwind for 
implementation in high performance environments.
I think we need to pursue something like what Phil is talking about where the 
intermediary server has it's own credential or authority.  


 On Thursday, March 26, 2015 1:25 PM, Phil Hunt  
wrote:
   

 See below

Phil

> On Mar 26, 2015, at 15:15, Justin Richer  wrote:
> 
> Your service layout will determine whether or not each bit calls the same AS 
> that issued the original token, since you can easily do it across boundaries 
> if your AS takes in cross domain tokens. That’s another benefit of having it 
> be a generic token swap, you can build it out using the same mechanism and 
> get both behaviors.
> 
> The AS could reject the swap for any number of conditions: wrong client 
> asked, token is expired, scopes don’t align, bad token, etc.
> 
> You can always optimize your system such that you just send a high-powered 
> token down the chain, in which case you’re not using token swapping. This is 
> not for those cases, obviously. This is for the cases when you *are* doing 
> token swapping and usually downscoping the privileges.

There is no high power token in my new proposal. Each server must act on its 
own authority with its own token. The original at is passed as evidence of 
scoped authority to the internal services. 

There is no super token. 

> 
> — Justin
> 
>> On Mar 26, 2015, at 2:53 PM, Phil Hunt  wrote:
>> 
>> What if A calls be with it’s own authorization token (server token ST1) and 
>> passes AT1 in another header e.g. on-behalf-of.
>> 
>> You save a call and can still check the scope downstream. Further, service B 
>> and C can each check whether ST1 and ST2 had the right to wield AT1 even 
>> when AT1’s POP proof is a proof of the external client.
>> 
>> The only reason I can think to call the AS is if there is some dynamic 
>> condition that might cause an AS to reject the swap.  If AT1 is valid, I 
>> can’t think of another reason why the answer isn’t already YES for all 
>> calls. If its no, its likely a permanent configuration problem not a dynamic 
>> decision.  In other words, B always expects A to call it on behalf of some 
>> one.  Likewise, C is always expecting B.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>>> On 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 docume

Re: [OAUTH-WG] Token Chaining Use Case

[Phil Hunt]

See below

Phil

> On Mar 26, 2015, at 15:15, Justin Richer  wrote:
> 
> Your service layout will determine whether or not each bit calls the same AS 
> that issued the original token, since you can easily do it across boundaries 
> if your AS takes in cross domain tokens. That’s another benefit of having it 
> be a generic token swap, you can build it out using the same mechanism and 
> get both behaviors.
> 
> The AS could reject the swap for any number of conditions: wrong client 
> asked, token is expired, scopes don’t align, bad token, etc.
> 
> You can always optimize your system such that you just send a high-powered 
> token down the chain, in which case you’re not using token swapping. This is 
> not for those cases, obviously. This is for the cases when you *are* doing 
> token swapping and usually downscoping the privileges.

There is no high power token in my new proposal. Each server must act on its 
own authority with its own token. The original at is passed as evidence of 
scoped authority to the internal services. 

There is no super token. 

> 
> — Justin
> 
>> On Mar 26, 2015, at 2:53 PM, Phil Hunt  wrote:
>> 
>> What if A calls be with it’s own authorization token (server token ST1) and 
>> passes AT1 in another header e.g. on-behalf-of.
>> 
>> You save a call and can still check the scope downstream. Further, service B 
>> and C can each check whether ST1 and ST2 had the right to wield AT1 even 
>> when AT1’s POP proof is a proof of the external client.
>> 
>> The only reason I can think to call the AS is if there is some dynamic 
>> condition that might cause an AS to reject the swap.  If AT1 is valid, I 
>> can’t think of another reason why the answer isn’t already YES for all 
>> calls. If its no, its likely a permanent configuration problem not a dynamic 
>> decision.  In other words, B always expects A to call it on behalf of some 
>> one.  Likewise, C is always expecting B.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>>> On 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

Re: [OAUTH-WG] Token Chaining Use Case

[Phil Hunt]

+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  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  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  
> Date: 03/26/2015 2:24 PM (GMT-06:00) 
> To: Justin Richer , ""  
> 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  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 
> ot

Re: [OAUTH-WG] Token Chaining Use Case

[Justin Richer]

Not really, because it’s not refreshing access. It’s getting access in the 
context of a separate access token, which wasn’t issued to it. The mechanism is 
similar to a refresh token but that’s it.

 — Justin

> On Mar 26, 2015, at 3:13 PM, Bill Mills  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  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 
> Date: 03/26/2015 2:24 PM (GMT-06:00)
> To: Justin Richer , "" 
> 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  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, cr

Re: [OAUTH-WG] Token Chaining Use Case

[Justin Richer]

Your service layout will determine whether or not each bit calls the same AS 
that issued the original token, since you can easily do it across boundaries if 
your AS takes in cross domain tokens. That’s another benefit of having it be a 
generic token swap, you can build it out using the same mechanism and get both 
behaviors.

The AS could reject the swap for any number of conditions: wrong client asked, 
token is expired, scopes don’t align, bad token, etc.

You can always optimize your system such that you just send a high-powered 
token down the chain, in which case you’re not using token swapping. This is 
not for those cases, obviously. This is for the cases when you *are* doing 
token swapping and usually downscoping the privileges.

 — Justin

> On Mar 26, 2015, at 2:53 PM, Phil Hunt  wrote:
> 
> What if A calls be with it’s own authorization token (server token ST1) and 
> passes AT1 in another header e.g. on-behalf-of.
> 
> You save a call and can still check the scope downstream. Further, service B 
> and C can each check whether ST1 and ST2 had the right to wield AT1 even when 
> AT1’s POP proof is a proof of the external client.
> 
> The only reason I can think to call the AS is if there is some dynamic 
> condition that might cause an AS to reject the swap.  If AT1 is valid, I 
> can’t think of another reason why the answer isn’t already YES for all calls. 
> If its no, its likely a permanent configuration problem not a dynamic 
> decision.  In other words, B always expects A to call it on behalf of some 
> one.  Likewise, C is always expecting B.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
>> On 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 

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

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  
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  
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer , ""  
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  
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

Re: [OAUTH-WG] Token Chaining Use Case

[Phil Hunt]

What if A calls be with it’s own authorization token (server token ST1) and 
passes AT1 in another header e.g. on-behalf-of.

You save a call and can still check the scope downstream. Further, service B 
and C can each check whether ST1 and ST2 had the right to wield AT1 even when 
AT1’s POP proof is a proof of the external client.

The only reason I can think to call the AS is if there is some dynamic 
condition that might cause an AS to reject the swap.  If AT1 is valid, I can’t 
think of another reason why the answer isn’t already YES for all calls. If its 
no, its likely a permanent configuration problem not a dynamic decision.  In 
other words, B always expects A to call it on behalf of some one.  Likewise, C 
is always expecting B.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

> On 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 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

Re: [OAUTH-WG] Token Chaining Use Case

[Justin Richer]

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  
Date: 03/26/2015  2:24 PM  (GMT-06:00) 
To: Justin Richer , ""  
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  
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

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

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  
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-WG] Token Chaining Use Case

[Justin Richer]

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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth