[OpenID] Multiple Domains and State

[Peter Williams]

This is the kerberos model: use one saml idp to issue a token granting the user  a pending-capability to use another op's attribute resolution service, which delivers attributes and thus capabilities to levage the attributes in an authorized manner on the particular target sp.

In openid terms: get a positive assertion that the rp ebgine then presents to an ax endpoint at another op, whose response is presented to the backend sp as an authorized attributes.

You see this done in the ssl/pki model too. User presents ssl client cert as positive assertion, which rp proxy (ssl protocol entity in ssl server role) presents to ocsp endpoint, whose signed realtime response has attributes and the authorization assertions that upon the response's sig/pki verification are then given to the https webapp by the ssl layer entity in the stack.


-----Original Message-----
From: Nate Klingenstein <ndk at internet2.edu>
Sent: Wednesday, April 23, 2008 12:05 PM
To: Trey Long <trey at propeller.com>
Cc: general at openid.net <general at openid.net>
Subject: Re: [OpenID] Multiple Domains and State

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.

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

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

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