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

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

Mobile OpenID を考える

日本の特殊なモバイル事情を考慮して、Mobile での OpenID が実現可能かどうかを探ってみます

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

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

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

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

技術的な制約

URL の最大長問題

Cookie サポート

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

デバイスとしての制約

さすがに URL の手打ちとか無いよね？ｗ

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

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 を想定すべき

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 を想定すべき

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

実際に試してみる

pibb に myopenid で実験 (using SREG)

checkid_setup -> 567 byte

id_res -> 921 byte

checkid_immediate -> 430 byte

Mobile OpenID 終了のお知らせ

本当にありがとうございました

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 でしか受け取れない クマッター＞＜

安西先生曰く

諦めたらそこで試合終了ですよ

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

冷静に考えよう

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 でしか受け取れない

クマッター＞＜

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

POST 時の Content-Body の制約

http://mobilehacker.g.hatena.ne.jp/ziguzagu/20070919/1190169316

id:ziguzagu++

ミニマムは DoCoMo PDC の 5KB なので余裕

Indirect Communication 時のレスポンスのみ未解決

id_res で必須になってるパラメータが多い

もうだめか？

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

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

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

id_res ってそもそも

認証結果をクエリパラメータに付与して return_to URL にリダイレクトしてくること

認証結果はどうだった？ (openid.mode=id_res)

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

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

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

署名したキー (openid.signed)

署名 (openid.sig)

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

何が重要なのか

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

アサーションの検証を再考

OpenID Authentication 2.0 の 11. Verifying Assertion を今一度確認

return_to URL が一致するか

ディスカバリしたデータと一致するか

重複した response_nonce でないか

署名が一致するか

最初の二つはわりとなくてもいいのではないか

本質的な目的は何か

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

署名と nonce の確認だけ出来れば良いんじゃないか

署名検証は check_authentication をそもそも拡張すればどうにかなる？

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 のレスポンスで受け取ればいいんじゃないか

と言う訳で

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 のレスポンスで受け取ればいいんじゃないか

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

Cookie と携帯

DoCoMo はそもそも Cookie 使えない

au は secure 属性のあるなしで SSL/ 非 SSL で使い分けられるが、 secure 属性なしの Cookie の取り扱いに罠がある

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

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

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

携帯ウェブセキュリティ神話

提示されている IP アドレス帯以外からのアクセスはないはず

但し提示方法が http だったりするのに関しては今は考えない＾＾；

個体識別番号は全サイトに対して提供しているような状況

IP アドレス制約に加えると一意に特定の端末を認識出来るはず

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

使う値について

出来れば携帯端末ごとに割り振られる値より契約毎に割り振られる値が望ましい

i モード ID

EZ 番号

x-jphone-uid

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

また一般的には簡易ログインの判断基準となる

checkid_setup/checkid_immediate の際に OP 上でのログイン処理を簡略化できる

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

どんな世界が広がるか

PC の世界と携帯の世界が一つの Identity で繋がる

つなげられそうなこと

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

持ち運びたいプライベートな情報をシームレスに携帯に

あるいは決済だけモバイルで出来る枠組みだったり

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

問題になること

URL の最大長問題

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

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

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

個体識別番号 +IP

利便性を上げることが出来そうだが、 IP 帯の更新は絶対に忘れないこと

と言う訳で

モバイルでの OpenID は来年辺りに活発に議論したいななんて思ってたりします！