Grants and scopes

A grant records one recipient, one purpose, the selected context, limits and expiry, and has exactly one audience: the resource it was requested for. Its stored state is authoritative on every action, including every L0 and conditional read. Token scope and request filters cannot widen it.

Reading and contributing

Reading and contributing use distinct grants with separate approval, tokens and revocation, and neither implies the other. A read grant names domain ceilings and explicit keys, declared-only or confidence restrictions, a maximum number of reads, any right to keep a copy and whether it may be delegated. A contribution grant names an exact domain and key allowlist, a maximum number of events and whether the contributor may request confirmation. A request that mixes the two is refused.

A grant is requested with scopes, described on Scopes, and a contribution grant also with a structured authorisation detail naming its allowlist. Parsing a valid scope does not create consent. Version 1 confirmation takes place in the person's own app; a contributor can request a review link but cannot declare a statement on the person's behalf.

Consent and purpose

Consent shows the named recipient, the purpose category with a plain-language explanation, read or contribution permission, the selected keys and levels, expiry, limits, retention and the evidence about who the recipient is. Each choice is revocable on its own, and a new purpose needs new consent. A client's class limits what it may hold: an unverified assistant's grant lasts at most 30 days and a service's at most 72 hours (A2).

Advertising needs separate, default-off permission. This edition restricts it to directly confirmed viewing, reading or music genres, for an eligible adult's own record, with one read within 24 hours, at most L1, and no retention or delegation. Ordinary personalisation is not advertising permission, and declining advertising leaves other grants intact.

Temporary context has its own validity interval. Both that interval and the grant must permit a read.

Tokens

Every access token is a short-lived JWT bound to the client's DPoP key, valid for at most one hour and never beyond the grant. Refresh tokens are issued only for a grant that can serve more than one action, rotate on every use and never outlive the grant; reusing a spent one revokes the grant.

Delegation

Optional delegation can only narrow an approved parent read grant whose allow_delegation is true, and reserves part of its remaining read budget. Offers are target-bound, single-use and expire within five minutes. A child cannot delegate again, and revoking the parent ends every child.

Revocation

The person can revoke a read or a contribution grant independently. Revocation takes effect on the next attempted action, including retries and conditional reads. It stops future access; purge evidence records what the recipient says it deleted. See The log and revocation.

The PDPP binding

The grant model is defined independently of any one authorisation protocol. The PDPP binding (B1) maps read grants onto PDPP Core for a provider that offers it, expressing each level as a separately declared stream; contribution grants are never PDPP grants. Where B1 and the authorisation chapter differ, the chapter wins.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.

Read the grant schema or the PDPP binding.

Written against edition 1.0-draft-1: A6 Authorisation