[xauth] details wrt how XAuth works?

[=JeffH]

this is an exercise in testing understanding...

NateK noted (over on the OpenID list)..
>
> 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 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 further
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

**
http://xauth.org/xauth.js
http://xauth.org/server.html


---
end





--
You received this message because you are subscribed to the xAuth group.
To post, send email to xa...@googlegroups.com

To unsubscribe from this group, send email to
xauth+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/xauth?hl=en

[=JeffH]

My prior message, if it wasn't clear, was a request for some confirmation with
respect to how xauth actually works under the hood.

do i have it right? anything missing?

thanks,

=JeffH