要約

  • draft-mcguinness-oauth-client-instance-id-00 は、検証済みの鍵変更を越えて client_instance_id を維持するが、同一性はattesterが保存するenrollment履歴に依存する。
  • インスタンス継続、grantの鍵拘束、attesterへの信頼、Receiver Scope、下流context、現在の提示者、認可と実行結果は別々の判断である。
  • 運用レシートには、登録、粒度、旧新鍵、ライフサイクル事象、証拠の鮮度、Consumer Scope、sender constraint、結果へのリンクが必要だ。

管理対象アプリが鍵をローテーションした。新しいattestationは有効で、以前と同じ client_instance_id を示す。認可サーバーは過去の監査や停止判断を新しい鍵の要求へ引き継ぐ。

新鍵そのものは旧鍵との関係を語らない。IDも、更新だったのか、再インストール、複製、スナップショット復元、交換だったのかを説明しない。同一性は、別の主体が「この申請者は前のenrollmentを継承する」と判定したため成立する。

2026年9月28日公開のrevision 00は、Standards Trackを意図する個人Internet-Draftである。OAuth WG採用文書でもRFCでもなく、実装や相互接続の証拠でもない。別のinstance assertion方式を置き換える。基礎となるattestation文書はWG Last Call中だが、その状態がこの個人profileを承認するわけではない。

現在の鍵と過去から続く主体は同じ問題ではない

基礎方式は、許可されたClient Instanceが現在の鍵を保持するかを検証する。新profileは、Receiverが以前に見た同じインスタンスかを問う。鍵ごとに新しいattestationが必要でも、それだけでは継続中のインストールと新設されたものを区別できない。

client_instance_id の割当主体はattesterであり、Source Instance Identityは (iss, client_instance_id) の組である。client_id はLogical Clientを表し、その下に多数の端末、コンテナ、agent runtimeがあり得る。利用者や委任されたprincipalとも異なる。

ここで、鍵の所持は現在の事実、インスタンス継続は歴史的な主張、認可はReceiver側の決定、業務効果は後の観測だと整理できる。有効な署名を、この四つすべての証明に拡張してはいけない。

不透明なIDではなくenrollmentが意味を支える

提案はIDを固有、不透明、予測不能、再割当禁止とする。ホスト名、ユーザー名、実行属性を埋め込めない。URIに見える値もURIとして解釈しない。Receiverは完全一致だけを使い、文字列から権限や粒度を推測しない。

しかし安全なラベルは継承の証拠ではない。attesterは、インスタンス、Logical Client、Receiver Scope、粒度、過去に検証した鍵を結ぶactive enrollmentを保つ。鍵変更では、新鍵のfresh possession、認証されたcustody transition、連続性チェック、その鮮度、観測したライフサイクル事象を記録する。

検証済み更新、鍵変更、installation粒度でのプロセス再起動、in-place updateならIDを保てる。再インストール、独立clone、交換、execution粒度での再起動、粒度変更では新しい登録が必要だ。restoreやrollbackは、単に鍵とデータがコピーされたことでは足りず、先行holderを継承するfresh evidenceを要する。forkを検出したら、正当な継続者を証拠で選べない限り、IDを廃止して別々に登録する。

連続性記録を削除した場合も再登録が必要だ。プラットフォーム固定値だけからIDを導出すると、再インストール後に退役IDを再生できる。したがって「永続ID」という機能の実体は、ポリシーで運用される状態機械である。

Receiver Scopeは実在するがIDから検証できない

原則としてReceiverごとに異なるIDを割り当てる。だがReceiver Scopeは登録・発行時の入力であり、OAuthパラメータでもattestation audienceでもない。ReceiverはIDを見ても、自分向けのscopeか判定できない。

共有には、名前を付けたReceiver集合への明示的な合意が必要で、Logical Clientやtrust domainの共有だけでは足りない。分離したいscopeではClient Instance Keyも別にしなければ、同じ公開鍵が異なるIDを結び付ける。

誤ったReceiverへ正しい形式のattestationを提示しても、Receiver自身が越境を発見できない場合がある。監査には、想定scope、ポリシー版、実施責任を残す必要がある。JWTの妥当性だけではこの設定を再現できない。

attesterに発言権を与えるのもローカル判断だ

Receiverは、承認したAttester Issuerを検証鍵および代理可能なLogical Clientと結び付ける。iss、署名、proof of possession、client metadataだけではその権限を成立させない。

隣接記事はClient Attester Endorsementの二重承認を扱った。本稿は承認後を対象とする。信頼されたattesterでも、設定されたassuranceに沿って継承を判断しなければならない。侵害されれば、許可範囲内のインスタンスを偽造できる。self-report、platform-verified、hardware-rooted evidenceは同価ではない。

独立したplatform evidenceがなければ、鍵と登録データを複製したcloneが原本と区別できないこともある。草案は検出済みforkへの処置を示すが、観測不能な複製を発見するとは約束しない。

identity continuityとkey binding continuityを混ぜない

Source Instance Identityは鍵変更後も保持できるが、既存refresh tokenの鍵拘束が自動で新鍵へ移るわけではない。refreshでは、現在のSource Identityが記録と一致すること、およびproof/key bindingが元の規則か別の認可済みrebinding profileを満たすことを独立に検証する。

前者は「同じ登録単位」、後者は「このgrantが受け入れる鍵を今回保持している」という意味だ。データベースの同じ行を見つけただけで権限を新しい秘密へ移すべきではない。

codeなどを認可時にinstanceへ結び付けたなら、redeem時にも証拠を要求する必要がある。権限が確定する場所で証拠を省く経路を残すと、登録時の厳格さが無意味になる。

suspensionは一つの時刻では完了しない

attesterは停止・退役enrollmentへの新規発行を止める。認可サーバーはgrantを撤回し、introspectionでinactiveを返せる。それでも既発行attestationは満了まで、access tokenはそれ自身の寿命まで使える可能性があり、offline validationするresource serverはローカル撤回を知らない。

status distributionは範囲外だ。再登録や別Receiver Scopeによって、停止IDと関連付けられない新IDも作り得る。封じ込めには、prior enrollment、replacement admission、撤回配布、残存時間の明示が必要になる。

「停止済み」という表示だけでは、誰が決めたか、いつ効いたか、どのenrollmentとtokenが対象か、誰まで通知されたかが欠けている。

下流contextは第二のID台帳を作る

任意の client_instance objectは、token issuerがresource serverへ検証済みinstance contextを渡す仕組みだ。attester IDの単純なコピーではなく、Source Instance Identityをissuer自身の (iss, id) へ写像し、token audienceで選ぶConsumer Scopeに制限する。

mappingはgrantやtokenが有効な間、安定していなければならない。再現不能なら別IDを作らずcontextを省く。audienceがない、または複数scopeにまたがるtokenには唯一の正解がない。scope外のintrospection callerにも返さない。

ここで二つの台帳が必要になる。attesterはenrollmentの歴史を保持し、token issuerはconsumer向けprojectionを保持する。それぞれ権限、鍵、保存期間が異なる。どちらかの喪失を新IDで覆い隠せば、監査上の連続性が捏造される。

発行に参加したinstanceと今のpresenterは別だ

Instance Contextは権限を与えない。それ単体では、token取得に参加したinstanceを示すだけで、現在のHTTP要求を誰が提示したかは示さない。

presenter attributionにはDPoP、mutual TLSなどのsender constraintが要る。鍵を複数instanceが共有すれば個体の帰属にならない。拘束のないbearer tokenでは主張できない。

token exchangeでは、入力tokenを検証しても、そのissuerのassertionが認証されるだけで、内部の全upstream authorityが自動認証されるわけではない。consuming profileが、現在のpresenterか上流instanceか、関連をどう検証するか、いつremap/preserve/omitするかを決める。contextはactor chainでも独立tokenでもない。

sender proofが通っても、資源側の認可、実行回数、最終結果は別のレシートを必要とする。

privacyは観測者間の取引である

Receiver別IDはReceiver同士の相互追跡を減らすが、attesterはReceiver Scopeを知る。広い共有scopeならattesterに個別Receiverを見せにくくなる代わり、Receiver同士がinstanceを関連付けられる。

同じDPoP keyや証明書を使えば、異なるIDも同じthumbprintで結ばれる。他のclaimやアプリケーションデータも同様だ。privacyをID列だけで評価せず、各観測者、鍵、保存期間が作る連結可能性を測るべきだ。

必要なのはcontinuity receiptだ

レシートはattester issuer、検証鍵、Logical Client、enrollment、粒度、Receiver Scope、trust policyを記録する。transitionごとに旧新鍵の指紋、ライフサイクル事象、custody evidence、鮮度、retain/re-enroll/suspend/retire/forkの判断を結ぶ。

grantではSource Identityとkey bindingを別フィールドにする。下流ではissuer、mapping input、Context ID、Consumer Scope、audience、provenanceを残す。要求ごとにpresenter proofとresource authorizationを記録し、最後に実行と観測結果を結ぶ。

この形ならIDは履歴への索引として働き、全工程の成功を装うことはない。