Privacy Preference Declaration Taxonomy

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Privacy Preference Declaration (PPD) architecture depends on a shared understanding of privacy-related semantics. [I-D.draft-dsmullen-ppd-architecture] defines the roles, trust boundaries, and lifecycle. [I-D.draft-dsmullen-ppd-protocol] defines the participant-facing message flow and object structure. This document defines the vocabulary those messages use.¶

The baseline PPD protocol carries atomic descriptive statements from device-side participants and atomic effective-policy rules from the household side. This taxonomy defines the meaning of the terms used in those statements and rules. It does not define a household policy authoring workflow, a conflict-resolution procedure, or a full reasoning engine.¶

The taxonomy is designed to be useful in constrained operational environments. It therefore separates the stable meaning of terms from any richer external semantic framework that might also describe them. Implementations can map these terms to richer vocabularies or ontology representations where useful, but such machinery is not required for baseline participant-facing interoperability.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Design Goals

• Semantic Clarity: Provide stable, unambiguous meanings for privacy-related terms used in PPD messages.¶

• Core Primitive Coverage: Standardize the dimensions needed by the baseline protocol rule and statement model.¶

• Compact Operational Use: Support compact identifiers in participant-facing JSON messages.¶

• Extensibility Without Fragmentation: Allow organization-specific vocabularies while requiring mapping back to shared core primitives.¶

• Validation and Comparison Support: Enable comparison of participant assertions and household policy without forcing every deployment to use a single heavy semantic framework.¶

• Interoperability: Preserve a shared vocabulary floor across vendors, device classes, and household deployments.¶

4. Core Taxonomy Structure

The baseline taxonomy consists of five core dimensions plus selected qualifier terms. These dimensions are used together in atomic declaration statements and atomic effective-policy rules.¶

5. Identifier Model

6. Use in PPD Messages

The protocol and taxonomy have different jobs:¶

• the protocol carries which atomic combinations a participant asserts or a household policy applies; and¶

• the taxonomy defines what the terms used in those combinations mean.¶

This distinction matters. A flat bag of supported data types, purposes, actions, and destinations is not enough to describe which combinations actually apply to a participant. The protocol therefore carries atomic declaration statements and atomic policy rules, while this taxonomy defines the term spaces and qualifier meanings used in those objects.¶

A declaration statement example is:¶

{
  "statement_id": "event-clip-remote-viewing",
  "data_type": "ppd:eventClip",
  "purpose": "ppd:remoteViewing",
  "action": "ppd:transfer",
  "source": "ppd:cameraSensor",
  "destination": "ppd:vendorCloud",
  "constraints": {
    "retention": "ppd:shortLived"
  }
}

A corresponding effective-policy rule example is:¶

{
  "rule_id": "r2",
  "data_type": "ppd:eventClip",
  "purpose": "ppd:remoteViewing",
  "action": "ppd:transfer",
  "source": "ppd:cameraSensor",
  "destination": "ppd:vendorCloud",
  "effect": "allow",
  "constraints": {
    "retention": "ppd:shortLived",
    "locality": "ppd:householdApprovedRemoteService"
  }
}

The taxonomy defines the meaning of the identifiers in these objects. The protocol defines how those objects are carried, validated, acknowledged, and kept current.¶

7. Relationship to Richer Semantic Frameworks

This taxonomy is intentionally lighter than a full ontology language or rights-expression framework. Implementations MAY publish auxiliary representations, mappings, or tool-specific serializations when useful. For example, organizations might maintain internal ontology, graph, or policy-analysis artifacts that map to the stable identifiers defined here.¶

However, baseline participant-facing interoperability does not require OWL, RDF, JSON-LD, or comparable machinery on the wire. The participant-facing contract remains compact term identifiers plus the protocol-defined taxonomy context.¶

8. Security Considerations

Semantic drift, ambiguous extensions, and unresolved terms can undermine privacy signaling even when transport security is strong.¶

Organizations publishing extension vocabularies SHOULD document stable meanings and mappings back to shared core primitives. Participant-facing services and participants SHOULD NOT silently treat unresolved or unusable taxonomy terms as equivalent to known terms.¶

When unresolved or unsupported terms appear in participant-facing protocol messages, the handling defined by [I-D.draft-dsmullen-ppd-protocol] applies. In particular, unresolved terms in normative policy content are more serious than unresolved descriptive detail because they can change the meaning of an allowed or denied handling path.¶

9. IANA Considerations

This document requests no IANA actions.¶

10. References

Acknowledgments

The authors thank the participants in the related PPD architecture, protocol, and implementation discussions for the feedback that shaped this taxonomy direction.¶

Authors' Addresses