Claim stability and privacy
All domains, identifiers, and values in these examples are fictional.
Imagine that, a few years from now, you move to a different mail provider. You change the address on your photo account and close your old mail account. The mail service holds [email protected] for a while and then, under its own policy, lets someone else register it. The new owner creates a photo account with that address and verifies it. The photo service now reports "email": "[email protected]" and "email_verified": true for a different account, and its new owner selects Continue with your photo account at the printer.
A printer that found accounts by email address would open yours for them, with your order history, your saved projects, and the delivery addresses you entered. Every value it received was true. The address really is verified, and it really does belong to the person signing in. It just no longer belongs to you.
What can change
Almost everything about you can change, and the claims that describe you change with it:
| Claim | How it changes |
|---|---|
name, given_name, family_name | People change names when they marry, divorce, transition, or simply prefer another form. Two different people can share a name. |
email | You change it, and an address you give up can be reassigned to someone else. The specification explicitly allows a provider to report the same address for different people at different times. |
phone_number | Numbers move between carriers and people, and a number you give up can be issued to someone new. |
preferred_username | You can change it whenever you like, and someone else can choose a name you have given up. It was never guaranteed to be unique. |
sub, with iss | Never reassigned to another person within the issuer. A pairwise value changes only if the relying party's sector does. |
OpenID Connect draws the conclusion itself. The issuer and subject, taken together, are the only claims a relying party can rely on as a stable, unique identifier for a person. Claims such as email, phone_number, preferred_username, and name must not be used as unique identifiers, whether they arrive in the ID token or from UserInfo.
So the printer keeps two kinds of information apart. The pair of https://auth.photos.example and user-2048 is the key to your account. Your name, picture, and email address are copies: useful for greeting you, showing beside your projects, and sending confirmations, and expected to change. When the new owner of [email protected] signs in, their issuer and subject match no printer account, so they are a new customer, whatever their email address says. Trust across systems showed that matching on email alone can hand an account to the wrong person. Reassignment shows it can happen even when every value is honest.
What email_verified means
It is easy to read email_verified as "this is definitely their address". The specification says something narrower. When the value is true, the provider took affirmative steps to ensure that the person controlled the address at the time it carried out the verification. How it verified, and when, are left to the provider and to whatever agreements it operates under.
That leaves the printer three questions to judge. The first is when. The photo service may have sent you a confirmation link the day you created your account, years ago. The claim does not say, and control of an address can lapse in the meantime. The second is how. One provider confirms an address with a link sent to that inbox. Another accepts addresses from a company directory. A mail provider can report its own addresses as verified because it operates those mailboxes, though, as the mail service showed, it can also reassign them. The third is who. true from a provider the printer has never assessed is only as good as that provider's process, which is why Trust across systems said a service needs to understand how its identity partners verify account information.
The printer treats only the JSON value true as verified. false, a missing claim, and any other value all mean that, as far as the printer knows, the address is not verified.
Then the printer uses the claim in proportion to what is at stake, as it did with every claim in Standard and custom claims. A verified address is good enough to receive order confirmations. On its own, it is not good enough to connect a sign-in to an existing printer account with the same address, because that hands the account to whoever controls the address now, and after a reassignment that is somebody else. Linking accounts covers how a relying party makes that connection safely. phone_number_verified works in the same way for phone numbers.
Collecting less
Every claim the printer stores is something it has to protect, keep accurate, and eventually delete, and something that can identify you to anyone who sees it. As Public and pairwise subject identifiers showed, it can also link you across services. The claim that is never requested causes none of those problems.
So the printer starts from what each feature needs. Greetings need a given name, saved projects look friendlier with a picture, and order confirmations need an email address. Where a provider supports the claims parameter, the printer asks for given_name, picture, email, and email_verified, and leaves the rest of profile alone. It does not ask for the address claim at sign-in just because it ships parcels. It asks for a delivery address at checkout, when you are deciding where this particular book should go, which may not be your home. Smaller requests also make shorter consent screens, and people are more willing to approve what they can read at a glance.
Then it keeps its copies current. Each sign-in brings updated_at with the other claims, and the printer stores it with its copies. After your last sign-in it holds 1788220800, 1 September 2026, the last time you changed your photo profile. If a later sign-in brings a larger value, something in your profile changed at the photo service, and the printer refreshes its copies. If you have edited your display name at the printer itself, the printer has to decide which version wins, for example keeping your own edit unless the photo service's details changed after you made it. Between sign-ins the copies can lag behind, which is acceptable for a greeting and a picture.
It also lets go of what it no longer needs. When a feature stops using a claim, the printer stops requesting and storing it. When you close your printer account, the copies go with it.
Last, claims stay out of places they do not belong. A sign-in log records what happened: the time, the issuer and subject, the stage, the outcome, and a correlation ID. It does not need your name, email address, or picture, and it never records a UserInfo response body or a token. The same goes for error reports and analytics. A support engineer can find your account from the issuer and subject, and a leaked log reveals far less about you.
That leaves the printer holding two kinds of information from each provider: the issuer and subject that identify your account, and a few copies that describe you. Connecting a sign-in to an account, the first lesson of Application accounts and sessions, builds the printer's account record around them.