Subject: [OAUTH-WG] Refresh of chaining draft

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Nov 2012 14:44:04 -0800

All,

After a request at IETF85 and a reminder from Hannes, I've posted a refresh of my original chaining document. No changes have been made in the refresh.

My current position is that this type of chaining (as defined in my earlier draft) is useful when you need to get a new token after crossing an administrative boundary.  It is less useful when you have servers wanting to chain in essentially an act on behalf of case where a 1-leg solution is more desirable and 2-legs are costly.

My plan is to work with Justin and reconcile with his work on http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt

> A new version of I-D, draft-hunt-oauth-chain-01.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Filename:	 draft-hunt-oauth-chain
> Revision:	 01
> Title:		 Chain Grant Type for OAuth2
> Creation date:	 2012-11-28
> WG ID:		 Individual Submission
> Number of pages: 10
> URL:             http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-hunt-oauth-chain
> Htmlized:        http://tools.ietf.org/html/draft-hunt-oauth-chain-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-chain-01
> 
> Abstract:
>   This specification defines a method by which an OAuth protected
>   service, can use a received oauth token from its client, to in turn,
>   act as a client and access another OAuth protected service in a
>   'chained' profile.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Ebling, Sebastian" <[email-masked]>
Date: Fri, 30 Nov 2012 11:25:58 +0100

Hi Phil,

Some comments on draft-richer-oauth-chain-00.txt:

Section 3.1.
- I dislike the name of the grant type. "redelegate" is the use case but not the grant presented to the AS from RS1. I suggest to use "access_token" according to other grant types like authorization_code, password, refresh_token.

Section 3.2
"As this access token is bound to an existing access token, the authorization server MUST NOT issue a refresh token."
>From our operating experience [1] it may be useful to issue a refresh token in some cases. 

Example:
RS1 may be a batch processing system that must be able to access RS2 some hours later to fulfill the originary request from the Client. The access tokens (AS to C and AS to RS1) may have expired when the job starts from the queue. Issuing a refresh token enables RS1 to obtain a fresh access token (AS to RS1).
AS may limit the duration of the refresh token for such clients (RS1).

Regards

Sebastian

[1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsible for the system life cycle of our Secure Token Service. We have already implemented a very similar custom grant type for service chaining at Deutsche Telekom.

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 30 Nov 2012 10:31:01 +0000

> - I dislike the name of the grant type. "redelegate" is the use case but not the grant presented to the AS from RS1. I suggest to use "access_token" according to other grant types like authorizatio…
Interesting. What about adding one more optional parameter to 
"refresh_grant" ?

thanks, Sergey

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 30 Nov 2012 23:35:35 +0900

Just to add more support for the usefulness of the chaining, OpenID
Connect's aggregated claims model indeed falls under this category.

Sent from iPad

2012/11/29 7:44、Phil Hunt <[email-masked]> wrote:

All,

After a request at IETF85 and a reminder from Hannes, I've posted a refresh
of my original chaining document. No changes have been made in the refresh.

My current position is that this type of chaining (as defined in my earlier
draft) is useful when you need to get a new token after crossing an
administrative boundary.  It is less useful when you have servers wanting
to chain in essentially an act on behalf of case where a 1-leg solution is
more desirable and 2-legs are costly.

My plan is to work with Justin and reconcile with his work on
http://tools.ietf.org/id/draft-richer-oauth-chain-00.txt

URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-chain-01.txt

Abstract:

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 30 Nov 2012 08:36:57 -0800

Two things.

1. I think access_token would be a bit confusing in some contexts even though thats what it is. However it is likely a foreign access token. "chain" is also shorter. 

2. Regarding refresh, any idea on the use case? My impression is that if anything lifetime should be shorter than the current access token. All cases i have been looking at tend to be closer to single use --> which has led o feedback that a single leg solution would be better for same domain cases. 

Phil

Sent from my phone.

On 2012-11-30, at 2:31, Sergey Beryozkin <[email-masked]> wrote:

> Interesting. What about adding one more optional parameter to "refresh_grant" ?
> 
> thanks, Sergey
> 
>> Section 3.2