JICS2013レポート(3) 3/4午後 OpenID Summit
OpenID Foundationについて
- nat
- 1997年米国オレゴン州
- WGが仕様を作る
- AB/Connect WG
- Accont Chooser WG
- Backplane WG
- Specs Council: WGを設置していいかを審査する
- membership 300名くらい
- Board: 財務、戦略
- WGが仕様を作る
- OIDFメンバーの得
- 戦略に影響を与えられる
- 思想的なリーダーに接触して話を聞くことができる
OpenID Foundation
- Don Thibeau
- Identity Data Leverage
- 金融市場のレバレッジと比べてみよう
- データレバレッジ
- ツールとルール
- technology tools: open standards, protocols
- policy and rules: trusted systemがvalueを生みだすためにdriveする
- インターネットidentityの2つの組織
- OpenID Foundationと日本ブランチ
- protecting intellectual porperty, brand, trademarks
- OIX: Open Identity Exchange
- policyを決め、相互運用性を保証する
- OpenID Foundationと日本ブランチ
- Tools + Rules = Trust
- トラストフレームワークはデータレバレッジにおいて三者間の調停をする
- Policy makers, IdPs, RPs
- TFの例: クレジットカードシステム
- VISA
- pre-negociated tools + rules
- issuing bank - merchant bank
- cardholder - Merchant
- repeatability
- 効率のよいTFの働き → あらかじめ知ることができる
- 文書化と標準化、義務の強制
- 法的なきまりごと
- data subjects: data integrity
- RPs: assurance
- IdPs: risk reduction
- stakeholder requirements
- reliability, predictability : これら2つが基本
- interoperability: 技術的な標準、プロトコル → 複数サービスが情報の種類等をあらかじめ知ることができる
- security: must: セキュリティーへの平等なcontribution
- easy user interfaces
- cost effectiveness: レバレッジ活用のために効率化が必要
- risk reduction: ID盗用などのリスクをすべてのstakeholderが解決
- trancparency
- privacy-enhancing
- → design principlesに反映
- → 競合社をstakeholdersにかかえる中でdutyとpolicyを明らかにする
- トラストフレームワークはデータレバレッジにおいて三者間の調停をする
- building 信頼 in online identity
- tool + rulesができた後、shared notion of transparency
- 標準の開発において平等であること
- 価値創造
- 学認の例: 複数のstakeholder, 組織が新しい価値を開こうとしている
- 学認はtrust frameworkの日本における最初の挑戦であろう
- 議論のコンテキストは広い。WGが初期のインサイトをtoolsに入れる
- account chooserがUXを根本的に変える。backplaneではweb site運用者にまた違うaspectsをもたらす
- Google in London, Mountain View, Munichで対話が始まっている
- dataをunlockするための新しい方法
OpenID Connect
- nat, John Bradley
- OpenID Connect: OAuth2.0の上に乗せるidentity層
- identity = ある実体に対する属性の集合
- entity - attribute modelを理解
- 相手によってどの属性を見せるかを制御することによってidentityを見せている
- 男性は数個、女性はもっとたくさんのidを使い分けているw
- OAuthじゃダメなの?
- OAuthはアクセス許可プロトコルなのでidentityの概念は含まれていない
- aliceがcindyにbettyの情報アクセスを許可してもcindyはaliceではない
- OAuthはアクセス許可プロトコルなのでidentityの概念は含まれていない
- Signed Request vs Id Token
- 誰がいつ何の目的で認証を受けたのか
- OpenID Connect
- Interop中。始めるならいま
- OpenID Connect: 共同作業の産物
- MS, G, f, ebay, Y!, T, ...
- 週2回電話会議、大量のMLメッセージ
- OpenID 2.0との違い
- Simple Things Simple/Complex Things Possible
- Standard UserInfo for Simple "Connect" Ability だじゃれ
- 必要なところだけ取って使えばいい
- ゴール: すべてのプラットフォームで動く
- claimモデル
- 集合、分散、暗号
- 公開鍵で暗号化すると、特定読者にしか読めないようにできる
- SAMLとの違いとして
- パラメータをクレーム上に乗せることができる
- 18歳以上、クレジットステータスがOKなど
- 集約クレーム
- 従来の問題: 情報をひとつにまとめる必要があった
- Connect: ポインターを複数入れればよい
- シンプルクライアントは署名のこととか気にしなくていい
- Connect Interop
- 4th round
- 14 implementationsが参加
- 仕様が何を言っているのか合意できる
- ID Token
- JWT token representing logged-in session
- iss, user_id, aud, iat, exp, nonce
- claim requests
- scopes: openid, profile, email, address, phone
- UserInfo claims
- implicit flowの例 ブラウザ内のJSアプリ
- userinfo request にaccess_tokenを渡す
- Connect仕様のサブセット
- minimum
- dynamic: discovery + dynamic client registration
- complete: 集約・分散claim, セッション管理
- basic client profile
- シンプル、self-contained、web-server based RP
- implicit profile
- agent based, ブラウザ内のJavaScript clientなど
- messages & standard
- データフォーマット
- session management
- single logout機能: SAMLではうまく扱えなかった
- G+を妻から夫に切り換えたらRPも同期して切り換わるなど
- OAuth 2.0は完了
- 仕様のopen issues → すべて解決した
- webfingerを使うことを決定した
- related specs
- OAuth dynamic-registration
- User managed access
- risk
- IETF仕様への依存が少し残っている
Acconut Chooser
よ
- Federated Identity
- Account Chooser デモ
- Account Chooser for users
- ワンクリックでログイン可能
- 複数のIdPをツークリックで切り換え可能
- AC for Web sites
- ワンクリックサインナップ
- ナスカ問題なく正しいIdPを選択可能
- ID連携への移行がカンタン: だんだんと移行可能
- 間違ったIDでのログインが減る
- AC for 開発者
- 1. https://www.accountchooser.com/ac.js をインクルードしたらOK。これだけ
- IdPリストを送ってもよい
- 2. ac.jsがaccount-statusに情報をPOSTする
- email address, IdP, Photo URL, Display Name
- 3. account-statusから結果を返す。registered: true/false またはauthUrl
- 4. After signin update ac.js 取得した情報をac.jsに教える。通常は何も発生しないけどね
- とってもカンタン
- 1. https://www.accountchooser.com/ac.js をインクルードしたらOK。これだけ
- account chooserのセキュリティー
- ACの画面に行くと通常のWebサイトに見えるが、これはfakeである。リストされているアカウントの情報はHTML5のローカルストレージに記録されている。これらの情報はaccountchooser.comに送信されるわけではない
- Account Chooserは
- ID連携の最初のステップ
- ブラウザのHTML5 storageを使用。すべての情報はユーザーのPC内
- ワンクリックでログイン、ワンクリックで登録
Backplane Protocol
- Backplane
- trusted application間で情報共有するためのprotocol
- アプリウィジェットが複数のIdPからの情報を共有
- トラストモデルdriven
- Social Identity Can Make Apps Sticky
- janrainのsite admin: login widgetをつける
- OpenIDでログインできるようになる
- Backplaneサービスでこれが可能に
- Add activity stream appを画面につける: ゲーミフィケーションとか
- feedback widgetが他のサービスプロバイダ
- どうやってログインしているユーザーの情報を渡せるか
- integration challenges
- transport layerがない
- 実装がinconsistent
- security leaks
- ペイロードのセマンティクスが決まってなかったり
- custom developmentが必要
- backplaneで解決
- secure transport layer
- payload semantics
- plug'n'play
- speed the market
- how it works
- 1. publish event id/login
- 2. receive event as activity
- backplaneを使うとき
- アプリ間でデータを渡したいとき: id, activityなど
- consume profile data from IdPs, user id, profile, analysis, 3rd-partyシステムに知らせる
- example: NASDAQシステム, AA(American Airlines) Social Newsroom
- backplane-enabled apps
- app developers
- backplane v2 demo in janrain
- oppotunity
- simplify integration to share information btwn sites
- backplanex.com/japanに資料貼っとくからー
OpenID活用事例と最新動向
- 越川さん (楽天)
- Open Services Platform Section
- あんしん支払い、OpenID / OAuthなど
- Open Services Platform Section
- 楽天について
- 1997年創業、年商1兆円
- 楽天スーパーポイント → 会員データベース
- 渡辺さん
時間があまったのでQ&A
- DNSポイゾニングをしてac.jsを置きかえる攻撃に対してどうな対策をしているか
- BackplaneとOpenSocialの違いは?
- good question!
- trust frameworkでやる
その他
- 会場では各種のデモなどもありました。その中でTuliooのデモはなかなか面白かったです
- https://www.trulioo.com/
- facebookアカウントを実在する人間かフェイクのスパム用アカウントか判定してくれます
- 「このアカウントの現在のありようをフェイクするなら1000時間かかる」などと結果が出ます
- ホテルレビューサイトでヤラセ評価を検出するために活用しているとのことです
- クローリングした日記や写真などの活動を元に評価しているそうです。アジアの言語はどうやっているのかと聞いたのですが、難しいようですね
- この後の懇親会にも参加させていただきました
