iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来？について
最近、自分自身のテクノロジー的な世界観に対して影響を与える刺激がいろいろとあったわけだけど、その中におぼろげながら共通点が感じられたので、最初はGoogle+にLimitedなメモとして書いたのだが、ブログの方に清書する。
-
-
-
-
-
- -
-
-
-
-
最初のきっかけは、AppleのiOS5へTwitter APIが組み込まれる、というニュースだった。それはTwitterサービスにiOSの提供するAPIを通してアクセスでき、その際の認証はOSが代行してくれる、というものだ。それが基調講演で発表された時には「なんでそこにOSが絡まなきゃいけないのか、オープンスタンダードなやり方があるのだからいいじゃないか」という理由で否定的に受け取ったわけだけども、よくよく考えてみれば位置情報でもストレージでも、リソースへのアクセス許可に対して承認許可ダイアログをOSが出しているわけだし、それがWebサービスでもまあありかもな、と考えるようになった。ただTwitterという１サービスだけじゃつまらんので、KeyChainをもう少しWebサービスに広げた OAuth版KeyChainみたいにならんのかな、などと考えていた。
そしてそんなTweetをしていたら「それってなんてAccount Manager on Android？」って感じのことをTL上で言われて、しかし当時残念ながらAndroidには疎かったので、何だろそれと思ってちょっと調べてみた。で、調べてみたらなるほど、確かにそれっぽい。例えばGoogleのカレンダー情報にアクセスしたい時は、その旨をAccount Manager (Android OS)に伝えて、OSがユーザに承認確認画面を出して、それにOKを出すとGETしたカレンダーサービスへのアクセストークンが使えるようになる、という感じ。若干荒削りな気はしたけど、やろうとしたいことは十分わかる。こういう挑戦的なことができるのは新興のデバイスであるスマートフォンならではの醍醐味だろうな、と思った。
ここで「スマートフォンならでは」と思ったのは、昔々に（それほど昔でもないが）PCの世界でそれをやろうとして、でももうそんな普及できるような段階じゃなくって、結局しぼんでしまったInfoCard（後にCardSpaceと変更）という試みを思いだしたからだ。Microsoftが提唱して、なんとかVistaか何かに標準で組み込んだはずだったが、結局その存在にみんな気づくことはなかった。実質IEでしか使えないまま、多くのWebサイトはあえて対応することなどなく、そしてMS自身も終結宣言した。
やっぱりMSは例のごとく時代を先取りしすぎ（タイミングを読み間違え）たのだろうか。そんな気を特に強くさせたのが、この２、３日にTLの一部を賑わせたMozillaのBrowserIDの発表のニュースだった。
BrowserIDの詳細は別サイトを参照いただくとして、発表直後から各方面よりセキュリティ／プライバシー／Eメールアドレスに依存することついての疑念などが寄せられた。ただしこの記事ではそこらへんについては触れずにおく。
僕がBrowserIDを見て最初に感じたのは、そのInfoCardやAccount Managerとの類似性だった。ブラウザ（OS）側で資格証明を管理し、Webサイト（アプリケーション）のリクエストに応じて、ブラウザやOSがユーザに対してアクセス要求を適切にプロンプトして承認を取り、データをWebサイト（アプリケーション）側に払い出す、という点は非常にInfoCard（Account Manager）的だ。
ただまあ、本質的にブラウザの拡張によってそれを達成しなければいけないという点で、本当にスケールできるの？InfoCardの二の舞じゃないの？という疑問はあるのだけれど、今の時代ならHTML5（Local Storage, Cross Document Messaging）のパワーを使えるので非対応のブラウザでもある程度は代替できるんじゃね？という提案については、ちょっと新しく聞こえるわけだ。
いやいや、ブラウザ拡張じゃスケールしないとは言ったが、案外そうでもないかもしれない。Chromeなんかはもうブラウザ拡張をそのままWeb Storeで提供できるようにしてしまっているから、ユーザとしてはiOSにアプリをダウンロードする感覚に近くなってるのかもしれない。アプリのダウンロード提供めんどくさい、Webアプリケーション万歳、と言っていた時代は、AppStore的なマーケットプレイスの登場と集中管理の自動アップデートのインフラが台頭してきたことにより変わってきた。いわば、クライアント／デバイス上で稼働する「アプリ」が主役で活躍する時代になった。
このような時代になってきたのだから、Webサービスのコントロールの中心も、従来主流であったクラウド上から、必然的にクライアント／デバイス方面によってきて当たり前なんじゃないか、と思えてくる。そしてその裏付けとなる証拠が、おそらくiOSのTwitter対応であり、AndroidのAccount Managerであり、MozillaのBrowserIDである、というわけだ。サーバ／クラウド側にコントロールハブを置くアーキテクチャから、クライアント／デバイス／ユーザエージェントに近い場所にパーソナル・データの流量制御弁を置くアーキテクチャへと、次第に移行していくんじゃないか、という仮説である。
もちろん、クライアント側主導ですべて済むわけではなく、サーバ／クラウド側で行うWebサービスの連携については、依然必要とされるだろう。しかし、OAuthなど、Webアプリの連携を前提に設計されてきたプロトコルには、スマートフォンなどのクライアントからの利用に対して若干後付け的な気持ちの悪さがあるのは否めない。そこにクライアント中心型のWebサービスのコントロール手法が発展できるかもしれない十分な理由がある。（さらに言うならば、もしかしたらiOSのTwitter対応は、ジョブズがiPhoneのTwitterアプリのOAuthダンスのUIを見て、ふざけんなとダメ出ししたためなんじゃないかと邪推している*1。）
-
-
-
-
-
- -
-
-
-
-
余談になるけれども、その昔、Dick Hardtという高速プレゼンの名手（！）が「User Centric Identity」あるいは「Identity 2.0」という概念を元にSXIPという会社を起ち上げた。その彼の理想とするところは、サービス側からユーザ側へとアイデンティティ制御の主導権を取り戻し、そしてアーキテクチャ上もユーザ側にコントロールの中心を持ってくるという、まさに今記事で触れた世界そのままだった。ただ、そのSXIPは資金難に陥りDead Pool入りとなり、DickはMicrosoftへと移った。先に述べたとおりMSにはInfoCardプロジェクトがあったが、結果についても先に述べたとおり。移ってから１年ほどでDickはMSを辞めている。
その後はいわゆるステルス状態で彼自身の秘密プロジェクトをやっているようだったが、今回のBrowserIDの発表に対し、自身のブログにおいて、彼の信じるUser Centric Identityの世界の実現を試みるものだ、として好意的なコメントを寄せている。
