Kazuho@Cybozu Labs

WEIS Protocol Version 1.0 (Draft)

　WEIS は、ウェブサービスが他のウェブサービスに部分的な機能を公開するための、ウェブブラウザベースの認証トークン発行プロトコルです。HTTP Authentication や HTML Form を応用しているので、既存のウェブアプリケーションに容易に組み込むことができます。

　具体的には、 WEIS を利用することにより、ウェブ型 RSS リーダーで SNS の更新情報を確認する、といった使い方が想定されます。また、 Atom Publishing API 等とも透過的に組み合わせることができるので、一定の条件を満たした情報をブログに自動投稿するようなウェブサービス等も、簡単に実現できるようになります。

認証 API

　「認証 API」と一口に言っても、その中には Authentication (認証) 機能を提供するものと Authorization (承認) 機能を提供するものの２種類があります^注1。

　このうち、 Authentication API については、Typekey, OpenID, sxip など、議論や実装が進んでいますが、 Authorization API については、いまだ API として独立したものは無いように思われます^注2。ウェブアプリケーションに組み込まれた承認 API については、 flickr のものや 30 boxes のものが存在します。

flickr vs. 30 boxes vs. WEIS

　flickr や 30 boxes の API と比較した場合の WEIS の特徴は、下表のようになります。

	スケーラビリティ	サービス間の認証	権限の種類	トークン授受
flickr API	1:n	独自	read,write,delete	GET redirect & direct HTTP
30 boxes API	1:n	独自	なし	GET redirect注3
WEIS	m:n	HTTP 認証	任意	POST redirect

　表の各項目について説明します。なお、以下では WEIS の仕様に準じ、リソース (データあるいは機能) を提供するウェブサイトを Provider、それを利用するウェブサイトを Consumer と呼びます。

・スケーラビリティ

　Consumer が Provider 毎にサービスをカスタマイズする必要があるかどうか、を示すのがこの項目です。
　flickr や 30 boxes の承認 API は自社のアプリケーションに密結合されています。また、無知な Consumer がリソースにアクセスしようとして認証を要求された場合に、どのようにして認証トークンを要求すればよいか、発見 (Discover) する仕組みを持っていません (つまり、認証 API の URL について、 Consumer が事前に知っておく必要がある) 。
　したがって、flickr や 30 boxes の API は、Provider 毎に Consumer が結びつく 1:n モデルだと言うことができます。それに対し、 WEIS では、API がアプリケーションから独立し、また Discovery のスキームを備えているので、 m:n モデルだと言うことができます。

・サービス間の認証手法

　flickr や 30 boxes の API では、認証パラメータとアプリケーションのパラメータとの間に、明確な区別がありません。それに対し、WEIS では、サービス間の認証には HTTP Authentication を使っているので、上位の各アプリケーションは CGI Parameter を自由に使うことができます。

・権限

　flickr では、 Consumer に授与する権限は、 read, write, delete の３種類となっています。30 boxes では、権限という考え方は内容で、常に、全ての API にアクセスを認めることになるようです。
　一方、WEIS では、 HTTP 認証の realm を使用することで、各アプリケーションが自由に権限を定義できるようになっています。これは、どのような権限の種類が必要かは、アプリケーションによって異なるためです。

・トークン授受

　flickr は、まずブラウザリダイレクトでセッション ID を交換し、その後 Consumer が Provider にセッション ID を引数として認証トークンを要求するという、やや複雑な手法をとっています。
　30 boxes と WEIS では、ブラウザリダイレクトで認証トークンを交換します。
　ちなみに、いずれの API においても、認証トークンの授受の際に暗号化は行われていません^注4。

API を採用するにあたって

　ウェブサービス提供者が自社の Web Services API を公開する場合、まず問題になるのは、 Consumer を登録制にするかしないか、という点です。
　WEIS のターゲットである RSS のような分野 (m:n であることが望ましい API) では、各 RSS リーダーやに登録を求めるというのは現実的でないでしょう。逆に、自社のウェブサービス特有の機能で、1:n モデルでも問題がない類の API については、各 Consumer に登録を要求するのもアリだと思います。

　はてなのケースでは、実際にどのような類の API の公開が検討されているのかわかりませんが、自社サービスに囲い込みをするような 1:n モデルではなく、 m:n モデルを採用することで、業界全体の革新を早めるような英断を期待したいところです^注5。

注1: 「認証」「承認」については、Apache の用語に従うことにします。
注2: ご存知の方は教えてください。
注3: ブラウザのツールバー等で漏洩する可能性があるので、 POST を使うべき
注4: 公開鍵か共有鍵を Provider に登録させて、レスポンスを暗号化＆署名すれば、技術的には可能。ただし、WEIS を使った場合でも (各 Provider に鍵を登録しなければならないという意味で) 1:n モデルということになってしまう。
注5: WEIS をつかってくれれば、それに越したことはないわけですが (笑)