Client Instance Assertion — SPIFFE Workload (SPIRE → OAuth)
A Kubernetes pod attested by SPIRE fetches a JWT-SVID from the SPIFFE Workload API, then exchanges it at a SPIFFE-OAuth adapter (Instance Issuer) to receive a re-minted client-instance+jwt. The re-minted assertion adds cnf.jkt (DPoP key binding), client_id, and the required typ — bridging SPIFFE workload identity into OAuth sender-constrained tokens. SPIRE's CredentialComposer cannot bind a workload-supplied public key into JWT-SVIDs during issuance (the API provides no mechanism for the workload to inject cnf.jkt at SVID mint time), so the adapter must independently verify key possession via a DPoP-style proof before embedding cnf.jkt. Without this proof step, a stolen SVID could be used with an arbitrary public key, binding the wrong key into the re-minted assertion.
The pod calls the SPIFFE Workload API over a UNIX domain socket (no credentials needed — the SPIRE Agent attests the caller via kernel-level process inspection). It requests a JWT-SVID bound to the Instance Issuer's URL as audience. The SPIRE Agent contacts the SPIRE Server to fetch a valid SVID for this workload's SPIFFE ID.
• The SPIFFE Workload API is a gRPC API exposed by the SPIRE Agent over a UNIX domain socket (default: /run/spire/sockets/agent.sock).
• Attestation is transparent — the SPIRE Agent authenticates the caller using OS-level signals (Linux namespaces, cgroups, pod UID). No credentials are passed in the request.
• The audience list MUST match the Instance Issuer's identifier. Presenting this SVID to any other service will fail audience validation.
• SPIRE issues SVIDs backed by the SPIRE Server's CA — the trust bundle (root CA certs) is what the Issuer uses to verify the SVID signature.
Step 1: FetchJWTSVID (Workload API)
application/grpc+proto
true
{
"audience": [
"https://issuer.openai.example.com"
],
"spiffe_id": "spiffe://openai.example.com/codex/pod-abc123"
}