Anyone seen

=JeffH Jeff.Hodges at
Mon Apr 19 23:05:30 UTC 2010

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

..which makes use of "the XAuth library", which itself is apparently here (in 
operational terms)..

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 "" 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 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 (depending on what's in those scripts..).

In terms of how it seems to work overall, allow me to please test my 

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 

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.



More information about the specs mailing list