OpenID Authentication 2.0時代の幕開け：OpenIDの仕様と技術（5）（2/3 ページ）

[山口徹，サイボウズ・ラボ株式会社]

長くて覚えられないURLは覚えなくてもよい

　OPから提供されるエンドユーザーのIdentifierには非常に長いものがあります。例えばベリサインのPIPというOPが提供するIdentifier URLはとても長いです。筆者のIdentifierは、

http://zigorou.pip.verisignlabs.com/

ですが、この長い文字列をテキストとして入力するのは面倒ですし、タイプミスして認証できないといったことにもなりそうです。われわれのようなIT業界の人間ならともかく、一般人にこういったURLを一字一句覚えてタイプさせるという苦行を行わせるのはあまりに酷でしょう。これはPIPに限った話ではなく、例えばYahooが提供するOpenIDによるOP-Local Identifier（http://my.yahoo.com/username）も十分長い文字列です。

　OpenID Authentication 2.0では、より一般ユーザーが使いやすいIdentifierと認証方式が採れるような、アクセシブルな仕様が盛り込まれています。

User-Supplied Identifierとは何か

　では、User-Supplied Identifierとは何でしょうか。

　OpenID Authentication 2.0の7.1 Initiationに書かれていますが、これまでどおりRPはエンドユーザーにログインフォームを表示します。1.1の場合ではClaimed Identifierというエンドユーザーが所有しているが、まだ認証されていないIdentifierを入力することとなっていました。ここが2.0ではUser-Supplied Identifierに変わったのです。

　User-Supplied Identifierとは「RPに対してエンドユーザーが入力したClaimed Identifier、またはOPにおいてエンドユーザーが選択したIdentifierのこと」と説明しましたが、この文章をひもとけば、

• 従来どおりにClaimed IdentifierをRPのログインフォームに入力して認証する
• （Claimed IdentifierをRPに伝えずに）OPにおいて使用したいIdentifierを選択して認証する

という方法があるとことが分かります。二番目の方法を実現したい場合は、Claimed Identifierの代わりにOP Identifierを入力することになっています。

　仮にexample-provider.comがOPだとし、自分が所有するIdentifierがexample.comとします。この際にOP IdentifierとOP-Local Identifier、Claimed Identifier（delegate先はOP-Local Identifier）は例えば次のようになります。

• OP Identifier
  →　http://example-provider.com/
• OP-Local Identifier
  →　http://username.example-provider.com/
• Claimed Identifier
  →　http://example.com/

　つまりOpenID Authentication 2.0に対応したRP、OPの場合は従来どおり「username.example-provider.com」、「example.com」でも認証できますし、「example-provider.com」のようにOP Identifierを利用してもよいのです。

　もっと端的にいいましょう。仮に国内SNS大手のmixiがOpenID Authentication 2.0ベースのOPになった場合、「mixi.jp」と打つだけで認証できるようになるのです。これはとても大きな変更点です。この部分を「mixiアカウントでログインする」のようなボタンにしてもよいのです。ユーザーはOpenIDを意識することなくRPのサービスを受けることができるようになるでしょう。

　このあたりはDiscovered Informationで規定されていますが、openid.modeがcheckid_immediateまたはcheckid_setupの際にopenid.identityというパラメータにIdentifierの選択をOP側でエンドユーザーに選択させるという意味を持った識別子「http://specs.openid.net/auth/2.0/identifier_select」を設定して、RPはエンドユーザーをOPにリダイレクションさせます。

図1　OP Identifierによる認証の流れ

　これにより、ユーザーは自分の長いClaimed Identifierを覚える必要がなくなり、OP Identifierを入力して、そのOPでの認証を済ませたあとに、OPによる認証結果としてRPに渡すことが可能なIdentifierを選択して、認証結果を返すということが可能になります。

　YahooのIdentifierはユーザーごとに2つずつIdentifierがありますが、自分のアカウント名が含まれないランダム文字列のようなものがsuffixにあるURLは、OPにおける実際のuser名を流出させたくない場合などに使えます。

新しいディスカバリー

　次はOpenID Authentication 2.0で大きく変わったディスカバリーです。ディスカバリーとはいままでの仕様でいう、

1. Claimed Identifierを入力して、
2. RPがClaimed Identifierにあるlink要素のopenid.serverと、必要であればopenid.delegateを解決して、
3. RPはエンドユーザーをOPにリダイレクト

の1、2のプロセスに当たります。この部分は2.0の仕様では大きな変更点があります。

　まずはIdentifierの記述形式ですが、いままでのhttpまたはhttpsで表現されるURLのほかに、XRIという形式でも記述できるようになりました。XRIはURIに対して上位互換を保ちつつ、さまざまなリソースを表現するために語彙（ごい）が増えたものです。

　Claimed IdentifierにXRIを指定した場合は、XRIが実際に何のリソースを指しているかの解決を行う必要があります。ともあれ多くの方がXRIという新しい形式に戸惑うことでしょう。ものは試しということで、具体例を挙げてみます。

論より証拠、XRIの例

　XRIで筆者のブログ（http://d.hatena.ne.jp/ZIGOROu/）を表現すると、

xri://=zigorou/(+blog)

になります。

　誰のブログでもこのように表現できるのかといえば、決してそうではありません。筆者専用の個人用のXRIをi-name providerから購入したので、このXRIが使えるようになっています。 URLの世界でいうとドメインを取るのと同じ感覚です（つまり=zigorouはドメイン名のようなものだと思って構いません）。

　ただし、この見慣れぬプロトコルをブラウザに入力しても当然リソースを見ることはできません。XRIの//以下の文字列をhttp://xri.net/の末尾に付けるとxri.netのXRI Proxy ResolverがXRI文字列を解釈して適切なリソースを返します。つまり、

http://xri.net/=zigorou/(+blog)

によって実際にお使いのブラウザなどで筆者のブログにたどり着けます。私のXRIを用いたIdentifierは正しくはxri://=zigorouとなりますが、=はXRIで拡張された語彙ですので、=zigorouだけでIdentifierとして認められています。

　つまり今までURLを一生懸命打ち込んでいましたが、XRIがあれば=zigorouだけでOpenID対応しているRPのサービスを使えるようになります。XRIの話は、またの機会に詳しく解説したいと思います。