When a cloud platform trusts an outside identity provider for a workload, what does the platform store and what does it not?

## What external identity trust actually configures Federation at the platform boundary is the platform agreeing to act as a **relying party**: it accepts an identity that was minted somewhere else and converts it, at the moment of the call, into one of its own. The thing people get wrong is what the setup step produces. It is not a better hiding place for a secret. It is a written-down relationship, and the relationship is the only durable artifact. A registration of this kind carries four pieces: - **Which issuer** the platform is prepared to believe — a named outside identity provider, not a caller. - **How its signature is checked**, so that an assertion signed by anything else is rejected outright. - **A narrowing condition**, so that a match means the caller you meant rather than everything that issuer is willing to sign for. - **The platform identity a match receives**, and through it the grants that identity already carries. None of those four is a secret belonging to the caller. The caller keeps its own signing relationship with its own issuer; the platform keeps a description of what it will accept. Neither side holds a value that the other could present. ## The per-call exchange At runtime the sequence is short and repeats on every call that needs a credential: 1. The workload asks its own issuer for a signed assertion naming the platform as the intended recipient. 2. It presents that assertion to the platform's exchange. No secret is sent, because none exists. 3. The platform looks up a registration for that issuer, verifies the signature against it, and applies the narrowing condition. 4. On a match it mints a **short-lived credential** carrying the identity the registration grants, and returns it. 5. The workload uses the credential for its call and discards it. The important property is in step 4: the credential is created for that exchange. The platform does not look one up, because there is nothing stored to look up. If the same fleet calls a thousand times, a thousand credentials are minted and a thousand expire, and no record of any of them is something an attacker could take and replay later. ## Stored secret against registered trust | | Stored credential model | External identity trust | |---|---|---| | What the caller keeps | A long-lived value, wherever it runs | A relationship with its own issuer | | What the platform keeps | A credential it issued and must keep valid | A registration naming an issuer and a grant | | What leaks if the caller is compromised | A value usable until someone notices | An assertion that was already spent | | What you operate | Distribution, expiry, rotation | The registration, and the issuer | | How you stop the caller | Invalidate the value everywhere it spread | Remove or tighten one registration | The right-hand column is not free. It replaces one operational burden with another: the issuer is now on the critical path, and the registration is now a grant that deserves the review a permission change gets. ## Why "nothing to rotate" is the operational point Rotation exists because a long-lived value gets copied — into a configuration file, a deployment template, an image layer, a colleague's shell history — and the only way to undo that spread is to make the value stop working. A design with no durable value has no spread to undo. That is the whole benefit, stated honestly: not that federation is cryptographically superior, but that it removes the object whose copies you were chasing. It also changes what revocation means. There is no key to invalidate, so stopping a caller is an edit to the registration: remove it, or tighten its condition, and the platform stops minting for that caller. Credentials already minted run out on their own short lifetime. This is a preventive control on new access, not a recall of what is already in flight. ## Where the risk moves Two things get harder, and a good answer says so: - **The issuer becomes a dependency.** If it cannot sign, the caller cannot obtain anything. That is a new failure domain, not an inherited one. - **The registration becomes a control point.** A registration written only against an issuer, with no narrowing, hands your platform identity to every caller that issuer will sign for. The registration is where the scope lives, so it belongs in change control alongside the grants themselves. A candidate who can say what is *stored*, what is *minted*, and what has *moved* rather than disappeared is answering at the right altitude. One who describes federation as "the key lives in a safer place now" has missed that the key stopped existing.