日本の携帯向けOpenIDの考察

1. Considering OpenID for Mobile (jp) Toru Yamaguchi id:ZIGOROu <zigorou@cpan.org>

2. アジェンダ Mobile OpenID を考える 日本の特殊なモバイル事情を考慮して、Mobile での OpenID が実現可能かどうかを探ってみます その際にプロトコルを弄る必要があるかどうかも考えてみます またモバイルの特徴をユーザビリティなどに活かせないかも考えてみます

3. Mobile OpenID の前に Mobile OpenID を考える前に携帯の制約と特徴について考える 技術的な制約 URL の最大長問題 Cookie サポート IP アドレス帯制約＋個体識別番号 デバイスとしての制約 さすがに URL の手打ちとか無いよね？ｗ ID/PW を入れるのもめんどくさそう

4. URL の最大長問題 (1) DoCoMo 「全機種共通の画面を作成する場合の目安・基準」より http://www.nttdocomo.co.jp/service/imode/make/content/html/notice/standard/ URL エンコード後の文字長は最大 512 バイト au 「オープンアプリ (Java) 」より http://www.au.kddi.com/ezfactory/tec/spec/openappli.html 最大 256 バイトの文字列で ascii のみ オープンアプリ (Java) の制約なのでこの情報は不確かかも。 Softbank 「 WEB & NETWORK 技術資料・開発ツール」の「 HTML 編 - 2.5.8 URI の制限」より http://creation.mb.softbank.jp/doc_tool/web_doc_tool.html 概ね 1024 byte つまり 256 バイト以下を想定しておく必要がありそう 意外と少ない、、、大丈夫？ au はソース元が Java の話なので良くても 512 byte を想定すべき

5. URL の最大長問題 (2) 実際に試してみる pibb に myopenid で実験 (using SREG) checkid_setup -> 567 byte id_res -> 921 byte checkid_immediate -> 430 byte Mobile OpenID 終了のお知らせ 本当にありがとうございました

6. URL の最大長問題 (3) 安西先生曰く 諦めたらそこで試合終了ですよ と言う訳でもう少し頑張る 冷静に考えよう UA を介した Indirect Communication は checkid_setup/checkid_immediate, id_res/setup_needed/cancel のみ checkid_* は認証要求 つまりこの部分は GET or POST が可能 POST にすれば URL にパラメータを含める必要がなくなる id_res/setup_needed/cancel は HTTP リダイレクトで来る認証応答 GET でしか受け取れない クマッター＞＜

7. URL の最大長問題 (4) POST 時の Content-Body の制約 http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070919/1190169316 id:ziguzagu++ ミニマムは DoCoMo PDC の 5KB なので余裕 Indirect Communication 時のレスポンスのみ未解決 id_res で必須になってるパラメータが多い もうだめか？

8. URL の最大長問題 (5) id_res の内訳 (key + val のバイト数 ) openid.response_nonce : 47 openid.ns.sreg : 51 openid.mode : 17 openid.sreg.nickname : 27 openid.sreg.email : 42 openid.claimed_id : 45 openid.assoc_handle : 50 token_url : 42 openid.ns : 41 openid.signed : 130 openid.sig : 38 openid.op_endpoint : 48 openid.identity : 43 openid.return_to : 107 URL, QUERY_STRING URL : 194 (? も含めて ) QUERY_STRING : 728

9. URL の最大長問題 (6) id_res ってそもそも 認証結果をクエリパラメータに付与して return_to URL にリダイレクトしてくること 認証結果はどうだった？ (openid.mode=id_res) プロトコルバージョン (openid.ns) このアサーションセッションに対する OP が発行する一意な値 (openid.response_nonce) アソシエーションで使われた署名方式 (openid.assoc_handle) 署名したキー (openid.signed) 署名 (openid.sig) それ以外は署名検証に必要なだけでそんな重要じゃない？ 何が重要なのか

10. URL の最大長問題 (7) アサーションの検証を再考 OpenID Authentication 2.0 の 11. Verifying Assertion を今一度確認 return_to URL が一致するか ディスカバリしたデータと一致するか 重複した response_nonce でないか 署名が一致するか 最初の二つはわりとなくてもいいのではないか 本質的な目的は何か Indirect Communication によるメッセージ通信を鵜呑みに出来ないから検証するのが目的 署名と nonce の確認だけ出来れば良いんじゃないか 署名検証は check_authentication をそもそも拡張すればどうにかなる？

11. URL の最大長問題 (8) と言う訳で mode, signed, sig, response_nonce に URL を加えてみる 468 byte になる！ しかも良く考えたら OP 丸投げならば reponse_nonce と op_endpoint だけあれば良さそう 289 byte になる 結論 id_res を極力ミニマムにして、 response_nonce をキーにして Direct Communication で OP に問い合わせる枠組みがあればいい ( んじゃないか？ ) identity, claimed_id などのパラメータは OP への Direct Communication のレスポンスで受け取ればいいんじゃないか

12. Cookie のサポート Cookie と携帯 DoCoMo はそもそも Cookie 使えない au は secure 属性のあるなしで SSL/ 非 SSL で使い分けられるが、 secure 属性なしの Cookie の取り扱いに罠がある Softbank は SSL 領域での Cookie に対して非 SSL からアクセス出来ない (secure 属性ありのような動作 ) と言う訳で余り使えない技術 orz…

13. IP アドレス帯制約 + 個体識別番号 (1) 携帯ウェブセキュリティ神話 提示されている IP アドレス帯以外からのアクセスはないはず 但し提示方法が http だったりするのに関しては今は考えない＾＾； 個体識別番号は全サイトに対して提供しているような状況 IP アドレス制約に加えると一意に特定の端末を認識出来るはず

14. IP アドレス帯制約 + 個体識別番号 (2) 使う値について 出来れば携帯端末ごとに割り振られる値より契約毎に割り振られる値が望ましい i モード ID EZ 番号 x-jphone-uid Cookie 等で session_id を管理する変わりに用いる事が出来る また一般的には簡易ログインの判断基準となる checkid_setup/checkid_immediate の際に OP 上でのログイン処理を簡略化できる

15. Mobile OpenID の世界 どんな世界が広がるか PC の世界と携帯の世界が一つの Identity で繋がる つなげられそうなこと PC サイトの方が当たり前のように便利だが、モバイルの方が便利なものにつなげたい 持ち運びたいプライベートな情報をシームレスに携帯に あるいは決済だけモバイルで出来る枠組みだったり

16. まとめ 問題になること URL の最大長問題 そもそも URL を短くする必要あり それでもはみ出る可能性があるのでプロトコルに手を加えないと出来ない Auth 2.1 での =nat さんに期待ｗ 個体識別番号 +IP 利便性を上げることが出来そうだが、 IP 帯の更新は絶対に忘れないこと と言う訳で モバイルでの OpenID は来年辺りに活発に議論したいななんて思ってたりします！