natさんから連絡をいただいたので、読ませていただきました。
http://www.sakimura.org/specs/ab/
実装する側の観点として、8.1/8.2あたりのRequestの作り方/Responseのさばき方に注目しました。
EncryptionとSecurity Considerationについては自分にもう少し勉強が必要なのでまた後で・・・。
=== ここから ===
■ 5.3. Request Parameter File (rpf)
8.1のProfile1で利用する、RPがAuthN Request Parameterを保存しOPに参照させるファイルの内容の話ですね。
少し気になったのが、modeの指定です。
mode: "direct_checkid_setup" or "direct_checkid_immediate"
これは、rpfに書かなくても8.1.2でRPがつけるmodeパラメータで制御するほうがいいのではないかと思います。
RP側からみると、checkid_immediateで失敗してcheckid_setupで送りなおすとき、たいていは同じパラメータを送ろうとすると思います。
その場合、2つのrpfが必要になりますね。
OP側からみると、(Y!のように実装不十分で)checkid_immediate対応していない場合でもrpfの中身を見てから判断する必要があります。
全体の流れを無視してこの点だけを考えると、modeは以下のような感じが実装しやすいかなと思います。
- direct_art_req : 8.2でパラメータをpushし、artifactを取得する際のmode
- direct_art_res : RPがDirect Communicationでartifactを返す時につけるmode
- art_res : RPがIndirect Communicationでartifactを返す時につけるmode
- art_checkid_immediate : artifact bindingを使ったimmediateリクエスト
- art_checkid_setup : artifact bindingを使ったsetupリクエスト
- direct_assertion_req : 8.1/8.2のAssertionを要求するときに使う
- direct_assertion_res : 8.1/8.2のAssertionを応答するときに使う
と言いながら、ちょっと冗長ですかね。
■ 8. Protocol Profiles
Profileとしていくつかのパターンをサポート
1. Profile 1: Request made by RPF URL.
2. Profile 2: Request parameters being pushed.
3. Profile 3: Signed Response
4. Profile 4: Encrypted Response
5. Profile 5: Other Assertion Types
■ 8.1. Profile 1: Request made by RPF URL
- RPはAuthN Parameterをファイルに保存 or いつも同じ内容ならStaticなファイル作成とか
- AuthN Repuest : mode=art_req,rpfurlにそのURLを指定。URL作成ロジックがまっとうならガラケーでもいけそう(URL長の話)
- AuthN Response : mode=art_res,codeにArtifactの値
- RPはArtifactの値を用いてレスポンスを取得
Artifactを使ったAssertionの取得は一回きりですよ(MUST?)って制限があれば便利かもですね。
■ 8.2. Profile 2: Request parameters being pushed
- Request Artifact Request : RPはPOSTでパラメータ送る。OPは"ns", "mode", "code"を返す
- AuthN Requestはmodeとartifactをつける
- そのあとは8.1と同じ
artifactを送るパラメータはcodeではないのでしょうか?
あと、modeが共通なので、OPはartifactとrpfurlが両方あるときどう実装するの?って話になりそうです。
OP側がProfile1との区別がしやすいように、以下のような制限もあると嬉しいかもです。
=== ここまで ===
これなら携帯でも実装できそうですね。
8.1のようなシンプルなパターンなら、Staticはrpf+JSのみでも実装できそうです。
Facebook/twitter anywhereのような、OpenID用JS実装が出回るとOpenIDもより使えるものになりそうですね。
そういえば、今回のOpenIDと別途調べているOAuth 2.0と組み合わせ(hybrid)がどうなるかも気になりますね。