Identity Conference #4 2008-12-10

Considering Considering OpenID for Mobile (jp)OpenID for Mobile (jp)

Toru YamaguchiToru Yamaguchi

id:ZIGOROu <zigorou@cpan.org>id:ZIGOROu <zigorou@cpan.org>

アジェンダアジェンダ

Mobile OpenID Mobile OpenID を考えるを考える日本の特殊なモバイル事情を考慮して、日本の特殊なモバイル事情を考慮して、 Mobile Mobile

での での OpenID OpenID が実現可能かどうかを探ってみまが実現可能かどうかを探ってみますす

その際にプロトコルを弄る必要があるかどうかその際にプロトコルを弄る必要があるかどうかも考えてみますも考えてみます

またモバイルの特徴をユーザビリティなどに活またモバイルの特徴をユーザビリティなどに活かせないかも考えてみますかせないかも考えてみます

Mobile OpenID Mobile OpenID の前にの前に

Mobile OpenID Mobile OpenID を考える前に携帯の制約とを考える前に携帯の制約と特徴について考える特徴について考える 技術的な制約技術的な制約

URL URL の最大長問題の最大長問題

Cookie Cookie サポートサポート

IPIP アドレス帯制約＋個体識別番号アドレス帯制約＋個体識別番号

デバイスとしての制約デバイスとしての制約 さすがに さすがに URL URL の手打ちとか無いよね？ｗの手打ちとか無いよね？ｗ

ID/PW ID/PW を入れるのもめんどくさそうを入れるのもめんどくさそう

URL URL の最大長問題 の最大長問題 (1)(1)

DoCoMoDoCoMo 「全機種共通の画面を作成する場合の目安・基準」より「全機種共通の画面を作成する場合の目安・基準」より

http://www.nttdocomo.co.jp/service/imode/make/content/html/notice/standard/http://www.nttdocomo.co.jp/service/imode/make/content/html/notice/standard/

URL URL エンコード後の文字長は最大 エンコード後の文字長は最大 512 512 バイトバイト auau

「オープンアプリ 「オープンアプリ (Java)(Java) 」より 」より http://www.au.kddi.com/ezfactory/tec/spec/openappli.htmlhttp://www.au.kddi.com/ezfactory/tec/spec/openappli.html

最大 最大 256 256 バイトの文字列で バイトの文字列で ascii ascii のみのみ オープンアプリ オープンアプリ (Java) (Java) の制約なのでこの情報は不確かかも。の制約なのでこの情報は不確かかも。

SoftbankSoftbank 「「 WEB & NETWORK WEB & NETWORK 技術資料・開発ツール」の「技術資料・開発ツール」の「 HTMLHTML 編 編 - 2.5.8 URI - 2.5.8 URI のの

制限」より制限」より http://creation.mb.softbank.jp/doc_tool/web_doc_tool.htmlhttp://creation.mb.softbank.jp/doc_tool/web_doc_tool.html

概ね 概ね 1024 byte1024 byte つまり つまり 256 256 バイト以下を想定しておく必要がありそうバイト以下を想定しておく必要がありそう

意外と少ない、、、大丈夫？意外と少ない、、、大丈夫？ au au はソース元が はソース元が Java Java の話なので良くても の話なので良くても 512 byte 512 byte を想定すべきを想定すべき

URL URL の最大長問題 の最大長問題 (2)(2)

実際に試してみる実際に試してみる pibb pibb に に myopenid myopenid で実験 で実験 (using SREG)(using SREG)

checkid_setup -> checkid_setup -> 567567bytebyte

id_res -> id_res -> 921921bytebyte

checkid_immediate -> checkid_immediate -> 430430bytebyte

Mobile OpenID Mobile OpenID 終了のお知らせ終了のお知らせ 本当にありがとうございました本当にありがとうございました

URL URL の最大長問題 の最大長問題 (3)(3)

安西先生曰く安西先生曰く 諦めたらそこで試合終了ですよ諦めたらそこで試合終了ですよ

と言う訳でもう少し頑張ると言う訳でもう少し頑張る

冷静に考えよう冷静に考えよう UA UA を介した を介した Indirect Communication Indirect Communication は は checkid_setup/checkid_imcheckid_setup/checkid_im

mediate, id_res/setup_needed/cancel mediate, id_res/setup_needed/cancel のみのみ checkid_* checkid_* は認証要求は認証要求

つまりこの部分は つまりこの部分は GET or POST GET or POST が可能が可能 POST POST にすれば にすれば URL URL にパラメータを含める必要がなくなるにパラメータを含める必要がなくなる

id_res/setup_needed/cancel id_res/setup_needed/cancel は は HTTP HTTP リダイレクトで来る認証応リダイレクトで来る認証応答答 GET GET でしか受け取れないでしか受け取れない クマッター＞＜クマッター＞＜

URL URL の最大長問題 の最大長問題 (4)(4)

POST POST 時の 時の Content-Body Content-Body の制約の制約 http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070919/1190169316http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070919/1190169316

id:ziguzagu++id:ziguzagu++ ミニマムは ミニマムは DoCoMo PDC DoCoMo PDC の の 5KB 5KB なので余裕なので余裕

Indirect Communication Indirect Communication 時のレスポンスのみ時のレスポンスのみ未解決未解決 id_res id_res で必須になってるパラメータが多いで必須になってるパラメータが多い もうだめか？もうだめか？

URL URL の最大長問題 の最大長問題 (5)(5)

id_res id_res の内訳 の内訳 (key + val (key + val のバイト数のバイト数 )) openid.response_nonce : 47openid.response_nonce : 47 openid.ns.sreg : 51openid.ns.sreg : 51 openid.mode : 17openid.mode : 17 openid.sreg.nickname : 27openid.sreg.nickname : 27 openid.sreg.email : 42openid.sreg.email : 42 openid.claimed_id : 45openid.claimed_id : 45 openid.assoc_handle : 50openid.assoc_handle : 50 token_url : 42token_url : 42 openid.ns : 41openid.ns : 41 openid.signed : 130openid.signed : 130 openid.sig : 38openid.sig : 38 openid.op_endpoint : 48openid.op_endpoint : 48 openid.identity : 43openid.identity : 43 openid.return_to : 107openid.return_to : 107

URL, QUERY_STRINGURL, QUERY_STRING URL : 194 (? URL : 194 (? も含めても含めて )) QUERY_STRING : 728QUERY_STRING : 728

URL URL の最大長問題 の最大長問題 (6)(6)

id_res id_res ってそもそもってそもそも 認証結果をクエリパラメータに付与して 認証結果をクエリパラメータに付与して return_to URL return_to URL

にリダイレクトしてくることにリダイレクトしてくること 認証結果はどうだった？ 認証結果はどうだった？ (openid.mode=id_res)(openid.mode=id_res)

プロトコルバージョン プロトコルバージョン (openid.ns)(openid.ns)

このアサーションセッションに対する このアサーションセッションに対する OP OP が発行する一意なが発行する一意な値 値 (openid.response_nonce)(openid.response_nonce)

アソシエーションで使われた署名方式 アソシエーションで使われた署名方式 (openid.assoc_handle)(openid.assoc_handle)

署名したキー 署名したキー (openid.signed)(openid.signed)

署名 署名 (openid.sig)(openid.sig)

それ以外は署名検証に必要なだけでそんな重要じゃない？それ以外は署名検証に必要なだけでそんな重要じゃない？

何が重要なのか何が重要なのか

URL URL の最大長問題 の最大長問題 (7)(7)

アサーションの検証を再考アサーションの検証を再考 OpenID Authentication 2.0 OpenID Authentication 2.0 の の 11. Verifying Assertion 11. Verifying Assertion をを今一度確認今一度確認 return_to URL return_to URL が一致するかが一致するか ディスカバリしたデータと一致するかディスカバリしたデータと一致するか 重複した 重複した response_nonce response_nonce でないかでないか 署名が一致するか署名が一致するか

最初の二つはわりとなくてもいいのではないか最初の二つはわりとなくてもいいのではないか 本質的な目的は何か本質的な目的は何か

Indirect Communication Indirect Communication によるメッセージ通信を鵜呑みに出来によるメッセージ通信を鵜呑みに出来ないから検証するのが目的ないから検証するのが目的

署名と 署名と nonce nonce の確認だけ出来れば良いんじゃないかの確認だけ出来れば良いんじゃないか 署名検証は 署名検証は check_authentication check_authentication をそもそも拡張すればどうをそもそも拡張すればどう

にかなる？にかなる？

URL URL の最大長問題 の最大長問題 (8)(8)

と言う訳でと言う訳で mode, signed, sig, response_nonce mode, signed, sig, response_nonce に に URL URL を加えてみを加えてみ

るる 468468 byte byte になる！になる！ しかも良く考えたら しかも良く考えたら OP OP 丸投げならば 丸投げならば reponse_nonce reponse_nonce と と op_op_

endpoint endpoint だけあれば良さそうだけあれば良さそう 289289 byte byte になるになる

結論結論 id_res id_res を極力ミニマムにして、を極力ミニマムにして、 response_nonce response_nonce ををキーにして キーにして Direct Communication Direct Communication で で OP OP に問い合わせに問い合わせる枠組みがあればいいる枠組みがあればいい (( んじゃないか？んじゃないか？ ))

identity, claimed_id identity, claimed_id などのパラメータは などのパラメータは OP OP への への DirecDirect Communication t Communication のレスポンスで受け取ればいいんじゃのレスポンスで受け取ればいいんじゃないかないか

Cookie Cookie のサポートのサポート

Cookie Cookie と携帯 と携帯 DoCoMo DoCoMo はそもそも はそもそも Cookie Cookie 使えない使えない au au は は secure secure 属性のあるなしで 属性のあるなしで SSL/SSL/非非 SSL SSL

で使い分けられるが、で使い分けられるが、 secure secure 属性なしの 属性なしの CookiCookie e の取り扱いに罠があるの取り扱いに罠がある

Softbank Softbank は は SSL SSL 領域での 領域での Cookie Cookie に対して非 に対して非 SSL SSL からアクセス出来ない からアクセス出来ない (secure (secure 属性ありの属性ありのような動作ような動作 ))

と言う訳で余り使えない技術と言う訳で余り使えない技術 orz…orz…

IP IP アドレス帯制約 アドレス帯制約 + + 個体識別番号 個体識別番号 (1)(1)

携帯ウェブセキュリティ神話携帯ウェブセキュリティ神話 提示されている 提示されている IP IP アドレス帯以外からのアクアドレス帯以外からのアクセスはないはずセスはないはず 但し提示方法が 但し提示方法が http http だったりするのに関しては今だったりするのに関しては今

は考えない＾＾；は考えない＾＾；

個体識別番号は全サイトに対して提供している個体識別番号は全サイトに対して提供しているような状況ような状況 IP IP アドレス制約に加えると一意に特定の端末を認識アドレス制約に加えると一意に特定の端末を認識出来るはず出来るはず

IP IP アドレス帯制約 アドレス帯制約 + + 個体識別番号 個体識別番号 (2)(2)

使う値について使う値について 出来れば携帯端末ごとに割り振られる値より契出来れば携帯端末ごとに割り振られる値より契

約毎に割り振られる値が望ましい約毎に割り振られる値が望ましい iiモードモード IDID EZEZ 番号番号 x-jphone-uidx-jphone-uid

Cookie Cookie 等で 等で session_id session_id を管理する変わりに用を管理する変わりに用いる事が出来るいる事が出来る

また一般的には簡易ログインの判断基準となる また一般的には簡易ログインの判断基準となる checkid_setup/checkid_immediate checkid_setup/checkid_immediate の際に の際に OP OP 上で上で

のログイン処理を簡略化できるのログイン処理を簡略化できる

Mobile OpenID Mobile OpenID の世界の世界

どんな世界が広がるかどんな世界が広がるか PC PC の世界と携帯の世界が一つの の世界と携帯の世界が一つの Identity Identity でで

繋がる繋がる つなげられそうなことつなげられそうなこと

PC PC サイトの方が当たり前のように便利だが、モバサイトの方が当たり前のように便利だが、モバイルの方が便利なものにつなげたいイルの方が便利なものにつなげたい

– 持ち運びたいプライベートな情報をシームレスに携帯に持ち運びたいプライベートな情報をシームレスに携帯に– あるいは決済だけモバイルで出来る枠組みだったりあるいは決済だけモバイルで出来る枠組みだったり

まとめまとめ

問題になること問題になること URL URL の最大長問題の最大長問題

そもそも そもそも URL URL を短くする必要ありを短くする必要あり

それでもはみ出る可能性があるのでプロトコルに手を加えないそれでもはみ出る可能性があるのでプロトコルに手を加えないと出来ないと出来ない

– Auth 2.1 Auth 2.1 での での =nat =nat さんに期待ｗさんに期待ｗ

個体識別番号個体識別番号 +IP+IP 利便性を上げることが出来そうだが、利便性を上げることが出来そうだが、 IP IP 帯の更新は絶対に忘帯の更新は絶対に忘

れないことれないこと

と言う訳でと言う訳で モバイルでの モバイルでの OpenID OpenID は来年辺りに活発に議論したいは来年辺りに活発に議論したい

ななんて思ってたりします！ななんて思ってたりします！