Subject: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people

From: Thomas Hardjono <[email-masked]>
Date: Tue, 7 Sep 2010 16:24:55 -0400

__________________________________________

> -----Original Message-----
> From: Brian Campbell [mailto:[email-masked]]
> Sent: Wednesday, August 25, 2010 4:29 PM
> To: Thomas Hardjono
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML
> people
> 
> Again, sorry for the slow reply.
> 
> On Thu, Aug 19, 2010 at 1:52 PM, Thomas Hardjono <[email-masked]>
> wrote:
> 
> >  Does Oauth-v2 today allow
> > the Authorization Server to delegate/relegate the actual obtaining of
> > the access token to a 3rd Party?
> 
> I'm not sure I follow the question?

Brian, apologies for the delay.

What I meant to say is that User#1/Client#1 asks for 
an access token (to a given resource) with the
intention of later handing over the access-token to 
a different User#2/Client#2.

Ideally, this model could be extensible where
User#2/Client#2 asks the Auth Server to "swap" (re-issue)
this token for a different client_id (User#3/Client#3).

However, this bring us into space of role based access
control and permissions, which would somewhat complicate
the Oauth 2.0 authorization model :)

/thomas/

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 07 Sep 2010 16:36:24 -0400

Thomas,

It looks to me like the intention in this use case is similar to that of 
the "multilegged OAuth" (later renamed to the politically-correct 
"recursive delegation"). This use case has been published in Bart's and 
Zachary's draft. which has expired now. This case has moved into the 
overall use case compilation document.

Zachary, maybe you could shed some light here?

Igor

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

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 7 Sep 2010 16:15:25 -0500

Igor,

The intention of the draft draft-vrancken-oauth-redelegation was to specify a mechanism for doing exactly what Thomas has described:
> ... User#1/Client#1 asks for 
> a different User#2/Client#2
The mechanism is design to support also the situation where
> this token for a different client_id (User#3/Client#3)

The difference is that the mechanism of the draft-vrancken-oauth-redelegation relies on the "temporary credentials" and "token credentials", which were used in OAuth 1.0, and not on the access tokens.

Zachary
-----Original Message-----
From: Igor Faynberg [mailto:[email-masked]] 
Sent: Tuesday, September 07, 2010 4:36 PM
To: Thomas Hardjono; Zeltsan, Zachary (Zachary)
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people

Thomas,

Igor

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Sep 2010 12:45:43 -0400

I've looked over this draft, and I don't think a lot of it is necessary
under OAuth2.0. The protected resource no longer has any kind of
client_id associated with it, so a client can take an access token and
hand it off to any other client to use without any other information
needed. To support this behavior, I can see two main things missing from
the current OAuth2 spec:

1) The ability of the already-authorized client to ask for a new token
for the purposes of handing off to another client, without bugging the
user. This was the impetus for the re-scoping discussion on the list.
Seems like we can use an assertion profile that uses the refresh or
access token on the token 

2) A mechanism for handing the token off between clients. At the very
least, this could always happen out-of-band, but for some kinds of
clients (both web servers, for example) we could define a way to request
and hand off the credentials acquired in step 1 to the delegated client.

 -- Justin

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 08 Sep 2010 13:37:58 -0400

So, maybe you and Thomas can generalize that use case to rely on either 
mechanism?

Igor

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 9 Sep 2010 11:13:21 -0400

Thanks Igor and Zachary,

Are there any plans to renew this expired draft?  Also, is there a limitation to the number of "swaps" that can be supported?

Thanks.

/thomas/

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Zeltsan, Zachary (Zachary)
> Sent: Tuesday, September 07, 2010 5:15 PM
> To: Faynberg, Igor (Igor); Thomas Hardjono
> Cc: oauth
> The intention of the draft draft-vrancken-oauth-redelegation was to
> specify a mechanism for doing exactly what Thomas has described:
> > an access token (to a given resource) with the intention of later
> > handing over the access-token to a different User#2/Client#2
> > User#2/Client#2 asks the Auth Server to "swap" (re-issue) this token
> > for a different client_id (User#3/Client#3)
> 
> The difference is that the mechanism of the draft-vrancken-oauth-
> redelegation relies on the "temporary credentials" and "token
> credentials", which were used in OAuth 1.0, and not on the access
> tokens.
> 
> Zachary
> It looks to me like the intention in this use case is similar to that
> of the "multilegged OAuth" (later renamed to the politically-correct
> > What I meant to say is that User#1/Client#1 asks for an access token
> > (to a given resource) with the intention of later handing over the
> > access-token to a different User#2/Client#2.
> >
> > User#2/Client#2 asks the Auth Server to "swap" (re-issue) this token
> > for a different client_id (User#3/Client#3).
> >
> > However, this bring us into space of role based access control and
> > permissions, which would somewhat complicate the Oauth 2.0
> > authorization model :)
> >
> > /thomas/
> >
> >
> >
> >

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 14 Sep 2010 05:24:26 -0500

Thomas,

The draft does not specify a limit on the number of delegations from Client#N to Client#(N+1).

The draft's revision would require a substantial work because the draft relies on the community version of OAuth, which differs significantly from the current OAuth v.2. I am talking with our developers to determine if there is sufficient support for this work.

Zachary
-----Original Message-----
From: Thomas Hardjono [mailto:[email-masked]] 
Sent: Thursday, September 09, 2010 11:13 AM
To: Zeltsan, Zachary (Zachary); Faynberg, Igor (Igor)
Cc: oauth
Subject: RE: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people

Thanks Igor and Zachary,

Thanks.

/thomas/

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 14 Sep 2010 13:33:04 -0400

Thanks Zachary,

> From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-
> lucent.com]
> Sent: Tuesday, September 14, 2010 6:24 AM
> To: Thomas Hardjono; Faynberg, Igor (Igor)
> Cc: oauth

ok, great.
> 
> The draft's revision would require a substantial work because the draft
> relies on the community version of OAuth, which differs significantly
> from the current OAuth v.2. I am talking with our developers to
> determine if there is sufficient support for this work.

Hmm, I guess it is always a good thing to have code as close as possible to spec :) 

/thomas/

> Are there any plans to renew this expired draft?  Also, is there a
> limitation to the number of "swaps" that can be supported?
> 
> Thanks.
> 
> /thomas/
>