OAuthの前に立ちはだかるPIMの壁

PIMって何よ

たまにこう思うわけです。
PIM(Personal Information Manager/Management)とか呼ばれるソフトにおいては、ID/PWを直接送ってデータをやりとりする仕組みがすでにできあがっています。
メール、カレンダー、アドレスブック。
前職で社内のいろんな話を聞いていたとき、こんなに仕様が整っていることを知りました。

CalDavやCardDavはそれぞれカレンダー/アドレスブックの情報をやりとりするための仕様です。
HTTPS + basic認証の組み合わせが仕様に入っています。

ちなみに、そいつらをまとめて管理しちゃおうぜってのもいます。
DavMail POP/IMAP/SMTP/Caldav/Carddav/LDAP Exchange Gateway

多様化するClientとリスク

以前は、こいつらを使うのClientはPCにインストールするデスクトップアプリやモバイル系の端末のメーラーとかだったのでしょう。
「PC上保存はするけど、通信のときは直接メールサーバに送られるだけだからそんなに気にする必要はないじゃん。気にすることないよ」
それはそうですね。なんとなく気持ちはわかります。

でも今は、SNSが招待メールをばらまいたりメアドで登録済のユーザーとつながるようにレコメンドをしたりする時代です。
また、複数サイトで同じメアド/PWを利用する人がたくさんいることは周知の事実です。

もし、あなたの使っているメールクライアントがメアド/PWを誰かのサイトにしれっと送っていたらどうなるでしょう。

多様なサービスを持つサイトの憂鬱

たくさんのサービスデータをOAuthで提供していて「あなたのID/PWは外のやつらに触らせませんよ」と言ったところで、PIM系の上記のプロトコルに対応しているものがあると、上記のリスクは残ります。

頑張ってOAuth対応のAPIに変えていっても、どこかで漏れたID/PWを使って各サービスを死ぬ気でスクレイピング。PIM系のプロトコルのために、いつまでもふさげない穴がそこにあります。

こいつら、OAuthでできないのか？

できると思います。

Portable Contactsのようにデータフォーマットやパラメータのみとユーザー認証を整理して、あとはID/PWを送る部分をTokenに変えれば良いだけですからね。
OAuth 1.0系は署名うんぬんでもういいですが、OAuth 2.0ならさらに導入しやすくなるのではと思っています。

立ちはだかる壁

OAuth化を推進していくならば、会社でIdentity担当の人きっと以下のような壁に遭遇するでしょう。

  • 確立しているUX(主にメール)を崩したくない。これらのプロトコルに乗らないとライバルサービスに置いていかれる
  • ブラウザ立ち上げて画面数枚かますことの利便性低下（そんなに面倒かなぁ・・・）

こいつらを乗り越えるためには、新たな標準仕様が必要だと思います。
既存のもののOAuth Bindingといった立ち位置でもいいでしょう。

Thnderbirdの最初のめんどくさい設定をしないでブラウザを立ち上げてOAuthの処理を行い、終わったらカスタムURIスキームを用いてThunderbirdが立ち上がりすぐにメールが使えるようになる。
素晴らしい話じゃないですか。サーバ設定(サーバ名、ポートとか)もOAuthのAPIでとってこれそうですし、アドオンでカレンダーを使いたければScopeを増やせばよい。

え？OAuthだとServerが限定されそうだって？
それはOAuth 2.0でDynamicなClient登録などが考えられているのでなんとかなるんじゃないかって思いますよ。

Googleさんに問いたい。「Facebookさんと揉めるのもいいですが、そのまえにこの辺なんとかする気はないですか？」と。

（追記）
以前、IMAP/SMTPとOAuthでブログ書いてたので、今後の動きに期待って意味です。
http://googlecode.blogspot.com/2010/03/oauth-access-to-imapsmtp-in-gmail.html

では今日はこの辺で。