When a secret store verifies proof signed by an issuer it does not run, what does a valid signature alone establish?

## What a valid signature settles A store that accepts proof minted elsewhere does something narrow and mechanical. The caller presents a signed document. The store finds the key the named issuer publishes for signing, checks that the document was produced with that key, and checks that nothing in it has been altered since. When that passes, exactly one proposition is established: **this issuer produced this document about this subject**. That is authorship. It is not entitlement. The signature says nothing about whether the caller should receive anything, because the issuer does not hold your values and was never asked what its callers are worth to you. A store that treats a successful signature check as the whole admission decision has handed its front door to an organisation that cannot see what is behind it. ## The three decisions that stay with the store 1. **Whether this issuer is trusted here at all.** A signature is only interesting because you decided in advance to care about that issuer. Trust does not travel inside the document; it is configuration on your side, and a document from an issuer you never listed is a well-formed document from a stranger. 2. **Which subjects from that issuer you will accept.** An issuer can mint a document naming any subject inside its own domain. Accept every subject it signs and you have accepted every workload and every person that domain contains, including the ones that do not exist yet. 3. **Which local identity an accepted subject becomes.** The outside name means nothing to your rules until it is mapped onto something local. That mapping is the moment the outside world acquires a position inside yours. ## Why 'trusted issuer' is larger than it sounds Trusting an issuer is not the same as trusting the callers you had in mind while configuring it. It is trusting: - the people who administer that issuer, because they decide what it will sign; - anyone who can create a workload or an account inside that trust domain, because creation is how a chosen subject name comes into existence; - that issuer's key custody, because whoever holds its signing key can mint anything it can; - that issuer's availability and its rollover discipline, because both now sit on your admission path; - the naming convention that domain uses, because your pin is written against it and they can change it without telling you. None of that is visible in a single successful verification, which is exactly why the question gets asked. ## Where the pin is usually too broad The pin is the part of the configuration that says which caller the issuer may speak for. It is routinely written wider than the need it was written for. | what you pin | what is admitted | the usual failure | |---|---|---| | the issuer alone | every subject that issuer can mint, now and later | one new workload in their domain becomes a new caller in yours | | the issuer and a pattern over subjects | everything the pattern matches, including future names | the pattern fitted today's naming and nobody re-read it | | the issuer and one stable subject identifier | one caller | a rename on their side breaks it loudly, which is the safe direction | The third row costs more to maintain and fails in the direction you want: access disappears instead of spreading. ## A concrete shape A central platform team runs one store. A service belonging to another business unit needs one credential from it, and that unit runs its own issuer. The resulting configuration has three parts and they fail differently: - the issuer entry, which says where that issuer's published keys come from and how the copy stays current — this part fails as an outage, all at once, for every caller of that issuer; - the accepted subject, which says which caller in that domain may be spoken for — this part fails silently and in the attacker's favour when written loosely; - the local identity the subject becomes, which is what the rest of the store reasons about — this part fails as scope creep, months later. Naming which of the three a symptom belongs to is most of the production skill here. ## What the mapping does not decide The mapping settles **who the caller is** locally. What that local identity may then read is a separate rule, evaluated afterwards, and keeping the two apart is the point of having both. The common real defect is not weak verification, which is the part everyone implements. It is a rigorous check followed by a mapping onto a local identity that holds far more than the caller needed. ## Saying it in an interview The answer has three beats: the signature proves authorship; trust in the issuer is your configuration rather than a property of the document; and the mapping from outside subject to local identity is the step that actually grants something. Stopping at 'the signature is valid, so the caller is authenticated' answers a smaller question than the one asked.