要約

  • OpenID Authentication 2.0は、本人が名乗るURLと、認証事業者の内部で使う識別子を区別した。本人がURLを管理していれば、名前を変えずに認証先を変更できる設計だった。
  • ログインを受け入れるサイトは、そのURLから事業者を発見し、返された主張を発見結果と照合し、本人が名乗るURLをローカルアカウントの鍵にする必要があった。仕様書はこの仕組みを示すが、実際の移行件数は示さない。

ログインを引き受ける会社を替えても、ほかのサイトで同じ人として扱われるには何が残るべきか。OpenID Authentication 2.0の最終仕様は、本人が管理するURLをその軸に置いた。利用者はサイトにURLを伝える。サイトはそのURLから認証事業者の情報を見つけ、ブラウザをそこへ送り、戻ってきた応答を確かめる。OpenID Foundationは2007年12月5日に最終仕様を発表した。属性交換の別仕様も同時に最終化されたが、ここでの焦点は認証と名前の持ち主である。

仕様は二種類の識別子を明確に分ける。Claimed Identifierは利用者が自分のものだと主張する名前だ。OP-Local Identifierは認証事業者の内部にある名前で、利用者自身が管理できるとは限らない。サイトが後者を自分の会員台帳の鍵にすると、認証事業者の変更で同じ人を別人として扱いかねない。URLが残っていても、台帳が違う名前を見てしまう。

URLが認証先を示す方法の一つはHTMLだ。本人が名乗るURLのページには、認証事業者の窓口を指すrel="openid2.provider"リンクを置ける。必要なら、事業者内の利用者名を示すrel="openid2.local_id"リンクも置く。URLを提供するホストと認証事業者のホストは別でよい。したがって本人が自分のページにある行き先を変更すれば、ほかのサイトに名乗るURLを維持したまま認証担当を移せる。

サイト側には、行き先を読むだけで済まない仕事がある。肯定応答が届いたとき、そこに書かれた本人のURLについて発見を済ませ、そのURLが指す事業者の窓口と内部識別子が応答と一致するかを確認しなければならない。まだ発見していなければ、応答を受けてから調べる。これを省くと、ある事業者が他人のURLについて勝手に名乗れる。URLの持ち主が認証を任せる相手を示し、サイトはその委任先から返事が来たか確かめる。

何を保存するかにも仕様は踏み込んだ。認証に成功した利用者の情報は、本人が名乗る識別子を鍵にして保存することを推奨した。OpenID 1.1との互換処理では、古い応答にopenid.claimed_idが入っていない。名乗るURLと事業者内の名前が異なる場合、サイトは発見に使ったURLをセッションなどに保持し、戻ってきた人を正しいアカウントにつなぐ必要がある。

OpenIDは、事業者やサイトの登録を中央機関が許可しなくてよい仕組みとして説明された。利用者は認証事業者を選び、切り替えても自分の識別子を保てる。これは仕様上の設計である。実際に何サイトがこの鍵の付け方を守ったか、何人が無事に移れたかは、ここで参照する原資料には載っていない。URLの管理権、認証先へのリンク、応答の照合、会員台帳の鍵が揃って初めて、乗り換えの道になる。

当時の賭けは、パスワードを検査する会社にインターネット上の名前まで預ける必要があるのか、というものだった。OpenIDは名前を本人のURLに残し、認証の仕事だけを移せるようにした。しかし最後にどの会員記録を開くかは、受け入れるサイトが決める。分散した仕組みの自由は、その地味な照合作業にかかっていた。

一次資料