要約

  • 2026年9月28日に初版が提出された個人Internet-Draftは、証明者が割り当てるclient_instance_idを提案する。確認済みの鍵変更をまたいで同じ登録インスタンスを識別できるが、RFCやIETFの承認ではない。
  • この識別子は、既発行の更新トークンを新しい鍵へ付け替えない。基礎となる草案の既定ルールでは、新鍵による旧トークンの更新は鍵拘束の検査に失敗する。別に適用されるプロファイルが拘束を変える場合は別だ。
  • 提案に沿って発行した権限について、認可サーバーは記録済みのSource Instance Identityと現在の証明を照合する。それでもトークンの鍵拘束と所持証明は独立して確認する。

鍵交換後の「続き」を誰が認めるか

アプリケーションが鍵を交換する場面では、停止時間を短くしたいという運用上の圧力がある。証明者が新鍵の正当な引き継ぎを検証し、同じインスタンス識別子を発行すれば、認可サーバー側も古い更新トークンをそのまま通したくなる。しかし、そこで問われているのは「同じ設置か」だけではない。「そのトークンはどの鍵を使う条件で発行されたか」という別の約束もある。

K. McGuinnessによる新しい-00草案の5.1節は、同一性の継続を許しても、古い鍵に結び付いた更新トークンの結び付け先を変更しないと明示する。基礎の認証草案では、更新トークンは既定でClient Instance Keyに拘束される。そのため、旧鍵を前提にしたトークンに新鍵の証明を添えても、既定の検査には通らない。インスタンス識別子の一致を理由に例外扱いするのは、この提案には含まれていない。別の適用可能な規則が更新トークンの拘束を定義し直した場合だけ、その規則で判断できる。

これは暗号的な矛盾ではなく、責任の分担である。証明者は鍵交換後の登録関係を評価する。認可サーバーは発行済みの権限とトークン条件を守る。識別子が一致したからといって鍵検査を省けば、名前をアクセス権の代用品にしてしまう。便利な復旧手順に見えても、実際には既存権限の移し替えを無言で行うことになる。

複製と正当な後継の境目

提案の識別子は不透明で推測しにくく、別の登録へ再割り当てしてはならない。同じ登録の下で正当に検証された鍵変更なら維持し得る。一方、再インストール、独立した複製、新しい実行単位には新規登録が必要となる。古い鍵やデータ、識別子をコピーしただけでは、正当な後継と証明できない。スナップショットを復元した場合でさえ、認証された新しい後継証拠が求められる。この境界が曖昧だと、「同じ名前」を名乗れる複製を「同じ設置」と誤認する。

識別子は原則として一つのReceiverの範囲に限られる。複数の認可先を横断する世界共通の端末番号ではない。範囲ごとに鍵と識別子を分けるというプライバシー上の設計は、運用側が実際に守って初めて意味を持つ。また草案は、インスタンスの証明だけで利用者のsubを決めたり、代理のact連鎖を広げたり、鍵所持証明を代替したりできないとしている。任意のclient_instanceトークン・内省コンテキストは、資源サーバーに設置単位を伝える手掛かりであって、自動的な権限追加ではない。

このプロファイルで作られた権限では、認可サーバーはSource Instance Identityを記録し、更新時に現在の有効な証明と照合する。識別子が変わっていれば継続の条件を満たさない。識別子が同じでも、古い更新トークンに対する鍵拘束の検査は残る。二つの判定を別々に記録すれば、拒否した理由も説明できる。

Datatrackerの記録では、文書は初版の個人Internet-Draftで、状態はI-D Existsだ。表紙のStandards Trackは目標とする扱いであり、作業部会での採択やRFC化を示さない。実装の普及、相互運用性、事故を裏付ける測定結果も確認できない。現時点で評価できるのは提案された制御の筋道である。

出典