at posts/single.html

OpenID の相反する用途について

OpenID 勉強会に参加できなかった(存在を知らなかった><)ので、ここでちょっと思考実験。 勉強会の感想を読んでの印象か、ふと思いついたのかは分からないけど、 OpenID の用途は二極化するのでは、と思った。 あんまり深く考えていないので、連載の方じゃなくてこっちに書くよ。

用途1: シングルサインオンとして

ネットでいろいろなサービスに登録していると、 ID とパスワードを覚えることが大変になっていく。 一つの ID とパスワードでどこにでも入れるといいのに、と思うことがあるけど、これを実現するのがシングルサインオン。 この場合の OP (OpenID Provider), RP (Relying Party), 利用者の導入メリットを考えてみる。

OPのメリット自社IDによる囲い込み
RPのメリットサービス利用者の拡大
利用者のメリットパスワード管理の負担軽減

主要な目的がパスワード管理の負担軽減なので、以下のような方向に進んでいきそう。

  • 主要なターゲットはそれほどネットに詳しくない平均的な利用者
  • ID の匿名性を高める
    • User-Claimed Identifier から OP ローカルのIDが特定できない (例: Yahoo!)
    • 通知する ID を RP ごとに別にする。
  • 特定の大手 OP への集中
  • ログイン時は「○○のアカウントでログイン」のようなボタンを付ける。

この場合の成功のポイントは「簡単」と「安心」のバランスになりそう。

用途2: 複数アイデンティティの連携

Twitter と LDR とはてなブックマークのような複数のサービスを利用していると、それぞれのサービスでアイデンティティを連携させたくなる。 例えば…

  • LDR で購読しているブログの人の Twitter をまとめて follow したい
  • ついでにはてブがあればお気に入りに追加したい

などなど。 OpenID の delegate を使ってブログの URL と livedoor のアカウントを結びつけることができれば、お互いに相手のブログを読んでいる人をピックアップすることもできる。 利用者が望む範囲で複数のアイデンティティを連携させることで、より便利なサービスが生まれるように思う。 個人的には面白いって思うんだけど、本当にそこまでの仕組みが必要か?ってことと、使いこなせるユーザを絞ってしまう(ブログを書いていない大多数の人に届かない)ことが気になるところ。

OpenID が登場した背景は良く知らないんだけど、最初は後者のアイデンティティの連携(もしくは、そのためのアイデンティティの確立)を目指していて、その後、大手の OP が参入する仮定でシングルサインオンの色が強まっているのかも。

ちょっと眠くなってきたので、後半の考察が甘いかも…。

関連する日記