OpenIDの認証プロトコルまとめ。
OpenIDの認証プロトコルには、認証の正当性をチェックする方法としてdumbモードとsmartモードの2種類、認証時の制御の流れをどうするかに関してsetupとimmediateの2種類、計4種類のバリエーションが存在するが、とりあえず分かりやすいdumb+setupモードから。
1) ユーザーが入力したID(URL)を受け取ると、OpenID対応サービスはまずそのURLを読み取りにいって、openidのタグを読み取って、delegateを処理したりごにょごにょごにょっとやって、最終的なID(URL)と認証サーバのURLを取得する。ここまではどのモードでも一緒。
2) (dumbモードでは)ここで対応サービスは、認証サーバのURLにID(URL)とか認証が成功した時に戻ってくるURL(対応サービス上の)とかを付加して、このURLにユーザーをリダイレクトする。
3) ユーザーがこのURLにアクセスすると認証サーバは、認証状態をチェックして、すでに認証済みならすぐ戻り先URLに認証情報をくっつけたURLにユーザーをリダイレクトする。そうでなければパスワードを要求したりとかして認証をセットアップして、最終的に認証が成功したらやっぱり戻り先URL＋認証情報にユーザーをリダイレクトする。失敗した時は戻り先URL＋cancelというURLにリダイレクトする(かもしれないし、しないかもしれない)
4) 認証が成功して戻り先URLに戻ってくると、対応サービスは認証情報を抜き出して、この正当性を認証サーバに問い合わせる。これに対して認証サーバがOKを返せば認証完了。あとはセッションIDを発行したりなにやかや、自サイト上で認証結果を保持するための処理を行う。
setupモードではなくimmediateモードだと、3の部分の処理が変わる。
3') ユーザーがこのURLにアクセスすると認証サーバは、認証状態をチェックして、すでに認証済みならすぐ戻り先URLに認証情報をくっつけたURLにユーザーをリダイレクトする。そうでなければ戻り先URLに「未認証」状態を示すフラグと、認証をセットアップするためのURL(ログイン・フォームのURLとか)を付加して、やはりすぐに戻り先URLにリダイレクトする。「未認証」状態を受け取った時にどうするかは対応サービスの勝手だが、まあ、普通はログイン・フォームだかなんだかにユーザーをリダイレクトすることになる。
一方、dumbモードとsmartモードでは認証情報の正当性の確認方法が違って、dumbモードの4の部分の処理はsmartモードには存在しない。smartモードの場合はこう：
1) dumbモードと同じ。
1.5) 対応サービスは認証サーバに問い合わせを行ない、認証用の「ハンドル」とHMAC-SHA1のキーのペアを受け取る。この通信は平文で行なうこともできるし、不安なら対応サービスはDH鍵交換による取得を認証サーバにリクエストすることもできる(が、認証サーバはそれをシカトして平文で返してくるかもしれない)
2') ユーザーをリダイレクトする際に、さっき受け取った「ハンドル」もパラメータにくっつける点がdumbモードと違う点。あとは一緒。
3) dumbモードと同じ。
4') 認証情報を受け取ったら、1.5で受け取ったHMACのキーを使ってその正当性をチェックする。正当なら認証完了。
OpenID自身がハッキリFAQで言ってるわけだけど、結局OpenIDってのは、「あるURLが認証したユーザーであること」を保証しているだけなんだよな。それが信用できるのかどうかは分からない。hotmailとかyahooメールのアドレスが信用できるなら信用してもいい、というレベル。yahooメールで思い出したけど、DomainKeysと良く似てるよな。Fromが詐称されていないことを保障してくれる、でも、そのFromを信用できるのかどうかについては何も語っていない。2chのトリップのようでもある。
「信用」を証明する手段は大雑把に言うと2つあって、一つはなんらかの「権威」に対して「徳」を証明して、その「権威」が皆に「コイツは信用してもいい」と保証する方法。もう一つはslashdotのカルマ・システムなり、(アングラな)ファイル交換における1:nルールみたいな、実際の行動で「徳」を示した記録の積み重ねで「コイツは信用してもいい」という評判を獲得する方法だ。
どっちの方式を取るにしても、まずidentityを確認する手段がないと「コイツは信用してもいい」の「コイツ」の部分が成立しないので、まずそこの部分がOpenIDによってdecentralizeされた形で実現される、その結果としてdecentralizeされた「信用」の証明の可能性が生まれる、という意味でOpenIDは有用なのかもしれない。
でも、それって結局Envelope Fromの正当性チェック＋RBLのレベルのSPAM対策が実現できるってだけの話であって、それでも日々SPAMを受け取るハメになるのと同様に、本当の問題は99.99%エロSPAMだと分かっていても、残り0.01%の本当の「素敵な出会い」の可能性を排除したくない人の性なのであって、そういう下心がある限り、結局のところSPAMを受け取り続けることには変わりないんでは？と思ってしまったり。
つか、思ってしまったりとかとぼけて言ってるけど、たぶん絶対にそういうことだよな。