Discovery and handles

Handles

A handle has the form autonym:<local>@<authority>. Newly issued pairwise locals are exactly 32 lower-case base32 characters. The authority is the provider's configured DNS hostname, with no port; an IP address is never an authority.

Each recipient gets a different handle and different entry references, derived under a key dedicated to each record partition, and a rotation changes a recipient's handle and every reference at once. Record identifiers stay owner-only: a recipient never receives a canonical entry ID, another client's handle or another client's grant ID. Pairwise identifiers prevent joins on identifiers; they do not make context anonymous.

A memorable public handle is optional: 3 to 30 lower-case letters, digits and single hyphens. It points a recipient towards consent; it does not reveal contents, confirm that a person exists or create read permission.

Discovery

GET /.well-known/autonym is unauthenticated and contains no person's identifier or record information. In the edition published here, it carries the protocol version, the configured issuer and authorisation server, the JWKS URI of the provider's signing key set, the REST and MCP endpoints, each null when that surface is disabled, and a role-specific capability claim (A3.3). The claim is self-declared, and a provider names only the capabilities it actually offers.

The key set at that JWKS URI holds the ES256 public keys the provider signs disclosures, receipts, purge instructions and exports with, each named by its RFC 7638 thumbprint. A retired key stays in the set with the time of its retirement, so earlier receipts still verify.

OAuth metadata is separate. Each protected resource has its own RFC 9728 document under /.well-known/oauth-protected-resource/, for example /mcp, /v1 and, for a provider offering the PDPP binding, its PDPP resource, each a distinct audience, and the authorisation server publishes RFC 8414 metadata. A client resolves the provider from a handle or a configured address, checks HTTPS and the metadata's origin, and never trusts forwarding headers as the provider's identity.

Moving providers

Moving providers carries the person's exported entries and history. The new provider creates fresh pairwise keys, handles and references, and every recipient needs new authorisation for the new audience. The old provider does not tell a contributor the destination, and never redirects API or token requests or forwards credentials there. See Export and move.

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

Read handles and discovery and the generated discovery schema.

Written against edition 1.0-draft-1: A3 Identifiers, handles and resolution