In SAML 2.0, what does a party's entityID identify, and what does it not?

## What an entityID is In SAML 2.0, `entityID` is the name a party answers to. It is carried as an attribute on that party's `<EntityDescriptor>`, and it is what every message means when it names a party rather than a person: the issuing party's `entityID` is what a message's `<Issuer>` element carries, and the intended party's `entityID` is what the element naming the assertion's intended consumer carries. It is defined as a URI. In practice deployments almost always use an absolute `https` URL, often the address where the party's own metadata document happens to be published — but that is a convention, not a rule the protocol enforces. ## What it is not Three confusions account for most of the trouble. - **Not a person.** `entityID` names an organisation, a tenant or a deployment. Who signed in is a different identifier entirely, carried in the assertion's subject. A stem or a log line that mixes the two is unreadable: one is stable for years and shared by everybody at that party, the other may be transient and is per-person. - **Not an endpoint.** The locations messages are sent to are separate values on the party's role descriptors. A party can move every endpoint it operates to a new hostname and keep the same `entityID` — and that is usually the right thing to do, because the name is what the counterparties registered. - **Not something you fetch.** The specification does not require a relying party to dereference an `entityID`, and a consumer that tries to fetch one in order to decide whom it is talking to has invented a trust mechanism the protocol does not have. Trust comes from the key a counterparty registered, not from whatever an HTTP GET to that URL returns today. ## How the comparison actually works Counterparties match `entityID` by **exact string comparison**. This is undramatic until it bites: - `https://sp.example.net/saml` and `https://sp.example.net/saml/` are two different parties; - `http://` and `https://` spellings of the same host are two different parties; - a difference in case in the path is a difference in party; - a party that regenerates its identifier during a platform migration has not migrated — it has appeared for the first time. The failure this produces is distinctive and worth recognising: sign-on fails at the consuming side even though the signature verifies, because the message named a party the consumer has no registration for, or was addressed to a spelling the consumer does not recognise as itself. ## Three identifiers in one login, and what each names | Value | Names | Changes when | |---|---|---| | `entityID` | the party — identity provider, service provider or attribute authority | essentially never; changing it means re-registering with every counterparty | | an endpoint location | where one kind of message is delivered at that party | the deployment moves, without the name changing | | the assertion's subject identifier | the person the statement is about | per person, and for some formats per session | ## Why a stable name matters more than it looks In a port community — a carrier, a terminal operator, a customs broker and a dozen hauliers exchanging the same consignment documents — every pair of parties has, at some point, registered each other by name and key. There is no central register that can rename you on everybody's behalf. So the name is the one value in the whole arrangement that is expensive to change: endpoints move with a configuration edit on your side, keys roll over with a planned overlap, but a new `entityID` is a coordinated change at every counterparty, each of which has its own change process and its own idea of how long that will take. The practical advice that follows: 1. choose a URI in a namespace you will still control in ten years, and do not tie it to a hostname you expect to retire; 2. write it once and copy it everywhere rather than retyping it, because the comparison is exact; 3. treat it as an opaque name in your own code — never parse it for a tenant name or a region, and never build a URL from it; 4. if you genuinely must change it, run both names in parallel as two registrations for the transition rather than flipping in one step. ## The one-line version `entityID` is the name of a party, matched as a string, owned for the long term. The subject identifier in an assertion names a person; the endpoint locations say where messages go. Keeping those three apart removes an entire class of confused integration tickets.