要約

  • draft-mcguinness-oauth-client-attesters-00 は client_attesters に issuer と jwks_uri を載せ、特定のクライアントについて証明できる attester を示す。00版は個人 Internet-Draft であり、RFC でも採択済み標準でもない。
  • クライアント発行者の endorsement と authorization server の trust は独立している。前者は証明者の資格、後者は受け入れる鍵源と保証水準を決める。
  • endorsement の削除は、キャッシュ更新後の新規認証を止めるだけで、既発行 grant や token は失効させない。直接検証する resource server にも自動では届かない。

「削除済み」という監査記録があるのに、同じ attester の証明がまだ通る。最初に疑うべきは改ざんではなく時間軸だ。authorization server は有効期限内のメタデータをキャッシュし、access token は別の寿命を持ち、resource server は別の信頼設定で直接証明を検証しているかもしれない。

この複数の状態を一つにしないことが、OAuth 2.0 Client Attester Endorsement の中心である。ATTEST は Client Instance と鍵について attester が何を署名し、受信側がどう検証するかを扱う。しかし、その attester が特定の client_id のために話す資格を誰が与えたかは定義していなかった。

提案される client_attesters は、その関係を権威ある client metadata に置く。各要素は attestation の iss と一致する issuer、公開 JWK Set の HTTPS jwks_uri を持つ。これは発行者の意思表示であって、trust anchor、利用者の委任、resource access の許可ではない。

交差したときだけ受け入れる

受理には二条件が要る。選択された metadata が現在その issuer を endorsement していること。そして authorization server の方針が、その client-attester 関係と鍵の信頼方法を許していることだ。

発行者は一覧に書くだけで server に信頼を強制できない。server も、一般に信頼する attester を未承認の client に追加できない。方針は公開集合を狭められるが広げられない。この交差が、発行者と verifier の権力を分離する。

publisher-authorized key selection では、server があらかじめ発行者に attester と鍵源の選択を許す。endorsed jwks_uri を HTTPS、origin、path、network の制約下で取得する。多数の client を扱うには効率的だが、保証は発行者から独立しない。CIMD を支配した者は、自ら運営する attester と鍵を指定できる。

AS-configured attester trust では、server が exact issuer ごとに鍵源を設定する。公開された URI は設定値か明示的 alias と一致しなければならず、代替取得先にはならない。不一致時に一方へ自動的に寄せないことが独立性を守る。

ただし設定の影響は広い。ある exact issuer に一度でも configured trust があれば、全 client でその方式が優先する。設定を消しても publisher selection へ自動移行しない。alias も issuer 全体に効く。変更審査は一 client の作業として扱えない。

検証順序が鍵の意味を固定する

まず client_id に対して権威ある metadata source を一つだけ選ぶ。登録情報と CIMD を混ぜたり、失敗後に別の source へ逃げたりしない。次に issuer == iss の唯一の entry、client-attester policy、key source、そして一意な kid の公開鍵を順番に決める。

鍵は client、issuer、source、policy の組に束縛される。kid だけ、または複数 JWK Set の和集合では不十分だ。jku、x5u、x5c、jwk header も選択を変更しない。署名、proof、sub == client_id を確認した後でも、grant と resource policy は別に判断する。

削除と停止は同じ操作ではない

endorsement を削除しても、有限だが未満了の cache は残る。草案は最大時間を規定しないため、収束時間は trust agreement で決める必要がある。実際に 404 または 410 を観測すれば cached document を捨てるが、timeout や 5xx は fresh cache を無効にしない。

鍵 rotation も重複期間を要する。新鍵を公開し、cache lifetime を待ってから署名を始め、旧鍵は旧 attestation の満了まで残す。URI 変更なら metadata cache と server 側設定の双方が関係する。

さらに、endorsement withdrawal は将来向きだ。既存 grant、access token、refresh token を取り消さない。停止には grant/token revocation、refresh 拒否、introspection の inactive 化、offline validation の寿命管理が必要だ。Client Attestation を直接検証する resource server はこの profile の discovery 対象外なので、個別に更新する。

署名ではなく判断の receipt を残す

運用記録には client_id、一つの metadata source、hash、取得時刻、cache expiry、exact endorsement、発行者の設定権限を入れる。続いて trust mode と優先理由、key source、alias、JWK Set hash と freshness、kid、algorithm、一意に選んだ key を記録する。

attestation が endpoint で必須だったかも欠かせない。client_attesters の存在自体は提出を強制しない。optional signal なら他の credential だけで進める方針もあり得る。最後に grant decision を別欄で保存する。

withdrawal 時には最初の観測、cache convergence、最後の成功、attestation expiry、token revocation、refresh、introspection、offline token、direct validator を追記する。これは Daniel Kade の運用提案であり、draft の normative text ではない。

公開エラー invalid_client_attestation が詳細を隠すのは妥当だ。だが内部では endorsement 不在、source mismatch、曖昧な kid、一時的 fetch failure を区別しなければならない。policy conflict は新しい attestation を作っても直らない。