In OpenID Connect, which claims do the profile and email scope values request, and which do they not?

## A scope value is a pre-agreed bundle In OpenID Connect a scope value on the authorization request does two different jobs depending on which value it is. `openid` switches the identity layer on. `profile`, `email`, `address` and `phone` each select a **claim set** — a fixed, specification-defined group of attributes about the end user. The client does not name the attributes; it names the bundle, and the bundle's contents are the same at every conforming provider. All four are **OPTIONAL** scope values. A provider is a conforming OpenID Provider without supporting any of them, and advertises the ones it does accept in the `scopes_supported` member of its configuration document. ## The four claim sets, exactly | Scope value | Claims it requests | |---|---| | `profile` | `name`, `family_name`, `given_name`, `middle_name`, `nickname`, `preferred_username`, `profile`, `picture`, `website`, `gender`, `birthdate`, `zoneinfo`, `locale`, `updated_at` | | `email` | `email`, `email_verified` | | `address` | `address` | | `phone` | `phone_number`, `phone_number_verified` | Fourteen claims in `profile`, two in `email`, one in `address`, two in `phone`. Three details in that table are worth saying out loud: - **`profile` is a claim name as well as a scope value.** The `profile` claim is a URL for the end user's profile page; the `profile` scope value is the request for the whole bundle that contains it. Same word, two objects. - **`email_verified` and `phone_number_verified` are booleans about the provider's own verification**, and they travel with their value claim rather than being separately requestable by scope. - **`address` is a structured claim**, not a string, and it is the only member of its claim set. ## What no scope value selects The subject identifier is not scope-selected: an ID token identifies the end user whether or not any of these four values was asked for. Claims outside the standard set — anything a deployment invents for its own purposes — are not selected by these scope values either. And a scope value is a **request**, not a guarantee: a provider returns the claims it holds and is permitted to release, and a request for `profile` at a provider that stores no birth date simply comes back without `birthdate`. ## Why the width matters The mapping is all-or-nothing, and that is the trap. There is no scope value for "just the display name". A client that needs one name asks for `profile` and receives thirteen further claims it never wanted, including two — `birthdate` and `gender` — that most privacy regimes treat as sensitive personal data the moment they land in a database. Run the nature reserve's species-sighting recorder through it. Each sighting record needs a label saying which ranger filed it. The developer wants a human-readable name rather than an opaque identifier, adds `profile` to the request, and ships. From that day the recorder receives a birth date, a gender, a time zone, a locale, a profile-page URL and a picture URL for every ranger on the reserve, stores whatever its user table happens to have columns for, and writes the rest into a log. Nothing fails. There is no error, no warning and no ticket. A year later somebody asks which personal data the reserve holds, and the answer is a surprise to everyone. The defect is not a bug in the code. It is a request that asked for more than the task needed, and the request is where it has to be fixed. ## Asking narrower There are two honest ways out, in order of preference: 1. **Do not ask.** If a stable per-user key is enough for the label, `scope=openid` alone is the whole request and the recorder holds no personal attributes at all. 2. **Ask by claim name.** Where the provider supports it, an individual claim can be requested by name instead of by bundle, which is how a client asks for `name` without also receiving `birthdate`. What is *not* a way out is filtering after the fact. Discarding the unwanted claims in application code still means they crossed the network, sat in a response body, and very probably appeared in a log line written before the filter ran. ## The interview version of this Being able to recite fourteen claim names is worth little on its own. What an interviewer is checking is whether the candidate knows the mapping is fixed and coarse, and therefore treats the scope list as a data-collection decision made at integration time rather than as boilerplate copied from a quickstart.