Hatena::ブログ(Diary)

Yet Another Hackadelic

2009-10-17

OpenSocial mobile のシーケンス

先日の idcon #6 にて発表した際に使ったシーケンスです。資料自体は大分グレーなので公開しませんw

例によってシーケンスのテンプレとして WebSequenceDiagrams - Draw sequence diagrams online in seconds こちらもご利用下さい。

2009-02-01 風邪引いた><

OpenID Mobile Profile

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

Error 404 Not Found

ここがスレ一覧。

ここで言われてるのは、

  • 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.
  5. Re: OpenID Mobile Profile?
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.
  5. Re: OpenID Mobile Profile?
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. Re: OpenID Mobile Profile?
同意w 確かにもっといい方法って言ってるから興味はあるけど中身が分からない。 その回答。 とりあえず仕様に違反するけど、可能な限りパラメータを少なくして、またさらに必要なパラメータをあらかじめ 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.
  10. Re: OpenID Mobile Profile?
以下、オレオレ意訳。
  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:登録してるメアドじゃないから弾かれてたw

2008-12-25

続・モバイル用の OpenID 考

ちょうど今日、有志でモバイル用 OpenID について議論してきたので気分転換に。

の続きです。

ニーズの話

OP 側の視点がメインです。但し一方的に OP だけにシナジーがあっても使われる訳が無いので RP にもメリットがあるといいねという感じで考察してみます。

SSO システムとしての OpenID

前はニーズについては触れなかった。認証の簡略化という意味で端末IDは現実的に使われていて、仮に異なるサービス間だとしてもその端末IDさえ何らかの形で共有出来れば同一IDでのSSOは実現出来る。

それが自社内の異なるコンテンツならばまったく問題は無いけど、異なる会社の異なるサービスでと言う場合には端末IDの共有でSSOと言う話は余り聞かない気がする。

まぁそれはそれ以上のシナジーが無いからなんだろうなと思う。

URL ベースのサービスディスカバリ

やはりこの点が一番期待出来る点なのかなと。

OP Local Identifier は URL であり、また通常その URL に大してディスカバリをかける事によって、その URL からたどれるサービスを利用出来る。

属性交換もそうだし、将来的には Portable Contacts なども利用出来るような世界になるんだろう。それ以外にも OP 上のプラットフォームを最大限利用した RP を作れば、ミニマムのウェブアプリ、特に作りたい物に特化して通知などは全部 OP のプラットフォーム任せなシステムとかありえるのかなと。

あるいは課金サービスもキャリアのそれに頼らず出来るようになれば、モバイル用の OpenID は存在意義があると思われる。

実装

まぁニーズに関しては確実に読めるのはキャリアより割りの良い課金サービスを強力な OP が提供するのが一番だとは思うんだけど、その点はまぁ置いといて。

実装は幾つか方法があるのかなと思います。

POST ベースの実装

一つは POST ベースにしてしまう方法。これは checkid_setup, checkid_immediate, id_res, cancel などの Indirect Communication の際に URL の最大長を超えてしまうような場合、フォームを利用した POST メソッドでやってしまうと言う物。

この場合は何も OpenID の仕様を弄る事無く実装は出来るけど、現実的に見ると今だとアクセスしただけで認証済みとなるような日本のモバイル事情を考えたらあり得ない実現方法だと言える。

端末IDをフルに利用し、尚且つ極力 Indirect Communication に本質的に不要なパラメータを排除し、Direct Communication で補うと言う形が最も現実的な解じゃないのかなと思われる。

OpenID Extension を定義する

日本のモバイル用に新しい Extension を定義するってのはありかもしれない。コンセプトとしては POST を使わずに Redirect ベースで。

今まで OpenID のコアな仕様を弄くらないと実現出来ないかなと思ってたんだけど、

  • checkid_setup or checkid_immediate の時に必要最小限のパラメータに Extension のパラメータつける
    • Extension では収まりきらないパラメータの RP 上での取得先を OP に提示
    • OP は上記の RP 上の URL に問い合わせて収まらなかったパラメータを取得する
  • id_res も必要最小限のパラメータに Extension の応答モードを付与
  • 必ず check_authentication して、その際に再び Extension のパラメータを付与して、id_res で収まらなかった値を取得

みたいな拡張を定義すればいいのかなと。

ちょっとライブラリ側の実装とか仕様上の制約がありそうなので、出来るかどうかは要検証。*1

この辺りは別途日を改めて詳しく検証してみる。

*1:と言うか今ちょっと調べたら id_res の制約がやはり厳しい。

2008-11-07

モバイル用の OpenID 考

いつか書こうと思って書いてなかったので。ちなみにモバイルサイト開発は不得手と言うか余り経験が無いので、突っ込み歓迎です。

またモバイルの世界に OpenID なんて(ry ってのは今は考えない。

特徴

Cookie と個体識別番号

RP サイドで、アサーションのレスポンスに対する中間者攻撃を防ぐ為に Cookie を事前に発行しておくなんていう対策を採る訳ですが、これは別にリクエスト時の個体識別番号と一致してれば良いので、モバイルでの場合に例外的な扱いはするものの技術的には Cookie が無くても問題は無さそう。

URL の最大長

こっちは引っかかる可能性がある。512バイトまでが共通して言える安全な長さだとすると、Indirect Communication 時に GET を用いる場合に引っかかる場合がありそうだ。

リクエスト時 (checkid_setup/checkid_immediate) の場合は、POST を使えば回避出来ると思うんだけど、レスポンス時は結構な量のパラメータがくっついてくるので、これが実用上問題になる可能性がある。

恐らく必要最低限のパラメータに加えて、RP から OP に対しての問い合わせ用に token を発行しておいて、その token を用いて check_authentication するとかそういう風にすれば良さそうな気がする。

まぁそんな訳で

日本の場合、携帯事情が特殊かと思うのでモバイル用ってのは考えてもいいんジャマイカと思うます。