これまでの連載では，ruby-openidライブラリやRailsのOpenID Authenticationプラグインを使いながら，主にプログラムの観点からOpenIDでログインできるWebサイト（RP, Relying Party）を構築してきました。 連載の最後に，設計・運用の観点からOpenIDの課題についてみていきましょう。

OpenIDに登場する「ID」のまとめ

OpenIDではいくつかの「ID」が登場します。 これまでの連載で作成したサンプルを例にして，OpenIDに登場する「ID」をまとめてみましょう。

ユーザ提供識別子（User-Supplied Identifier）

利用者がログイン画面で入力するURLです。自分のOpenIDアカウント名を入力することもできますし，代わりにyahoo.comのようにOPのドメインを入力することもできます。特定のOPのみのログインを許可するようなRPの場合，セレクトボックスから選択させるようなインタフェースにすることもあるでしょう。

ユーザ主張識別子（User-Claimed Identifier）

本連載で「OpenIDアカウント名」と呼んでいたIDです。RPが利用者を識別するためのIDとなります。OPからRPへは，このIDが渡されます。

さらに，利用者にとってのIDはこれだけではありません。 OPにログインする時のID（はてなやYahoo!やlivedoorなどのアカウント）がありますし，今回のサンプルのようにRPにユニークなIDを登録する場合もあります。 OpenIDでIDが一つになるどころが，逆にIDが増えてしまったような印象も受けます。 OpenIDを使うことで，利用者のとって逆に管理が面倒になるようでは困りますね。

URLをIDに使うことによる問題

インターネットで爆発的に増えるIDを整理するために登場したOpenIDですが，なぜ逆に煩雑になるように感じるのでしょうか。 一つの理由は，「URLをIDとして使う」ことにあるのではないでしょうか。 OpenIDに対応したRPが増えれば，図1のように一つのIDで複数の対応サイトへログインできるようになります。

このID（Claimed Identifier）はURLであるため，利用者がIDとして認知しずらいという問題があります。 最近はメールアドレスをIDとして使用するWebサイトも多いですが，利用者にとってメールアドレスが「自分のもの」と認知しやすいのに対して，ブログを書いているような一部の利用者でないとURLは「自分のもの」と思わないでしょう。

一つの対策は，利用者にIDを意識させないことです。 連載の第1回で見たように，Yahoo!のOpenID実装はユーザにOpenIDのアカウント名を意識させないようになっています。 OpenIDでのログイン時に「○○でログイン」というボタンを用いるのであれば，利用者はログイン時にOpenIDのアカウント名を意識しないですみます。 しかし，RPへログインした後は，RP側でもユーザのIDが必要になります。 今回の連載で作成したようなミニブログサービスでは，ユーザのIDを画面上に表示する必要があったため，図2のようにOpenIDでのログイン後にRPローカルのIDを登録しました。

一方で，利用時にIDを意識しなくていいようなサービスであれば，RPローカルでのID登録は不要になるでしょう。 そのような軽いサービスのほうが，OpenIDの導入は容易であるかもしれません。

もう一つの対策はURLの代わりにシンプルなXRIを使うことです。 OpenIDでは，利用者が覚えにくいURLの代わりに，XRIという覚えやすいIDを使う方法も提案されています。 XRIとURIは，DNSのホスト名とIPアドレスの関係に似ています。 XRIが普及することで，OpenIDを利用する上でのIDの覚えにくさは解消されるでしょう。 しかし，XRIを利用するためには別途XRIサーバに自分のIDを登録する必要があり，現時点では誰でも簡単に使える状況になっていません。 そのため，XRIについての説明は割愛しますが，XRIが普及すればURLを使うことの分かりづらさは根本的に解決されるでしょう。