idcon9レポート

7/8に渋谷mixi本社で行われたidcon9に行ってきました。発表者さんの資料へのリンクはATND記事にあります。

広くてキレイな会場です。参加者も前回、前々回よりぐっと増えました。

本題ではやっぱり話についていけなかった部分があるので、間違いもあると思いますがメモを貼っておきます。なんかおかしいぞ、と思ったら発表者さんの資料を確認してください〜。

自分がその場で理解できるところより上の話を聞くとやはり面白いです。idconはいつもいつもついていけてない感じですが、やっぱり面白い。懇親会も時間を忘れて話し込んじゃいました。

司会まつおかさんのあいさつ

idcon自体は3〜4年前に崎村さんとか工藤さんとか山口さんが勉強会としてスタート。 最初は10人。最近まで10人〜20人規模だった。 今回はmixiさんから会場のオファーがあったということで、規模を大きくしてみた。

  • 懇親会ではATNDで募集するとやっぱり人が来ますねー、とか、ある時点から急に参加者が増えるーとかの声が聞こえました。
    • ATNDだと参加者の歩留まりが読みにくいという話もありましたね

(1)「OAuth support on mixi Platform」@asyoulike007

  • 鈴木さん 入社半年ちょっと mixi Graph APIの開発。拍手を要求!
mixiのOAuth 2.0サポート
  • 2010年9月より、当時の最新ドラフト Draft10
  • 対応認可方式
    • Web Server Flow
    • Resource Owner Password Credentials
    • Client Credentials (Draft 12から入った仕様)
Web Server Flow
  • ユーザーがオーナーであるリソースが多い (プロフ、日記、写真……)
  • ユーザー認可によってどんな情報が出ていくのか理解しやすい
    • 認可画面がカワイイ
Resource Owner Password Credentials
  • どういうときに向いているか
    • ブラウザが使えない場合
    • 認可画面がカワイイのでクライアントの要望に応えられない場合もある
  • 事前にクライアント審査を行う → 信用のおけるところにのみ使わせている
Client Credentials
  • 開発予定
  • いま: リアルなソーシャルグラフを元に交流していただく
    • → 今後: マイミク以外も参照できるコンテンツを増やしていきたい
    • → アプリにも提供したいが、アプリの認証は行いたい
おまけ: User Agent Flow (Implicit Grant)
  • なぜ対応しないのか
  • secretが不要で、クライアントの正体が確かではない → 不安
  • クライアント毎の正確なアクセス状況も把握できない
    • 開発者へのデータ提供もできない
  • → ポリシーに合わない
mixi API SDK for Android
  • 2011/05 リリース。Android native app向けSDK
  • mixi アプリAPI、mixi Graph APIを簡単に利用可能
  • 認証認可をSDKがやる。トークンリフレッシュもやる。開発者はらくらく利用可能!
  • Androidアプリは逆コンパイルしてsecretを盗めちゃう → secretを使わない方法を考えた
secretを使わない認証認可
  • Android OSの機能でアプリのパッケージ署名というのがある。別のアプリから署名を取得可能
  • 事前にmixiへdeveloper登録するときに署名を登録 → 認証時に照合
  • フロー
    • 一般アプリからclient_idとscopeを渡す
      • mixiの公式アプリが認可画面を出してユーザー認可
      • 公式アプリがAndroid署名を照合
Q&A
  • Q: 公式アプリを母艦にすると、そこのセキュリティーに依存してしまう。公式アプリの開発はサービスとは独立して行われがちであって、セキュリティー上の信頼性としては不安があるのではないか
  • A: 公式アプリは開発が早いが、SDKチームと連携を密にして対応している。 セキュリティーを担保できるようにがんばっている
  • 懇親会にて、レピダム@lefさんから、 公式アプリ方式のフローは提案してみた方がいいとのコメント。 仕様を作っている人達は現場の苦労があまりわからないから、だそうです。 公式アプリでなくOSレイヤで仲介する場合も、同じモデルでいけそうですね。

(2)「OpenTransactって何？」@nov

たまにはお金の話をしよう
  • transactionのオープンスタンダートが必要
    • スタンダード不在 → オンライン決済のナスカ現象が発生
    • PayPalがうまくまとめてくれている
  • smartfm → iKnow! 有料化のときにpaypal対応した → 文書が大量
  • Paypal思ったらiPhoneだ、Google checkoutだ
    • 各社独自で歴史的な仕様がいろいろあって大変です
OpenTransactの登場
  • ペレ: RubyのOAuthライブラリを作ってる人
  • The world's simplest spec for financial transactionsをめざす
  • Bitcoinの再来じゃないのか? → そうじゃなくてtransactionを標準化するんだ
  • transactionの種類: 送金、物を買う、毎月払い
  • Asset: 基本的にはcurrencyのこと。通貨でなくてもいいんだけど
  • Asset Service: Assetと一対一に対応してAssetを発行するサービス
  • Transaction URL: ひとつのAssetを扱うRESTful API Endpoint
    • GET: ヒストリ取得、POST: transaction生成
  • 認証認可にはOAuthを使用
サンプル実装
  • PicoMoney.com: ペレ自身が実装。自分でcurrencyを定義できる
  • GitKarma.com: PicoMoneyで作ったcurrencyを使える
    • 特定のgitプロジェクトにcommit, pull requestしてくれた人に投げ錢
  • 遊んでみてやりたいこととやれることがわかってきた
    • 自分でも作ってみた: OAuth.jp Karma
      • karma.oauth.jp
      • github.com/nov/oauth.jp-karma
  • サンプル実装にはUndocumented Specもいろいろある
議論中の話題
  • OAuthのscope
    • single_payment / recurring_payment を定義しようとしている
    • amount, frequencyをどう表現するか議論中
  • Currency Exchange
    • @pelleb + @novで両替できる仕様を考えてみたい
    • サンプル実装中。OAuthとの連携もまだやってない。始まったばかり
  • OAuth 2.0 / OpenID Connect 連携
    • 来週くらいにOpenID Connect
まとめ
  • まとめるほど、仕様はないw
    • MLでは自分でcurrencyを作る流れのようだ
  • 情報源: Google Groups: opentransact, agile-banking
  • GitHub: @opentransact SMSで送金するサンプルなど
Q&A
  • Q: nat: 広めていくためにはtransactionやっている会社をリクルートして採用してもらわないといけないと思う。そんな活動は?
  • A: やってない
  • Q: セキュリティーモデルは?
  • A: OAuthベースで、とだけ決まっている。 いまホットなトピックはscope。 scopeをJSONで表現する方法を議論中

(3)「Identity over the Browser」@bkihara

  • 木原さん レピダム 会社人1年目
Identity in the Browser
  • W3Cのワークショップ 5月下旬
  • ブラウザベンダーが集まって次の課題を相談するミーティング
  • IETF流のハミングをした!
Hot Topics
  • Device ID
    • 動画を保護機能のあるデバイスのみで再生
    • 銀行ページを対タンパ性のみで表示したい
    • プライバシーの問題
    • ユーザー同意が難しい
  • Non-phishable Credentials
    • Phishingはもうかる(爆)
    • 認証は相互であるべき
    • ブラウザのchromeエリアにセキュアな認証が必要
      • HTTP Mutual Authとかが候補
    • IETF HTTP Auth WG (to appear)
  • Account Manager Standardization
    • アカウントマネージャーのデータ形式がバラバラ
    • ひとつのブラウザを使っているとロックインされるという問題
    • OSとの統合 → Android Honeycomb使うといいよ、とか
    • .net passportってどうなった?
  • Form Annotation for ID Input
    • HTML Form認証とパスワードマネージャーの相性がよくない
    • Input要素が何なのかを機械可読に
  • JavaScript Crypto API
    • JSで暗号を使いたいとき、外部からロードするのがふつう
    • ブラウザ本体のネイティブ実装をJSから使いたい
    • Mozilla wikiに提案があるらしい
  • Security Indicators
    • TLSの鍵アイコンがブラウザごとに何う
    • ChromeはEVでなくても緑色になる
    • 鍵の場所もバラバラ
    • モバイル端末ではどうやるの?
    • W3Cでリサーチしよう!
個人的に面白かったもの
  • NSTIC
    • ほぼ専用のセッション
    • W3Cとしては関わりたくないような空気
  • REST-GSS
    • HTTPにREST的なログイン、ログアウトをつけよう!
    • ログイン用URLへのPOSTでログイン
    • セッションURLのDELETEでログアウト
    • バックエンドにGSSを使う
  • Verified Email
    • IDとしてメアドを使うことは多い
    • 所持を証明すれば連携ログインが可能
    • ユーザーの鍵ペアにメールプロバイダが証明書をつける
    • nonceをつけて署名すればassertできる
雰囲気
  • Browserの会議だったので、何でもブラウザでやりたいという強い意志
  • セキュリティー、プライバシーの重視
  • W3CとIETFの協調
next steps
  • crypto API
  • Account manager stand
  • non-phishable credentials
  • security indicators
  • CA and browsers
Q&A
  • Q: 下道さん: W3CとIETFの絡みの具体的なグループはどのあたり?
  • A: どうもW3C側に新しいWGを作るための議題集めだったようだ。 public-identityというMLがW3Cにある

(4)「OpenID Connect最新仕様」@ritou

はじめに
  • 最近情報漏洩さわぎがあって、パスワード使い回しリスクが認識された
  • OpenID / OAuthへのネガティブな影響
    • あるOPのパスワードがもれたら、RP/Clientまで全部やられるよね!
    • 悪い評判が広まってるorz
  • 大きなところが安全なAuthZ/Nを提供してみんなのっかればいい
OpenIDとOAuth
  • 仕様が似ているから混ぜてみよう → OpenID OAuth Extension
    • なかなか難しかった。中途半端。流行らなかった
  • OpenID v.Next
    • Artifact Binding
  • OAuth 2.0
    • OAuth 2.0なかなか決まらない。specは更新されてはいる
  • OpenID Connect いきなり登場
    • ABと同じようにやればいいじゃん
    • ちゃんとスタンダードになるように進めよう!
OpenID Connect
  • AuthZ: OAuth 2.0 Base
  • 追加する
    • AuthN
    • Attribute trnasmission
    • Discovery: XML大変だった → JSONにしよう
    • Dynomic Client Registration
    • Session Management: IDトークンでかんたんに
Spec
  • ひとつの仕様に全部入っていると見る方は楽だが作る方は大変
OpenID Connect Core
  • 基本はOAuth 2.0にかぶせる
  • scopeには"openid"を含む
  • display: none, popup, mobile
  • prompt: login, consent, select_account
Discovery
  • 今だとOP Identifier Selectで始めたりする
  • OpenID Connect Discovery
    • Endpoint、メタデータをdiscovery
    • HTTPS + GETでdiscovery用のエンドポイントにアクセス → JSONで取得
  • Simple Web Discovery
  • GET /.well-known/simple-web-discovery?パラメータ……
Dynamic Client Registration
  • mixiなどにはclient登録が必要 → dynamicに
  • discoveryによりregistration endpointを取得
  • HTTP POSTでJSONオブジェクトを渡す、となっているが、JWTではないか?
    • nat: JWTですね
    • client_id, client_secret, expire_inがJSONでもらえる
HTTP Redirect Binding
  • OAuth 2.0のフローにOpenID Connectのパラメータをどう入れる
    • Query Parameters Method
    • Request Parameter Method
      • リクエストをJSONオブジェクトにする → JWTで文字列にしてパラメータで送る
      • 3文字のラベルとかwww
    • Request File Method
      • ファイルに書いてURLを送る: モバイルでも使えるように512byte以内!
  • JWT: JSONオブジェクトを文字列として表現
    • Base64Encした3つの部品をつなげる
    • jwt_header.jwt_payload.jwt_crypto
  • distributed なんとか
    • 外部ソースのendpointとアクセストークン
    • nat解説での「別のロッカーの鍵」に相当
Session Management
  • ID Tokenを返す
  • ID Token: JWSを用いた署名つきクレーム
    • Clientからログアウトを要求できる
  • Requestでid_tokenを指定するとResponseでid_tokenがもらえる
  • JSONでもらってもわからない人のためにCheck Sessionというendpointがある
仕様は日々更新中
Q&A
  • Q: 下道さん: 「再認証」とはどういう意味か?
  • A: OPにログインした状態でOAuthを始める場合、どれくらい時間が経っているかわからない。 RPからOPに対してログイン画面をもう一度出せと要求することができる仕様

(5)「SalesforceのID関連について」@mitsuhiro

  • Mitsuhiro Okamoto salesforce.com
  • 今日は話が高度すぎて理解できませんが〜
  • ある社でのID回りでどうやっているかについて話します〜
Salesforceとは
  • Google Appsに近いが、ユーザーIDは必ずどこかの組織に属する
SAML対応
  • SP, IdPの両方に対応している
    • jp.force.com でアカウント作成できる
  • なんでOpenIDじゃないの?
    • システム連携の現場ではSAMLは意外と使われている
  • Salesforceのアプリ設定パネルからIdPをGUIで設定できる
  • OpenIDも考えてはいるが、業界として使われるようになれば使うよ
OAuth対応
  • 動機: エンタープライズでもアンチパターンはやめよう
  • OAuth 1.0もやったが難しすぎた
  • OAuth 2.0 Draft 10を実装中
    • Web Server Flow / User Agent Flow をサポート
  • 設定画面から「リモートアクセス」としてアプリケーションを登録
    • consumer key/secretが生成される
      • 「コンシューマーの秘密」www
  • 使っている例: seesmic.com
  • Token usecase
まとめ
  • SAMLに対応してるよー
  • OAuth2対応してるよー
  • こんなとき使えます
    • 手頃に実験してみたい
    • OAuthつきのDBがほしい
    • プラットフォーム側の実装の参考に
Q&A
  • ブログに書かないでね、と言われたので書きません
  • でも#idconで検索すると話題になってるw

崎村さんのつなぎトーク

  • 11月30日ごろにOpenIDサミットの日本版をやります
  • アメリカからGoogleのEric、MSのMike、FBの人も来る
  • OpenID Connectではいろんなところで採用が始まるでしょう

(6)「番号制度と情報連携基盤について」@gjmtj

番号制度
  • 一体改革を支える制度・システム基盤
  • 公平性確保のために各国民の情報を正確に把握するために使う
    • サラリーマンは把握できているが、自営業の人はできてない
    • 不正受給を受けてる人がいる
  • プライバシー侵害のリスク → 最小限にしながら
  • 情報マッチング基盤として電子化が必要
情報マッチング基盤(情報連携基盤)の要件

1. 必要な情報連携ができること

  • 必ずしもICカードを必要としないこと
    • コスト対効果が出なくなるから
    • オプトインだけでなくオプトアウトもできるように

2. 国家による「個人に関わる情報」の集中管理をしえないこと
3. 情報保有機関の結託による不正な名寄せされないこと、それによるプライバシー侵害が出ないこと
4. 複数の機関からの情報漏洩によって第三者による名よせができないこと

プライバシーって何?
  • .Nat Zone参照: www.sakimura.org/2011/06/1124/
オーストリアセクトラルモデル
  • 分野毎に異なる番号を使用するが、番号間には関連性がある
    • PPID
  • データ連携時にデータ保護委員会を介することで、行政機関による不正な「名寄せ」を監視
    • セクターBの情報をセクターAが必要とする場合、Bの公開鍵で暗号化されたssPINをDSKが生成
  • 日本には単純に適用できない
    • オーストリアではセクター間の情報連携がまれ
    • 情報弱者がオプトインできないので、オプトアウト方式が必要
マイナンバー
  • 住民票コードを元にマイナンバーを発行して配布
  • 情報連携基盤にはIDコード(やはり住民票コードから作成)を出す
  • 情報保有機関にまたがる同じ人の情報に対するリンクコードを作成
    • リンクコードができたらマイナンバーは忘れる
  • 第三者機関による監視
なんでこんなにややこしいことすんの?

やる夫キターwww

  • フラット派: リンクコードとかじゃなくて番号でやればいいよ
  • セクトラル派: 要件に反するよねー
参考: 他の連携モデル
  • リンクコードがあっても番号が同じなら名寄せされちゃうじゃん
そもそも、共通番号である必要あるの?
  • 医療費の保険料返還を例として
  • 会社と社保の間でリンクコードを使って調べる
  • うまくないところ
    • 情報連携基盤を通さないで番号流通したらダメじゃん
    • 健保番号変えないとダメ
  • 解決方法
    • 分野ごとに番号が分かれていてもリンクコードで照合できればいい
    • 既存の番号を変えなくていい。新しいリンクコードとひも付ければいい
GWモデル v アクセストークンモデル
  • データ埋め込みリスク
  • p2pの連携テストが大変
  • 現状: 要件を定義してからでないと議論にならない
まとめ
  • 「番号制度」という名前になっているが非常に大きなIT投資
  • 内容はこれまで非公開で議論されていた。目的や論点がわかりにくい
  • #kokuminID で要ヲチですよ
Q&A
  • Q: 下道さん: みなさんに期待することは?
  • A: 議論をもり上げてほしい。重大な話だし将来の日本を左右する話なのにもり上がっていない。一部の人達だけの話になってしまっている。
  • Q: どこで?
  • A: #kokuminID
  • 高木センセのtweet: そうか、「やる夫で学ぶ番号制度」とか、「やる夫が番号制度に賛成するようです」とか、作ればいいんだな。
    • 期待しようw

以上です。