WebアプリXは悪意があるかもしれません。秘密のカレンダーを読み出して、公衆にさらすかもしれません。エンドユーザはWebアプリXにどこまで許すかを設定する必要があります。この設定はあくまでSNS上で行う設定です。WebアプリXはエンドユーザから許可を得られれば、SNS上の秘密のカレンダーを取得することができます。このモデルでは、この設定を「ユーザ認可」と呼べます。取得を許してしまえば、その情報をどうするかはWebアプリXの世界なので、SNS上の設定では関与できません。エンドユーザはWebアプリXを信用できるかを見極める必要があります。SNSを信用するかはこの文脈ではあまり意味がありません。秘密のカレンダーを作っている時点で、信用しているからです。ここまでの話をまとめると、ユーザ管理やユーザ認証が面倒なので、既存SNSに丸投げして楽をしたついでに、エンドユーザが許す範囲で、エンドユーザの権限でSNS上のデータを読み書きできるようになったということです。言うまでもありませんが、SNS側が、こういうことのできる仕組みを提供してくれたら、というただし書きつきです。Calendarはこういうことができるわけです。facebookの場合、もうひとつ面白い点があります。facebookの画面内にWebアプリXの画面を埋め込めることです。埋め込むパターンはふたつあって、ひとつはcanvasと呼ばれ、もうひとつはprofileと呼ばれています。後者はGoogle的にはgadgetsです。前者はfacebookのアプリ領域画面全体をWebアプリXが奪うイメージです。proxy的な動作の2種類あります。proxy的動作)をFBMLと呼んでiframe型と区別しています。上図と同様の動作(つまりエンドユーザが最初にアクセスするのがfacebookアプリXで、そこからfacebookのユーザ認証画面に飛ばす)のfacebookアプリXも可能ですが、一般には、エンドユーザは最初にfacebookにログインして、その後、ナビゲーションメニューからfacebookアプリを呼び出します。この辺りはまた別の機会に書きます。facebookは技術的に稚拙と思える部分も多々あります。対して常にPOSTメソッドで行い、かつ意味的な区別はパラメータのmethodの値で行います。POSTすればイベント取得を意味する、といった動作です。これでRESTと主張しています。彼らの中では、URL叩いてレスポンスがXMLならRESTなのでしょう。技術のブレークスルーには、ある種のおおらかさと言うか、アナーキーさと言うか、そういうものが必要なのかもしれません。facebookを見ているとそう感じます。ここでようやくOpenSocialの登場です。実はOpenSocialの存在が微妙です。上のモデルを標準化しようという動きなら分かりやすいです。OpenSocialはそういう側面も持っています。APIsと呼んでいる部分です。facebookと違ってGoogleはきちんとRESTする会社です。API)で行い、データアクセスをAtomPub(Google的にはGData)で行うはずです。APIsの情報がまだ不明瞭だからです。OpenSocialでは、なぜか(ぼくから見ればあまり本質とは思えない)gadgetsのスペックばかり決めています。APIsと呼んでいる、上図のフローの方が重要だと思うのですが。OpenSocialにもひとつ良い点があります。Apps」(http://code.google.com/apis/opensocial/container.html)です。ここまで、SNSは与えられたもの、という感じで書いてきましたが、自分で作っていけない法はありません。Apps」はSNSを作る側の話です。この文脈ではOpenIDにも触れておくべきでしょう。ここまでSNSが一括してユーザ管理とユーザ認証を行う中央集権モデルを前提にしてきました。ここでのSNSの定義のもとで言えば、OpenIDはオレオレSNSを作っているようなものです。モデル的には、WebアプリXは決まったSNSではなく、エンドユーザが提示するOpenIDサーバ(IdP)とやりとりをします。OpenIDの場合も最初に書いた「絶対ルール」は成立します。OpenIDに対応したWebアプリXは、ユーザ管理機能らしきものは必要になる気がしますが、少なくともパスワード管理からは解放されます。