Considering  OpenID for Mobile (jp) Toru Yamaguchi id:ZIGOROu <zigorou@cpan.org>
アジェンダ <ul><li>Mobile OpenID を考える </li></ul><ul><ul><li>日本の特殊なモバイル事情を考慮して、Mobile での OpenID が実現可能かどうかを探ってみます </li></ul></ul>...
Mobile OpenID の前に <ul><li>Mobile OpenID  を考える前に携帯の制約と特徴について考える </li></ul><ul><ul><li>技術的な制約 </li></ul></ul><ul><ul><ul><li...
URL の最大長問題 (1) <ul><li>DoCoMo </li></ul><ul><ul><li>「全機種共通の画面を作成する場合の目安・基準」より </li></ul></ul><ul><ul><ul><li>http://www.nt...
URL の最大長問題 (2) <ul><li>実際に試してみる </li></ul><ul><ul><li>pibb  に  myopenid  で実験  (using SREG) </li></ul></ul><ul><ul><ul><li>...
URL の最大長問題 (3) <ul><li>安西先生曰く </li></ul><ul><ul><li>諦めたらそこで試合終了ですよ </li></ul></ul><ul><ul><ul><li>と言う訳でもう少し頑張る </li></ul><...
URL の最大長問題 (4) <ul><li>POST  時の  Content-Body  の制約 </li></ul><ul><ul><li>http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070...
URL の最大長問題 (5) <ul><li>id_res  の内訳  (key + val  のバイト数 ) </li></ul><ul><ul><li>openid.response_nonce : 47 </li></ul></ul><u...
URL の最大長問題 (6) <ul><li>id_res  ってそもそも </li></ul><ul><ul><li>認証結果をクエリパラメータに付与して  return_to URL  にリダイレクトしてくること </li></ul></u...
URL の最大長問題 (7) <ul><li>アサーションの検証を再考 </li></ul><ul><ul><li>OpenID Authentication 2.0  の  11. Verifying Assertion  を今一度確認 </...
URL の最大長問題 (8) <ul><li>と言う訳で </li></ul><ul><ul><li>mode, signed, sig, response_nonce  に  URL  を加えてみる </li></ul></ul><ul><u...
Cookie のサポート <ul><li>Cookie  と携帯  </li></ul><ul><ul><li>DoCoMo  はそもそも  Cookie  使えない </li></ul></ul><ul><ul><li>au  は  secu...
IP アドレス帯制約 + 個体識別番号 (1) <ul><li>携帯ウェブセキュリティ神話 </li></ul><ul><ul><li>提示されている  IP  アドレス帯以外からのアクセスはないはず </li></ul></ul><ul><u...
IP アドレス帯制約 + 個体識別番号 (2) <ul><li>使う値について </li></ul><ul><ul><li>出来れば携帯端末ごとに割り振られる値より契約毎に割り振られる値が望ましい </li></ul></ul><ul><ul>...
Mobile OpenID の世界 <ul><li>どんな世界が広がるか </li></ul><ul><ul><li>PC の世界と携帯の世界が一つの Identity で繋がる </li></ul></ul><ul><ul><li>つなげられ...
まとめ <ul><li>問題になること </li></ul><ul><ul><li>URL  の最大長問題 </li></ul></ul><ul><ul><ul><li>そもそも  URL  を短くする必要あり </li></ul></ul><...
Upcoming SlideShare
Loading in …5
×

Mobile Openid

21,737 views

Published on

日本の携帯向けOpenIDの考察

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
21,737
On SlideShare
0
From Embeds
0
Number of Embeds
273
Actions
Shares
0
Downloads
47
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Mobile Openid

  1. 1. Considering OpenID for Mobile (jp) Toru Yamaguchi id:ZIGOROu <zigorou@cpan.org>
  2. 2. アジェンダ <ul><li>Mobile OpenID を考える </li></ul><ul><ul><li>日本の特殊なモバイル事情を考慮して、Mobile での OpenID が実現可能かどうかを探ってみます </li></ul></ul><ul><ul><li>その際にプロトコルを弄る必要があるかどうかも考えてみます </li></ul></ul><ul><ul><li>またモバイルの特徴をユーザビリティなどに活かせないかも考えてみます </li></ul></ul>
  3. 3. Mobile OpenID の前に <ul><li>Mobile OpenID を考える前に携帯の制約と特徴について考える </li></ul><ul><ul><li>技術的な制約 </li></ul></ul><ul><ul><ul><li>URL の最大長問題 </li></ul></ul></ul><ul><ul><ul><li>Cookie サポート </li></ul></ul></ul><ul><ul><ul><li>IP アドレス帯制約+個体識別番号 </li></ul></ul></ul><ul><ul><li>デバイスとしての制約 </li></ul></ul><ul><ul><ul><li>さすがに URL の手打ちとか無いよね?w </li></ul></ul></ul><ul><ul><ul><li>ID/PW を入れるのもめんどくさそう </li></ul></ul></ul>
  4. 4. URL の最大長問題 (1) <ul><li>DoCoMo </li></ul><ul><ul><li>「全機種共通の画面を作成する場合の目安・基準」より </li></ul></ul><ul><ul><ul><li>http://www.nttdocomo.co.jp/service/imode/make/content/html/notice/standard/ </li></ul></ul></ul><ul><ul><ul><li>URL エンコード後の文字長は最大 512 バイト </li></ul></ul></ul><ul><li>au </li></ul><ul><ul><li>「オープンアプリ (Java) 」より </li></ul></ul><ul><ul><ul><li>http://www.au.kddi.com/ezfactory/tec/spec/openappli.html </li></ul></ul></ul><ul><ul><ul><li>最大 256 バイトの文字列で ascii のみ </li></ul></ul></ul><ul><ul><ul><li>オープンアプリ (Java) の制約なのでこの情報は不確かかも。 </li></ul></ul></ul><ul><li>Softbank </li></ul><ul><ul><li>「 WEB & NETWORK 技術資料・開発ツール」の「 HTML 編 - 2.5.8 URI の制限」より </li></ul></ul><ul><ul><ul><li>http://creation.mb.softbank.jp/doc_tool/web_doc_tool.html </li></ul></ul></ul><ul><ul><ul><li>概ね 1024 byte </li></ul></ul></ul><ul><li>つまり 256 バイト以下を想定しておく必要がありそう </li></ul><ul><ul><li>意外と少ない、、、大丈夫? </li></ul></ul><ul><ul><li>au はソース元が Java の話なので良くても 512 byte を想定すべき </li></ul></ul>
  5. 5. URL の最大長問題 (2) <ul><li>実際に試してみる </li></ul><ul><ul><li>pibb に myopenid で実験 (using SREG) </li></ul></ul><ul><ul><ul><li>checkid_setup -> 567 byte </li></ul></ul></ul><ul><ul><ul><li>id_res -> 921 byte </li></ul></ul></ul><ul><ul><ul><li>checkid_immediate -> 430 byte </li></ul></ul></ul><ul><ul><li>Mobile OpenID 終了のお知らせ </li></ul></ul><ul><ul><ul><li>本当にありがとうございました </li></ul></ul></ul>
  6. 6. URL の最大長問題 (3) <ul><li>安西先生曰く </li></ul><ul><ul><li>諦めたらそこで試合終了ですよ </li></ul></ul><ul><ul><ul><li>と言う訳でもう少し頑張る </li></ul></ul></ul><ul><li>冷静に考えよう </li></ul><ul><ul><li>UA を介した Indirect Communication は checkid_setup/checkid_immediate, id_res/setup_needed/cancel のみ </li></ul></ul><ul><ul><li>checkid_* は認証要求 </li></ul></ul><ul><ul><ul><li>つまりこの部分は GET or POST が可能 </li></ul></ul></ul><ul><ul><ul><li>POST にすれば URL にパラメータを含める必要がなくなる </li></ul></ul></ul><ul><ul><li>id_res/setup_needed/cancel は HTTP リダイレクトで来る認証応答 </li></ul></ul><ul><ul><ul><li>GET でしか受け取れない </li></ul></ul></ul><ul><ul><ul><li>クマッター>< </li></ul></ul></ul>
  7. 7. URL の最大長問題 (4) <ul><li>POST 時の Content-Body の制約 </li></ul><ul><ul><li>http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070919/1190169316 </li></ul></ul><ul><ul><li>id:ziguzagu++ </li></ul></ul><ul><ul><li>ミニマムは DoCoMo PDC の 5KB なので余裕 </li></ul></ul><ul><li>Indirect Communication 時のレスポンスのみ未解決 </li></ul><ul><ul><li>id_res で必須になってるパラメータが多い </li></ul></ul><ul><ul><li>もうだめか? </li></ul></ul>
  8. 8. URL の最大長問題 (5) <ul><li>id_res の内訳 (key + val のバイト数 ) </li></ul><ul><ul><li>openid.response_nonce : 47 </li></ul></ul><ul><ul><li>openid.ns.sreg : 51 </li></ul></ul><ul><ul><li>openid.mode : 17 </li></ul></ul><ul><ul><li>openid.sreg.nickname : 27 </li></ul></ul><ul><ul><li>openid.sreg.email : 42 </li></ul></ul><ul><ul><li>openid.claimed_id : 45 </li></ul></ul><ul><ul><li>openid.assoc_handle : 50 </li></ul></ul><ul><ul><li>token_url : 42 </li></ul></ul><ul><ul><li>openid.ns : 41 </li></ul></ul><ul><ul><li>openid.signed : 130 </li></ul></ul><ul><ul><li>openid.sig : 38 </li></ul></ul><ul><ul><li>openid.op_endpoint : 48 </li></ul></ul><ul><ul><li>openid.identity : 43 </li></ul></ul><ul><ul><li>openid.return_to : 107 </li></ul></ul><ul><li>URL, QUERY_STRING </li></ul><ul><ul><li>URL : 194 (? も含めて ) </li></ul></ul><ul><ul><li>QUERY_STRING : 728 </li></ul></ul>
  9. 9. URL の最大長問題 (6) <ul><li>id_res ってそもそも </li></ul><ul><ul><li>認証結果をクエリパラメータに付与して return_to URL にリダイレクトしてくること </li></ul></ul><ul><ul><ul><li>認証結果はどうだった? (openid.mode=id_res) </li></ul></ul></ul><ul><ul><ul><li>プロトコルバージョン (openid.ns) </li></ul></ul></ul><ul><ul><ul><li>このアサーションセッションに対する OP が発行する一意な値 (openid.response_nonce) </li></ul></ul></ul><ul><ul><ul><li>アソシエーションで使われた署名方式 (openid.assoc_handle) </li></ul></ul></ul><ul><ul><ul><li>署名したキー (openid.signed) </li></ul></ul></ul><ul><ul><ul><li>署名 (openid.sig) </li></ul></ul></ul><ul><ul><ul><li>それ以外は署名検証に必要なだけでそんな重要じゃない? </li></ul></ul></ul><ul><ul><li>何が重要なのか </li></ul></ul>
  10. 10. URL の最大長問題 (7) <ul><li>アサーションの検証を再考 </li></ul><ul><ul><li>OpenID Authentication 2.0 の 11. Verifying Assertion を今一度確認 </li></ul></ul><ul><ul><ul><li>return_to URL が一致するか </li></ul></ul></ul><ul><ul><ul><li>ディスカバリしたデータと一致するか </li></ul></ul></ul><ul><ul><ul><li>重複した response_nonce でないか </li></ul></ul></ul><ul><ul><ul><li>署名が一致するか </li></ul></ul></ul><ul><ul><li>最初の二つはわりとなくてもいいのではないか </li></ul></ul><ul><ul><li>本質的な目的は何か </li></ul></ul><ul><ul><ul><li>Indirect Communication によるメッセージ通信を鵜呑みに出来ないから検証するのが目的 </li></ul></ul></ul><ul><ul><ul><li>署名と nonce の確認だけ出来れば良いんじゃないか </li></ul></ul></ul><ul><ul><ul><li>署名検証は check_authentication をそもそも拡張すればどうにかなる? </li></ul></ul></ul>
  11. 11. URL の最大長問題 (8) <ul><li>と言う訳で </li></ul><ul><ul><li>mode, signed, sig, response_nonce に URL を加えてみる </li></ul></ul><ul><ul><ul><li>468 byte になる! </li></ul></ul></ul><ul><ul><ul><li>しかも良く考えたら OP 丸投げならば reponse_nonce と op_endpoint だけあれば良さそう </li></ul></ul></ul><ul><ul><ul><li>289 byte になる </li></ul></ul></ul><ul><li>結論 </li></ul><ul><ul><li>id_res を極力ミニマムにして、 response_nonce をキーにして Direct Communication で OP に問い合わせる枠組みがあればいい ( んじゃないか? ) </li></ul></ul><ul><ul><li>identity, claimed_id などのパラメータは OP への Direct Communication のレスポンスで受け取ればいいんじゃないか </li></ul></ul>
  12. 12. Cookie のサポート <ul><li>Cookie と携帯 </li></ul><ul><ul><li>DoCoMo はそもそも Cookie 使えない </li></ul></ul><ul><ul><li>au は secure 属性のあるなしで SSL/ 非 SSL で使い分けられるが、 secure 属性なしの Cookie の取り扱いに罠がある </li></ul></ul><ul><ul><li>Softbank は SSL 領域での Cookie に対して非 SSL からアクセス出来ない (secure 属性ありのような動作 ) </li></ul></ul><ul><ul><li>と言う訳で余り使えない技術 orz… </li></ul></ul>
  13. 13. IP アドレス帯制約 + 個体識別番号 (1) <ul><li>携帯ウェブセキュリティ神話 </li></ul><ul><ul><li>提示されている IP アドレス帯以外からのアクセスはないはず </li></ul></ul><ul><ul><ul><li>但し提示方法が http だったりするのに関しては今は考えない^^; </li></ul></ul></ul><ul><ul><li>個体識別番号は全サイトに対して提供しているような状況 </li></ul></ul><ul><ul><ul><li>IP アドレス制約に加えると一意に特定の端末を認識出来るはず </li></ul></ul></ul>
  14. 14. IP アドレス帯制約 + 個体識別番号 (2) <ul><li>使う値について </li></ul><ul><ul><li>出来れば携帯端末ごとに割り振られる値より契約毎に割り振られる値が望ましい </li></ul></ul><ul><ul><ul><li>i モード ID </li></ul></ul></ul><ul><ul><ul><li>EZ 番号 </li></ul></ul></ul><ul><ul><ul><li>x-jphone-uid </li></ul></ul></ul><ul><ul><li>Cookie 等で session_id を管理する変わりに用いる事が出来る </li></ul></ul><ul><ul><li>また一般的には簡易ログインの判断基準となる </li></ul></ul><ul><ul><ul><li>checkid_setup/checkid_immediate の際に OP 上でのログイン処理を簡略化できる </li></ul></ul></ul>
  15. 15. Mobile OpenID の世界 <ul><li>どんな世界が広がるか </li></ul><ul><ul><li>PC の世界と携帯の世界が一つの Identity で繋がる </li></ul></ul><ul><ul><li>つなげられそうなこと </li></ul></ul><ul><ul><ul><li>PC サイトの方が当たり前のように便利だが、モバイルの方が便利なものにつなげたい </li></ul></ul></ul><ul><ul><ul><ul><li>持ち運びたいプライベートな情報をシームレスに携帯に </li></ul></ul></ul></ul><ul><ul><ul><ul><li>あるいは決済だけモバイルで出来る枠組みだったり </li></ul></ul></ul></ul>
  16. 16. まとめ <ul><li>問題になること </li></ul><ul><ul><li>URL の最大長問題 </li></ul></ul><ul><ul><ul><li>そもそも URL を短くする必要あり </li></ul></ul></ul><ul><ul><ul><li>それでもはみ出る可能性があるのでプロトコルに手を加えないと出来ない </li></ul></ul></ul><ul><ul><ul><ul><li>Auth 2.1 での =nat さんに期待w </li></ul></ul></ul></ul><ul><ul><li>個体識別番号 +IP </li></ul></ul><ul><ul><ul><li>利便性を上げることが出来そうだが、 IP 帯の更新は絶対に忘れないこと </li></ul></ul></ul><ul><li>と言う訳で </li></ul><ul><ul><li>モバイルでの OpenID は来年辺りに活発に議論したいななんて思ってたりします! </li></ul></ul>

×