When you stand in for a venue operator's identity provider in tests, why must the stand-in really sign its assertions?

## The design decision, not the tool choice The useful question is not which stub server you run. It is what the stand-in has to be **faithful** about. A federated sign-in is a trust decision, and the whole decision rests on a cryptographic signature made by a party you do not control. If your stand-in does not sign, the only way your endpoint accepts its output is if you turn signature verification off in the test profile — and the moment you do that, the test exercises a configuration that will never run in production and cannot fail for the reason production would. So the stand-in generates a keypair, the suite registers the public half against a test connection as that venue operator's assertion-signing certificate, and every fixture is signed for real. The keypair is throwaway, generated per suite run, and is emphatically not the service provider's own signing or decryption key and not the TLS certificate on the endpoint — those are different keys with different owners and different rotation stories. ## Faithful about what, fake about what | The stand-in must be faithful about | It may fake entirely | |---|---| | Producing a real signature over the real bytes | Any login screen or password prompt | | The element the signature covers | Whether a human was present | | `AudienceRestriction` naming your `entityID` | The venue's directory or HR system | | `Conditions` and `SubjectConfirmationData` `NotOnOrAfter` | Multi-factor, consent, or risk checks | | A `NameID` and the attributes your mapping reads | Session state at the identity provider | | `InResponseTo` echoing a request you issued | Any endpoint your code never calls | The test is not about the venue operator's authentication quality; it is about what your service provider does with what arrives. ## The negative cases are the deliverable Once the stand-in signs, a single fixture builder with overrides yields the suite that actually matters: - **Signed by the wrong key** — a second, unregistered keypair. Must be refused as a signature failure, not as a parse error. - **Wrong audience** — `AudienceRestriction` naming a different service provider. This is the check that catches an assertion minted for somebody else's tenant. - **Wrong issuer** — a message whose `iss` is a venue connection other than the one it was posted for. - **Unsigned** — the document with the signature stripped. Must be refused, never silently accepted as "nothing to verify". - **Expired** — a `NotOnOrAfter` already in the past at the test's clock position. - **Uncorrelated** — an `InResponseTo` naming a request identifier you never issued. - **Replayed** — the byte-identical accepted message posted a second time. Each asserts a **specific** outcome. "It threw" is not an assertion: a typo in the fixture builder also throws, and a suite that only checks for failure will happily stay green after the check under test has been deleted. Assert the rejection reason and the response the endpoint gives, and assert that no local session was issued. ## The trap in "it rejected it" The subtlest defect this suite catches is a message that is validly signed but signed over the wrong part of the document — a structure that verifies cleanly while the data your code reads comes from somewhere the signature never covered. Your stand-in can produce that shape deliberately because it holds the private key. A recorded fixture from a real counterparty never will, because a real counterparty never sends one. ## Where this stops being yours Two boundaries are worth stating out loud. First, the rules a signature must satisfy — what must be covered, how encryption composes with it — are the specification's, and your test asserts conformance to them rather than restating them. Second, how you start a stub server, tell it which requests to answer, and whether it runs inside or outside the test process is generic tooling that has nothing to do with identity; the identity-specific part is what the stand-in signs, what it claims, and which mutation of it you expect to be refused. ## What good sounds like "We generate a keypair per suite run and register it as that connection's signing certificate, so the stand-in really signs. Then the value is in the mutations: wrong key, wrong audience, wrong issuer, unsigned, expired, uncorrelated, replayed — each one a named test asserting a specific refusal and no session. A double that cannot sign forces you to disable the verifier, and then the test proves nothing about the code that runs in production."