Tweet

第2回 あなたのサイトをOpenID対応にしている2行の意味

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要素の各属性について解説すると、

となります。

図1　IdPの宣言

　HTML文書中の宣言がこの1つで済むのは、サーバのエンドポイントURLが同一ホストにある場合のみです【注1】。

　Delegateの仕組みについて

　当然ながら、End UserがClaimed Identifierとして用いるURLのホストと同一ホストでIdPを立ち上げなければならないわけではありません。自分のClaimed Identifierを認証する認証サーバーと、認証サーバーと同一ホストにあるIdentifierを明示する事によって、元のClaimed Identifierの認証を外部の認証サーバーに委ねることができます。

　具体的にはhead要素の子要素として、下記のように記載します。

　link要素の各属性について解説すると、

となります。

　このようにHTML文書中のlink要素として指定されたフォーマットで情報を記載しておくことによって、ConsumerはEnd UserからClaimed Identifierを受け取ったときに、どのIdPに問い合わせればよいかが分かります。

図2　delegateの仕組み

　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が割り当てられているならば、問題なく利用することができるでしょう。

　これらに関してはいずれ深く言及したいと思います。

1/3

Index
あなたのサイトをOpenID対応にしている2行の意味
	Page1 Claimed Identifierの宣言 IdPの宣言 Delegatingの仕組みについて URLをIdentifierとするメリットとデメリット
	Page2 OpenID対応サイトを作る際のユーザビリティ OpenIDでの認証手続きの流れ
	Page3 登録手続きにおけるOpenID拡張 ミニコラム：OpenID提唱者インタビュー

OpenIDの仕様と技術 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード