Webカレンダーの30Boxesが「出す」と宣言していたAPIの一端を公開した。まだイベントの作成と更新が公開されていないが、それが出れば手元のツールと同期するプログラムとか簡単に書けそうだ。
Google、Amazon、eBayで始まったWeb APIの大きな流れは、当初の読み取り専用データのWeb公開（Open Data!）を経て、Flickr APIとその仲間たちやAtom PPのような更新できるAPI（をSPIと呼んだこともあったっけ）へと歩を進めつつある。
更新できるAPIで重要なのは、認証機能だ。30Boxesも、カレンダーにデータを追加することを念頭においているわけだから当然だが、最初から認証機能が用意されている。こんなAPI呼び出しでユーザーの承認を受けることができる。Flickrとその仲間たちも同じような仕組みでユーザーがアプリへ承認を与えることができる。Amazon Web サービスも最近共有秘密による認証をシステムに組み込んだ。
ここで重要なのは、彼らはHTTPのBasic認証メカニズムを使っていないということだ。Basic認証などのHTTPのメカニズムでは、ユーザーはサードパーティのアプリケーションに、そのアプリケーション用ではなく、他のサービスにおける自分のパスワードを教えなければならないからだ。Flickr!は僕が2005年のDevelopers Summitでデモしたときは写真のアップロードにBasic認証を使っていたが、その後現在の仕組みを構築した。Web APIでユーザーのパスワードをアプリケーションに対して入力させるような認証機能は今すぐ仕組みを考え直したほうがいい。パスワードは常にユーザーとサービスとの直接対話でのみやり取りされなければならない。でないとman in the middle認定されてしまう。
と、ここまでの話は実はほとんど先日miyagawaさんとチャットしたときにmiyagawaさんがおっしゃったことだ。miyagawaさんはずっと以前にすでに書いてたし（追記）。日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある（僕のMTプラグインとか）が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。
ところで30BoxesのAPIからのレスポンス。
<?xml version="1.0" encoding="ISO-8859-1"?>
<rsp stat="ok">
<ping>pong>/ping>
<msg>API key for user 14734 was verified.&ｌt;/msg>
</rsp><rsp stat="fail">
<err code="2" msg="Incorrect API key"/>
</rsp>
<rsp> rulez!
http://blog.bulknews.net/mt/archives/001852.html
前に書いた気がしてみてみたら、ここにありました。
> Web APIでユーザーのパスワードをアプリケーションに対して入力させるような認証機能は今すぐ仕組みを考え直したほうがいい。
その API を利用するのが、別のウェブサービスである場合は、おっしゃるとおりだと思います。逆に、API を利用するのが、PC で動作するクライアントアプリケーションである場合は、同じパスワードを使うことに問題はないと思います。
たとえば、フォト蔵の API は、言及している「貼る蔵」を見ても、後者の利用形態を前提にしているんじゃないでしょうか。
＞PC で動作するクライアントアプリケーションである場合は、同じパスワードを使うことに問題はないと思います。
配布元およびダウンロードしたファイルの内容を信頼できる、またはソースが公開されていて自分でビルドできるならであって、問題なしと言い切るわけにはいかないと思いますが。変にログとか残ったりしてあとでGoogle Desktopで曝されたりする可能性を考えると。PCで動作するソフトウェアであろうがWebアプリであろうが、パスワード収集機能を持っていないことを信用できなければ同じだと思うのです。僕がパラノイアなだけでしょうか？僕はAtom PPを利用してブログにポストするアプリケーションも使う気になれません。
じゃあiTunesは、puttyはどうなんだっていわれるとツラいところではありますが、そこは信頼できるってことで；）
ご返答ありがとうございます。
> 配布元およびダウンロードしたファイルの内容を信頼できる、またはソースが公開されていて自分でビルドできるならであって、問題なしと言い切るわけにはいかないと思いますが。
PC にインストールされたソフトウェアからは、cookie データベースにアクセスすることやブラウザにキーロガーを仕掛けること等、何から何まで出来てしまいます。
ですので、クライアントアプリケーションにパスワードを教えるか否かでセキュリティ上のリスクが変化することはない、と (理論的には) 言えると思います。
実装上のミスの可能性を含めた危険性については、おっしゃるような観点も含め、いろんな議論が可能だと思います。
いずれにせよ、現行の各サイト毎の API にはいろいろ危険性もあったりするので、ガイドラインなり標準化なりが図られるべきだ、と思います。
> 何から何まで出来てしまいます。
そうでもないです。黙ってそういうことをしようとするアプリケーションを排除することは現行のWindows上でも不可能ではないです。もちろん実際にそういうことを気にかけているソフトウェアと、そういうソフトウェアだけを使おうとするユーザーが少ないということは知っていますが。
APIを使って写真を送り込もうとするクライアントアプリケーションの場合、黙ってパスワードを使うわけではないので、悪意のキーロガーをどうするかという話とはちょっと違いますね。