#idcon7 レポート

6月25日にヤフー会議室で行われた第7回Identity Conferenceに行ってきました。
ディープな話題を中心にする、という方針だそうで、
=natさんのブログなどで予習していってぎりぎりついていけた感じでした。

懇親会も楽しかったし美味しかったです。idconはディープな方向へ特化して、もっと裾野を広げるための入門編のような勉強会は別枠にするとよいのでは、という話でした。
酒の席で出たアイディアですが、国民に広くディジタルアイデンティティーを理解してもらうために、マンガとか使って勉強できる教材があるといいねーとか、絵をかいてくれる人募集しようとか。

以下、スライドは後で公開されると信じてQ&Aを中心にメモを貼ります。

OAuth 2.0仕様紹介

  • 伊東 諒さん =ritou, @ritou
  • まとめると、
    • 実装がかんたんに
      • 署名なし
  • 気になるところ (by @ritou)
  • Level of Assurance
    • クライアント詐称できちゃうんじゃないの? → レベル0
    • type: web_server, user_agentのどっちで取得したトークンかによって許可レベルを変えるなどが必要
  • refresh tokenのclient secretなしでどーすんだ?
  • ドラフト9で最後にでかい修正が入る予定
    • extensionとか、はやくして

OpenID Artifact Binding/Contract eXchange

  • 崎村夏彦さん =nat @_nat
  • まとめると
    • request file (RF), authorization assertion (AA)をJSON形式で作り、そのURLをRP/OP間でやりとり
    • JSONなのでmagic signatureで署名可能
    • CXの話は正直ついていけませんでした。復習しよう
  • Q/A
    • v.Nextと同じもの?
      • とは限らない。Connectの方が先になりそう
    • multi serverでデータを複数RPに渡り歩かせるときにどう聞けばいいの?
      • CXを使っていれば、DS1からDS2へ、とか記述することができる
        • proposalの中に書いておく。データ加工方法なども
        • encryptionはDSごとに行う
    • public keyを使っているが、鍵のライフサイクルはどうなっている?(nahi)
      • あまり議論していない。
      • 最初の配布はproposalの中に入れるが、revokeは考えられていない
      • trustの問題はスコープ外としている: OPの鍵はout of boundでやりとりしてください
      • TLSを使う前提だと結局そこがややこしくなってしまう(nahi)
        • SSLがあればpubkey encryptionでLoA2までいける
      • タイムスタンプを打った瞬間にPKIやってるのと同じになってしまうのでは(nahi)

Twitter OAuth

  • 真武信和さん @nov
  • TwitterによるOAuth拡張2件
    • OAuth Echo
      • クライアントからtwitpicへ写真を送ると、twitpicがtwitterにツイートしたい
      • クライアント: X-OAuth-Payloadで署名の範囲を入れる
      • twitpic: X-OAuth-Append-Payloadで追加したパラメータの署名の範囲を入れる
      • twitter上にはまだ実装されていない
      • http://j.mp/raffi_echo2
    • OAuth for Open Source(仮名)
  • Q&A
    • consumer keyを悪用されて、詐称されるのでは?
      • 最初のキーはあまり意味がない
      • key exchangeで得たckはユーザー別なので、悪いやつがいたらそれだけを殺せばいい
    • open sourceの作者を守るための仕組みだよねー

HTTP Mutual Authentication protocol proposal

  • 井奥さん@Y!
  • 林達也さん@レピダム
  • PAKEを使ったパスワードベースの認証
  • ブラウザに組込のパスワード入力欄をアドレスバーの近くに配置
  • 「グリーンなら個人情報を入れてもいい」というリテラシーにしたい@高木センセイもなっとく!
  • Q&A
    • OpenIDの仕様とバッティングするところとは?
      • 最初の認証情報を登録するところ(ID,PASSWORDをサーバーに送る)の難しさが解決されていない
      • 結局SSLになっちゃうんじゃない?
      • いったん信頼した後、HTTPSには乗らない。認証したという情報を他で使うには?
      • IETFで活動していると、RFC化が中心になり、OpenIDとの連携の話がすすまない
    • (nahi)End2Endの保護なので、バッティングというよりは連携可能性の問題
    • パスワードの安全な配り方
      • 窓口で渡す
      • 郵便で送る
        • → SAMLの知見が生かされていない
    • SAMLはSSL証明書は高いからダメって言ってる
      • EV-SSLが要求されている
    • PKIが高い、という話だが、この話では途中で抜かれることを気にしてるよね? それならサーバーpublic keyでencryptionするようなプラグイン/extensionでやればいいんじゃないの?(nat)
      • プラグイン/extentionでやるのは意味がないというところが出発点
      • (nat)最初にパスワードを登録するサーバーは信頼してるはずだから、そのサーバーのpubkeyを保存すればいいんでない?
        • 最初のパスワード登録はちゃんとは考えられていない
    • どうしてブラウザのあの部分に?
      • ロケーションバーを絶対守る、というのがブラウザベンダーやユーザーの合意
      • その近くに

Y!からの宣伝

    • Y!Jもメールアドレスログインができるようになりました!

ということで、次回までにはもっと勉強しておこうと思います。