A standard way to ask, decide,
remember and respect.
ADPC creates a machine-readable exchange between a service and the software acting for the user. The service declares the data-protection choices it needs. The user-side tool presents those choices, supports the person, remembers the decision and communicates the result back.
withdraw=marketing
One communication layer.
Five steps. All rights covered.
From the moment a service makes a request to the moment the decision is applied and recorded, ADPC handles every step in a standardised, auditable way.
The service describes the request
A website, app, IoT device or other service describes what it wants to do in a structured format. The request should be clear enough for a person to understand and precise enough for software to process. For example: “Allow us to measure site usage with analytics” or “Allow this device to collect motion data for training feedback.”
The user-side tool receives the request
The request is discovered by a browser, operating system, app, personal assistant, guardian tool or other user-trusted software. On the web, this can happen through an HTTP header, a linked consent-requests resource or a JavaScript interface. In IoT or pervasive environments, ADPC can be transported through other protocols, including Bluetooth.
The person decides with support
The user-side tool can present the request in a consistent, accessible and context-sensitive way. It can use age-appropriate language, accessibility features, translations, privacy dashboards, personal rules or trusted assistance. For children, the request can be routed to a guardian while giving the child an age-appropriate explanation.
ADPC communicates the decision
The tool communicates the result in machine-readable form. The decision may be consent, refusal, withdrawal of earlier consent, objection to processing, or a combination of specific choices. ADPC can express “withdraw all”, “object to direct marketing”, “consent to analytics only”, or similarly structured choices depending on the context.
The service applies and records the result
The controller, CMP, CMS or device-side system applies the decision and keeps the necessary evidence. The user-side tool can also keep a record, making later review, withdrawal and auditing more practical. The same decision can be reused when the same request appears again.
ADPC is not tied to
one interface or protocol.
The design principle is protocol flexibility with rights consistency. The same communication logic extends across environments, from web browsers to connected devices to AI-assisted systems.
Web: HTTP and JavaScript
A service exposes a consent-requests resource and signals its availability to the browser via an HTTP header. The user-side software presents the request and communicates the decision through the ADPC header or an equivalent JavaScript interface. Compatible with existing web stacks.
Browser extensions and apps
ADPC can be implemented by browser extensions, operating systems, mobile apps and personal assistants. User-side software manages preferences, remembers decisions and communicates choices without requiring interaction on every site visit.
IoT, mixed reality and beyond
ADPC’s communication logic can be transported through other protocols for IoT devices, robotics, immersive systems and AI-mediated interfaces. The legal and design goal remains: rights-relevant choices should be understandable, machine-readable, auditable and under meaningful user control.
See the specification
and examples.
The specification provides technical details, conformance notes and implementation examples for developers, CMPs, CMSs and user-agent providers.