Scopes
Scopes describe requested access. The stored grant remains authoritative: a token's scope is
advisory, and no recipient route accepts scopes. An authorisation server parses the scope of an
authorisation or token request; no recipient authorisation endpoint is released yet.
Reading
autonym:read:<domain>:<level> names a domain and a ceiling, and :declared restricts a read to
declared entries. A read scope is required even at L0, and a missing domain never implies an L0
floor. The wildcard is allowed only as autonym:read:*:L0; a specific domain may separately request
a higher ceiling, which takes precedence. Any accepted :declared makes the whole stored grant
declared-only, and mixing unrestricted and declared-only reads of one domain is refused, so
different restrictions need separate grants.
Purpose
Every complete scope set contains exactly one purpose. The categories are booking,
recommendation, safety, fulfilment, personalisation, research, care, medical,
employment and advertising, prefixed with autonym:purpose:. A set without one fails
purpose_missing; two, even identical ones, fail invalid_scope. Where a purpose has to be an
absolute URI, it is written urn:autonym:purpose:<category>.
A purpose alone gives no read, contribution, retention or delegation right. Advertising needs its own explicit consent; ordinary personalisation does not cover it, and parsing the category does not make advertising reads available.
Capabilities
Each capability scope has one meaning at issuance, and only four may be issued to a recipient, when its class may hold them. The other four are reserved to the person's own first-party clients and are never issued to a recipient:
| Scope | Who may hold it | Meaning |
|---|---|---|
autonym:propose |
Third party | Requests a contribution grant, separate from any read grant |
autonym:confirm |
Third party | Sets allow_confirmation on that contribution grant |
autonym:persist |
Third party | Permits persist_until on a read grant |
autonym:delegate |
Third party | Sets allow_delegation on a read grant |
autonym:confirm:safety |
First party | Reserved to the person's own first-party clients |
autonym:write:declared |
First party | Reserved to the person's own first-party clients |
autonym:log:read |
First party | Reserved to the person's own first-party clients |
autonym:manage |
First party | Reserved to the person's own first-party clients |
A request that mixes read and contribution, such as autonym:propose with a read scope, or asks for
a capability its client's class cannot hold, fails OAuth invalid_scope. openid and
offline_access are not scopes of this standard and are refused like any other unknown scope. The
separate client lifecycle scope, autonym:lifecycle:purge, is not a record-grant scope.
Parsing
The separator is exactly one ASCII space. Input is limited to 16,384 bytes, 128 tokens and 128 characters per domain, and nothing is trimmed, decoded or case-folded. The parser rejects unknown tokens, other whitespace and malformed boundaries, and its errors carry a fixed code and title, never the input. See consent, temporary context and portability and the published scope definitions.
Written against edition 1.0-draft-1: Scope grammar implementation