Anyone seen xauth.org?

Nate Klingenstein ndk at internet2.edu
Tue Apr 20 03:38:42 UTC 2010


Jeff,

> What they have realized is that with postMessage() and  
> localStorage() being built-into newer browsers, they can do that CDC  
> technique, without each trust circle setting up a real life common  
> domain and without using cookies, and doing it all client-side in  
> the browser (it seems).

It's unclear to me how the means by which the information is stored in  
the client (cookie vs. database) matters much in this instance, other  
than that it won't send localStorage information by default when  
xauth.org is visited(though it does list tokens on index.html, so  
probably just an attempt to avoid being bombarded with data).

> Although they are supplying a global common domain string via  
> "xauth.org" and serving the latter two scripts above from it, as  
> well as using it to label the common browser-side frame they use as  
> the target for postMessage() -- presumably one could supply one's  
> own existing domain to do this, and/or embed all the .js code in the  
> browser somehow such that snarfing if off a site in real time isn't  
> necessary and thus one could name the common browser-side frame  
> foobar or whatever (?), and have a notion of distinct trust circles  
> aka identity federations.

If it's open source and plagiarizable, yes, but doing so somewhat  
contravenes the spirit and function for which the service was built  
and leaves an SP/"retriever" with an interesting set of questions as  
it tries to reconcile the results.  I don't know if it's the right  
approach.

If I wanted to leverage this for an educational federation, I would  
use an opaque XAuth token extended by the federation itself to the set  
of federation SP's.  That token would represent something about past  
IdP choices made by the user.  It'd basically supplant existing DS  
functionality natively implemented that already does the same thing,  
but on a per-DS basis, and possibly more widely supported by more SP/ 
RP's.

It might not obey the spirit of the spec because it's a DS session  
rather than an IdP session -- dunno -- but I think it'd obey the  
letter, and it'd cause way less issues in the educational community  
than the spirit of the spec would.  As I indicated to Chris in my  
earlier message, our attempts at centralizing discovery ( see

http://lists.openid.net/pipermail/openid-general/2009-February/017227.html

) have not been successful, for a variety of reasons.

> I'm guessing that the only actual network interaction with xauth.org  
> is to snarf over the latter two scripts above from it. Once the  
> iframe is instantiated and the scripts fetched, there perhaps isn't  
> any further network interaction with xauth.org (depending on what's  
> in those scripts..).

I think this part is actually really important, though.  My  
understanding is that the localStorage has the same restrictions on  
access by scripts that cookies would(except for no control over path,  
etc.), even down to allowing users to block this sort of third-party  
storage via iframes.  By definition, the browser will only cough up  
the localStorage for xauth.org to a script at xauth.org.  xauth.org  
becomes the only authority that is able to instruct a client to write  
or read the set of sessions associated with it.  Indeed, this is a  
little different(and easier) as compared to the common domain model,  
where the entities that wanted to share sessions like this would be  
allocated control over portions of a namespace in a common DNS domain.

Whether xauth.org does see these sessions in standard operation is  
important, and I agree that it doesn't, but it retains the ability  
definitionally that only xauth.org -- and scripts hosted at xauth.org  
-- is able to retrieve any of/all of this information.  And there are  
no limitations on which pieces of information xauth.org could pull.   
It(and retrievers with the right permissions) could associate the  
identities of the individual at a variety of services.  We trust it to  
behave, and it is critical infrastructure.

This service, again, does many things we're uncomfortable with: stores  
active user sessions at third parties, stores trust lists on behalf of  
third parties, tightly couples a specific discovery service to the  
rest of the federated identity infrastructure, and contingent on other  
checks, it could present its users' bearer tokens/sessions, if those  
are represented by extenders' XAuth tokens.

As I mentioned earlier, I can think of ways I could leverage XAuth to  
avoid some of those drawbacks, but not others.  I'm not against  
trusted services: they're important and necessary for infrastructure.   
I'm not suggesting any of those attacks is probable.  But it means  
xauth.org would have to be an immensely trusted and well-governed  
service, and federated identity infrastructure would be much more  
centralized than it is today.

So, having it randomly pop up from Meebo based on a bunch of ideas  
floated by Google with absolutely no information about governance,  
ownership, security measures, etc. gives me the willies.  Address some  
of those things, confirm that the appropriation I described earlier is  
okay, and I'll feel a little better, maybe even like this could be  
useful.

Thanks for doing the brainwork,
Nate.


More information about the specs mailing list