要約

終了日を決める会社と、利用者台帳を持つサイト

Googleの2014年2月の発表はOpenID Connectの正式化を歓迎すると同時に、古い入口の終了日を記した。OpenID 2.0のサポートは2015年4月20日まで。Googleは連携ログインを新規格へ集め、開発者向けに自社の導入手段も示した。一年以上の予告期間があったが、期限を決めるのは身元確認サービスを動かす側だった。Googleでログインさせていたサイトは準備できても、旧入口を自分だけの判断で延命できない。

サイトに残るアカウントはログイン動作だけではない。古い識別子に購入履歴、保存した文書、会員資格や操作権限が結び付く。OpenID 2.0では、確認されたClaimed Identifierをサイト側のアカウント鍵にできた。OpenID Connectの識別子は発行者と主体の組で表される。同じ利用者であっても鍵の形は違う。新しいログインが成功しても、古いアカウントへ自動的に戻るわけではない。空の重複アカウントを作ることも、別人に古い記録を渡すことも起こり得る。

2015年3月20日の通知でGoogleは4月20日を再び示した。OpenID 2.0を含む旧方式は停止し、移行を終えていないアプリはGoogleとの接続を失う可能性がある。ログイン機能もその影響を受け得るとした。これは障害件数の報告ではなく、旧認証サービスの終了がアプリへどう響くかを示す警告だった。利用者台帳の運営者には、入口の交換と台帳の引き継ぎが同時に迫った。

最終仕様の承認から停止予定まで四日

OpenID Foundationが2015年4月16日に公表した投票結果は、賛成28、反対0、棄権4だった。Googleの予定日まで残り四日。開発が四日前に始まったという話ではない。Googleの終了告知は前年に出ており、最終仕様の付録は2014年6月時点のGoogle移行ガイドと自分たちの規定を比較している。四日という数字は、共通の完成した手順が正式に承認されてから、予定された旧入口の停止までの間隔を示す。

最終仕様は古い鍵と新しい鍵を同時に扱う。サイトは認証要求にopenid2スコープを加え、OpenID Connectの本人確認に加えて古い識別子も求める。提供者がその人の旧識別子を知っていれば、ID Tokenのopenid2_idに入れて返す。サイトはまずトークンを検証する。しかし有効な新トークンに古い識別子が書かれているだけでは、その発行者が古い識別子について語る権限まで証明されたことにはならない。

そこで仕様は権限の照合を要求する。旧サービスと新サービスが制約された同一の権限主体にある場合はその一致を使える。そうでなければ、古い識別子のURIへAccept: application/json付きでアクセスし、返るissがID Tokenの発行者と厳密に一致するかを確かめる。XRI識別子には別の経路がある。確認に失敗すれば古い識別子を受け入れず、成功して初めてサイトが既存のOpenID 2.0アカウントと新しい発行者・主体の組を関連付ける。鍵の交換を記録するのはサイト自身の台帳だ。

仕様の付録Bは、Googleの2014年6月のガイドとの違いを残している。ガイドはopenid.realmを使い、最終仕様はopenid2_realmを選んだ。古い識別子の項目もガイドのopenid_idに対し仕様はopenid2_idとした。付録はさらに、ガイドには最終仕様にある依頼サイトの確認と旧識別子に対する提供者の権限確認がなかったと述べる。これは仕様の執筆者による当時のガイドとの比較で、Googleの全運用を計測したものではない。共通規格が必要だった理由がここにある。古いアカウントへの権利は、新しいトークンの見た目だけでは決まらない。

引用した原記録には、移行を終えたサイトの数も誤った関連付けの件数もない。個別サイトの移行記録があれば結果を調べられる。資料から確実に読めるのは役割の分担である。Googleが古い入口の閉鎖を決め、各サイトが利用者の古い記録を誰に渡すか決めた。