Core

A2. Actors and trust model

Status: normative. Document version 1.0-draft-1.

The provider is an OAuth protected resource and normally its own authorisation server; an implementation may split these while preserving issuer and audience boundaries. The person chooses the provider and controls consent from an authenticated first-party session.

Clients are registered as assistant, assistant_unverified, service, connector or self. Registration evidence, not the client's own assertion, determines the class. A client is assistant when the operator's assistant allowlist names the host of its Client ID Metadata Document or, for a client registered without one, names exactly every redirect URI it registers. A client that registers or publishes a loopback redirect URI is never assistant, by either path and whatever the allowlist names, because any program on the person's device can receive a redirect there, so the client's identity cannot be assured (RFC 8252 section 8.6). A redirect URI is a loopback URI when its host, as a URL parser reads it, is localhost, a name ending in .localhost or a loopback address, whatever its scheme. Any other public client, one that does not authenticate to the token endpoint, is assistant_unverified; a confidential client that authenticates with a key it registered (A6.1) is service. Only the operator assigns connector, and only the provider's own first-party clients are self. No class uses Bearer tokens: every access token is bound to the client's DPoP key (A6.3). Version 1 has no certified registry tiers.

A client's class limits the grants it may hold (A6.2), and a request beyond them fails OAuth invalid_scope:

An assistant_unverified, connector or self client never holds autonym:persist or autonym:delegate; whether an assistant or service client may hold either is the provider's policy for that client. A self client holds no grant: the person's first-party capabilities (A6.2) are not issued through the grant flow. The assistant class the allowlist gives and the operator's own classification are the only trust signals a class carries. Every client that is not assistant and that the operator has not classified appears at consent with a warning that it is unverified, whatever its class.

The provider is trusted to store/encrypt correctly, enforce grants and preserve audit evidence. The protocol does not cryptographically prevent a malicious provider from reading information it processes. Operators must have no routine decrypt-arbitrary-records interface. Device compromise, recipient copies and off-platform misuse remain outside what a grant can prevent.

The principal threats are token theft, widened/stale authority, overspent counters, unsafe inference, hidden identifier leakage, contributor replay, expired temporary context, malicious record text, compromised URL fetches and misleading portability claims. Controls are specified in A3 to A17 and the bindings. Pairwise handles reduce direct linkage; L0 is not a promise of anonymity. Purge evidence is not proof of deletion. Duress and guardian controls require future designs and cannot be claimed as v1 protection.

A2.1 Recipient registries and trust evidence

A registry can provide evidence about a recipient, but cannot grant access to a person's record. The provider's stored grant remains authoritative. Names, logos, registration metadata and client assertions are not certification. Registry unavailability cannot silently increase permission. If a future grant depends on active trust evidence, unverifiable, expired or suspended evidence fails closed. No recipient registry may expose another recipient relationship or the person's destination provider.

Checks: CORE-01, PAIR-01, CLAIM-01, OAUTH-01, CONSENT-01 and the cross-cutting controls in A15.

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