What does a valid signature on a federated identity assertion actually prove?

## The direction of the claim The single most useful discipline in this area is asking what a piece of proof actually asserts, in the direction it actually points. A verified signature asserts: *this artefact was produced by something holding the corresponding private key*. Everything else people read into it is inference layered on an assumption that only the issuer holds that key. What a valid signature therefore does **not** prove: - that a human was present, or that any credential was presented anywhere; - that an authentication occurred at the issuer at all; - that a second factor or sign-in condition was satisfied, since those are applied at issuance and issuance did not happen; - that the named account exists, is enabled, or holds the groups the assertion claims; - that the issuer would confirm it issued this, because it usually is not asked. ## What a relying party actually does When an assertion or token arrives, a relying party typically performs local checks: the signature verifies against a key it obtained in advance, the validity window has not expired, and the assertion is addressed to this relying party rather than another. Some also pin the issuer identifier and refuse assertions replayed twice. Every one of these is computed from the artefact plus previously configured material. There is no call to the issuer that asks *did you issue this?* This is not an oversight. Self-contained signed credentials exist precisely so that verification is cheap, works at scale, and continues to work when the issuer is slow or unreachable. A per-request call to the issuer would couple every sign-in to the issuer's availability and add a round trip to the critical path. The property that makes the design good is the same property a key holder exploits: acceptance depends only on the signature. ## The exceptions, and why they matter Two designs break the symmetry, and naming them is what turns this from a definition into a control-class answer. **Resolvable or reference credentials.** If what the relying party receives is an opaque handle it must resolve with the issuer before use, forgery of the artefact buys nothing: the forger cannot make the issuer's own state contain a handle it never created. The cost is exactly the coupling that self-contained tokens were invented to avoid, which is why this design tends to appear at high-value relying parties rather than everywhere. **Back-channel delivery.** Some federation profiles have the relying party fetch the assertion from the issuer over a direct channel rather than receiving it through the user's browser. This narrows the delivery path, though it does not by itself defeat a key holder who can reach that channel. ## Why lifetimes and audience restrictions do not save you A short validity window limits how long a **captured** genuine assertion can be replayed. Against someone who can sign at will it is not a control at all: they write the window themselves, and if it expires they mint another. An audience restriction limits which relying party a given assertion is for, but the forger writes that field too. Both controls constrain what somebody who **found** an artefact can do with it. Neither constrains somebody who **authors** artefacts. ## What this means when you have to make a claim Asked whether a specific admission was legitimate, the honest position from the relying party's side is that its acceptance is consistent with both a genuine issuance and a forged one, and that the distinction can only be drawn at the issuer, where in the forged case there is nothing at all. That is an uncomfortable answer, and it is the correct one. Candidates who assert that the acceptance itself proves the user signed in have inverted the direction of the claim, which is the most common single error in this whole subject. ## The design conclusion If your identity design is entirely self-contained signed credentials verified locally, then the security of every relying party reduces to the custody of one key and the honesty of everything that can invoke it. That is a defensible design, but it should be a chosen one, with the key's custody and the replacement drill treated as first-class, and with resolvable credentials preferred at the relying parties whose loss you could not accept.