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