[1] XAuth ( 版) http://xauth.org/

[3] XAuth Info ( 版) http://xauth.org/info/

[4] XAuth Specifications ( 版) http://xauth.org/spec/

[5] シンプルなXAuthの仕様をまとめてみる - r-weblife ( 版) http://d.hatena.ne.jp/ritou/20100424/1272106914

[6] Google Code Blog: Using XAuth to simplify the social web ( 版) http://googlecode.blogspot.com/2010/04/using-xauth-to-simplify-social-web.html

[7] Social Web Blog: Simplifying the social web with XAuth ( 版) http://googlesocialweb.blogspot.com/2010/04/simplifying-social-web-with-xauth.html

[2] 最近ではいろんな Web サービスに他の Web サービスとの連携機能がついていて、その Web サービスのリストがずらずら出てくるけど、実際にユーザーが使っているのは一握り (ただしどの一握りかはユーザーごとに違う)、というのがそもそもの問題で、それを解決するためにどのサービスにログインしているかを把握できるようにするのが XAuth です。

[8] 面白いのは実現方法で、ブラウザを拡張するとか、どこかの中央サーバーで保存するとかがぱっと思いつくところですが、 XAuth では postMessage + localStorage でブラウザ内に保存します。 postMessage の宛先として中央サーバーが必要になっちゃいますが、データはブラウザが持っていてサーバーには送られません。

ログイン情報の共有ということで心配なのはプライバシーですが、サーバーに送られない点に加え、何を共有するかは共有する側のサービスが選べるようになっています。ログイン中か否かの2値でもいいですし、 OAuth みたいな認証トークンを渡しちゃってもいい。

[9] この仕組みの大きな問題は、中の人も書いていますが、いろんなサービスが XAuth に対応して情報を出してくれないことには使う側もメリットがない、という鶏と卵な構造です。4月に発表されたときには Google とか Yahoo! とかが賛同していて対応予定とか書いてありましたけど、その後どうなったのかはよくわからない。 (なんで xAuth と紛らわしい名前にしたんだかw)

もう1つの大きな問題は、 xauth.org を信用しても良いかです。サーバーには送られないと言っても、それは今そうなっているだけで、今後もそうであり続ける保障はありません。今の xauth.org の所有者は信用するとしても、ドメインが失効して変な人の手に渡ったら、というのは怖いですね。

[10] >>1 はドメインが失効してるようです。

>>9 怖いですね。

[11] Twitter の xAuth とは関係がありません。