Subject Identifiers

## What `sub` actually names Every ID token an **OpenID Provider** issues carries a `sub` claim: the identifier that provider uses for the end user who has just authenticated. It is an opaque string — the specification gives it no internal structure a client may parse — and it is meaningful only inside that issuer's own namespace, which is why an application stores accounts against the `(iss, sub)` pair rather than against `sub` on its own. The part that catches people out is that `sub` is not a fact the provider looks up and reports. It is a **name the provider chooses to hand to a particular client**, and `subject_type` is the setting that decides how that name is chosen. The same person, authenticating to two clients of one provider in the same minute, can legitimately receive two entirely unrelated `sub` values — not because something is broken, but because the provider was configured to name that person separately for each client. ## The two values | | `public` | `pairwise` | |---|---|---| | Value seen per client | identical for every client | different for each client | | Two clients joining user tables | they match on `sub` | they find no overlap | | Who can still correlate | anyone holding both records | only the provider | | Stability for one client | stable | stable | | Typical fit | clients one organisation runs and wants to share an identity | third-party clients, or anywhere client collusion is a concern | Both values are advertised the same way: the provider lists the types it is willing to issue in `subject_types_supported`, and a client that has a preference and finds more than one type listed MAY state a `subject_type` when it registers. A provider that advertises no `subject_types_supported` is taken to issue `public` values — worth knowing precisely because it is the quiet default that permits correlation. ## What pairwise hides, and from whom - It hides the link **from the clients**. Two relying parties cannot discover that they have the same user by comparing stored identifiers. - It does **not** hide the link from the provider. The provider derives both values and must be able to reproduce each one on every sign-in, so the mapping is retained on its side for the life of the account. - It does not hide anything the user volunteers elsewhere. If both clients also ask for and store an email address, the two records join on that instead, and the pairwise subject has bought nothing. - It is not encryption. A pairwise `sub` is a different value, not a ciphertext addressed to one client; there is nothing to decrypt and nothing a client is expected to unwrap. - It is not a per-session value. The identifier is stable for that client, which is what makes it usable as an account key at all; a value that changed on every login would be useless for lookup. - It says nothing about the other claims. The profile and email claim sets a provider returns are governed by the scopes requested, not by the subject type. ## How a client ends up with one or the other 1. The provider decides which subject types it supports at all and advertises them in `subject_types_supported`. 2. Where more than one is advertised, a client MAY register a preferred `subject_type`. Where only one is advertised, the client takes what it is given. 3. Where the provider advertises no `subject_types_supported`, `public` is what applies. 4. On each authentication, the provider derives the value for that client and puts it in the ID token's `sub` claim. None of those steps is something the relying party computes. The client's job is to store the value it is handed, alongside the `iss` that produced it, and to look the user up by that pair on the next sign-in. ## Why the choice is a design question Three applications run by one organisation against one provider make the trade-off concrete. If the provider issues `public` subjects, all three recognise the same person immediately: a volunteer who also buys a ticket and makes a donation is one identity across the estate, with no linking work. That is a feature if the organisation wants a single view of that person, and a privacy leak if it does not — and it is the same mechanism either way. If the provider issues `pairwise` subjects, each application sees a stranger, and the estate has to either group those clients deliberately or accept three separate identities. The consequence worth internalising is that a subject value is a **product of configuration**, not a property of the human being. Anything a relying party has stored under one configuration stops matching if the configuration changes, and the protocol offers no migration for that. So the correlation question is answered once, before the first relying party stores anything, and the answer is then effectively fixed.