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 phil.h...@oracle.com 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 > 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 ? > > > _______________________________________________ > 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
