Kazuho@Cybozu Labs

1) シンプルで美しい

　安全性の評価は、一般的な Challenge-Response 型のプロトコル (cert の値が Challenge に相当) と考えればいいんでしょうか。でも、なぜ MD5 なの？

2) ログイン用リンクに署名は不要

　毎回同じ api_sig になるので、存在意義がないと思います。

3) コールバック URL が固定

　パラメータを指定できたほうが良いと思います。固定のままでも、サードパーティアプリ側で Cookie を使えば、パラメータ指定と同等のことはできますが、処理が煩雑になるので。
　また、 POST リクエストに対して認証が必要になってリダイレクトするようなケースでは、 CSRF を防ぐために、 Cookie とコールバック URL のパラメタを組み合わせる必要がありますので、そのような動作をサポートしたい (たとえば、ブログのコメントをポストする際に認証を要求するようなウェブアプリに対応したい) のであれば、パラメータ指定は必須になります^注1。

4) サードパーティアプリについて、コールバック URL 以外の情報を設定できるのは、良くない

　URL に対して偽の説明をつけることが可能になります。大多数のユーザーは、「はてなの新サービスです」のようなタイトルの、このようなリンク を含むメールが送られてきた場合に、それがフィッシングであることに気づかないでしょう。
　このあたりは、高木浩光さんの、アドレスバーを隠すのが何故問題かという議論と同一の背景をもつように思います。
　蛇足になりますが、「はてな認証APIで取得できる情報は限られているから問題ない」という反論は、必ずしも正しくありません。名寄せが可能だからです^注2。

14:36 追記: コールバック URL とアプリケーションURL が同一ドメインであるべき、という指摘は既にあるようです。奥の 4) は、「コールバック URL以外をユーザに判断基準として示すべきではない」という風に理解いただければ^注3。

注1: CSSXSS を JavaScript を用いずに防止する場合も、同様の手法が有効だと思います
注2: アダルトサイトにリダイレクトするようにしておいて、釣られたユーザーのブログ日記に「閲覧ありがとうございました。コメントが不要な場合は、有料会員になってください」みたいなコメントを残すとか？　他にも、社内情報システムへリダイレクトさせることで、社内情報を漏洩しているはてダを書いているのが誰だか特定するとか？　あまり良い例ではないような気もします
注3: ユーザーへのメッセージは、ホスト名を用いて「172.16.3.195 が読み取り許可を要求しています」のようにするのが望ましいと思います

api_sig 以外のパラメータも指定できるようになりましたね。

> api_sig 以外のパラメータも指定できるようになりましたね。

気づいていませんでした。ありがとうございます。これで、 POST 処理段階での認証要求もできますね。

なお、(後で認証の際に利用される) nonce か、あるいは、有効期間を含むパラメータが必須となったわけではないので、ログイン用リンクに署名をつけるメリットがないという点は変わらないと思います。

どうもです。参考になります。

コメントが長くなりそうなので

- http://naoya.g.hatena.ne.jp/naoya/20060506/1146904097

に書いておきました。