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

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

On Tue, 2010-09-07 at 17:15 -0400, Zeltsan, Zachary (Zachary) wrote:
> 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 
> > an access token (to a given resource) with the
> > intention of later handing over the access-token to 
> > a different User#2/Client#2
> The mechanism is design to support also the situation where
> > 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
> -----Original Message-----
> From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] 
> 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,
> 
> 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:
> > __________________________________________
> >
> >   
> >> -...
> >
> > 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/
> >
> >
> >
> >
> > _______________________________________________
> > 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