Re:OpenID再利用問題
この話は非常に興味深いですね。
もしも、私達が利用しているOpenIDプロバイダがドメインの更新を忘れて、第三者にドメインが取得された場合、私達のアカウントがこの第三者により不正に使用される可能性が出てくる。
事業者としてやりきる覚悟が無いならば OpenID Provider にはなって欲しくないし、まぁさすがに全うなネット事業者ならまずそういう事はあり得ないとは思いますけど。
ユーザは、セキュリティ的、高可用性の両方の側面からRelying Partyでのユーザ登録に、OP-Local Identifierを使用すべきではない。
言わんとしている内容は理解出来ますが、普及の点からすれば多くのユーザーは自分のドメインでdelegateしているなんて考えにくく OP-Local Identifier をそのまま使っているであろうから、全面的には同意しかねますね。
もう少し、現実的に起こりえそうな問題は、OpenIDプロバイダにより特定のアカウントの持ち主が変更されたケースである。初めは、Aというユーザが、a.example.comというOP-Local Identifierを保持していたが、Aが退会して同じOP-Local IdentifierがBというユーザに渡った場合、Bは、AがOP-Local Identifierを用いて会員登録したRPにサインインして登録された情報に自由にアクセスすることができる。
ポジティブに書くならば、
- OpenID Provider は退会したユーザーidを他のユーザーに割り当てない
とすればこの問題はあっさり片付く話なはず。
余り id のあるレコードごとバッサリ消して、再利用可能にしてしまうシステムは公のウェブサイトでは無い気がするんだけど、どうでしょう。大体はフラグ立てるだと思うんだけどなぁ。
もう一つの問題は、自分のHPのURLを識別子として利用した場合のリスクである。この場合、自分がドメインの更新を忘れて(または意図的に)、ドメインが第三者の手に渡ると、Relying Party上に残した私達の情報が、第三者に再利用される可能性が生まれる。
まぁこればかりは OpenID に限った話じゃないですし、仕方無いですねぇ。更新し忘れない！
自ドメインなどを Claimed Identifier にした場合、Claimed Identifier に対して OP-Local Identifier が一対一の対応ならば、RP がそれを覚えておく事によって、不正な利用かどうか判断できるんですが、XRDS の場合だと複数指定出来るので、その全ての Service 要素で指定された OP-Local Identifier を覚えておく、だとちょっと非効率ですよね。
XRDS のハッシュ値みたいのを覚えておいて〜とかなのかな。
後で考えるないしは次の idcon で酒の肴にする（ぇ
OpenID URLの変更とアクティベーションのサンプルはついていないが、RPはこの機能を用意すべきだろう。
ですねー。同意。
最初にアカウントを作った人、と言う事を担保出来るようにしないとダメっすね。
追記 (2008-04-30T11:40:54+09:00)
トラックバック頂いてました。ありがとうございます。
> OpenID Provider は退会したユーザーidを他のユーザーに割り当てない
OpenID2.0の仕様であれば、OPのつくりにもよると思うけど、ユーザーIDを再利用した場合に「以前使っていたユーザー」なのか、「今つかっているユーザー」なのかがわかるようにフラグメントの値をわけ、RP側でそれを受け入れるつくりにすることで対応可能かと。
ご指摘の通りですね。仕様だと 11.5.1. Identifier Recycling に書いてあります。
OpenID Providers with large user bases can use fragments to recycle URL Identifiers if it is so desired. When reassigning a URL Identifier to a new end user OPs should generate a new, unique fragment part. The full URL with the fragment part constitutes the Claimed Identifier in positive assertions, therefore Relying Parties will distinguish between the current and previous owners of the fragment-less URL. This mechanism allows the (presumably short, memorable) recycled URL Identifiers without the fragment to be used by end users at login time and by Relying Parties for display purposes.
簡単に言えば、重複した URL を割り当てるなら、ユーザーごとにユニークな値を URL fragment にくっつけろって事ですね。
