Another business unit asks you to trust its issuer so one of its services can read a shared credential from your store — what do you require first?

## What is actually being asked for The request sounds bounded: one service, one credential. The mechanism is not bounded in the same way. Trusting an issuer is a standing arrangement under which another organisation's administrators can produce documents your store accepts, for as long as the entry exists. The credential is the occasion; the trust relationship is the thing you are being asked to create, and it will outlive the reason for it unless you arrange otherwise. That is why this is a judgment call rather than a task. The narrow question ('can we configure this?') always has the answer yes. ## Three ways to serve the same need | option | where your trust boundary ends up | what it costs | |---|---|---| | deliver that one value into their own store, on a rotation you both accept | unchanged; they hold a copy and own it | a delivery path and a rotation both sides honour; one more copy exists | | put a small service in front of what the credential unlocks, so they call the operation | unchanged; they never hold the value | something to build, run and keep available | | trust their issuer and map a subject onto a local identity | extended to their administrators and their key custody | ongoing; the largest of the three and the hardest to take back | None of the three is right in general. The point of putting them side by side is that the third is routinely chosen without the first two being considered, because it is the one that requires no engineering. A good answer names the alternatives before accepting the trust. ## If the answer is yes, what you require 1. **A named owner on their side**, a person or team who is accountable for the issuer and reachable outside an incident. 2. **Advance notice of key rollover**, in writing, plus your own side hardened so a rollover you are not told about is survivable rather than an outage. 3. **Notice of naming changes**, because your pin is written against their naming convention and they can change it without knowing you exist. 4. **Stable subject identifiers**, so the pin cannot be moved by a rename on their side. 5. **A pin that matches exactly one service**, never a pattern that any workload created in their domain can satisfy. 6. **Its own local identity**, created for this and holding only what this credential requires — never a reused one that your own workloads also use, because that destroys attribution as well as scope. 7. **A review date and a way out**: one change that removes the trust, and prior knowledge of exactly what stops working when you make it. ## What you have taken on Be explicit about this, because it is what the decision actually trades: - their administrators can mint the subject you pinned, so their joiner and leaver discipline is now part of your admission control; - their issuer's availability sits on your callers' path, and its rollover discipline sets your worst-case verification outage; - a compromise of their signing key is an admission bypass at your store, not just theirs; - their name space grows without consulting you, so a pin written as a pattern widens by itself; - your access trail now contains callers whose real-world owner is identified by records you do not hold. ## The counter-argument, which is real Refusing every trust relationship does not produce a smaller attack surface. It produces long-lived shared values copied by hand into places nobody tracks, which is measurably worse and fails silently. So the judgment is not federate-or-not. It is: how many such relationships, on what terms, owned by whom, reviewed how often, and removable how quickly. A store with one trusted issuer has one such dependency. A store with six has six, and its own controls reduce none of them. The usable test for an existing relationship is four questions: who owns it, what may it mint, when was that last reviewed, and what happens at its next rollover. An issuer nobody can answer those about has stopped being a decision and become a fixture. ## How to present the decision Say yes or no with the terms attached, and put the terms where they will be read again — in the request record, next to the configuration, with the review date. The failure mode for this kind of approval is not a wrong answer on the day. It is a right answer whose conditions were spoken aloud, implemented once, and never checked again, so that three years later a service that no longer exists is still represented by a trust relationship that still admits anyone that domain names.