Privacy Preference Declaration Taxonomy

4.1. Data Type (What)

Defines the nature of the data being collected, used, or transmitted.¶

Examples:¶

• temperatureReading¶

• videoCapture¶

• locationCoordinate¶

• audioTranscript¶

• deviceIdentifier¶

• healthStatus¶

This dimension aligns with data classification in privacy laws and informs sensitivity.¶

4.2. Purpose (Why)

Describes the rationale for processing the data.¶

Examples:¶

• coreFunctionality (e.g., heating control)¶

• analytics¶

• advertising¶

• securityMonitoring¶

• personalization¶

• diagnostics¶

Each purpose can be mapped to categories of lawful basis for processing under regulations like GDPR (e.g., contract, consent, legitimateInterest).¶

4.3. Action (How)

Specifies what is being done with the data.¶

Subclasses:¶

• collection (retrieval or ingestion)¶

• usage (processing or decision-making)¶

• transfer (sharing externally)¶

• retention (storage over time)¶

• deletion (erasure procedures)¶

These actions enable both auditing and fine-grained controls.¶

4.4. Source and Destination (Where and To Whom)

Defines the data origin and endpoint.¶

Source may be, in the abstract:¶

• userInput¶

• sensor¶

• inferred (e.g., derived from other data)¶

• thirdPartyImport¶

Destination may include, in the abstract:¶

• localProcessing¶

• cloudStorage¶

• manufacturerServer¶

• thirdPartyPartner¶

• dataBroker¶

Concrete examples of these abstract categories of source and destination may also be used, such as [RFC3986]. This classification enables constraints on data flow (e.g., local-only, no third-party sharing).¶

5.1. Example OWL Classes

<owl:Class rdf:ID="DataType"/>
<owl:Class rdf:ID="temperatureReading">
  <rdfs:subClassOf rdf:resource="#DataType"/>
</owl:Class>

<owl:Class rdf:ID="Purpose"/>
<owl:Class rdf:ID="coreFunctionality">
  <rdfs:subClassOf rdf:resource="#Purpose"/>
</owl:Class>

<owl:ObjectProperty rdf:ID="hasPurpose">
  <rdfs:domain rdf:resource="#DataHandlingAction"/>
  <rdfs:range rdf:resource="#Purpose"/>
</owl:ObjectProperty>

6.1. Sample Policy Statement (JSON-LD)

{
  "@context": "http://example.org/ppd-taxonomy",
  "@type": "Policy",
  "appliesTo": "device:smart-thermostat-123",
  "allows": {
    "action": "collection",
    "data": "temperatureReading",
    "purpose": "coreFunctionality",
    "destination": "localProcessing"
  },
  "prohibits": [
    {
      "action": "transfer",
      "data": "temperatureReading",
      "destination": "thirdPartyPartner"
    },
    {
      "action": "collection",
      "data": "locationCoordinate"
    }
  ]
}

7.1. Tamper resistance

Devices must not forge or misrepresent declared purposes. Term identifiers MAY include cryptographic hashes for integrity. All entries MUST be tamper-resistant and digitally signed where applicable. Devices SHALL reject policies using unrecognized or invalid terms.¶

7.2. Immutable references

Policy enforcement relies on exact matching; hash-based identifiers may be used.¶

7.3. Cross-device reasoning

Shared taxonomy supports detecting conflicts or inconsistencies in multi-device settings.¶

8.1. Purpose and Justification

The Privacy Taxonomy Registry described in this document serves as the authoritative catalog of privacy-related semantic terms used across the Privacy Preference Declaration (PPD) architecture. Managed under the Internet Assigned Numbers Authority (IANA), this registry provides a consistent, governed vocabulary to ensure interoperability, enforcement, and semantic alignment among privacy declarations, devices, and policy engines.¶

Unlike many traditional IANA registries that define protocol-level constructs such as status codes or media types, the Privacy Taxonomy Registry defines semantically rich terms suitable for reasoning over privacy constraints. Each term is designed to be both human-readable and machine-processable, enabling automated policy enforcement, auditing, and semantic validation in distributed environments like home networks. The registry helps prevent semantic drift, ensures privacy declarations are interpretable across vendor ecosystems, and provides a compliance anchor point for policy analysis and device certification. It supports a unified approach to policy expression that is extensible yet constrained by formal definitions, such as those expressed in OWL-DL. This registry distinguishes itself by supporting semantic reasoning and structured validation, not just name-value mappings. It is foundational to privacy-preserving automation.¶

8.2. Registry and Extension Mechanism

The success of the Privacy Preference Declaration framework depends on a shared, extensible, and authoritative vocabulary of privacy-related concepts. A unified taxonomy ensures that:¶

• Users can write meaningful, enforceable policies with well-understood terms.¶

• Device manufacturers can interpret and comply with these policies using standard semantics.¶

• Policy processing engines can reason over device declarations and user constraints for compatibility, conflicts, or enforcement.¶

Without a centralized governance model, the ecosystem risks semantic drift — where different devices interpret similar terms differently, or invent new, incompatible terms — undermining both interoperability and policy clarity.¶

8.3. Registry Structure

Each entry in the registry MUST include the following fields:¶

• term_id: Globally unique identifier (e.g., ppd:purpose.analytics, ppd:dataType.temperature)¶

• category: One of: DataType, Purpose, Action, Source, Destination¶

• definition: Human-readable description of the term¶

• owl_definition: OWL-DL class or property definition¶

• examples: At least one real-world usage scenario¶

• status: Enum: active, deprecated, or experimental¶

• submitted_by: Name of contributing entity (organization or individual)¶

• date_registered: ISO timestamp of official inclusion¶

• version: Semantic versioning identifier (e.g., 1.0.0)¶

• references: Optional legal or technical citations (e.g., GDPR, RFCs)¶

All entries MUST conform to this structure and be encoded in both machine-readable (JSON-LD, RDF/XML) and human-readable formats.¶

8.4. Initial Registry Contents

IANA SHALL initialize the registry with the baseline terms defined in this document's core taxonomy. These include:¶

• Core Data Types: temperatureReading, locationCoordinate, audioRecording, videoStream, deviceIdentifier, userPreference, biometricData, healthData, presenceIndicator¶

• Core Purposes: coreFunctionality, security, personalization, analytics, advertising, diagnostics, regulatoryCompliance¶

• Core Actions: collection, usage, transfer, retention, deletion¶

• Core Sources: sensor, userInput, thirdPartyImport, derivedData¶

• Core Destinations: localProcessing, cloudStorage, manufacturerServer, thirdPartyPartner, dataBroker¶

Each of these SHALL be registered with complete metadata as described above.¶

8.5. Registry Management

The registry SHALL be maintained under the “Expert Review” policy defined in [RFC8126]. The designated expert(s) will evaluate submissions for:¶

• Conformance with the OWL-DL ontology¶

• Semantic clarity and non-ambiguity¶

• Necessity and non-duplication¶

• Privacy and security impact (if applicable)¶

The review process MUST include a public comment period and the ability to appeal decisions.¶