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. _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
