idcon#5WebブラウザハックとアイデンティティWebサービスについて

Apr 10, 2009

株式会社マッシュマトリックス冨田　慎一

はじめに• idconでのプレゼン自体は初めてなので、自己

紹介

• id:shinichitomita

• twitter.com/stomita

• 会社やってます（株式会社マッシュマトリックス）

• 企業向けマッシュアップのミドルウェア提供／コンサルティングとか

位置づけ• アイデンティティ愛好家（自称）

『手に何も持たぬから̶̶̶̶空手』『そう教えられてきたハズの両雄だった…』『しかし̶̶̶』『歩んだ日常があまりにも違っていた』『その違いが̶̶̶』『一方を空手家へ』『もう一方を空手愛好家へと道を分けた』

餓狼伝　Vol.216　より

• 愛好家とプロフェッショナルの違い

• 背負ってたつものがないので、気楽にできる（重要）

• 裏を取る作業を怠るので、穴が多い（＝信頼感にかける）

切り口• テーマ：

• 軽量Webサービスとアイデンティティの融合

• アイデンティティWebサービスの企業内情報統合への利用（本業に近い）

• ポリシー：

• できるだけ専門用語を使わない

• 仕様は必要なときしか見ない。そこはプロに任せる

• ブログ書くときはさすがにちょっと調べるが、付け焼き刃。きっと間違ってたらだれか教えてくれるはず、という甘い期待

重要なこと• アイデンティティWebサービスが市民権を得

た

• 少なくとも、デベロッパーには解放された

• プロトコルはどうあれ、Libertyがやりたかった世界に近づいてきた

• 今新卒エンジニアだったら、絶対あそんでる

近代• その昔、Liberty Allianceがあった

（もちろん今もある）

• 2000年新卒当時、Sunの下道さんとか

• 有名な航空券予約デモ

• これがほんとのWebサービスですか！（単純な新卒脳を洗脳）

現代• Liberty => SAML は、当初の「インターネッ

トにおけるアイデンティティ連携」の主流からは外れてきたように思える

• しかしB2B、SaaS連携では着実に実績がある

• プライバシーなど仕様にもりこまれてるため、安心

• ファイアウォールをまたいだ連携

• Google Apps, Salesforce の２大SaaSがともに採用

• あまり人目に触れにくいのが残念なところ

Open Stack の勝因？• サービス側主導で採用

• 今すぐに見えるものがある、というのは重要

• オープンソースコミュニティ

• 軽さ、とっつきやすさ、自由度

• たとえ無償で出しても、インストール＆セットアップに１日かかるなら、コミュニティはスケールしない

OpenID の悩み• ユーザビリティ低くね？

• 選択の自由なんかいらない、って人が多数じゃない？

• 仕様は自由だが、運用は固定でもOK

• ホワイトリスト、「Yahooでログイン」ボタン

• ユーザはあまり標準仕様とかどうかとか気にしない

プロプラへの回帰• どうせ大人の事情で「ユーザが完全自由に選

択」なんてできないし、そもそもユーザがそれを望んでるかどうかが怪しい

• じゃあ今のところ独自の仕様でも別にいいよね？（常人には危険な発想）

• そのかわり、もっと普及を促進するようなアイディアを盛り込めないか（？）

Facebook Connect• ポルシェ乗り回してVCから総スカン食らった

現マイクロソフト Dick Hardt、絶賛• Facebook Connect - fatal blow for OpenID?

http://identity20.com/?p=151

• アイデンティティ・サイロを批判してたはずなのに？（どうしたの？）

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/

Google Friend Connect• 「Facebook Connectの対抗馬」と喧伝され

る

• ソーシャルグラフの解放、流通を目指す

• 最初はウィジット型での提供だったのでFBCとの差異は多かった

• 今はAPIとして提供され、Facebook Connect に近づいた

FBC、GFCの共通点• Consumer側にサーバ実装が要らない！

• HTML+JavaScriptで完結• Google Maps API• ブログにスクリプトを貼付けるだけでFacebook/GFCの

サービスを利用できる• ブラウザ拡張とはちがう、事前のインストール必要なし• コピペでばらまき可能であることのスケーラビリティ、

ウィジット化

• 同様の試み（ブラウザのみでWebサービス接続）

• Google GData JS API (Google Account Auth AuthSub JS)• GoogleカレンダーのプライベートカレンダーにJSのみでアクセス

できる

技術（ハック）による克服点• ブラウザ上でのクロスドメインコミュニケーショ

ンをどう実現するか

• 通常セキュリティ制約により通信できない => Hack

• IFRAME越しのフラグメント識別子通信

• window.postMessage (only for relatively modern browsers)

• ユーザに同意させる仕組みはどうするか

• 認証トークンのやり取りはどうするか

• フラグメント識別子 => Cookie保存

• 署名は省く

個人的見解• 「HTML+JavaScriptのみ」で、参入敷居が下がるなら歓

迎。”開発者 = Code書き” の式はどこまで壊せるか？

• 独自仕様は。。。

• でも実装にハックが多いので、標準仕様にするのは難しくないか？

• まずはプロプラ実装が可能性を示すのは、正常な進化である気がする

• アクティビティストリームへの吸い上げに有効

• FBやGoogleがFBC/GFCを出してる主な理由

• 情報アグリゲーション型の軽量マッシュアップにも有効

• 複雑なことをやろうとすると、サーバが絡むだろうから、そうなるとあまりかわらないかも

• 日本は携帯対応でないと、という冷ややかな反応

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/