Consent, temporary context and portability

Edition 1.0-draft-1 defines separate permissions for reading and contributing, time-limited context and portable records. The service, recipient integrations and conformance certification are not available yet.

A provider you choose

A compatible service should speak the open protocol to your chosen provider. It should not need a proprietary connection to Autonym. The protocol uses autonym: identifiers. Changing providers should preserve your portable record, with any unsupported data explained before you move.

Advertising is a separate choice

A service could ask to use selected interests to choose advertisements. That needs its own explicit permission, separate from recommendations or ordinary personalisation. Advertising permission is specified as off by default. This edition admits only directly confirmed viewing, reading and music genres, for an eligible adult's own record: one read within 24 hours, maximum L1, declared values only, with no retention, delegation or onward-sharing right. Declining it leaves a separately approved non-advertising grant intact.

The draft names this purpose autonym:purpose:advertising. The scope parser recognises it, but that does not authorise a read. Advertising grants remain unavailable until the consent and data eligibility controls are implemented and verified. Sensitive information is not made eligible by a scope string.

A grant identifies the recipient, selected context, detail, purpose, expiry and any permission to keep a copy. The provider records and enforces that choice. A service's own consent manager cannot replace an active provider grant. A different purpose needs a new choice.

No resale, advertising identifiers or cross-recipient correlation service is permitted. Permission to choose an advertisement does not imply permission to send your context to an advertising exchange. Autonym's websites continue to have no advertising or tracking scripts.

Revoking a grant stops future reads through the provider. It cannot erase copies already held by a recipient. A purge request and its acknowledgement are separate evidence, not a guarantee that no copy remains. Purpose limits also depend on recipients honouring their obligations after receiving data; a protocol cannot prevent every off-platform misuse.

Temporary context sits alongside lasting preferences

A family holiday, an injury recovery period or a business trip can change what is useful for a while. The published draft defines a temporary preference with an explicit end date, without rewriting the lasting record. You choose whether it is active and which situation it applies to.

An entry becomes eligible at its start instant and stops being eligible at its end instant. Its recipient grant must also be valid. After expiry, the eligible lasting preference applies again. History is retained according to the record's retention rules; expiry is not a promise of deletion. Conflicting temporary choices need your resolution. A temporary preference cannot silently remove a safety-critical fact, such as an allergy.

Examples of planned uses include a week of family travel, six weeks of reduced walking, a three-day business trip, a festival weekend or a month without alcohol. These examples are not live integrations. A calendar or booking import can suggest context, but source and confirmation remain visible. Derived or cached context must not keep an expired temporary state active.

Services can contribute as well as read

Imagine a streaming service contributing viewing activity to your provider, followed by a second service requesting selected preferences. This illustrates a possible use of the protocol; it is not an available integration.

Contribution and reading need separate permissions. A service allowed to contribute cannot read your record unless you also grant that right. Contributions retain their source and timestamps and pass through the proposal and review process. They cannot silently overwrite a fact you declared or turn an inference into your confirmed preference. Continuous contributions can be stopped.

You choose raw activity history, reviewed preferences or both. Sharing a reviewed preference does not mean sharing its raw history. A derived entry whose inputs are outside the grant is withheld under the current draft; a separately confirmed declared preference can be shared on its own. The source service does not get to see which competitors read your record or where you move it.

Portability claims must say what works

Capabilities are claimed by role. A provider claims Core, Write, Portable or Delegated, and a recipient claims Read, Contribute or Reciprocal. Consent and reading sit in Core, accepting contributions builds on Write, and export, import and migration sit in Portable. Capability claims are self-declared and describe supported behaviour; they are not certifications.

A read-only integration can accurately describe what it reads. It cannot claim full portability. No export means no full portability claim. A Portable provider needs both export and import; a recipient claiming reciprocal portability needs both directions for the categories it declares. Claims must name the role, version, supported categories, tests and limitations.

Portability covers supported user data, not a service's model weights or ranking algorithms. Moving a record preserves its portable entries, provenance and time limits, or reports what cannot be carried. Old tokens and imported consent history do not automatically authorise access at a new provider. Users need a valid authorisation flow there.

What is specified and what is not implemented yet

Edition 1.0-draft-1 specifies temporal schemas, advertising eligibility, separate contribution events, portability formats and role-specific capability claims. The reference repository tests the generated schemas, selected policy checks, the disclosure compiler library, a signature verifier library and the published test vectors, and has integration tests of its provider against real storage. Stored-grant enforcement, the transactional read path, recipient APIs, signed exports and a public conformance runner are not implemented yet. No certification badge is available.

Read the consent and advertising rules, temporary context, versioning and changes and the implementation status.

Written against edition 1.0-draft-1: A17 Conformance and change process