[diso-project] XAuth

[Will Meyer]

Thought it worth posting this here...Meebo launched XAuth:

http://xauth.org/spec/

Common server, domain, cookie/storage space for social account prefs.
Techcrunch says
(http://techcrunch.com/2010/04/18/spearheaded-by-meebo-xauth-looks-to-make-social-sites-smarter/)
its in tandem with goog, yahoo, janrain, etc. Don't know if there's a
mailing list or anything besides a meebo contact email on the spec.

Curious what the ID folks think of this. Its basically an open
version of what most sharing tools do today on their own domains.

W

--
You received this message because you are subscribed to the Google Groups "Diso Project" group.
To post to this group, send email to diso-p...@googlegroups.com.
To unsubscribe from this group, send email to diso-project...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en.

[Robert]

This sounds like it's a big step forward for discovery?  I'm not sure I'm fully getting the implications yet (on the run, don't have time).  Does this help toward solving el nascaro problemo?

[Will Meyer]

Is a central server/domain really the best way to do this? Yes it
works, and is similar to the way sharing platform vendors do things
(AddThis for example has a user.getPreferredServices() call, among
other similar ones). Personally I am far partial to representing
preferred account existence with WebFinger and not by introducing a
mediating server, even if it is a .org and not a .com.

W

[Chris Messina]

I'm totally sympathetic (and supportive) to distributing and decentralizing XAuth but have come to be more pragmatic recently, if only because there are two paths forward:

* centralize your list of preferred services in the browser (meaning upgrade EVERYONE's browser)

* centralize everyone's preferred services on a single server (with appropriate controls for opting-out and controlling data access)

Unfortunately, it's really hard to get browser makers to take the identity opportunity seriously, and as a result, the industry decided to move in this direction.

Now, it's important to note that XAuth is not a unique approach to this problem. In fact it's what many institutions in Europe and academia do using SAML:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html

I think XAuth is somewhat clever in how it leverages HTML5 localStorage and postMessage, and provides a way forward for how the browser could actually get more involved in service publication/discovery.

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[Will Meyer]

Thanks for weighing in, just saw your post as well. In the spirit of
open discussion...

On Mon, Apr 19, 2010 at 15:52, Chris Messina <chris....@gmail.com> wrote:
> I'm totally sympathetic (and supportive) to distributing and decentralizing
> XAuth but have come to be more pragmatic recently, if only because there are
> two paths forward:
> * centralize your list of preferred services in the browser (meaning upgrade
> EVERYONE's browser)
> * centralize everyone's preferred services on a single server (with
> appropriate controls for opting-out and controlling data access)

I thought "personal discovery" was all about the third way. For
example, you can webfinger me and get a list of services that I prefer
to use. This tells you which services I use (and in the case of my
example, also how to communicate with them, OExchange). E.g.
http://webfingerclient-dclinton.appspot.com/lookup?identifier=wi...@willmeyer.com&format=web.
Granted, XAuth is a more general case, "get the services on which I
have accounts" identified by domain as opposed to some other spec, but
its the same concept. Webfinger, or at least the spirit of personal
discovery, would provide a way to allow users to have service
preferences be discoverable without having to share javascript and
allocate one domain/js for a shared cookie space.

> Unfortunately, it's really hard to get browser makers to take the identity
> opportunity seriously, and as a result, the industry decided to move in this
> direction.

I'm all for industry moving forward... Who owns xauth.org? Who
updates the JS? Who controls that CDN? For example, AddThis has a
ton of this kind of data (who uses what services to share content),
and an api to get at it, though I wouldn't have positioned it as a
standard; its a product feature.

> Now, it's important to note that XAuth is not a unique approach to this
> problem. In fact it's what many institutions in Europe and academia do using
> SAML:
> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html
>
> I think XAuth is somewhat clever in how it leverages HTML5 localStorage and
> postMessage, and provides a way forward for how the browser could actually
> get more involved in service publication/discovery.

This is basically how most proprietary implementations of this kind of
thing work today. Getting around x-domain by sharing some JS and
having it post back to the parent is well-known. I'd also argue that
just because its html5 storage as opposed to cookies doesn't get
around the issues, both real and perceived, currently plaguing 3rd
party cookies.

In any case, I'm a big fan of things moving forward in real, practical
terms. So kudos there to concrete progress. This to me just reads to
me more like a product-level integration than it does an open model,
and one that has a lot of technical concerns at that. Maybe I got too
excited about Webfinger's potential for personal discovery, if we're
all just going to do this with x-domain cookie hacks and shared JS.
Will be anxious to participate in the XAuth discussion once it opens
up somewhere (I did email the meebo account on the spec page).

[peter cowan]

Will,

my understanding is that as of now meebo is hosting the service, but has plans to open source it soon, and that ultimately it would be owned and hosted by an organizatino like the open web foundation, or the openId foundation.

On Mon, Apr 19, 2010 at 1:27 PM, Will Meyer <wi...@willmeyer.com> wrote:

I'm all for industry moving forward...  Who owns xauth.org?  Who
updates the JS?  Who controls that CDN?  For example, AddThis has a
ton of this kind of data (who uses what services to share content),
and an api to get at it, though I wouldn't have positioned it as a
standard; its a product feature.

[David Recordon]

Open sourcing the JavaScript?

The Open Web Foundation doesn't have infrastructure resources and I
don't think they've talked to the OpenID Foundation about it.

[peter cowan]

i meant open sourcing the xauth service, but i was loosely quoting seth sternberg (meebo's ceo), he says "we're going to make it completely open. so, um... we're ultimately going to be handing it off to one of the standards bodies like open exchange or openid foundation, for example". 

i admit, i don't know what "completely open" means in this context. the quote is from scoble's interview starting at ~3:33. there is more there, but that is specifically what i was referring to, and i don't have time to listen to the whole thing again right now. 

[Luke Shepard]

Speaking of open source, does anyone know if there is an unminified version of http://xauth.org/xauth.js or http://xauth.org/server.html available? It's hard to tell what it's doing exactly from those files.

--
- Luke Shepard
773-742-9163

[Will Meyer]

I couldn't find any personally. FWIW I did dig through the minified
code (after reformatting it at least) enough to see that its basically
posting the command set (extend, retrieve, etc) as json strings to the
frame (which is http://xauth.org/server.html), and the frame is itself
using the origin property of the incoming message as the security
mechanism to determine who is actually trying to do the extension.

Sure would be nice if there was a place to discuss this implementation
stuff with those involved in the project.

W

[Robert]

Okay, interesting.  So it sounds like discovery is being relegated to the cloud.  But by one organization, namely XAuth, which it sounds like it will be handed off to one of the standards groups.  (It also wasn't clear to me from the video.)

A few questions:

Doesn't this ultimately mean there's only one discovery service, namely wherever XAuth is hosted?  I realize that one can still have multiple OpenID providers under this scenario, which could be anywhere, but the one-cloud-space approach for discovery seems antithetical to a distributed approach.  Not that I'm against it.  We need *something,* and this certainly seems like a great solution and start, but I thought it was worth saying.

--Robert Hall

[Robert]

Oh boy -- just reread Chris's thread and realized this concern had already been proffered.

Well, count that twice anyway.

I'll reiterate, I am greatly in favor of better discovery methods over nothing.  As I see it a lack of good discovery techniques was the main hurdle in user experience, and hence was stifling adoption rates.  Hopefully we're about to see the circle close on this. 

[Chris Messina]

On Mon, Apr 19, 2010 at 5:26 PM, Luke Shepard <lu...@lukeshepard.com> wrote:

Speaking of open source, does anyone know if there is an unminified version of http://xauth.org/xauth.js or http://xauth.org/server.html available? It's hard to tell what it's doing exactly from those files.

Does this help?

http://gist.github.com/371328

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[Chris Messina]

On Mon, Apr 19, 2010 at 6:31 PM, Will Meyer <wi...@willmeyer.com> wrote:

I couldn't find any personally.  FWIW I did dig through the minified
code (after reformatting it at least) enough to see that its basically
posting the command set (extend, retrieve, etc) as json strings to the
frame (which is http://xauth.org/server.html), and the frame is itself
using the origin property of the incoming message as the security
mechanism to determine who is actually trying to do the extension.

Sure would be nice if there was a place to discuss this implementation
stuff with those involved in the project.

We've done a bad job of promoting the list, but you can discuss XAuth here:

http://groups.google.com/group/xauth

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[Steven Livingstone-Perez]

I watched the video and first thought was would xAuth not be better implemented as an OpenID extension?

 

So your OpenID server (distributed) does the job (via a local xAuth implementation) of asking the other networks what you are “interested” in and then when you authenticate with a site using OpenID it allowing this joining to happen. This means it would also be implicitly distributed and accessible using some of the standard OpenID data exchange mechanisms or an extended API if need be.

 

Nice work though.

 

/steven

[Rabbit]

Correct me if I'm wrong but this is similar to the Google Gears or
Chrome Frame approach to solving the same kind of scenario.

Problem:
- Functionality X is desirable.
- Functionality X is best native to the browser.
- Browsers do not support Functionality X.

Solution:
- Establish a easy-to-implement plugin.
- Wait for browsers to catch up.

If XAuth were widely adopted, the pull to fix identity in the browser
would be greater. At least for the problem that this solves. It also
gives browser developers a point of reference for starting a
conversation which is great! I like that we can now talk about the
NASCAR problem in the context of an existing solution and without
necessarily needing to involve the mechanics of OpenID or Facebook
Coonect as part of that conversation.

=Rabbit

[Chris Messina]

The problem which thwarts all others is: how do you tell *any* website which set of service providers to list for that first third party login?

We wouldn't need XAuth (or similar solutions) if people could remember their OpenIDs -- what they seem to remember is that they at least *have* any account somewhere... and then they have to pick from the NASCAR, which then fails them if they have an account with more than one of the listed providers. So they're staring at a bank of logos, recognize a few logos, but don't know which one to pick or why. 

This is a fundamental challenge with OpenID as it exists today. 

Chris 

Sent from my iPhone 2G

[Steven Livingstone-Perez]

I like some of the work from the FOAF+SSL combined with OpenID to enable
this seamlessly. I played with it - nice but tricky UX [for now].



Agree there are some UX challenges around the NASCAR.



Be neat if as part of your profile page on FB, Twitter etc it had an XRDS
file that pointed to your OpenID - or... if it were past back as part of
the authentication hops (captured earlier in your profile say). That way you
log in with your site account but get an identifier locally you can hook
into. Could also be used to look up services. Maybe that is what webfinger
is all about (need to read up again).

[Chris Messina]

Thanks for that -- a very apt observation!

It's important to note, however it is perceived, that it was Meebo
that came to Google and others *first* seeking to remedy this problem.
GCF and Gears were both definitely Google-born (and Gears has
subsequently been retired).

Chris

Sent from my iPhone 2G