[OpenID] Multiple Domains and State

[Trey Long]

Thanks for the responses and resources you've provided.
Comments inline.

On Apr 23, 2008, at 3:05 PM, Nate Klingenstein wrote:

> Trey & Shade,
>
> Here's a picture and writeup courtesy of UAB, NCSA & their early  
> proxying experiments that might help:
>
> https://spaces.internet2.edu/display/GS/MyVocs
>
>> About #1. If openId's are unique why would the authenticating party  
>> need to specify which one out of two or more? Assuming they were  
>> using one openId for my properties we could use that openId- 
>> provider.com/username as the key to lookup the user on the original  
>> domain.
>
> In your example, would the RP receive the identifier auth.com/trey,  
> or openid.com/trey?  Who would have issued and confirmed it?  How do  
> you avoid auth.com/trey going to openid.com/ndk or microsoft.com/ 
> bgates?
>
> It gets worse when you start dealing with attributes.
>

In the example auth.com would be a trusted resource and if the user  
had no session would ask about his identity (openid.com/trey).  
Auth.com would confirm the authentication in the standard way and  
communicate with the original domain that this users identity  
"openid.com/trey" has been verified.

This process does add another step in the chain as well as another  
spot for compromise. However it seems to me not to add any additional  
security concerns as it's only repeating the process and proxying the  
information back to a trusted consumer. The standard of security  
remains the same in my eyes.

>> Also, to double check. You are saying that openId supports -- or  
>> maybe more specifically doesn't prohibit -- chaining authentication  
>> to an intermediary server?
>
> If you're just using openid.com/trey to authenticate for auth.com/ 
> trey, then you're probably within the specs.  If your intention is  
> to allow auth.com to be authoritative for openid.com/trey through  
> some other process, you've probably moved outside the specs, as  
> Shade alludes to.
>
> In particular, you'd have issues with the Return URL.  What does  
> openid.com stick in there that is spec-legal, goes to auth.com, and  
> will be trusted by related-a.com?

I would expect auth.com to act as a proxy for the entire authorization  
chain and would be the return URL. This would allow auth.com to  
establish state and then return the user to the original domain. The  
original domain would then do the requisite communication directly  
with auth.com to confirm.

>
>> Lastly, is there anything published online (specs, docs, howtos,  
>> thoughts or reflections) about what we're trying to do here that  
>> you know of?
>
> See the document above(as well as the IAMSuite work out of  
> Australia).  The flow diagram is significantly more complicated than  
> it needs to be because they were trying to integrate with existing  
> software packages.  I can also send you an old paper I wrote on this  
> off-list if you're interested.  There are a few other ways to skin  
> this cat.

If you think it's a resource that would help with this problem send it  
on. Ideally it would be great if I could either fit this within openId  
or extend openId to support trusted chains or proxies. If not, home  
brew will do.

It does seem though that single sign on for multiple domains is  
desired elsewhere. I would like to hear other thoughts on the topic as  
well, outside of my original idea that may apply. Perhaps I am being  
stupid about the solution, it certainly wouldn't be the first time.

>
> Glad to have your insights on this old problem,
> Nate.

I look forward to being schooled,
Trey.