I took a look at it. the spec is a browser-side javascript API spec. If you
want to see the code, check out the javascript embedded on the pages..
http://xauth.org/
http://xauth.org/spec/
..which makes use of "the XAuth library", which itself is apparently here (in
operational terms)..
http://xauth.org/xauth.js
http://xauth.org/server.html
Basically, it is making use of the html5 browser-side functionality of
postMessage() and localStorage().
NateK noted..
>
> The XAuth proposal seems also, on quick, distract glance, to have
> flavors of the "common domain cookie" in the original SAML specs
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).
> Brings me to another major distinction that I didn't mention in my
> last message to Chris. These discovery services and common cookies
> were and are scoped to specific "circles of trust," or federations, or
> other cohesive, and generally legally extant entities.
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.
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..).
In terms of how it seems to work overall, allow me to please test my
understanding..
There is some given site, called an "extender", that explicitly notes in the
browser's localStorage that some particular set of (partner/affiliated) sites
(termed "retrievers") may obtain a token, placed there by the extender, from
localStorage.
Thus, one could have a "retriever" site (termed a Relying Party by some other
specs, Service Provider by others, a "consumer" in the original OAuth spec),
and you could have relationships with several "extenders" (aka social networks
sites, whathaveyou). Thus once the browser loads your page, you can have script
in your page query the browser, using the XAuth API, asking about the entire
list of extenders you (the "retriever" aka RP/SP) have relationships with, and
if the user is logged into any of them at that time (i.e. if localStorage has
unexpired tokens from any of them), then you'll get that info. From there you
can use whatever info is in each individual extender token (that is up to the
extender to define). Then, having your site directly interact with any of the
extenders is up to you and the extender work out, and how your site
authenticates with extender site(s) isn't defined, you could for example then
use OAuth in your further interactions.
thanks,
=JeffH
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
