日向夏特殊応援部隊

俺様向けメモ

OpenID Tech Night ＃1で話してきました

OpenID

本日、OpenID Japanの技術イベントにてスペシャルゲスト(笑)として登場しました。
いやー、なんかみんなこうあれですよね、とにかく物凄い緊張しました（ぇ

で、今日の感想とかとか。

OpenID Authentication 2.0 〜概要とシーケンストレース〜

=natさんこと崎村さんと=katsuさんによるプロトコルのガチ解説。

curlでディスカバリの話をしているときはともかくしてパケットキャプチャしだした辺りからガチ過ぎて面白かったｗ

もきちんと話していて素晴らしいーと思った。
Realmとreturn_to辺りの話とか、RP Discoveryとかの話は＠ITの連載とかでいつか真面目に話そうかなと思います。

Building Relying Party Best Practice

こちらは恥ずかしながら僕のプレゼン。

と言う訳で本日の資料公開。

本当はもっと Best Practice があるんだろうけど、最低限 Relying Party になるつもりのサービス開発者は参考にして貰えると幸いです。
実は Reputation の話とかも触れたい所なんだけど、この辺りの話をすると中々厄介なので今回は言わなかった。

飲み会とか

=natさんやtkudoさん、mizzyさんなどと帰りにちょっと呑んで来ました。

XRI と CanonicalID の事、あとClaimed Identifier の fragment の話
% curl http://xri.net/=zigorou?_xrd_r=application/xrds+xml

とかやると分かるんだけど、

<CanonicalID priority="10">=!545A.6972.43FA.38AD</CanonicalID>

とかでCanonicalIDってのが出てくる。これは何かと言うと現在 =zigorou に割り当てられている実態みたいなの。
ドメインと実際のIPアドレスみたいな感じ。

ただ、これは固定IPアドレスみたいな物であると同時に、仮に =zigorou が別のジゴロウさんになったとした場合、異なるCanonicalIDが割り振られる。つまり再利用しないって事みたい。

ドメイン失効とか乗っ取られたりしたらその Identifier は一見他人を表してしまうけど、そうならないように、Canonical IDは個人にユニークな値を割り振る。

同様に URL の fragment もそういう扱いだったりする。

fragment は シーケンスのように同じ値を二度と割り当てないようにして URI fragment としてくっつけるといいですよ、って事。そういえばopenid-ja MLでその話盛り上がってたなー。

=nat さんは次回の Identity Conference で基調講演として XRI/XRDS と Reputation について基調講演して下さる予定です。
YAPCとかIIW(?)とかあるんで5月24日以降だといい感じみたい＞id:mizuno_takaaki

Reputation の話

セキュリティレベルの監査とか、OP, RP, Userの3者の間で各々の評価を行う仕組みが出来て、評価する枠組みが "公平" だとしても、Reputation で高い得点となったとしても、実際にユーザーに使われてて、広く認知されてなかったりなんて事もありそうとtkudoさんが言ってたんだけど、僕もそれに同意。

今度改めて。

しょこたん

しょこたん似の人に写真を撮られるなどした。
名前聞かなかったけど idcon 来て下さい。

=katsu さん

ブログ書いてたら教えて下さい。あと書いてなかったら書いて下さい（ぇ

んー

今日、色々聞けたから一つずつ後できちんと調べて勉強します。

これからPerlやろうかなーとか思ってる人へ

Perl

id:perlcodesampleさんが凄い丁寧に入門記事書いてます。

Perl界隈で初心者向けのコンテンツって余り無い気がするので、こうして書いて下さる方が居るってのは貴重だなとずっと思っていたんですが、紹介しそびれてたです。
オヌヌメ。

delegateとIdentifierの冗長性・ロードバランシング

OpenID

今は delegate とは言わず OP-Local Identifier の方が妥当なのかな。

多くの人が既にご存知かと思いますが、実際の OP にある Identifier (つまり OP-Local Identifier) を Claimed Identifier とせずに、
自分が既に持っているドメインなどを Claimed Identifier として OP-Local Identifier に対して delegate を行う事が出来ます。

具体的に言えば、

Claimed Identifier
art-code.org
OP-Local Identifier
zigorou.myopenid.com

みたいにする。

Claimed Identifier は URL の場合は Yadis Protocol or HTML Based Discovery に則って OP EndPoint URL などの discovery が上手く行くように情報を定義しないとダメです。
で、Yadis Protocol を使った場合に、Service 要素の priority 属性を用いて、OP-Local Identifier を複数指定しつつ、肝心の Claimed Identifier に対して冗長性を持たせる事が出来るーなんて話がこないだの OpenID 勉強会であったのですが、本当にそういう事が出来るような仕様なのか気になってました。

Yadis Protocol

The OPTIONAL priority attribute MAY be used with the Service element, allowing the User to specify preferences for the service to be used.

Example:
The example document at 7.4 above indicates that the User prefers the OpenID protocol using the server www.myopenid.com/server, and that the last choice is LID version 1.0.

The OPTIONAL priority attribute MAY be used with the URI element, allowing the User to specify preferences for the URI to be used.

Note:
The LID SSO service elements in the document at 7.4 above do not contain a URI element because in LID SSO the LID URL itself is used to obtain LID services.

In keeping with the goal of ease of implementation, a Relying Party Agent MAY ignore priority attributes. A Relying Party Agent that recognizes and uses the priority attribute in one or more Service or URI elements MUST follow the specification of priority attributes in Clause 3.3.3 of the XRI Resolution 2.0 specification.

Note:
The XRI Resolution 2.0 specification provides that the User prefers first the element with the smallest number in the value of the priority attribute, then those with higher numbers in the order of that number, and prefers last those elements with no priority attribute.

とあって、基本的には優先度の話しかしてなくて、後は XRI Resolution 2.0 に丸投げしてますね。

XRI Resolution 2.0

3. If two or more instances of the same element type have identical priority attribute values (including the null value), the consuming application SHOULD select one of the instances at random. This consuming application SHOULD NOT simply choose the first instance that appears in XML document order.

priority属性が同じ値を持つ要素が複数ある場合は、ランダムに選択してくれと言ってますね。あと出現順で判断しちゃダメとも申してます。

IMPORTANT: It is vital that implementers observe the preceding rule in order to support intentional redundancy or load balancing semantics. At the same time, it is vital that XRDS authors understand that this rule can result in non-deterministic behavior if two or more of the same type of synonym elements or service endpoint elements are included with the same priority in an XRD but are NOT intended for redundancy or load balancing.

まぁ後はざっくり言って冗長性とかロードバランシングを行う上でランダムに選ぶってのがあるんだぜって解釈で良さそうですね。

まとめ

XRDS 文書のpriority属性を同じ値にしておくと delegate する OP-Local Identifier を複数指定出来て、RP 側のライブラリが親切ならばロードバランシングしてくれるよーって話でした。