⚙️ Workload identity (SPIFFE)
A workload — a CI job, a VM, a pod — already holds a credential its OWN platform issued it.
Instead of shipping it a static API key, it exchanges that credential
(RFC 8693) for a first-class, keyless identity: a short-lived JWT-SVID whose sub is a SPIFFE ID.
Honest simulation — read this first
In production, a workload's own platform (GitHub Actions, a cloud instance-identity service, a projected Kubernetes service-account token) issues its external credential, and the relying party verifies it against that platform's own published JWKS — trust anchored in a key the Lab does not control. This sandbox has no second party to run, so “Mint simulated credential” below fabricates a stand-in external token using the Lab's own signing key — the Lab is playing both the upstream issuer and the relying party with one key, exactly like the federated login lab's simulated IdP. What's fully real: the RFC 8693 exchange shape, the issuer+subject binding lookup, and the minted JWT-SVID — a genuine ES256 JWT you can verify against the Lab's existing /.well-known/jwks.json (no second key, no separate JWKS).
1. Register a binding
"I trust issuer X's subject Y; give it SPIFFE ID Z with audience A." No secret is minted here — this is a pre-registered trust relationship, exactly what a platform team configures once for a pipeline.
Your bindings
2. Federate a workload
Pick one of your bindings (or type an issuer + subject by hand), mint the simulated external credential a real platform would hand the workload, then exchange it for a JWT-SVID.
Inspect a JWT-SVID
Paste any SVID (yours from above, or a tampered copy) to see it decoded and verified.