Hatena::ブログ(Diary)

Yet Another Hackadelic

2008-03-31 腰痛が激化している件

OpenID Japanの翻訳プロジェクトについて

OpenID Japanのウェブサイトの叩き台が既に出来ています。*1

この中で翻訳プロジェクトと言う物があります。

まだかっちりした体制が出来ているわけではありませんが、OpenIDでログイン出来るMediaWikiを使ってやっていくようなので、皆さん是非参加して頂けるとありがたいです。

言うだけで何もやらないのもなんですので、僕の方でも手元で以前コツコツ拙訳していたYadis 1.0仕様を出来ている部分全てを投稿しておきました。

多分に間違えている点など多々あるかと思いますが、参考にして頂くもよし、ガンガン修正して頂くも良しです。

追記

色々と参加に当たってあれやこれやある方もおられると思いますので、

翻訳プロジェクト、まじめにやらにゃぁと思っております。 Authentication を皮切りとして、あと、IPRなんかもですよね...。 SVNでやれというと、結構敷居が高くなってしまうかと思い、 Wikiを建てました。 http://openid-japan.org/wiki/ 辞書も作りながらになりますが...。 協力者大募集です。ZIGOROuさんも、いかが? 「OpenID関連の和訳をCodeReposで始めました」のコメント欄

と言う事ですので、ある程度自由に参加していいのかなと判断してたりします。

で、現状少し問題と言うか面倒だなと思っているのが既存の仕様をMediaWiki形式にするのが面倒だなーと思ってたり。

*1=natさんら関係者の皆さんお疲れ様です。引き続き頑張って下さい!

2008-02-16 酒持ってこーい!-> 買ってきました

YadisとOpenIDの関係 (2) - Yadisプロトコル

d:id:ZIGOROu:20080214:1203011300の続きです。

Yadisプロトコルを知ろう

Yadis 1.0 (HTML) - The Yadis Protocolがテキストですが、仕様なので多少冗長なので要点だけ抑えていきましょう。

何のためにYadisプロトコルがあるのか

Relying Partyが、そのユーザーのYadis IDで使えるサービスを記述したYadis Resource Discriptorを得る為にあります。

もっと噛み砕いて言えばそのユーザーのYadis文書がどこにあるのかを調べる為の手続きです。

何故Yadis Resource Descriptorが必要なのか

与えられたYadis ID(それがURLならYadis URL)で使える認証サービスがどれなのかをRPが知る為にあります。ここで言う認証サービスはOpenIDだったりLIDだったりSAMLだったりします。

で、そもそもYadis Resource DescriptorってのはほとんどYadis文書(XRDS文書)と同じ意味です。(d:id:ZIGOROu:20080214:1203011300 を参照)

このYadis文書に、そのユーザーの認証を行えるサービスが複数記述出来たり、認証以外にもIDベースで使えるサービス(例えばプロフィール属性交換とか)があればそれを記載出来ます。

Yadisプロトコルの流れ

ざっくり言えば下記のようになります。

  • Yadis IDをユーザーがRPに教えます
  • RPはYadis IDで示されたURLにアクセスします

で、このYadis IDにアクセスするメソッド(GET/HEAD)で必要に応じて、最大2回追加のHTTPリクエストを行う必要があります。

最初のリクエスト

RPはユーザーから与えられたYadis URLに実際にアクセスします。

GETでもHEADでも構いません。

そのときのレスポンスにバリエーションがあって、

  • meta要素でhttp-equivを使ってx-xrds-locationを設定しているhtmlが返って来る
  • x-xrds-locationレスポンスヘッダを含んでいる
  • レスポンスヘッダのみで、x-xrds-locationレスポンスヘッダを含んでるか、content-typeがapplication/xrds+xmlの場合。あるいは両方
  • 文書のmimetypeがapplication/xrds+xmlであるもの

になります。

で、元々の目的はYadis文書を得る事だから最後のmimetypeがapplication/xrds+xmlの場合はGETでアクセスしてる場合は目的を達しているので、そこで終了になります。

それ以外の場合は、

  • x-xrds-locationが指定されてるなら、そこで指定されてるURL
  • content-typeがapplication/xrds+xmlでHEADでアクセスしてるか、レスポンスボディが無い場合は与えられたYadis URL

に対してそれぞれ再度GETリクエストを送る必要があります。

また最終的にapplication/xrds+xmlな文書が欲しい訳ですから、Acceptリクエストヘッダでapplication/xrds+xmlを追加指定しておけば、YadisのIdPはそれを解釈して直接XRDS文書を返してくれるかもしれません。*1

二番目のリクエスト

先に挙げた2パターンのリクエストを送るケースがあるのですが、元々のリクエストがHEADで、二番目のリクエストはGETに換えただけの場合で、x-xrds-locationが(レスポンスヘッダまたはmeta要素で)指定されている場合は改めて、そのURLにGETでアクセスしなければならない。

そのリクエストが3番目のリクエストです。

三番目のリクエスト

これはもうXRDS文書であることが保障されているはずなので、このリクエストに対するレスポンスが正しくXRDS文書であるならば、正常に終了と言う事になります。

どれをXRDS文書またはXRDS文書の所在とすべきかの優先順位
  • x-xrds-locationレスポンスヘッダで指定されてるURL
  • meta要素でx-xrds-locationが指定されてる場合
  • レスポンス本文がapplication/xrds+xmlの場合

の順番です。

OpenIDとYadisプロトコルの関わり

Yadis ID(Yadis URL)はOpenIDで言う所のClaimed Identifierと一致するケースがほとんどでしょう。

Claimed Identifierで表されたURL(またはXRI)は、何らかの形でXRDS文書を返すようにする方が、OpenID Authentication 2.0では優先されており、link要素でOP EndPoint URLを指定するのは小学生までな訳です。

Claimed IdentifierだろうがOP Identifierだろうが、XRDS文書を返した方が互換性の高い実装となると思います。

また他に何のサービスが使えるかをRPに教える事が出来ると言う点も大きいです。

link要素ベースの探索だと認証をする為だけの用途になってしまう訳ですね。

まとめ

Yadisプロトコルを実装するならHEADは使わない方が良いと思います。

GETで始めからアクセスしてれば最大2回のリクエストで済むからです。

また実装に当たっては、

  • Acceptヘッダを必ず見て、application/xrds+xmlが指定されていれば優先的にXRDS文書を返すようにする
  • そうでなければレスポンスヘッダにx-xrds-locationを指定する

のが綺麗な実装なのかなと思います。


次はXRDS文書の中身を書く予定です。

*1:と言うかIdPは、そう実装すべきですね。

2008-02-14 子供が熱出して大変なのに、id:tokuhiromに絡まれまくった件w

YadisとOpenIDの関係 (1) - Yadisの用語

OpenID Authentication 2.0から正式にXRIおよびYadis Protocolが仕様に盛り込まれました。

一度きちんと勉強したいと思っていたのでYadisについてまとめると共にOpenIDとどのように関連しているのかまとめたいと思います。

Yadisとは

Yadisの概要

こちらは本家What is Yadisが非常に簡潔に説明しています。

Given an identity URL and no other information, how do we know what protocol needs to be used to authenticate that user? Yadis is a service discovery system allowing relying parties (aka identity consumers or membersites) to determine automatically, without end-user intervention, the most appropriate protocol to use. What is Yadis

要約すると、与えられたIdentity URLから自動的に認証サービスを見つけ出すRelying Partyの為のプロトコルと言えます。

具体的な利用目的についても同じくWhat is Yadisから拝借して、

  1. Single sign-on across web sites
  2. Profile exchange and form filling
  3. Blog anti-spam
What is Yadis

とあるように、

  1. webサイトでのシングルサインオン
  2. プロフィール交換と投稿フォームでの値の自動埋め込み
  3. アンチスパム(対コメント等)

が主な用途であるとしています。この辺りは非常にOpenIDと近い概念だと言えます。

但し大きく異なるのはYadisはOpenIDのように認証サービスではなく、認証サービス及び他のIdentityベースのサービスをdiscoveryするだけのプロトコルであると言う点です。

Yadisの用語

Yadis 1.0 (HTML) - 3.1 Implementor Termsより拙訳ですが、

Yadis User
Yadis IDをIdentifierとして使用するエンティティです
Yadis IDA
ひとつ、ないしは複数のYadis Serviceと共に使われるIdentifierです。Yadis IDはURLのでも構いません。あるいはXRIのようにURLとして解決可能な他のIdentifierでも構いません。
Yadis URL
Yadis IDの事で、それがURLであったり、さもなければYadis IDが解決するURLです。Yadis URLはYadis Protocolの中でYadis Resource Descriptorの取得に使う事が出来ます。
Yadis Resource
Yadis Protocolを使って一つないしは複数のサービスの所在を提供するソフトウェアのプロセス(ないしはシステム)の事です。
Yadis Service
Yadis Resourceによって提供されるサービスです。
Yadis document
Yadis Resource Descriptorに含まれる文書です。
Yadis Resource Descriptor
Yadis IDを使う事が出来るサービスを識別するYadis documentの要素です。
Resource Descriptor URL
Yadis documentの所在を示すURLです。
Agent
partyの為に動作するソフトウェア(あるいはシステム)プロセスの事です。
Yadis User Agent
Yadis Userの為に動作するagentの事です。(例えば一般的なウェブブラウザです)
Relying Party
Relying Party Agentに対して責任を持ち、またそのAgentの動作の代わりになる団体です。Relying PartyはYadis Resourceによって提供されるサービスの上に成り立っています。特にYadis IDによって識別される個人に関連するサービスによって提供されるデータに依存しています。
Relying Party Agent
Yadis User Agentによって提供されるYadis IDを使う(そしてYadis IDを用いて利用出来るデータを使う)Agentによって果たされる役割の事です。Relying Party AgentはYadis Protocolを使ってYadis IDで利用出来るサービスを見つけ、それぞれの挙動に従い修正する事が出来ます。
RESTful
RESTのアーキテクチャスタイルを持っている事です。

と言った感じです。

一々用語が小難しく定義されていますが、

  1. Yadis ID(それがURLならYadis URLと言う)
  2. Yadis Resource Descriptor
  3. Yadis document
  4. Resource Discriptor URL

くらい頭に入っていれば大体理解出来ると思います。

次回予定

Yadis 1.0 (HTML) - The Yadis Protocolを扱う予定。(実は既に調べ終えてるんだけど)

その後にYadis 1.0 (HTML) - 7. The Yadis documentを取り扱って、OpenIDとの関わりを明らかにして行きたいと思います。

かしこ。