Mobile Openid

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    3 Favorites & 1 Group

    Mobile Openid - Presentation Transcript

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

    + zigorouzigorou, 2 years ago

    custom

    3269 views, 3 favs, 3 embeds more stats

    日本の携帯向けOpenIDの考察

    More info about this presentation

    © All Rights Reserved

    • Total Views 3269
      • 3179 on SlideShare
      • 90 from embeds
    • Comments 0
    • Favorites 3
    • Downloads 30
    Most viewed embeds
    • 65 views on http://dready.org
    • 24 views on http://okyuu.com
    • 1 views on http://static.grazr.com

    more

    All embeds
    • 65 views on http://dready.org
    • 24 views on http://okyuu.com
    • 1 views on http://static.grazr.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    Groups / Events