日向夏特殊応援部隊

俺様向けメモ

OpenID Mobile Profile

OpenID Mobile

やっと specs のメーリングリストでもモバイル用の OpenID に関して議論が開始になったので、メモしておきます。

http://www.nabble.com/OpenID-Mobile-Profile--td21739618.html

ここがスレ一覧。

ここで言われてるのは、

  • URL の長さ
  • User Experience

の問題があると。あとは日本の携帯事情、特に端末ID絡みの説明とか。

日本の携帯サイトのありがちなシナリオについて。それと、

  1. First of all, the user needs to input an OpenID URI
  2. Due to the URL length restriction, RP will have to use POST, which means she will have to wait for the HTML form to be downloaded, then click on a button to submit it.
  3. She'll have to authenticate at the OP site, which we assume is no-op for the user assuming the OP uses the subscriber/device ID provided by the carrier.
  4. Upon successful authentication, the OP needs to again present at least a submit button to POST the results back to the RP.

URL の長さ問題を現状の仕様に違反せずにやった場合のシナリオ。RP initiated な場合は、POST するためにフォーム生成して、戻ってくる際にも POST の為にフォームの submit すると。

artifact 使えって話かな。

The current OpenID protocol doesn't require the RP to accept connections from the OP, which means that an RP could well be behind the firewall. It's a nice property to have. Using artifact binding for step 6 is fine, but doesn't step 4 require the OP to connect to the RP? I'm thinking something like a reverse artifact resolution:

  1. Upon discovering the OP endpoint, posts the request there.
  2. OP responds with a URL containing an artifact.
  3. RP redirects user to that URL at the OP
  4. OP resolves the artifact and finds the request in #1.

OP to RP な Direct Communication は Firewall 下に RP がある場合*1には非常に上手くマッチするんだけども、artifact binding やる場合には必要になるかもと。
僕もこの辺りはそれが無いと厳しいなーと思う。

分散認証として難しいんじゃないの？って反論。あとは OP にあらかじめ RP を登録して云々とか。

Sounds interesting, but I don't understand what you mean by a standard request format. Could you elaborate? Thanks.
同意ｗ 確かにもっといい方法って言ってるから興味はあるけど中身が分からない。 その回答。 とりあえず仕様に違反するけど、可能な限りパラメータを少なくして、またさらに必要なパラメータをあらかじめ OP に登録しておけばいいんじゃないのって話かな。 あらかじめ登録が妥当かどうかは分からないけど、僕はその点は RP Discovery でやればいいんじゃないかと思う。 その Discovery で、本来の仕様で明示するべきパラメータ、しかし本来やりたい事に関しては冗長なパラメータを押し込めてしまえば Indirect Communication で実際に使うパラメータを減らす事が出来る。 =nat さんが僕が spec ml に投稿出来ない*2から紹介してくれた。 で =nat さんの案は僕の考えてる事とほぼ同じだなぁ。
  1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.)
  2. RP posts this to the OP's artifact mode endpoint published in OP's XRD.
  3. OP issues a nonce as an "artifact" or "ticket".
  4. RP redirects the browser with this artifact.
  5. OP, receiving this artifact, reconstructs the OpenID message from the post received in step 2 above.
  6. Credentail presentation etc. happens as usual, and OP verifies the user's identity.
  7. OP creates a positive response and stores it with the artifact as the key.
  8. OP redirects the browser with the artifact to the RP.
  9. RP fetches the response created in 7. and examines it to authorize the access.
以下、オレオレ意訳。
  1. RP は他の拡張用も含めて普通にリクエスト用のデータを作ると
  2. RP は OP の XRD から artifact mode 用の endpoint を見つけて、その endpoint にリクエストデータを POST する
  3. OP は "artifact" なり "ticket" と言った一意な nonce を発行
  4. RP は "artifact" と共に UA を OP にリダイレクトさせる
  5. OP は "artifact" を受信したら同じ値を持つ事前に RP が POST したデータを元にリクエストを再構築すると
  6. OP はユーザーの identity を検証する
  7. OP はレスポンスを構築して、どっかに保存しとく。(key は当然 artifact)
  8. OP は artifact と共に UA を RP にリダイレクトさせると
  9. RP は artifact mode endpoint に対してレスポンスを取得すると
なるほど！すばらしい。既存の OpenID Authentication 2.0 には完全に違反するけど、これがやっぱ一番スマートだし、OP to RP な Direct Communication とか要らないのですっきりしてますね。 問題点として強いてあげるなら手続きが増える所と、やり取りの安全性の確保なのかなぁ。それと現状流通しているライブラリでは対応出来ないって点もか。

まとめ

雑なメモで申し訳ないけど、=nat さんの案ベースが一番良さそうな感触。僕もこの件に関しては仕様策定に積極的に絡んでいく所存でありますです。

追記1 (2009-02-01T21:34:45+09:00)

Mobile OpenID！=natさん案シーケンスは2でいきなり独自のDirect communicationが始まってるけどそうしないとURL長の問題はクリアできません。ということですね、現実的。
URL 長の問題は POST ベースにすれば解決出来るので、この案じゃなくても一応行けるはず。でも GET ベースでやろうと思った場合にはこういうやり方が一番スマートだよねと。 まぁそういう事です。

*1:イントラシステムなど

*2:登録してるメアドじゃないから弾かれてたｗ