YADISって何だ？

最近yadis.jpなんかも取って一人で盛り上がっている感があるYADISですが、ギークと一般との乖離を危惧してるとかいいながら自分は誰も興味持ってないこと綿々と綴っていくのもアレなので、この辺で説明をば。

YADISとは何か。
OpenIDです。違います。LIDです。違います。いや違わないか。
結局のところ、世の中にはOpenIDだのLIDだの、他には追いきれていないのですがXRIとかSxipとか、URIベースで識別機能を提供する仕様がたくさんあります。
これらの仕様は、それぞれ異なった設計思想で、識別機能を提供する上で重要視する部分も異なって作られているので、どれが優れていてどれが駄目ってもんでもなくて、識別されたいユーザや、識別機能を導入したいクライアントサービス側のニーズに従って選択されるべきもんなわけです。
日常生活で、免許証でIDを照明するか、クレジットカードか、保険証か、名刺か、利用するサービスのニーズによって使い分けるべきなのと同様に。
よってどれかを廃棄して、標準識別仕様を作ればよいというもんでもない。
でも、同じURIを用いた識別手段である以上、そのURIがOpenIDの識別URIなのかLIDの識別URIなのかを意識することなく相互運用できるように、URIからその対応する識別プロトコルをAuto-Discoveryする手順を標準化するという、そのAuto-Discovery手段の仕様がYADISというわけです。
（とりあえず何かを訳したわけではなく、私の頭の中の理解を文章化したので、細部では間違いあるかもしれません。その場合は突っ込みよろしく）

具体的には...と書こうとしたあたりで昼休み終了なので、続きは家で書く（バタンキューでなければ）
沈黙を破って再開。
YADISの仕様は、12月1日にSixApartで仕様決定の主たるプレーヤーが集まってミーティングを行った結果、大きく前進したみたいで、その成果をまとめたサイトはいくつかあるけど、ここが判り易そう。
要するに、実際にIDとして使う識別URLと、そのURLが対応する識別プロトコルを定義するYADIS文書の2つを用意して、

識別URL:

1. 識別クライアント側からアクセスを受けると、値としてYADIS文書のURLを設定した、X-YADIS-Locationという拡張ヘッダをHTTPヘッダに加え、レスポンスを返す。
2. YADIS文書のURLの指定方法は、HTTPヘッダによる指定の他、HTMLヘッダでの、http-equivをX-YADIS-Locationに設定した<meta>タグでもよい。
3. 識別クライアント側は、X-YADIS-LocationでYADIS文書のURLを受け取ると、そのURLに制御を移しYADIS文書を取得する。

YADIS文書:

1. YADIS文書は、Content-Typeとしてapplication/xrds+xmlを返す。
2. YADIS文書の書式は以下の感じ。
   

   <?xml version="1.0" encoding="UTF-8"?>
   <xrds:XRDS
     xmlns:xrds="xri://$xrds"
     xmlns:openid="http://openid.net/xmlns/1.0"
     xmlns="xri://$xrd*($v*2.0)">
     <XRD>
   
       <Service priority="0">
         <Type>http://openid.net/signon/1.0</Type>
         <URI>http://www.myopenid.com/server</URI>
         <openid:Delegate>http://xxxx.myopenid.com/</openid:Delegate>
       </Service>
   
     </XRD>
   </xrds:XRDS>
   

3. 見れば判るとおり、<Service>要素で対応する識別プロトコルを定義しています。 属性priorityはServiceを複数定義した際の優先度。小さいものほど優先されます。
4. 子要素の<Type>は必須。この要素で、対応する識別プロトコルやそのバージョンを一意に識別します。
   OpenIDなら現状、ここの値はhttp://openid.net/signon/1.0、TypeKeyならhttp://www.sixapart.com/typekey/sso/1.0、LIDのVer.2.0ならhttp://lid.netmesh.org/sso/2.0てな具合です。
5. 子要素の<URI>は、識別サーバのエンドポイントのURIを指定しますが、省略すれば識別URLの値が設定されます。よって、識別URLと識別サーバのエンドポイントが等しい、（Delegationを行わない場合の）LIDや、非分散型なので何を設定してもエンドポイントは一意なTypeKey等では設定不要ですが、OpenIDでは必須です。
6. 以上のYADISの持つ要素以外に、識別プロトコルによっては追加の要素が必要になる場合があります。
   その場合はプロトコル毎の別名前空間を準備し、それにより修飾された要素で必要事項を設定します。
   この名前空間は、OpenIDならhttp://openid.net/xmlns/1.0、TypeKeyならhttp://www.sixapart.com/typekey/xmlns/1.0といった形になるようです。
   このような拡張要素の例としては、OpenIDの場合、Delegation仕様を用いているために識別URLとエンドポイントの理解できる元識別URLが異なる場合、元識別URLの方をOpenID名前空間で修飾されたDelegate要素で設定してやる必要があります。
   同様に、TypeKeyの場合、ユーザ名を指定する、TypeKey名前空間で修飾されたMemberName要素が必要になります。

という感じになります。

この仕様の利点としては、最初に挙げた異なる識別プロトコルの運用共通化というのも一つなのですが、他にもいくつか挙げられると思います。

1. LID等、Delegation（あるURLが識別されればこのURLも識別される、という芋づる設定を通じて、実際にエンドポイントが識別するURLと別のURLでも識別できるようにすること）の概念を持っていない（っぽい）仕様でも、原理的にDelegationを実現できること。
   LID自身はDelegation仕様を持たないようなので、「あるURLが識別されればこのURLも識別されたとみなす」部分の作りこみは自分で作ることが必要になりますが…。
   まあそれを言い出すとYADISを扱えるAPIはまだ整備されてないので、全部一緒ですけど。
2. Serviceを複数定義できること。
   これにより、一時的に識別サーバが落ちていたとしても、別のサーバで識別できるので可用性が高まる他、同じ識別プロトコルだけでなく別の識別プロトコルの設定も並列して書けるので、例えば識別クライアント側が「OpenIDは信用できない、TypeKeyで識別できるユーザしか受け付けない」という考えを持っていても、YADIS対応のURLで同一ユーザのOpenIDとTypeKeyのアカウントが集約されるので、ユーザ側は同じ識別URLでログインできることになります。
   また別例として、OpenID等でそのオープン性が災いして、どこかのOpenIDサーバが個人情報漏れを起こして信頼できなくなった、とした場合、識別クライアント側が一斉にその識別サーバでの識別を拒否したとしても、ユーザ側はYADISに代替の別サーバを登録しておけばさえ、ユーザは識別サーバの置き換え等をすることなくこれまで通り識別サービスの恩恵を受ける事ができます。
   リッチにいろんな識別サービスの設定を設定しまくったYADIS文書のサンプルは、NetMeshのYADISエリアにある、このサンプルを見てみてください。
3. いろいろなサービスのアカウントが集約されるので、複数サービス間の機能の相互運用の架け橋になりうる。
   現在、例えばはてなとMixi、TypeKeyで例をとると、はてなのkokogikoアカウントとTypeKeyのkokogikoアカウント、Mixiの119403が同一人物だって事はシステム的には判らないわけですが、将来、それらのサービスがOpenIDや、そうでなくてもTypeKeyのような独自形式であってもオープン識別手段を提供し、さらにYADISにも対応すれば（名前空間とか定義するだけですが）、YADISを通じて同じ人だと判るようになるわけです。
   そうすると、これまで色々なサービスというと各サービスの物理境界で分断されてしまっていたわけですが、その間を橋渡しするような機能の実装も可能になり、実質的にバラバラ個々のサービス、というのではなく、インターネット全体が識別URLで識別される個人に対し、一貫したサービスをワンストップチャネルで提供するような事も実現できるようになるわけです。
   SNSなら私がずっと言ってきたSNSのオープン化も、実現できるようになる。

と言った感じでしょうか。

しばらく注目の仕様だと思います。