idcon#5 @ NTT musashino lab

1. idcon#5
Webブラウザハックと
アイデンティティWebサービス
について
Apr 10, 2009
株式会社マッシュマトリックス
冨田 慎一

2. はじめに
• idconでのプレゼン自体は初めてなので、自己
紹介
• id:shinichitomita
• twitter.com/stomita
• 会社やってます（株式会社マッシュマトリッ
クス）
• 企業向けマッシュアップのミドルウェア提
供／コンサルティングとか

3. 位置づけ
• アイデンティティ愛好家（自称）
『手に何も持たぬから̶̶̶̶空手』
『そう教えられてきたハズの両雄だった…』
『しかし̶̶̶』
『歩んだ日常があまりにも違っていた』
『その違いが̶̶̶』
『一方を空手家へ』
『もう一方を空手愛好家へと道を分けた』
餓狼伝 Vol.216 より
• 愛好家とプロフェッショナルの違い
• 背負ってたつものがないので、気楽にできる（重要）
• 裏を取る作業を怠るので、穴が多い（＝信頼感にかける）

4. 切り口
• テーマ：
• 軽量Webサービスとアイデンティティの融合
• アイデンティティWebサービスの企業内情報統合への利用（本
業に近い）
• ポリシー：
• できるだけ専門用語を使わない
• 仕様は必要なときしか見ない。そこはプロに任せる
• ブログ書くときはさすがにちょっと調べるが、付け焼き刃。
きっと間違ってたらだれか教えてくれるはず、という甘い期
待

5. 重要なこと
• アイデンティティWebサービスが市民権を得
た
• 少なくとも、デベロッパーには解放された
• プロトコルはどうあれ、Libertyがやりた
かった世界に近づいてきた
• 今新卒エンジニアだったら、絶対あそんで
る

6. 近代
• その昔、Liberty Allianceがあった
（もちろん今もある）
• 2000年新卒当時、Sunの下道さんとか
• 有名な航空券予約デモ
• これがほんとのWebサービスですか！
（単純な新卒脳を洗脳）

7. 現代
• Liberty => SAML は、当初の「インターネッ
トにおけるアイデンティティ連携」の主流か
らは外れてきたように思える
• しかしB2B、SaaS連携では着実に実績がある
• プライバシーなど仕様にもりこまれてるため、安心
• ファイアウォールをまたいだ連携
• Google Apps, Salesforce の２大SaaSがともに採用
• あまり人目に触れにくいのが残念なところ

8. Open Stack の勝因？
• サービス側主導で採用
• 今すぐに見えるものがある、というのは重要
• オープンソースコミュニティ
• 軽さ、とっつきやすさ、自由度
• たとえ無償で出しても、インストール＆セットアップに１日か
かるなら、コミュニティはスケールしない

9. OpenID の悩み
• ユーザビリティ低くね？
• 選択の自由なんかいらない、って人が多数
じゃない？
• 仕様は自由だが、運用は固定でもOK
• ホワイトリスト、「Yahooでログイン」ボタン
• ユーザはあまり標準仕様とかどうかとか気に
しない

10. プロプラへの回帰
• どうせ大人の事情で「ユーザが完全自由に選
択」なんてできないし、そもそもユーザがそ
れを望んでるかどうかが怪しい
• じゃあ今のところ独自の仕様でも別にいいよ
ね？（常人には危険な発想）
• そのかわり、もっと普及を促進するようなア
イディアを盛り込めないか（？）

11. Facebook Connect
• ポルシェ乗り回してVCから総スカン食らった
現マイクロソフト Dick Hardt、絶賛
• Facebook Connect - fatal blow for OpenID?
http://identity20.com/?p=151
• アイデンティティ・サイロを批判してたはず
なのに？（どうしたの？）

12. FBCのいいところ
• ログインが直感的
• 「Connect with Facebook」ボタン
• ポップアップで連携をユーザに確認
• I want sign in to Yelp, so keep me on the Yelp site
• OP側が小さい画面に最適化したプロンプト画面を提供
• inline frame での表示はユーザの邪魔をしないが、
もしかしたら昨今問題（クリックジャックとか）?
全部ウインドウポップアップになる？
• OpenID UXにノウハウ吸収される
• MySpace 等、既に Popup Experienceを実装
• OpenID UEX Summit (2009/02/10) @ facebook
• http://therealmccrea.com/2009/02/10/live-blogging-the-openid-
design-summit/

13. Google Friend Connect
• 「Facebook Connectの対抗馬」と喧伝され
る
• ソーシャルグラフの解放、流通を目指す
• 最初はウィジット型での提供だったので
FBCとの差異は多かった
• 今はAPIとして提供され、Facebook
Connect に近づいた

14. FBC、GFCの共通点
• Consumer側にサーバ実装が要らない！
• HTML+JavaScriptで完結
• Google Maps API
• ブログにスクリプトを貼付けるだけでFacebook/GFCの
サービスを利用できる
• ブラウザ拡張とはちがう、事前のインストール必要なし
• コピペでばらまき可能であることのスケーラビリティ、
ウィジット化
• 同様の試み（ブラウザのみでWebサービス接続）
• Google GData JS API (Google Account Auth AuthSub JS)
• GoogleカレンダーのプライベートカレンダーにJSのみでアクセス
できる

15. 技術（ハック）による克服点
• ブラウザ上でのクロスドメインコミュニケーショ
ンをどう実現するか
• 通常セキュリティ制約により通信できない => Hack
• IFRAME越しのフラグメント識別子通信
• window.postMessage (only for relatively modern
browsers)
• ユーザに同意させる仕組みはどうするか
• 認証トークンのやり取りはどうするか
• フラグメント識別子 => Cookie保存
• 署名は省く

16. 個人的見解
• 「HTML+JavaScriptのみ」で、参入敷居が下がるなら歓
迎。 開発者 = Code書き の式はどこまで壊せるか？
• 独自仕様は。。。
• でも実装にハックが多いので、標準仕様にするのは難しくないか？
• まずはプロプラ実装が可能性を示すのは、正常な進化である気がする
• アクティビティストリームへの吸い上げに有効
• FBやGoogleがFBC/GFCを出してる主な理由
• 情報アグリゲーション型の軽量マッシュアップにも有効
• 複雑なことをやろうとすると、サーバが絡むだろうから、
そうなるとあまりかわらないかも
• 日本は携帯対応でないと、という冷ややかな反応

17. OAuth XD JS Proxy
• OAuthプロテクトされたリソースを
HTML+JavaScriptから直接呼び出せるように変換
するプロキシサービス
• プロキシサービスは Google App Engine 上で稼働
• 同意や署名等はプロキシ側で実装ずみ
• クロスドメイン通信＝window.name + iframe fragment
identifier
• http://d.hatena.ne.jp/shinichitomita/
20090401/1238581497
• http://xdoauthproxy.appspot.com/