Mobile Openid

50 %
50 %
Information about Mobile Openid
Technology

Published on December 11, 2008

Author: zigorou

Source: slideshare.net

Description

日本の携帯向けOpenIDの考察

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 の手打ちとか無いよね?w ID/PW を入れるのもめんどくさそう

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

技術的な制約

URL の最大長問題

Cookie サポート

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

デバイスとしての制約

さすがに URL の手打ちとか無いよね?w

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 さんに期待w 個体識別番号 +IP 利便性を上げることが出来そうだが、 IP 帯の更新は絶対に忘れないこと と言う訳で モバイルでの OpenID は来年辺りに活発に議論したいななんて思ってたりします!

問題になること

URL の最大長問題

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

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

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

個体識別番号 +IP

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

と言う訳で

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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

MODRNA WG | OpenID

About Charter Status Repository What is MODRNA WG? MODRNA (pronounced modernah) stands for Mobile Operator Discovery, Registration &
Read more

mobile | OpenID

The largest mobile operator in Japan, NTT docomo, which covers approximately 50% of Japanese population, started offering OpenID authentication on March 9.
Read more

OpenID Connect | Mobile Connect Developer Portal

What is OpenID Connect OpenID Connect is a simple identity layer on top of the existing OAuth 2.0 protocol, which allows service providers to authenticate ...
Read more

Mobile ID OpenID Connect - Swisscom

2 C1 - Public Swisscom (Schweiz) AG R Business Development M& Security M 4/5 2 Overview of OpenID Connect to Mobile ID SOAP Before entering into more ...
Read more

OpenID on a mobile/cell phone - Stack Overflow

I am trying to set up OpenID authentication on a mobile version of a site of mine (ASP.net MVC, dotnetopenid). When i tested it out earlier (Using WAP ...
Read more

Migrating from OpenID 2.0 to OpenID Connect | Google ...

Important: OpenID 2.0 is no longer supported. ... (OpenID Connect) authentication with access to additional Google desktop and mobile features.
Read more

OpenID.TEL OpenID authentication using your mobile ...

OpenID.TEL Mobile Web authentication using your mobile business identity over dot TEL
Read more

Modern Identity and APIs: Mobile, OpenID Connect, OAuth ...

Table of Contents. Analysis OAuth Versus OpenID Connect Application Usage of the OpenID Connect ID Token Mobile Platform Challenges and Developments
Read more

The OpenID mobile experience | Factory Joe

Absolutely. OpenID providers should be providing mobile-friendly URLs for services like M.gnolia to point to. Meanwhile, I logged in via my ClaimID account ...
Read more