A contractor firm's identity provider cannot meet one of your validation requirements — how far do you bend, and who decides?

## The pressure is structural, so build for it The water authority onboards contractor firms continuously, and each brings an identity provider it did not choose and cannot change quickly. Some of them will not set the destination value. One will have a clock four minutes out. One will sign the response but not the assertion inside it. One will publish metadata that expired last year. In every case the request arrives the same way: *this is how our provider works, and the crew starts on Monday.* A team without a position on this makes the decision at the ticket level, under deadline, in a configuration file. Six months later nobody can say which counterparties are running on which exceptions, or why. The principal-level answer is not a list of yes and no; it is a mechanism that makes each answer local, visible and expiring. ## The mechanism: relaxations are data, scoped to one connection Three properties, and all three matter: 1. **Per connection.** A global switch flipped for one firm silently applies to every other. This is how an estate ends up with checks disabled that no customer ever asked for. 2. **Data, not code.** A branch in code cannot be audited by listing rows, cannot carry an owner, and cannot expire. A row can. 3. **With an owner, a reason and a review date.** Exceptions rot. Without a date, the temporary accommodation for one firm's 2026 provider is still there in 2029, long after that provider was replaced. Add the report that nobody asks for until they need it: every connection running on a non-default, how long it has, and who owns it. An alarm when a relaxation passes its review date turns a permanent hole into a recurring conversation. ## Ranking the requests by what they actually cost | Request | What it costs | Position | |---|---|---| | Widen clock skew | lengthens the period a message stays acceptable, and therefore how long replay-cache entries must live | grantable, bounded, with a stated maximum | | Relax the endpoint-binding checks | a message minted for one of your endpoints is accepted at another; harmless with one endpoint, not with several | grantable while you have one endpoint; re-examined the day you add a second | | Accept a response whose inner assertion is not individually signed | forces you to consume strictly the element verification covered, and narrows your library choice to one that returns it | grantable only with that guarantee demonstrated in code | | Accept expired metadata | you are trusting material the publisher has declared stale | refuse; take a fresh copy instead, even manually | | Drop the audience check | nothing ties the message to your service | refuse | | Drop single-use enforcement | a captured message stays usable for its whole window | refuse | The two refusals at the bottom are the ones worth being able to defend in a room with a commercial deadline in it, and the defence is short: one of them is what makes the message about you, and the other is what makes it usable once. ## The costs nobody counts at the time - **Your test matrix becomes per-connection.** A change to the validation path now has to be exercised against every relaxation combination live in production, not against the default path. Keep the set of permitted relaxations small precisely so this stays finite. - **The exception outlives the reason.** The provider is replaced, the firm's team changes, and the row remains. Only a review date catches that. - **Support loses the ability to reason.** *It works for everyone else* stops being informative once every connection is subtly different, and diagnosis becomes per-tenant archaeology. - **Precedent.** The second firm asks for what the first was given, and the argument that it is unsafe is now harder to make. ## What a good outcome looks like Publish the requirements as part of onboarding — what your service provider requires, what it will tolerate, and what it will not — so the conversation happens before a start date exists. Offer the tolerated set explicitly, with limits attached to each. Keep the refusals short and constant. Then make the default path the easy one: if configuring a connection correctly takes ten minutes and an exception takes a signature from a named owner with a review date, most firms will configure it correctly. That asymmetry, rather than any individual decision, is what keeps an estate of federated connections honest over years. ## The judgment being tested An interviewer asking this is not looking for a policy recital. They want to hear that you know the pressure is permanent, that you have separated the reversible accommodations from the ones that remove a security property, that you can name which is which and why, and that you have somewhere for the answer to live other than a config file and somebody's memory.