[OpenID] Multiple Domains and State

[Nate Klingenstein]

Trey,

Bear in mind I'm relatively new to this spec, and going pretty deep  
into it to answer you, so I might make a mistake.

> 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.

"Communicate with the original domain" is the tricky step.  How?  It  
can't forward the claimed identity because the claim was issued for  
auth.com's eyes only.  It can't claim the identity openid.com/trey  
because it doesn't control the URL.  It also can't spoof the response  
because it's signed.

It could spoof a request on behalf of the original domain to  
openid.com, getting the right return URL, but then why route the  
flows through auth.com in the first place, since it's not maintaining  
state?  It becomes a lookup service for OP's exactly like  
Shibboleth's WAYF; useful in some situations, but probably not what  
you're looking for.

This is a generic feature of security protocols that use bearer  
tokens, I'm afraid.  It's a deliberate measure to prevent a  
legitimate recipient of an assertion from replaying it at another RP.

You're trying to circumvent this security measure in a legitimate  
way, but doing so requires either:

A) extra trust between auth.com and the end domain (and, in this  
case, a different protocol if you want to remain spec-valid); or
B) a trust fabric between openid.com, auth.com, and the end domain so  
that you can make use of the Realms feature in 2.0 Auth(section 9.2).

> 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.

Depending on how you do it, various things would fail, again by design.

A)  If you pass along the entire assertion unmodified, the original  
domain MUST dump it because the return URL doesn't match (11.1);
B)  If you try to send openid.com/trey from auth.com, the signature  
won't be verifiable, because you don't control the domain it resolves  
to; or
C)  If you send auth.com/trey, the original domain will be receiving  
the wrong identifier.

> 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.

Probably, but it's pretty dense.  I'd just homebrew this part, or  
hardcode some overrides into your validation code if you really want  
to use OpenID.

Peter's suggestion to use attributes would work too.  That's what we  
did in Shibboleth.  There's just too much riding on successful  
identifier validation in OpenID, so deliberately breaking that's  
kinda dangerous.

> 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.

It's definitely not the first time I've heard the use case.  The  
trouble is that there's no good, lightweight solution. ;D

Take care,
Nate.