Unified Data Consent Framework

• The Unified Data Consent Framework is an interoperable, fine-grained system enabling human-centric, legally compliant management of consent across heterogeneous digital ecosystems.
• It employs key components such as user agents, data controllers, ontology services, and standardized messaging protocols to automate consent decisions and ensure auditability.
• The framework integrates regulatory requirements from GDPR, CCPA, and ePrivacy while supporting extensibility and cross-domain deployment through modular, vocabulary-agnostic mechanisms.

A unified data consent framework is a set of interoperable, standardizable, and automatable technical and semantic mechanisms enabling human-centric, fine-grained, and legally compliant control, communication, and enforcement of data processing rights, consent preferences, privacy metadata, and policy enforcement across heterogeneous digital ecosystems. Such frameworks operationalize rights to privacy and agency by providing formal means to represent, exchange, enforce, and audit consent, spanning personal data collection, use, withdrawal, and cross-jurisdictional obligations under regulations such as GDPR, CCPA, and ePrivacy (Human, 2022).

1. Architectural Overview and Component Roles

The canonical architecture for a unified data consent framework, as crystallized in ADPC (Human, 2022), is composed of a bidirectional, policy-driven interaction between User Agents (UA) and Data Controllers (DC), with support for extension via Ontology Services and external systems.

Diagrammatic layout (roles and flows):

+----------------------+ +----------------------+ | User Agent |<======>| Data Controller | | (Browser/PDPCAS) | ADPC | Backend/Consent | | | HTTP | Management API | | • UI / Policy Editor| Header | • Policy Engine | | • Local Consent DB |<–JSON>| • Consent Store | | • Ontology/Glossary | | • Enforcement Hooks | +----------------------+ +----------------------+ ∧ ∧ Messaging Storage Layer (HTTP, JS) & Enforcement | | +----------------------+ +----------------------+ | Ontology Service / | | External Systems | | Vocabulary Registry | | (CRM, Analytics, DSP)| +----------------------+ +----------------------+

• User Agent (UA): Hosts UI for consent and policy editing, local storage of consent records, ontology browsing, and translation of user actions to ADPC-standardized messages.
• Data Controller Backend: Implements a policy engine that parses ADPC-compliant messages, matches against stored policies and consents, and issues allow/deny directives via enforcement hooks.
• Consent Store: Persists tuples indexed by user, data category, purpose, time, and status.
• Ontology Service: Providers and consumers are decoupled from specific vocabularies by use of a managed registry for all data categories, purposes, and legal bases.

This modular separation enables integration with additional systems (e.g., CRM, analytics, DSPs), and is compatible with transports such as HTTP, JavaScript APIs, and, via extensibility, IoT protocols (CoAP, MQTT).

2. Formal Data Model and Policy Semantics

Universes

• $U$: User agents
• $D$: Data categories (e.g., “analytics,” “ad-profiling”)
• $P$: Processing purposes (e.g., “marketing,” “functional-cookies”)
• $T$: Time domain (timestamps)
• $$S = \{\text{grant}, \text{deny}, \text{withdraw}, \text{object}\}$$

Consent Record

$$C \in \mathcal{C} = U \times D \times P \times T \times S$$

$C = (u, d, p, t, s)$

Privacy Metadata

$\mathcal{M} = U \times D \times P \times KV$

Where $KV$ is a finite key–value map (e.g., “legalBasis”, “retentionPeriod”, “thirdParties”).

Policy Rule

$$\rho = (\mathit{cond},\,\mathit{action},\,\mathit{priority}) \in \mathrm{Cond} \times \{\text{allow}, \text{deny}\} \times \mathbb{N}$$

• Rules are partially ordered by priority, forming a lattice.
• Conflict resolution: Select rule(s) of highest priority.

Consent Status Combination

$$\mathsf{combine}(\{s_1, ..., s_n\}) = \begin{cases} \text{deny}, & \text{if any } s_i = \text{deny}\ \text{withdraw}, & \text{else if any } s_i = \text{withdraw}\ \text{grant}, & \text{if all } s_i = \text{grant}\ \text{object}, & \text{otherwise} \end{cases}$$

This formal model permits precise, automatable representation of data-subject consent for any combination of entities, categories, and purposes, fully versioned over time.

3. Messaging Protocols, API Specification, and Wire-Formats

HTTP Header–Based Protocol

• ADPC-Request: JSON object in HTTP header or JS API call, expressing queries over data category/purpose.
• ADPC-Response: Corresponds to exact decisions per query (grant/deny with timestamp).

Example (Request):

{ "@context": "https://adpc.org/context/v1", "messageType": "ConsentQuery", "requests": [ { "requestId": "r1", "dataCategory": "analytics", "purpose": "usageStats" }, { "requestId": "r2", "dataCategory": "ads", "purpose": "profiling" } ] }

Example (Response):

{ "@context": "https://adpc.org/context/v1", "messageType": "ConsentResponse", "responses": [ { "requestId": "r1", "status": "grant", "timestamp": "2024-05-10T12:34:56Z" }, { "requestId": "r2", "status": "deny", "timestamp": "2024-05-10T12:34:56Z" } ] }

JavaScript API

• UA exposes: navigator.adpc.sendRequest
• DC registers: window.onADPCRequest
• Both use structured JSON payloads matching the header schema.

JSON-LD Consent Record

{ "@context": { "adpc": "https://adpc.org/vocab#", ... }, "@id": "user:alice", "hasConsent": [ { "dataCategory": "analytics", "purpose": "usageStats", "status": "grant", "timestamp": "2024-05-10T12:34:56Z" }, ... ] }

This wire format is both human- and machine-readable, vocabulary-agnostic (new data categories/purposes are IRIs), and immediately serializable for storage, audit, or compliance evidence.

4. Enforcement Lifecycle Algorithms and Flow

Consent enforcement is automated via a standard lifecycle:

1. User Agent issues a ConsentQuery (e.g., on visiting a website or initiating a device interaction).
2. Data Controller’s policy engine:
   • Looks up relevant consent records in the Consent Store.
   • Applies lattice semantics to combine possibly conflicting statuses.
   • Returns explicit ConsentResponse to UA.
3. UA enforces—e.g., allows or blocks tracker scripts, cookies, or data sharing—based on the response.

Pseudocode (in algorithmic notation):

\begin{algorithmic}[1] \Procedure{HandleADPCRequest}{req} \State responses %%%%6%%%% [] \ForAll{r in req.requests} \State records %%%%7%%%% QueryConsentStore(r.user, r.category, r.purpose) \If{records = %%%%8%%%%} \State status %%%%9%%%% \textbf{deny} \Comment{default deny} \Else \State status %%%%10%%%% combine(\{rec.status \mid rec\in records\}) \EndIf \State responses.append(\{r.requestId, status, now()\}) \EndFor \State \Return \{ messageType: "ConsentResponse", responses \} \EndProcedure \end{algorithmic}

Flowchart (textual):

• UA → ConsentQuery → Policy Engine
• ↓ Lookup Consent Store
• ↓ Combine statuses
• ↓ ConsentResponse → UA
• ↓ UA enforces allow/deny on-action (e.g., blocks trackers)

Default-deny if no record is found enables a fail-closed stance, which is required for strong privacy guarantees.

5. Legal Mapping and Interoperability

ADPC’s semantic and transport layer unifies major regulatory regimes:

• GDPR Art. 6(1)(a): “grant” = explicit, informed opt-in
• GDPR Art. 21(2): “object” = objection to processing on legitimate interest legal basis
• ePrivacy (2002/58/EC Art 5(3)): ADPC HTTP/JS headers are interpreted as “appropriate settings”
• CCPA: “doNotSell” general signal expressed as ADPC event, directly supporting opt-out
• Vocabulary-agnostic Interop: Supports plug-in of Transparency & Consent Framework (TCF/IAB), Global Privacy Control (GPC), and binary consent semantics
• All consent, withdrawal, and objection actions are fully timestamped and versioned for audit and legal defense.

Thus, ADPC operationalizes compliance and can serve as authoritative evidence for regulatory demonstration (“demonstrability,” GDPR Art. 7(1)).

6. Extensibility and Multi-Domain Deployment

The ADPC-based unified consent framework is explicitly constructed for future-proof extensibility:

• Ontologies: Data categories and purposes are managed via extensible IRIs; new vocabularies require no protocol change.
• Policy Language: Policy rules ($\rho$) may include arbitrary predicates—e.g., “timeOfDay,” “deviceType.”
• Modularity: Enforcement Hooks support plug-in modules (e.g., IoT containers, mobile SDKs).
• Protocol Agnosticism: JSON-LD schemas and ADPC headers are portable to CoAP, MQTT, and other non-HTTP transports.
• Versioning: All protocol elements include “specVersion” fields.
• Legal/technical mapping: New regions or regulations can be mapped by extending the ontology and policy mapping only.

This enables deployment across web, IoT, mobile, and sector-specific stacks, avoiding fragmentation into incompatible, domain-specific consent silos.

7. Impact and Role in Replacing Legacy Solutions

The unified data consent framework realized by ADPC is:

• Bidirectional (data subject <-> controller)
• Declarative, policy-driven, and vocabulary-agnostic
• Aligned with GDPR, CCPA, and ePrivacy by construction
• Extensible to new vocabularies, purposes, and enforcement hooks
• Automatable at scale (header-based, API-driven)
• Designed to subsume and replace legacy approaches (cookie banners, Do Not Track, Global Privacy Control) with a single interoperable umbrella

This architecture provides not only robust compliance and technical interoperability but also human-centric control and auditability across all processing contexts, enabling a coherent, unified data consent regime suitable for modern, distributed, and cross-jurisdictional data ecosystems (Human, 2022).