あなたのサイトをOpenID対応にしている2行の意味：OpenIDの仕様と技術（2）（1/3 ページ）
OpenIDが知られるようになり、自分のURLにおいたHTMLヘッダに、link rel="openid.server"……から始まる2行を追加することで、自分のURLをIDとして利用ができる、ということを知っている方も多いかと思います。今回はヘッダに書かれた2行が、OpenIDの仕様ではどのように定義され、利用されているのかを解説します（編集部）
第1回ではOpenIDの基礎知識を取り上げ、登場する用語について説明していきました。今回は動作の概要として、具体的にClaimed IdentifierがVerified Identifierとなるための手続きについて説明します。前回紹介した用語をもう一度復習しながら読んでみてください。
Claimed Identifierの宣言
まずはOpenIDの動作概要について説明します。End UserがどのようにしてConsumerに対して自分のClaimed Identifierを認証するIdP（Identity Provider）を知らせるかについて学びましょう。
IdPの宣言
End Userは自分のClaimed Identifierを認証してくれるIdPを明示する必要があります。
この明示の仕方ですが、具体的にはそのClaimed IdentifierをWebブラウザで開いたときに表示されるhead要素の中にlink要素として、下記のように記載します。
<link rel="openid.server" href="http://example.openid-idp.com/server" />
このlink要素の各属性について解説すると、
"openid.server"
・rel
openid.serverと記載します。
・ href
IdPが提供するサーバのエンドポイントURLを記載します。
となります。
HTML文書中の宣言がこの1つで済むのは、サーバのエンドポイントURLが同一ホストにある場合のみです【注1】。
【注1】
サブドメインは異なっても構いません。
Delegateの仕組みについて
当然ながら、End UserがClaimed Identifierとして用いるURLのホストと同一ホストでIdPを立ち上げなければならないわけではありません。自分のClaimed Identifierを認証する認証サーバーと、認証サーバーと同一ホストにあるIdentifierを明示する事によって、元のClaimed Identifierの認証を外部の認証サーバーに委ねることができます。
具体的にはhead要素の子要素として、下記のように記載します。
<link rel="openid.server" href="http://example.openid-idp.com/server" /> <link rel="openid.delegate" href="http://example.openid-idp.com/user/zigorou" />
link要素の各属性について解説すると、
"openid.delegate"
・rel
openid.delegateと記載します。
・ href
IdPと同一ホストのClaimed Identifierとして使用するURLを記載します。
となります。
このようにHTML文書中のlink要素として指定されたフォーマットで情報を記載しておくことによって、ConsumerはEnd UserからClaimed Identifierを受け取ったときに、どのIdPに問い合わせればよいかが分かります。
OpenIDで使うlink要素で指定するURLに関していくつか注意点があります。
- openid.serverのURL(href属性値)はクエリーパラメータを含む場合があります。このクエリパラメータの開始記号である「?」は必ず1つにしてください。
- openid.server、openid.delegateのURLは絶対URLでなければなりません。
- openid.server、openid.delegateのURLは「&」、「」、「"」を除いた実体参照を含めてはいけません。またURL中に含めてはならない文字列は正しくURLエンコードをしていなければなりません。
基本的には常識的なことですが、注意しましょう。
URLをIdentifierとするメリットとデメリット
●メリット
OpenIDではIdentifierはURLそのものであり、なおかつopenid.server、openid.delegateの解決のためにHTML、もしくはXHTMLで表現する必要があります。
HTML文書で記述できるということは、Identifierに対して豊富なメタデータの提供を行うことができます。
参考程度にLive Journalの中の私のページのhead要素内からメタデータを抽出すると、
- RSS Feed
- Atom Feed
- FOAF
などが挙げられます。
また、マイクロフォーマットなどを利用してHTML文書をよりセマンティックな形でマークアップすることにより、Identifierから機械的にそのEnd Userのメタデータを引き出すことが可能になります。あるいは当然ブラウザで表示することも可能でしょうから、人間にとってもそのIdentifierを持つに際して、何らかの情報が得られる可能性が高いでしょう。
さらにいえば、URL中には、httpないしはhttpsの場合はホスト名が含まれるものがほとんどですので、例えば特定のco.jpドメインを持つIdentifierに関していえば、そのIdentifierのHTMLがco.jpドメインを持つ会社ではない、まったく無関係の第三者がねつ造したページでない限りは、おおむねその会社の人であると信じてもよいでしょう。
このように通常よくあるサイトでのIDは、暗黙の了解を除けばただの文字列にすぎないのに対して、OpenIDのIdentifierに関していえば、そのものに意味を見いだすことができるといえるでしょう。
●デメリット
当然ながらデメリットも存在します。簡単に列挙すれば、
- 認証サーバーは分散モデルなので複数存在することから、それらの認証サーバーを手放しに信頼してよいかどうか判断ができない。
- 信頼できない認証サーバーで認証されたIdentifierへの認可はどのように行うか判断ができない。
- URLをIdentifierとすることから、必然的にイントラネット内での利用が難しい。 【注2】
【注2】
Identifierがイントラネット内部にあるようなケースだと、外部ネットワークにあるConsumerがそのIdentifierのページを見ることができないので、少なくともConsumerからIdentifierが見える状態でないと利用できません。
Consumerもイントラネット内部にありIdentifierにURLが割り当てられているならば、問題なく利用することができるでしょう。
これらに関してはいずれ深く言及したいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.