Why should a store map an outside caller to a local identity by a stable identifier rather than a display name?
answer
- names are for people, not matching
- editable by whoever holds the account
- renaming is loud, reassignment is silent
- assigned once, never reissued
- match the identifier, display the name
basics
~20 sDisplay names are editable and reusable, so a mapping keyed on one follows the name rather than the account. Reassign the name and its new holder inherits the local identity; rename the real caller and its access silently disappears.
solid answer
~40 sA display name exists for people to read, and in most trust domains it can be changed by whoever holds the account and reissued to a different account later. A stable identifier is the opposite: assigned once, opaque, and never reused within that issuer. Key the mapping on the name and you get two failure directions. A rename of the legitimate caller breaks its access, which is loud and safe. A reassignment of that name to somebody else grants them the local identity, which is silent and is the one that matters. The store cannot tell the two apart, because all it ever sees is the name the issuer asserted. Match on the identifier and carry the name alongside as a label.
go deeper
Remember the rule and the reason: match on something that cannot be edited or handed to someone else, not on a name people read.
Explain both failure directions, and why the reassignment case produces no error anywhere while quietly granting the local identity.
Audit existing mappings for mutable match fields, and design the configuration so the readable label stays out of the matching path.
Make stable-identifier matching part of what any trust relationship must supply before it is accepted, so it is a precondition rather than a later clean-up.
## Two kinds of name, doing two different jobs Every issuer that can speak for a caller gives that caller more than one name. There is a **display name** — something a person recognises, often shaped like an address or a team-and-service string, and usually editable by whoever owns the account. And there is a **stable identifier** — opaque, assigned once when the account or workload was created, not meant to be read aloud, and never reissued to anything else inside that issuer. The two exist for different reasons. The display name is for humans reading a list. The stable identifier is for systems that must be able to say 'the same thing as last time' with no ambiguity. A mapping from an outside caller to a local identity is exactly such a system, and it is the second name it needs. ## The two directions this fails in | what changed at the issuer | what the mapping does | how you find out | |---|---|---| | the legitimate caller is renamed | stops matching; the caller loses access | immediately, as a failure nobody can ignore | | the old name is reassigned to a different account | matches the new holder; they receive the local identity | possibly never, because nothing failed | | the caller is deleted and recreated with the same name | matches the new one, which is a different principal | only if somebody happens to compare identifiers | The first row is an outage and it is the safe direction: access disappears. The other two are grants. Nothing throws an error, nothing appears in a failure report, and the store behaves exactly as configured — because it was configured to trust a string that the other side is free to move. ## Why the silent direction is the dangerous one Several things stack up here: - the store sees only what the issuer asserts, so it has no way to notice that the account behind the name changed; - reassignment is routine in normal operation, not an attack — a team retires a service and reuses the name, or a person leaves and their address is given to a successor; - an audit trail written against the display name is ambiguous after the fact, so reconstructing who actually read a value becomes guesswork; - the mapping is usually written once, during onboarding, by somebody who will not be the person reading it two years later. That combination is why this is a question at all: the failure is not exotic, it just leaves no trace. ## What 'stable' actually has to mean Three properties, and all three are required: 1. **Assigned once** for the life of the account or workload, so renames do not move it. 2. **Never reissued** to another principal, so a delete-and-recreate does not inherit anything. 3. **Scoped to its issuer**, and understood to be unique only there — two different issuers may both hand out the same-looking value, which is why a mapping keys on the issuer as well. A name that fails any one of them is display data, however official it looks. The practical way to find out is not to guess from the format: ask the issuer's owners which of the values they assert can change for the same account, and which can be handed to a different one. Anything that can be handed on is a grant to a future stranger. ## Keeping the configuration readable anyway The honest objection to opaque identifiers is that nobody can review a rule made of them. The answer is to store both and be strict about which one is load-bearing: - match on the opaque identifier, always; - carry the display name beside it as a label, refreshed when it changes; - show the label in the configuration, in review, and in the access trail; - never let the label creep into the matching path, however convenient it looks during an incident. That gives reviewers something readable without giving the other side the ability to move your grant by editing a field. ## In an interview What distinguishes a good answer is naming both directions and saying which one matters. Plenty of candidates say 'names can change'. Fewer say that the change which breaks access is the harmless one, and that the change which grants access is the one you will never see.
- How would you find out whether an existing mapping is keyed on something mutable?Ask the issuer's owners one question: which of the values you assert can change for the same account, and which can be reassigned to a different one? Anything that can change is display data. Anything that can be reassigned is a standing grant to whoever receives it next.
- Opaque identifiers make a rule unreadable in review. How do you handle that?Store both. Match on the opaque identifier and carry the display name alongside as a label, refreshed when it changes, so reviewers and the access trail have something human. The label is never what the match runs on, and an incident is exactly when people try to move it there.
A door list written by job title rather than by employee number: promote the person and their access vanishes, give the title to someone new and they walk in.
saying these in an interview costs you the question
- Assumes a display name is unique forever within its issuer.
- Thinks a rename and a reassignment fail in the same way.
- Believes the store can detect that the account behind a name changed.
- Treats an address-shaped name as an immutable identifier.
- Says an issuer would never reuse a name that was released.