Chapter 2

Consent Data Models

Comprehensive schemas, data structures, and JSON specifications for representing consent throughout the WIA-UNIVERSAL-CONSENT ecosystem

The foundation of any consent management system lies in its data models. WIA-UNIVERSAL-CONSENT defines precise, extensible schemas that capture all aspects of user consent while enabling interoperability across systems and compliance with global regulations. This chapter provides a comprehensive reference for all consent-related data structures.

2.1 Core Consent Receipt Schema

The Consent Receipt is the fundamental unit of record in WIA-UNIVERSAL-CONSENT. It provides a complete, verifiable record of a consent transaction that can be used for compliance audits, user transparency, and consent verification. The schema is designed to be self-describing, machine-readable, and cryptographically verifiable.

The Consent Receipt schema follows the Kantara Initiative Consent Receipt Specification while extending it with WIA-specific fields for integration with other Universal standards, particularly WIA-UNIVERSAL-IDENTITY for subject identification and WIA-UNIVERSAL-TIMESTAMP for cryptographic timestamping.

{
  "$schema": "https://wia.org/schemas/universal-consent/receipt/v1.0",
  "receiptId": "wia-cr-550e8400-e29b-41d4-a716-446655440000",
  "version": "1.0",
  "jurisdiction": "gdpr",
  "timestamp": {
    "issued": "2025-01-15T10:30:00.000Z",
    "wiaTimestampToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IldJQS1UU1QifQ...",
    "timestampAuthority": "wia-tsa.org"
  },
  "subject": {
    "principalId": "wia-id-user-12345678",
    "principalIdScheme": "wia-universal-identity-v1",
    "verification": {
      "method": "email_verified",
      "verifiedAt": "2025-01-15T10:29:45.000Z",
      "assuranceLevel": "substantial"
    }
  },
  "controller": {
    "name": "Example Corporation",
    "contact": "privacy@example.com",
    "address": "123 Privacy Street, Dublin, Ireland",
    "registrationId": "IE-DPC-12345",
    "dpoContact": "dpo@example.com"
  },
  "purposes": [
    {
      "purposeId": "marketing-email",
      "purposeCategory": "marketing",
      "description": "Send promotional emails about products and services",
      "legalBasis": "consent",
      "consentStatus": true,
      "dataCategories": ["email", "name", "preferences"],
      "retention": {
        "period": 24,
        "unit": "months",
        "justification": "Marketing subscription duration"
      },
      "thirdParties": [
        {
          "name": "Email Service Provider Inc.",
          "purpose": "Email delivery",
          "country": "US",
          "transferMechanism": "standard_contractual_clauses"
        }
      ]
    }
  ],
  "collectionMethod": {
    "method": "web_form",
    "interface": "consent_management_platform",
    "version": "2.1",
    "language": "en",
    "userAgent": "Mozilla/5.0...",
    "ipAddress": "[hashed]"
  },
  "policyUri": "https://example.com/privacy-policy",
  "policyVersion": "2025-01",
  "signature": {
    "algorithm": "ES256",
    "value": "MEYCIQDvF2WgY5bN...",
    "keyId": "wia-key-2025-01"
  }
}

2.1.1 Receipt Field Specifications

Field Type Required Description
receiptId string (UUID) Yes Globally unique identifier for the consent receipt with WIA prefix
version string (semver) Yes Schema version for forward compatibility
jurisdiction string (enum) Yes Applicable regulatory jurisdiction (gdpr, ccpa, lgpd, etc.)
timestamp object Yes Timestamp information with WIA-UNIVERSAL-TIMESTAMP integration
subject object Yes Data subject identification with WIA-UNIVERSAL-IDENTITY integration
controller object Yes Data controller information including DPO contact
purposes array Yes Array of consent purposes with granular settings
collectionMethod object Yes How consent was collected (web form, mobile app, etc.)
policyUri string (URI) Yes Link to the privacy policy applicable at time of consent
signature object Yes Cryptographic signature for receipt integrity

2.2 Preference Center Data Model

The Preference Center model provides a comprehensive structure for managing user preferences across multiple consent types and communication channels. This model enables sophisticated preference management while maintaining the granularity required for regulatory compliance.

    +-----------------------------------------------------------------------+
    |                    PREFERENCE CENTER DATA MODEL                        |
    +-----------------------------------------------------------------------+
    |                                                                        |
    |   +------------------------+      +------------------------+          |
    |   |     USER PROFILE       |      |    CONSENT SETTINGS    |          |
    |   |------------------------|      |------------------------|          |
    |   | - userId               |<---->| - globalOptOut         |          |
    |   | - identityRef          |      | - categoryPreferences  |          |
    |   | - locale               |      | - channelPreferences   |          |
    |   | - timezone             |      | - vendorPreferences    |          |
    |   +------------------------+      +------------------------+          |
    |              |                              |                          |
    |              v                              v                          |
    |   +------------------------+      +------------------------+          |
    |   |  COMMUNICATION PREFS   |      |   PURPOSE CONSENTS     |          |
    |   |------------------------|      |------------------------|          |
    |   | - channels[]           |      | - purposeId            |          |
    |   | - frequency            |      | - status               |          |
    |   | - quietHours           |      | - grantedAt            |          |
    |   | - doNotDisturb         |      | - expiresAt            |          |
    |   +------------------------+      +------------------------+          |
    |                                                                        |
    +-----------------------------------------------------------------------+
Figure 2.1: Preference Center Entity Relationship Diagram
{
  "$schema": "https://wia.org/schemas/universal-consent/preference-center/v1.0",
  "preferenceSetId": "wia-pref-87654321-abcd-efgh-ijkl-mnopqrstuvwx",
  "userId": "wia-id-user-12345678",
  "identityProvider": "wia-universal-identity",
  "lastUpdated": "2025-01-15T14:22:00.000Z",
  "locale": "en-US",
  "timezone": "America/New_York",
  "globalSettings": {
    "optOutAll": false,
    "doNotSell": true,
    "doNotShare": true,
    "limitSensitiveData": true
  },
  "categoryPreferences": {
    "essential": {
      "enabled": true,
      "modifiable": false,
      "description": "Required for basic functionality"
    },
    "analytics": {
      "enabled": true,
      "modifiable": true,
      "grantedAt": "2025-01-10T08:00:00.000Z",
      "receiptId": "wia-cr-analytics-001"
    },
    "marketing": {
      "enabled": false,
      "modifiable": true,
      "declinedAt": "2025-01-10T08:00:00.000Z"
    },
    "personalization": {
      "enabled": true,
      "modifiable": true,
      "grantedAt": "2025-01-12T16:30:00.000Z",
      "receiptId": "wia-cr-personalization-001"
    }
  },
  "channelPreferences": {
    "email": {
      "enabled": true,
      "address": "user@example.com",
      "verified": true,
      "frequency": "weekly",
      "categories": ["product_updates", "security_alerts"]
    },
    "sms": {
      "enabled": false,
      "number": null
    },
    "push": {
      "enabled": true,
      "deviceTokens": ["token-ios-001", "token-android-001"],
      "quietHours": {
        "enabled": true,
        "start": "22:00",
        "end": "08:00"
      }
    },
    "postal": {
      "enabled": false
    }
  },
  "vendorPreferences": {
    "schemaVersion": "tcf-2.2",
    "vendors": {
      "vendor-google-analytics": {
        "consent": true,
        "legitimateInterest": false
      },
      "vendor-facebook-pixel": {
        "consent": false,
        "legitimateInterest": false
      }
    }
  },
  "metadata": {
    "wiaMetadataRef": "wia-meta-pref-12345",
    "createdAt": "2024-06-15T10:00:00.000Z",
    "updatedAt": "2025-01-15T14:22:00.000Z",
    "version": 15,
    "source": "preference_center_web"
  }
}

2.3 Consent Purpose Taxonomy

WIA-UNIVERSAL-CONSENT defines a standardized taxonomy of consent purposes that enables interoperability while allowing for organizational customization. This taxonomy is hierarchical, with broad categories containing specific purposes that can be further refined.

Category Purpose ID Description Typical Legal Basis
Essential essential.service Core service functionality Contract / Legitimate Interest
essential.security Security and fraud prevention Legitimate Interest
essential.authentication User authentication Contract
Analytics analytics.performance Performance monitoring Consent
analytics.usage Usage statistics Consent
analytics.debugging Error tracking and debugging Consent / Legitimate Interest
Marketing marketing.email Email marketing communications Consent
marketing.sms SMS marketing messages Consent
marketing.push Push notification marketing Consent
marketing.advertising Targeted advertising Consent
Personalization personalization.content Personalized content recommendations Consent
personalization.profiling User profiling for personalization Consent
Third Party thirdparty.sharing Data sharing with partners Consent
thirdparty.sale Data sale (CCPA-specific) Consent / Opt-out

2.3.1 Purpose Definition Schema

{
  "purposeDefinition": {
    "purposeId": "marketing.email",
    "version": "1.0",
    "category": "marketing",
    "name": {
      "en": "Email Marketing",
      "es": "Marketing por Correo Electronico",
      "de": "E-Mail-Marketing",
      "pt": "Marketing por E-mail",
      "ja": "Eメールマーケティング"
    },
    "description": {
      "en": "We will send you promotional emails about our products, services, and special offers. You can unsubscribe at any time.",
      "es": "Le enviaremos correos electrónicos promocionales sobre nuestros productos, servicios y ofertas especiales. Puede cancelar la suscripción en cualquier momento."
    },
    "legalBases": ["consent"],
    "dataElements": [
      {
        "element": "email_address",
        "category": "contact",
        "required": true
      },
      {
        "element": "first_name",
        "category": "identity",
        "required": false
      },
      {
        "element": "preferences",
        "category": "behavioral",
        "required": false
      }
    ],
    "retention": {
      "defaultPeriod": 24,
      "unit": "months",
      "maxPeriod": 36,
      "deletionPolicy": "on_withdrawal_or_expiry"
    },
    "jurisdictionSpecific": {
      "gdpr": {
        "applicableArticles": ["6.1.a", "7"],
        "requiresExplicitConsent": true
      },
      "ccpa": {
        "isSale": false,
        "isShare": false
      },
      "lgpd": {
        "applicableArticles": ["7.I", "8"],
        "requiresSeparateConsent": true
      }
    }
  }
}

2.4 Consent Transaction Records

Every consent interaction is recorded as a transaction, creating an immutable audit trail that satisfies regulatory requirements for demonstrating valid consent. The transaction record captures the complete context of each consent decision, enabling reconstruction of the consent state at any point in time.

[i] Integration with WIA-UNIVERSAL-METADATA

Consent transaction records are enriched with metadata following the WIA-UNIVERSAL-METADATA standard. This metadata enables advanced querying, analytics, and compliance reporting across the consent management ecosystem.

{
  "$schema": "https://wia.org/schemas/universal-consent/transaction/v1.0",
  "transactionId": "wia-tx-2025-01-15-00001234",
  "transactionType": "consent_grant",
  "timestamp": {
    "eventTime": "2025-01-15T10:30:00.000Z",
    "serverTime": "2025-01-15T10:30:00.123Z",
    "wiaTimestamp": {
      "token": "eyJhbGciOiJFZDI1NTE5...",
      "authority": "tsa.wia.org",
      "serialNumber": 1705315800123
    }
  },
  "subject": {
    "universalId": "wia-uid-a1b2c3d4e5f6",
    "pseudonymId": "pnym-xyz789",
    "authenticationLevel": "mfa_verified"
  },
  "previousState": {
    "purposes": {
      "marketing.email": null,
      "analytics.usage": true
    }
  },
  "newState": {
    "purposes": {
      "marketing.email": true,
      "analytics.usage": true
    }
  },
  "changes": [
    {
      "purposeId": "marketing.email",
      "previousValue": null,
      "newValue": true,
      "changeType": "initial_grant"
    }
  ],
  "collectionContext": {
    "channel": "web",
    "interface": "consent_banner",
    "interfaceVersion": "3.2.1",
    "interfaceLanguage": "en",
    "pageUrl": "https://example.com/checkout",
    "referrer": "https://example.com/cart",
    "device": {
      "type": "desktop",
      "os": "macOS",
      "browser": "Chrome",
      "screenResolution": "1920x1080"
    },
    "geolocation": {
      "country": "DE",
      "region": "Bavaria",
      "detectionMethod": "ip_geolocation"
    }
  },
  "consentText": {
    "version": "2025-01-01",
    "hash": "sha256-abc123def456...",
    "content": "I agree to receive promotional emails about products and services..."
  },
  "verification": {
    "method": "checkbox_click",
    "userAction": "explicit_opt_in",
    "confirmationDisplayed": true
  },
  "metadata": {
    "wiaMetadataId": "wia-meta-tx-001234",
    "tags": ["checkout_flow", "new_customer"],
    "processingNode": "consent-processor-eu-west-1"
  }
}

2.5 Data Exchange Formats

WIA-UNIVERSAL-CONSENT supports multiple data exchange formats to enable interoperability with existing systems while promoting the adoption of standard formats. The WIA-UNIVERSAL-DATA-EXCHANGE standard defines the canonical serialization formats and transformation rules.

    +------------------------------------------------------------------+
    |                 DATA EXCHANGE FORMAT HIERARCHY                    |
    +------------------------------------------------------------------+
    |                                                                   |
    |   +-------------------+                                          |
    |   | WIA CANONICAL     |  Primary format for WIA ecosystem        |
    |   | (JSON-LD)         |                                          |
    |   +---------+---------+                                          |
    |             |                                                     |
    |             v                                                     |
    |   +---------+---------+                                          |
    |   | TRANSFORMATION    |                                          |
    |   | ENGINE            |                                          |
    |   +---------+---------+                                          |
    |             |                                                     |
    |    +--------+--------+--------+--------+                         |
    |    |        |        |        |        |                         |
    |    v        v        v        v        v                         |
    | +------+ +------+ +------+ +------+ +------+                     |
    | | JSON | | XML  | | CSV  | |Proto | | YAML |                     |
    | +------+ +------+ +------+ +------+ +------+                     |
    |                                                                   |
    +------------------------------------------------------------------+
Figure 2.2: Data Exchange Format Transformation Architecture

2.5.1 JSON-LD Canonical Format

The canonical format for WIA-UNIVERSAL-CONSENT uses JSON-LD (JSON for Linked Data) to enable semantic interoperability and integration with knowledge graphs. This format includes context definitions that link consent data to standard vocabularies.

{
  "@context": {
    "@vocab": "https://wia.org/vocab/consent#",
    "schema": "https://schema.org/",
    "gdpr": "https://w3id.org/GDPRtEXT#",
    "dpv": "https://w3id.org/dpv#",
    "wia": "https://wia.org/ontology#"
  },
  "@type": "ConsentReceipt",
  "@id": "https://wia.org/receipts/wia-cr-550e8400",
  "wia:version": "1.0",
  "dpv:hasDataSubject": {
    "@type": "dpv:DataSubject",
    "wia:universalId": "wia-uid-12345"
  },
  "dpv:hasDataController": {
    "@type": "dpv:DataController",
    "schema:name": "Example Corporation",
    "schema:email": "privacy@example.com"
  },
  "dpv:hasPurpose": [
    {
      "@type": "dpv:Marketing",
      "dpv:hasLegalBasis": {
        "@type": "gdpr:A6-1-a"
      }
    }
  ]
}

2.6 Consent State Machine

The consent state machine defines all valid states for consent and the transitions between them. Understanding this state machine is essential for implementing correct consent lifecycle management. Each transition is recorded as a transaction, ensuring complete auditability.

                           +-------------------+
                           |                   |
                           v                   |
    +--------+         +--------+         +--------+
    |  NOT   |-------->| PENDING|-------->|GRANTED |
    | ASKED  |  ask    |        | grant   |        |
    +--------+         +--------+         +--------+
         ^                  |                  |
         |                  | deny             | withdraw
         |                  v                  v
         |             +--------+         +--------+
         |             | DENIED |         |WITHDRAWN|
         |             |        |         |        |
         |             +--------+         +--------+
         |                  |                  |
         |                  | ask_again        | ask_again
         |                  v                  v
         |             +--------+         +--------+
         +-------------|  RE-   |<--------|  RE-   |
                       |  ASK   |         | ENGAGE |
                       +--------+         +--------+

    State Descriptions:
    - NOT_ASKED: Consent has never been requested
    - PENDING: Consent request displayed, awaiting response
    - GRANTED: User has given consent
    - DENIED: User has explicitly denied consent
    - WITHDRAWN: User has withdrawn previously granted consent
    - RE_ASK: Eligible for re-engagement after denial
    - RE_ENGAGE: Eligible for re-engagement after withdrawal
Figure 2.3: Consent State Machine Diagram
State Code Processing Allowed Valid Transitions
NOT_ASKED 0 No PENDING
PENDING 1 No GRANTED, DENIED
GRANTED 2 Yes WITHDRAWN, EXPIRED
DENIED 3 No RE_ASK
WITHDRAWN 4 No RE_ENGAGE
EXPIRED 5 No PENDING

2.7 Validation and Schema Enforcement

All consent data structures must be validated against their respective JSON Schemas before storage or transmission. The validation layer ensures data integrity and enables interoperability guarantees across the consent management ecosystem.

[!] Validation Requirements

Consent data that fails validation MUST be rejected with appropriate error codes defined in WIA-UNIVERSAL-ERROR-HANDLING. Partial or malformed consent records can lead to compliance violations and should never be accepted.

// WIA-UNIVERSAL-CONSENT Validation Interface
interface ConsentValidator {
  // Validate consent receipt against schema
  validateReceipt(receipt: ConsentReceipt): ValidationResult;
  
  // Validate preference center data
  validatePreferences(prefs: PreferenceCenter): ValidationResult;
  
  // Validate transaction record
  validateTransaction(tx: ConsentTransaction): ValidationResult;
  
  // Validate purpose definition
  validatePurpose(purpose: PurposeDefinition): ValidationResult;
}

interface ValidationResult {
  valid: boolean;
  errors: ValidationError[];
  warnings: ValidationWarning[];
  schemaVersion: string;
  validatedAt: Date;
}

interface ValidationError {
  code: string;         // WIA error code
  path: string;         // JSON path to invalid field
  message: string;      // Human-readable message
  severity: 'error' | 'critical';
}

2.8 Chapter Summary

[+] Key Takeaways
  • The Consent Receipt is the fundamental unit of record, containing complete consent transaction details
  • Preference Center model enables sophisticated multi-channel preference management
  • Standardized purpose taxonomy ensures interoperability across systems
  • Transaction records create immutable audit trails for compliance
  • JSON-LD canonical format enables semantic interoperability
  • Consent state machine defines valid states and transitions
  • Strict validation ensures data integrity across the ecosystem
[i] Next Chapter Preview

Chapter 3 explores Identity Integration, covering OAuth 2.0/OIDC integration, WIA-UNIVERSAL-IDENTITY binding, pseudonymization techniques, and authentication requirements for consent operations.

Chapter 2 — Notes & References

  1. WIA Standards Public Repository (universal-consent folder), MIT License, GitHub: WIA-Official/wia-standards-public/tree/main/universal-consent — open standard initiative providing source code for simulator, spec, API, and ebook assets cited throughout this volume; serves as the canonical verification record for all primary-source citations made by the WIA standard committee in this chapter. Canonical ENUM tokens used in this volume include GRANTED, REVOKED, EXPIRED, PENDING, SUSPENDED, WITHDRAWN, KANTARA_CR, HL7_FHIR_CONSENT, ISO_29184, W3C_DPV, UMA_2_0, OPENID_UMA, GDPR, PIPA_KOREA, CCPA, CPRA, LGPD, HIPAA, FERPA, COPPA, NECESSARY, CONSENT_BASED, LEGITIMATE_INTEREST, LEGAL_OBLIGATION, PERSONAL_DATA, SENSITIVE_DATA, SPECIAL_CATEGORY, BIOMETRIC, HEALTH_DATA, RIGHT_TO_ACCESS, RIGHT_TO_ERASURE, RIGHT_TO_PORTABILITY, RIGHT_TO_OBJECT, OAUTH_2_1, OIDC, UMA_2_0, CONSENT_RECEIPT, CMP, CIAM, SELECTIVE_DISCLOSURE, DIFFERENTIAL_PRIVACY, ISO_27001, ISO_27018, ISO_27701, PIPA_2024, MY_HEALTH_WAY, MY_DATA, MAIDATA_KOREA, KISA_PIA, KCMVP.