斜め読みOpenID Authentication 1.1 Overview (1)

d:id:ZIGOROu:20070319:1174304910 の続きです。
OpenID Authentication 1.1がソースです。

HTMLドキュメントをアイデンティティへと変換する

エンドユーザーはアイデンティティとしたいURLにあるHTMLドキュメントのhead要素内に指定されたlink要素を入れなければならない。
エンドユーザーがアイデンティティとして使用するホストはエンドユーザーのIdPである必要は無い。

例えばエンドユーザーのアイデンティティがhttp://example.com/だとして、http://openid.example.comがIdP*1の場合はhttp://example.com/のhead要素内に下記のようなlink要素を記載しなければならない。

<link rel="openid.server" href="http://openid.example.com/" />

認証の委譲(delegating)

エンドユーザーのアイデンティティがあるホストにIdPが無い場合や、他のホストでIdPを運用したい場合は認証を(他のホストに)委譲する必要が出てくる。

例えばエンドユーザーがexampleuserと言ったidでLiveJournalのアカウントを持っている場合、LiveJournalはOpenIDのIdPでもあるから、
http://exampleuser.livejournal.com/に認証の委譲を行う事が可能である。

example.comをアイデンティティとしてつかう為にコンシューマーは実際にはhttp://exampleuser.livejournal.com/をIdPと共に確認する為に、
example.comのhead要素内に下記のようなlink要素を追加する必要がある。

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml" />
<link rel="openid.delelgate" href="http://exampleuser.livejournal.com/" />

delegatingをつかうメリットは自分のアイデンティティをexample.comとして長く使用出来るという事で、
途中で自分のIdPを変更したりする事も出来るという点がある。

重要な注意点

• openid.serverのURL宣言*2はQueryパラメーターを含むかもしれない。従って既にQueryパラメーターの開始記号であるクエスチョンが存在するならば、２個目のクエスチョンは「追加してはならない。
• openid.server, openid.delegateのURLは共に絶対URLで無ければならない。コンシューマーは相対URLの解決に注意を払う必要が無い。
• openid.server, openid.delegateのURLは&,<.>,"を除いた実体参照を含めてはならない。また妥当なhtml文書でない文字列、文書のエンコーディングで表現出来ない文字列はRFC2396正しくURLエンコーディングされていなければならない。

まとめ

• delegatingを使わない状況だとIdPとIdentityは同一hostじゃないと駄目みたいですね。サブドメインならOKみたい。
• delegatingは要するにIdentityの実体を他の場所に指定する方法と思えば良さそう。

ふむ。

*1:Identity Providerの事。d:id:ZIGOROu:20070319:1174304910参照

*2:link要素のhrefの中の事