In OpenID Connect, what does the claims request parameter let a client ask for that a scope value cannot?

## Coarse bundles, fine requests OpenID Connect gives a client two ways to ask for attributes about the end user, and they sit at very different grains. - **Scope values** name a **claim set**: `profile` is fourteen claims, `email` is two. The bundle is fixed and cannot be narrowed. - **The `claims` request parameter** names **individual claims**. It is how a client asks for `name` without also being handed `birthdate`, `gender` and `zoneinfo`. Everything that makes the first approach convenient — one short value, the same everywhere — is what makes it blunt. The `claims` parameter is the fine-grained alternative, and it is OPTIONAL: a provider need not support it at all. ## The shape of the value The parameter's value is **UTF-8 encoded JSON** (form-encoded when it travels as a request parameter). At the top level it has two possible members: | Member | Meaning | |---|---| | `id_token` | claims the client is asking to have delivered in the ID token | | `userinfo` | claims the client is asking to have available from the provider's user-information response | Inside each member, a claim name maps either to `null` — meaning "I would like this, voluntarily" — or to an object that qualifies the request. That object may carry: - `"essential": true`, marking the claim as one the client's task depends on; - `"value"`, pinning a single expected value for the claim; - `"values"`, listing the values the client would accept. A claim name mapped to `null` and a claim name mapped to `{}` mean the same voluntary request. ## What `essential` really obliges This is where candidates overstate, and it is the crux of the question. Marking a claim `"essential": true` tells the provider that the client is requesting it to fulfil a specific task, and that failing to return it means the task cannot be completed. The provider may take that into account — for instance in deciding what to ask the end user for. What it does **not** do is compel a result. If the claim is not available, because the end user did not authorise its release or because the provider simply does not hold it, the provider returns the response without it and **must not generate an error** on that account, whether the claim was essential or voluntary, unless the definition of that specific claim says otherwise. An essential claim is a strong hint, not a contract. A client that treats a missing essential claim as impossible will fall over the first time it happens. ## Two preconditions 1. **Provider support.** The `claims_parameter_supported` member of the provider's configuration document says whether the parameter is honoured. When the member is absent the default is false, so a client that sends the parameter without checking may find it silently disregarded — with the same quiet failure shape as an ignored scope value. 2. **A response type that yields an access token.** Claims requested under the `userinfo` member require a `response_type` that returns an access token, because that is the credential by which the user-information side is reached at all. Asking for claims there in a flow that produces no access token asks for something the client cannot then collect. Alongside these, `claims_supported` lists the claim names a provider says it can produce. Read it as an advertisement of capability, not as a promise that any given end user has a value for any given claim. ## In the sighting recorder The nature reserve's recorder wants one human-readable label per ranger and nothing else. With scope values alone the options are bad: `openid` gives no name, `openid profile` gives fourteen claims. With the `claims` parameter the request becomes exactly what the task needs — `name`, marked essential because a record with no filer label is useless, and nothing else. The birth dates, genders and locales are never sent, so they are never stored, never logged and never in scope for a deletion request. The operational caveat stays: the provider may still return no `name`, essential or not, and the recorder needs a defined behaviour for that case — fall back to the subject identifier, say — rather than an exception in a nightly job. ## Why this is a senior question The recall half is easy. The judgment half is knowing that the parameter is optional and therefore not portable across providers; that `essential` is a signal rather than a guarantee; that a request for a claim under `userinfo` carries a response-type precondition; and that choosing between a bundle and a named-claim request is a data-collection decision, not a formatting preference. A candidate who has only wired up a quickstart will not have met the parameter at all, because quickstarts use scope values.