Subject: [OAUTH-WG] Chain Grant Type for OAuth 2 spec

From: David Robinson <[email-masked]>
Date: Mon, 4 Apr 2011 16:58:22 -0400

Phil,

I read through the Chain Grant Type for OAuth 2 draft and appreciate the
problem you are addressing.

We encountered the same issue when using open social gadgets with OAuth when
data needs
to come from more than one server.  It is not user friendly to prompt an end
user to log into multiple
servers and a robust chaining model can help.

You indicate a domain is all resource servers that share a common OAuth
token service (Section 2).
Is a token service actually an "authorization server" per v13 of the base
OAuth 2 spec or are you referring to something else ?

In Section 2.2, first two bullets, is the implication that "OAuth token
services" are performing identity federation ?
The spec states the method used to do this is in companion OAuth token
specifications, but it isn't clear to me
which token specification addresses identity federation.  Which token
specs/sections are you referring to as an example ?

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 14:07:42 -0700

I think in practical terms, an oAuth domain is simply one where the access token accepted. In practical terms this likely means they share the same token service.

Regarding 2.2. The attention is not identity federation, just federation of the token itself. The main thing is the target token server has to have a way to verify the inbound oauth_token. If it is a reference identifier, it will potentially have to make a call back to the issuing server (out of scope). If it is a parsabled token, then the token must be valid according to its specification (e.g. JWT token).

It is fair to assume that the inbound token includes certain claims (which may be identity) and scope being asserted by the originating token server.

Phil
[email-masked]

On 2011-04-04, at 1:58 PM, David Robinson wrote:

> Phil,
> 
> I read through the Chain Grant Type for OAuth 2 draft and appreciate the problem you are addressing.
> 
> We encountered the same issue when using open social gadgets with OAuth when data needs
> to come from more than one server.  It is not user friendly to prompt an end user to log into multiple
> You indicate a domain is all resource servers that share a common OAuth token service (Section 2).
> Is a token service actually an "authorization server" per v13 of the base OAuth 2 spec or are you referring to something else ?
> 
> In Section 2.2, first two bullets, is the implication that "OAuth token services" are performing identity federation ?
> The spec states the method used to do this is in companion OAuth token specifications, but it isn't clear to me
> which token specification addresses identity federation.  Which token specs/sections are you referring to as an example ?
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth