In RFC 9396, what can an authorization_details entry express about a requested right that a scope string cannot?

## What a scope value can and cannot say An OAuth 2.0 `scope` is a space-delimited list of strings, and each string is opaque to the protocol. It is a label that the authorization server and the resource server have agreed on out of band. That is enough while a right is a category — read something, write something. It runs out the moment the right has **parameters**: this meter and no other, these dates, up to this amount, this kind of reading. There is nowhere in a scope string to put a parameter except inside the string, and a string with structure in it is a private encoding that every party has to parse the same way, with no protocol support and no error when they disagree. ## The shape RFC 9396 defines `authorization_details` is a JSON array of objects, carried as an authorization request parameter or as a claim inside a request object. Each object describes one right. - **`type`** is the only member the specification requires. It names the kind of right, and it determines how every other member of that entry is interpreted — so it also determines who is entitled to define the rest. - **Common members**, defined once so that types can reuse them rather than reinvent them: - `locations` — where the right applies, typically the resource's URI. - `actions` — the operations being asked for. - `datatypes` — the kinds of data in play. - `identifier` — the specific resource the right is about. - `privileges` — the level or capacity being claimed. - **Type-specific members** may be added beyond these, and their meaning belongs to the type's definition rather than to the protocol. ## What travels back The array does not vanish once consent is given. The token response carries `authorization_details` describing what was actually **granted**, which is not necessarily what was requested: the resource owner may have approved part of it, or the authorization server may have narrowed an entry by policy. A client that assumes the granted array mirrors the requested one will act on rights it does not hold. A resource server, correspondingly, decides on the granted structure rather than on a string being present in a list. ## Discovery and failure | Element | Role | |---|---| | `authorization_details` | The request parameter, and the member echoed in the token response | | `type` | The required member that selects how the entry is read | | `authorization_details_types_supported` | Authorization server metadata listing the types it understands | | `invalid_authorization_details` | The error when the array is unusable — malformed, or naming a type the server does not know | Because an unknown `type` is an error rather than something quietly dropped, a client learns immediately that a right it asked for was not understood, instead of receiving a token that silently lacks it. ## Why the structure is the point Consider an in-flat display unit for a smart electricity meter. "Read my meter" as a scope string cannot distinguish half-hourly consumption for one supply point over one billing period from a complete history of every meter on the account, and it certainly cannot express a tariff switch limited to one supply point. Two entries do express it, and each entry says which resource, which operation and which data. 1. The client composes the array and sends it with the authorization request. 2. The authorization server validates each entry against the types it supports and renders them for consent — which is where the cost shows up, because a structured object has to be turned into a sentence a tenant can actually agree to. 3. What is granted comes back in the token response, and the resource server enforces against that. ## The trade it makes - **Interpretation moves into the servers.** Every type has to be understood by the authorization server that renders it and the resource server that enforces it, and those two readings have to match. - **Consent becomes a rendering problem.** A list of labels is easy to display; a structured right needs a human sentence, per type, in every language a deployment serves. - **The types become a contract** that somebody owns and versions, and an unknown one is a hard error rather than a shrug. - **It composes rather than replaces.** A request may carry `scope` and `authorization_details` together, which is what makes incremental adoption possible at all.