Client Instance Assertion — Self-Acting (client_credentials)
An AI agent workload authenticates itself using a Client Instance Assertion JWT, receiving a DPoP-bound access token where the instance is the principal — no user delegation, no act claim. This is the 'self-acting' case.
The client instance — a running container in Kubernetes — requests a Client Instance Assertion from its Instance Issuer. The issuer authenticates the runtime via platform attestation (e.g., Kubernetes service account token, SPIFFE SVID) and verifies the runtime is authorized to claim the given client_id.
• §7.1: The issuer MUST authenticate the runtime before minting. Common pattern: thin OAuth adapter wrapping a SPIFFE JWT-SVID.
• §7.1: The issuer MUST refuse to mint an assertion for a client_id the runtime is not authorized to claim.
• The request names the target AS as audience — this prevents cross-AS replay of the resulting assertion.
• Client metadata (instance_issuers array) is what authorizes this issuer to attest instances of this client.
Step 1: Request Instance Assertion
application/x-www-form-urlencoded
workload.openai.example.com
client_id=https%3A%2F%2Fopenai.example.com%2Fcodex&audience=https%3A%2F%2Fas.example.com