OAuth SPIFFE Client Authentication

RFC 7521・RFC 7523・attestation-based client authentication をプロファイルし、OAuth クライアントが client secret の代わりに SPIFFE の SVID (JWT・WIT・X.509) で認証できるようにする。

現在地
状態不明
公式本文
公式に文書化された対応
0
動き
1 件の動き (90 日)

この仕様の解説はまだ書かれていない。下の要約・関係・対応状況は維持されている。

RFC 7521・RFC 7523・attestation-based client authentication をプロファイルし、OAuth クライアントが client secret の代わりに SPIFFE の SVID (JWT・WIT・X.509) で認証できるようにする。

他の仕様との関係

関係図
flowchart LR
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_spiffe["SPIFFE"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  style s_spiffe_client_auth stroke-width:3px
  s_spiffe_client_auth -->|土台とする仕様| s_spiffe
  s_spiffe_client_auth -->|プロファイル対象| s_jwt_bearer
  s_spiffe_client_auth -->|プロファイル対象| s_attestation_client_auth

公式に文書化された対応

利用状況には、公式のドキュメント(ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ)に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

動き

Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。

このサイトの解説

  • AIMS のドメイン間ギャップの記述:発行者の信頼は認可を決めないこと、判断には有効期限があることを限定する文を加える方向で一致

    AIMS -01: upstream authorities for Workload Identity Certificates (trust between trust domains) (6 new messages)

    解説を読む

    このスレッドは、信頼ドメイン間の信頼に関するギャップを AIMS に記録するという David Croston の提案の続きで、機構に依存しない性質の一覧(二者間の設定なしに他ドメインの発行者を信頼できる、発行者は自身の名前についてのみ発言できる、検証者が受け入れるドメインを選ぶ、失効の時間的上限)が示されている。Jiahui Miao は、他ドメインの発行者を受け入れてもそれだけでは操作の認可は確立されないという限定的な性質を加えた。ShaoBao Li は、判断は観測時点で成立し、証拠の失効後は成立しないという時間面を加えた。Cliff は、ギャップ記述に一文、残り(「不許可」ではなく「未判定」と記録する規則を含む)を Section 10.4 に置くことに同意した。Sriram Shankarlingam も賛成し、自身の DNS リンクトークンは何も許可しないと述べた。複数のメッセージが著者自身のドラフトや適合性テストを引用している。

    • 二者間の信頼バンドル交換がない組織間でエージェントをフェデレーションする場合。
    • 権限を判定できず拒否した場合と、操作が許可されず拒否した場合を監査で区別する必要がある場合。
    • 関連: OAuth WG: draft-ietf-oauth-spiffe-client-auth. 関連は緩やか(ワークロード識別子と OAuth クライアントの結び付け)で、資料は引用していない。