Privacy Preference Declaration Taxonomy
draft-dsmullen-ppd-taxonomy-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel Smullen , Brian Scriber | ||
| Last updated | 2026-05-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dsmullen-ppd-taxonomy-05
Network Working Group D. Smullen
Internet-Draft B. Scriber
Intended status: Informational CableLabs
Expires: 23 November 2026 22 May 2026
Privacy Preference Declaration Taxonomy
draft-dsmullen-ppd-taxonomy-05
Abstract
This document defines the core vocabulary, comparison model, and
extension discipline used by Privacy Preference Declarations (PPDs)
to express atomic privacy-relevant dataflows in home networks. It
complements the companion PPD architecture and protocol work by
standardizing the core fields used in participant declarations and
household policy rules. The core vocabulary is the mandatory shared
semantic floor for baseline participant-facing interoperability.
Richer ecosystem-specific vocabularies remain possible, but
comparison-relevant non-core terms need explicit relationships to the
shared core so they remain computable. Baseline participant-facing
protocol messages use compact identifiers plus taxonomy context
rather than requiring full ontology exchange on the wire.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://drspangle.github.io/draft-dsmullen-ppd-taxonomy/draft-
dsmullen-ppd-taxonomy.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-dsmullen-ppd-
taxonomy/.
Source for this draft and an issue tracker can be found at
https://github.com/drspangle/draft-dsmullen-ppd-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/.
Smullen & Scriber Expires 23 November 2026 [Page 1]
Internet-Draft PPDTaxonomy May 2026
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 23 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Core Semantic Model . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Core Semantic Floor and Extension Model . . . . . . . . . . . 6
6. Core Taxonomy Structure . . . . . . . . . . . . . . . . . . . 7
6.1. Semantic Validity of Terms and Refinements . . . . . . . 8
6.2. Data Type (What) . . . . . . . . . . . . . . . . . . . . 9
6.3. Purpose (Why) . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Action (How) . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Source (From Where) . . . . . . . . . . . . . . . . . . . 13
6.6. Handling Context . . . . . . . . . . . . . . . . . . . . 14
6.7. Dataflow Qualifiers . . . . . . . . . . . . . . . . . . . 15
6.7.1. Retention . . . . . . . . . . . . . . . . . . . . . . 15
6.7.2. Processing Boundary . . . . . . . . . . . . . . . . . 16
6.7.3. Jurisdiction . . . . . . . . . . . . . . . . . . . . 17
7. Subsumption and Comparison . . . . . . . . . . . . . . . . . 19
8. Identifier Model . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Stable Term Identifiers . . . . . . . . . . . . . . . . . 20
8.2. Stability of Term Meanings . . . . . . . . . . . . . . . 20
8.3. Compact Wire Form . . . . . . . . . . . . . . . . . . . . 20
8.4. Extension Namespaces and Core-Primitive Mapping . . . . . 21
9. Use in PPD Messages . . . . . . . . . . . . . . . . . . . . . 22
10. Relationship to Richer Semantic Frameworks . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Smullen & Scriber Expires 23 November 2026 [Page 2]
Internet-Draft PPDTaxonomy May 2026
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 core fields and qualifier families used by those
messages.
The baseline PPD protocol carries atomic descriptive statements from
device-side participants and atomic effective-policy rules from the
household side. This taxonomy treats those statements and rules as
atomic privacy-relevant dataflows. It defines the meaning of the
fields used in those dataflows and the minimum semantic discipline
needed to compare them coherently across devices, vendors, and
household deployments.
The purpose of this taxonomy is to model those atomic privacy-
relevant dataflows as the fundamental semantic elements of PPD
policy. A participant declaration describes dataflows from the
participant side: which dataflows a device or associated service
performs, requires, or may attempt. A household policy rule
describes those same dataflows from the household side: whether they
are allowed, denied, or qualified. The taxonomy exists so these two
views can be compared coherently.
In this architecture, those household-side rules express household
privacy preferences for signaling and comparison purposes. They do
not by themselves define or imply a separate enforcement mechanism
that prevents, compels, or otherwise guarantees participant behavior.
Enforcement-capable extensions or local control mechanisms are
separate concerns and are outside the baseline scope of this
document, because the taxonomy's job is to provide a shared semantic
floor for expressing and comparing dataflows, while enforcement
depends on deployment-specific control points, trust models, and
device or service capabilities.
The taxonomy is designed to be useful in constrained operational
environments. It therefore separates the stable meaning of core
terms from any richer external semantic framework that might also
Smullen & Scriber Expires 23 November 2026 [Page 3]
Internet-Draft PPDTaxonomy May 2026
describe them. Implementations MAY use richer vocabularies, ontology
representations, or local policy-analysis artifacts where useful, but
baseline participant-facing interoperability depends on a shared
computable semantic floor rather than on a full external reasoning
stack.
The rest of this document does four things:
* it defines the core fields that make up an atomic PPD dataflow;
* it defines the initial qualifier families used with those fields;
* it defines the comparison model used to relate core and non-core
terms; and
* it defines what makes a participant-facing term or refinement
semantically valid or invalid for baseline use.
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. Core Semantic Model
The foundational semantic unit in this taxonomy is an atomic privacy-
relevant dataflow.
In the baseline PPD model, the participant-facing protocol defined by
[I-D.draft-dsmullen-ppd-protocol] carries atomic participant-side
dataflows in declarations and atomic household-side dataflows in
policy rules. Household-side policy rules also carry a separate rule
effect such as allow or deny. Comparison between participant
behavior and household policy is grounded in comparison of those
atomic dataflows.
A baseline atomic dataflow contains these five core fields:
* data_type: what kind of data is involved;
* purpose: why the dataflow occurs;
* action: which privacy-relevant action occurs;
* source: the immediate origin of the data in that dataflow; and
Smullen & Scriber Expires 23 November 2026 [Page 4]
Internet-Draft PPDTaxonomy May 2026
* handling_context: the context in which that dataflow occurs or
into which it is directed.
It can also carry structured dataflow qualifiers.
In this document, handling is the general umbrella term for the
collection, use, transfer, or inference of data represented by an
atomic dataflow. Processing is used more narrowly for execution
semantics, such as those constrained by processing_boundary.
Operation is reserved for protocol operations defined by
[I-D.draft-dsmullen-ppd-protocol].
One compact example is a camera that uses observed media data for a
security function within the household context. That can be
described as one atomic dataflow with data_type=ppd:contentData,
purpose=ppd:security, action=ppd:use, source=ppd:participantObserved,
handling_context=ppd:householdContext, and
processing_boundary=ppd:onDeviceOnly. The field and qualifier
sections below define the field families and qualifier families in
detail.
Modality is likewise not part of the taxonomy terms that populate the
core fields or qualifier families. Core and non-core taxonomy terms
MUST NOT encode policy effect or policy modality such as allowed,
denied, prohibited, required, or optional. If a deployment needs to
express both a dataflow concept and a policy position about that
concept, the concept MUST be carried in the appropriate core field or
qualifier family and the policy position MUST be expressed separately
through the policy-rule layer.
This document does not define a household policy authoring workflow,
a full conflict-resolution procedure, or a general reasoning engine.
It defines the minimum semantic structure needed so participant
declarations and household policy can be compared in an interoperable
way.
4. Design Goals
* Semantic Clarity: Provide stable, unambiguous meanings for
privacy-related terms used in PPD messages.
* Core Primitive Coverage: Standardize the core fields needed by the
baseline protocol rule and statement model.
* Compact Operational Use: Support compact identifiers in
participant-facing JSON messages.
Smullen & Scriber Expires 23 November 2026 [Page 5]
Internet-Draft PPDTaxonomy May 2026
* Extensibility Without Fragmentation: Allow organization-specific
vocabularies while requiring comparison-relevant extensions to
remain reducible to the shared core.
* 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 computable semantic floor
across vendors, device classes, and household deployments.
5. Core Semantic Floor and Extension Model
The baseline PPD core vocabulary is not intended to be the only
vocabulary used in real deployments. Device vendors, service
providers, vertical ecosystems, and user-facing policy tools are
expected to introduce richer concepts over time.
The purpose of the core vocabulary is different. It provides the
minimum shared semantic substrate against which participant
declarations and household policy can still be interpreted and
compared when those richer vocabularies are present.
This means the baseline model tolerates variability in how
deployments, vendors, or policy tools interpret and name finer-
grained concepts. It does not require every deployment to use the
same intermediate categories. It does require comparison-relevant
participant-facing terms to collapse back to the shared core in a
declared, computable way.
That tolerance also applies when participant-facing privacy
descriptions are broader, narrower, or intentionally ambiguous across
vendors or ecosystems. The purpose of the shared core is to ensure
that such local variation can still be reduced to a common computable
floor, so that household policies can be compared against participant
declarations without requiring the household to model each vendor's
vocabulary or interpretation strategy directly.
For baseline participant-facing interoperability:
* core terms define the shared semantic floor;
* richer non-core terms MAY be used through the taxonomy context
mechanism defined by [I-D.draft-dsmullen-ppd-protocol]; and
Smullen & Scriber Expires 23 November 2026 [Page 6]
Internet-Draft PPDTaxonomy May 2026
* when a non-core term or qualifier is used in a comparison-relevant
field, it MUST be defined with an explicit relationship or
reduction to the relevant core term or family-specific comparison
basis sufficient to keep the term computable against the shared
core model.
Terms that do not carry such a relationship can still be locally
meaningful, but they are outside baseline interoperable computation.
6. Core Taxonomy Structure
The baseline taxonomy consists of five core fields plus selected
dataflow qualifier families. These are used together in atomic
declaration statements and atomic effective-policy rules.
The baseline core is intentionally small. It is not meant to exhaust
the full space of home-IoT data categories, service roles, or policy-
authoring concepts. Its purpose is to define the minimum shared set
of computable primitives to which richer vocabularies can be related.
Later taxonomy releases can add terms, but the initial core terms
defined here are the mandatory baseline floor for interoperable
computation. The definitions in this section define the baseline
meaning of those initial core terms.
Within a given field family, the baseline core terms are intended to
act as the broad floor categories used for interoperable comparison.
Narrower terms used in that family are expected to reduce to exactly
one broader core term. If a local concept appears to span multiple
broad categories, that usually means the handling needs a narrower
term below the floor, a clearer field choice, or separate atomic
dataflows.
That ambiguity is expected to arise in practice, because humans and
local semantic systems will not always classify concepts the same
way. The baseline rule is therefore not that every local
interpretation must be identical. It is that any participant-facing
refinement used for interoperable comparison must ultimately resolve
to one computable branch within the relevant field family.
In other words, variation in local semantic expression is tolerated,
but the burden of reduction to the shared comparison basis belongs to
the participant-facing taxonomy content rather than to the household.
For field families that participate in subsumption, this document is
therefore intentionally prescriptive about refinement discipline:
* a non-core refinement MUST identify exactly one immediate broader
term within the same field family;
Smullen & Scriber Expires 23 November 2026 [Page 7]
Internet-Draft PPDTaxonomy May 2026
* repeated broader-than relationships MUST eventually terminate at a
core term in that family; and
* if a concept would require multiple immediate broader terms in the
same family, it is not a valid single refinement for baseline
comparison and should instead be modeled through a narrower term
under one branch, a clearer field choice, or separate atomic
dataflows.
These refinement rules do not allow policy modality to be folded into
field or qualifier concepts. For example, a term that attempts to
combine a handling-context category with a policy position, such as a
recipient marked as prohibited or required, is not a valid baseline
taxonomy refinement. Such modality belongs in the policy-rule layer
rather than in the taxonomy term itself.
6.1. Semantic Validity of Terms and Refinements
The baseline core and extension model defined here is intentionally
strict about semantic validity. This is necessary to preserve
interoperable comparison rather than allowing locally convenient but
semantically unstable labels to appear participant-facing on the
wire.
A term or qualifier value is semantically valid for baseline
participant- facing use only if all of the following are true:
* it belongs to exactly one field family or qualifier family defined
by this document or by a later compatible taxonomy specification;
* it follows the classification rule of the family in which it
appears;
* it does not collapse multiple semantic axes that this document
models separately, such as handling-context identity plus policy
modality, or data type plus origin history;
* if it is a refinement in a family that supports subsumption, it
preserves and specializes the meaning of its broader term rather
than contradicting, negating, or semantically escaping it;
* if a local concept cannot be placed in one family without relying
on multiple immediate broader terms in that same family, it is not
a valid single refinement for baseline comparison;
Smullen & Scriber Expires 23 November 2026 [Page 8]
Internet-Draft PPDTaxonomy May 2026
* if a local concept spans multiple semantic dimensions modeled
separately by this taxonomy, it is decomposed across the
corresponding fields or qualifier families rather than encoded
into one overloaded taxonomy term; and
* if that decomposition yields multiple distinct handling cases,
those cases are represented as separate atomic dataflows.
These validity rules apply equally to core terms and non-core
participant- facing refinements. A syntactically well-formed
namespaced identifier is not enough to make a term valid for baseline
comparison.
6.2. Data Type (What)
Data Type terms identify the kind of data involved in the dataflow.
They are classified by what the data is.
Data Type participates in semantic comparison and supports broader-
than/narrower-than relationships.
The core Data Type set is intentionally broad. Its purpose is to
provide a stable floor under which narrower device- or ecosystem-
specific terms can be placed. These categories are based on the
immediate semantic content of the data, not on its source, derivation
history, transport path, or downstream use. Whether data is directly
observed or derived from prior data is handled through the source
field rather than by a separate data_type category.
This also means different deployments may introduce different
narrower data type terms for concepts that are genuinely open to
interpretation. The baseline requirement is not to eliminate that
variability. The requirement is that a participant-facing data_type
term still classify by what the data is and reduce to one computable
branch of the shared core.
The initial core term set is:
* ppd:identifierData: data used to identify a user, household,
participant, device, account, or service interaction.
* ppd:profileData: data that describes a user, household, account,
or associated preferences and characteristics.
* ppd:sensorData: non-content measured or observed data obtained
from sensing of the device, the local environment, or an observed
space or object.
Smullen & Scriber Expires 23 November 2026 [Page 9]
Internet-Draft PPDTaxonomy May 2026
* ppd:contentData: content captured, communicated, or stored as
user- or environment-associated content, including text, audio,
image, and video content.
* ppd:locationData: data about physical location, movement, or place
association.
* ppd:deviceAndNetworkData: data about device configuration,
capabilities, settings, status, connectivity, or network
environment.
* ppd:usageData: data about interaction with the device, service, or
associated interfaces.
For example, a thermostat reading is ppd:sensorData, an account
nickname is ppd:profileData, and a doorbell video clip is
ppd:contentData.
Terms such as temperature readings, humidity readings, audio samples,
video frames, event clips, device identifiers, crash logs, and
occupancy estimates are expected to appear as narrower refinements of
these broader core data types. For example, an occupancy estimate
that describes the state of an observed space is still classified by
what that data means, while the fact that it was inferred from prior
data is captured separately through the source field.
Because humans ultimately define many of these refinements,
misclassification is a real risk. In particular, authors may be
tempted to classify by downstream use, by source, or by a composite
payload rather than by the immediate semantic content of the data
itself. Such cases are exactly why the baseline model requires
explicit reduction to the core and rejects a single participant-
facing refinement that would need multiple immediate broader terms
within the same data_type family.
6.3. Purpose (Why)
Purpose terms identify the reason or operational objective for the
handling. They are classified by why the current handling step
occurs.
Purpose participates in semantic comparison and supports broader-
than/ narrower-than relationships.
Smullen & Scriber Expires 23 November 2026 [Page 10]
Internet-Draft PPDTaxonomy May 2026
The core Purpose set is intentionally broad. It is designed to
reflect the high-level purpose categories commonly seen in privacy
notices and policy documents, while leaving room for narrower
operational purposes below it. These categories are based on why the
handling occurs in the rule at issue, not on product-feature labels,
recipient identity, data type, action, or policy modality.
The initial core term set is:
* ppd:coreFunctionality: handling directly necessary to provide the
primary function of the device or service.
* ppd:personalization: handling used to tailor behavior,
presentation, or operation to a user, household, or context.
* ppd:communicationsAndNotifications: handling used to communicate
with a user, household member, or administrator, including
notices, alerts, and service messages.
* ppd:security: handling used to maintain safety, security, fraud
prevention, abuse prevention, or protective monitoring.
* ppd:diagnosticsAndMaintenance: handling used to troubleshoot,
repair, maintain, or keep the device or service operational.
* ppd:analyticsAndImprovement: handling used to analyze operation or
improve the quality, reliability, or performance of the device or
service.
* ppd:legalCompliance: handling used to satisfy legal, regulatory,
audit, or compliance obligations.
* ppd:advertisingAndMarketing: handling used to target, deliver,
measure, or optimize promotional or marketing activity.
Terms such as remote monitoring, remote viewing, predictive
maintenance, product improvement, anomaly detection, and more
specific analytical or security purposes are expected to appear as
narrower refinements of these broader core purposes.
For example, a resident-requested live view can refine under
ppd:coreFunctionality, intrusion-alert scoring can refine under
ppd:security, and product-quality analysis can refine under
ppd:analyticsAndImprovement.
Smullen & Scriber Expires 23 November 2026 [Page 11]
Internet-Draft PPDTaxonomy May 2026
A purpose refinement MUST preserve and specialize the reason
expressed by its broader term. A purpose term MUST NOT collapse
purpose together with another semantic axis such as recipient
category, retention, data type, or policy effect.
Feature labels that can serve more than one broad purpose are not
good floor categories by themselves. For example, a motion-detection
feature may support ppd:coreFunctionality, ppd:security, or another
narrower purpose depending on the actual rule context.
When a real handling path genuinely serves multiple purposes, that
ambiguity MUST NOT be collapsed into one purpose label. For baseline
participant-facing use, the handling MUST instead be represented as
separate atomic dataflows, each with its own purpose classification.
This is not only a comparison convenience. It also improves
transparency by making it easier for a household, an implementer, or
an automated policy-analysis function to identify and reason about
specific sensitive purposes, specific data types, and the exact
handling paths to which they apply.
6.4. Action (How)
Action terms identify the privacy-relevant operation being performed.
Action terms are classified by which privacy-relevant operation
occurs.
Unlike several of the other core fields, the baseline action
vocabulary is intentionally flat rather than hierarchical.
The initial core term set is:
* ppd:collection: acquiring, observing, or accepting data into the
handling context of the participant or service.
* ppd:use: operating on data within the current handling context
without disclosing it to a different recipient.
* ppd:transfer: disclosing, transmitting, or otherwise making data
available to a different recipient or handling context.
* ppd:inference: deriving new data, classifications, or conclusions
from existing data.
Smullen & Scriber Expires 23 November 2026 [Page 12]
Internet-Draft PPDTaxonomy May 2026
6.5. Source (From Where)
Source terms identify the immediate origin of the handled data as it
enters the current handling step. They are classified by that
immediate origin. Source does not attempt to encode full provenance
or multi-step lineage. Source participates in semantic comparison
and supports broader-than/ narrower-than relationships.
The initial core term set is:
* ppd:userProvided: data intentionally provided by a user through
direct interaction with the participant, service, or associated
control surface.
* ppd:participantObserved: data directly observed by the participant
from the device, its environment, or an observed space or object.
* ppd:participantGenerated: data generated by the participant as
part of its own operation, status reporting, logging, or internal
state handling.
* ppd:householdProvided: data directly supplied to the current
handling step by another household-local device, controller,
gateway, or local service.
* ppd:vendorProvided: data directly supplied to the current handling
step by a service associated with the device or service vendor.
* ppd:thirdPartyProvided: data directly supplied to the current
handling step by a third party outside the participant's primary
vendor or household relationship.
* ppd:derivedFromPriorData: data whose immediate origin is prior
data processing within the current handling path rather than
direct observation, direct user provision, or direct supply from a
household, vendor, or third-party context.
When a provided category such as ppd:vendorProvided is used, this
field does not also attempt to encode deeper upstream lineage inside
that supplying context. For example, a vendor-delivered inference
result is still classified here as ppd:vendorProvided; the fact that
the vendor may have derived it from prior data is a deeper provenance
question outside the baseline source semantics defined in this
revision.
Smullen & Scriber Expires 23 November 2026 [Page 13]
Internet-Draft PPDTaxonomy May 2026
Terms such as camera sensor observation, microphone observation,
household gateway feed, vendor profile feed, and more specific third-
party or vendor-origin categories are expected to appear as narrower
refinements of these broader source categories.
For example, a camera frame captured by the participant is
ppd:participantObserved, a cloud-supplied account profile is
ppd:vendorProvided, and an occupancy score computed earlier in the
same handling path is ppd:derivedFromPriorData.
6.6. Handling Context
Handling Context terms identify the target handling context to which
the current atomic dataflow applies. For collection, Handling
Context identifies the context into which the collected data is
brought. For use and inference, Handling Context identifies the
context in which that dataflow occurs. For transfer, Handling
Context identifies the recipient- side context into which the data is
transferred. Handling Context participates in semantic comparison
and can support broader-than/narrower-than relationships. It is
classified by the target handling context to which the current
dataflow applies. Here, target means the context the dataflow is
directed into or occurs within. It does not imply that every action
is modeled as a transmission.
Handling Context does not by itself express a placement restriction
on how a use or inference operation executes inside that context.
More specific execution restrictions belong in the
processing_boundary qualifier family. The two are related but not
interchangeable.
Handling Context classifies semantic handling context, not
organization identity. Named entities such as a particular company
or service brand are not themselves core handling-context terms. If
such identifiers are introduced through non-core refinements, their
role-specific meaning still needs to reduce to one of the handling-
context categories below.
The initial core term set is:
* ppd:householdContext: a handling context that remains within the
participant or household-local relationship rather than
introducing a remote external service or audience.
* ppd:vendorContext: a handling context operated by, or acting on
behalf of, the participant's primary device or service vendor.
Smullen & Scriber Expires 23 November 2026 [Page 14]
Internet-Draft PPDTaxonomy May 2026
* ppd:thirdPartyContext: a handling context operated by an entity
outside the participant's primary vendor or household
relationship.
* ppd:publicAudience: a disclosure context in which data is made
available to the public or to an open audience rather than to a
bounded service relationship.
Terms such as vendor cloud, household controller, partner analytics
service, data broker, public feed, or other more specific recipient
or handling contexts are expected to appear as narrower refinements
of these broader handling-context categories.
For example, sending data to the device vendor is ppd:vendorContext,
using data within a household hub is ppd:householdContext, and
publishing data to an open feed is ppd:publicAudience.
6.7. Dataflow Qualifiers
The baseline protocol also allows structured qualifiers through the
constraints object. This document defines the initial qualifier
families used by that object.
The protocol wire object remains named constraints, but its members
are semantically qualifiers on atomic dataflows.
Qualifier families are action-sensitive. They are not a free-form
bag of attributes that apply equally to every action. A qualifier
family is only valid where this document or a later specification
defines its meaning for the relevant action context. Baseline
participant-facing uses that attach a qualifier family outside its
defined applicability are invalid.
6.7.1. Retention
Retention qualifies how long the relevant data or resulting artifact
may persist after the scoped action in question. It is classified by
how long the relevant data or artifact may persist after that scoped
action.
Retention is action-sensitive. In particular:
* for collection, retention qualifies whether the collected result
is allowed to persist after collection;
* for use, retention qualifies how long the data or resulting
artifact may remain available for that use;
Smullen & Scriber Expires 23 November 2026 [Page 15]
Internet-Draft PPDTaxonomy May 2026
* for transfer, retention qualifies downstream persistence by the
receiving side rather than only the sender's local storage
duration; and
* for inference, retention qualifies how long inferred output may
persist.
The baseline retention model distinguishes two strong named poles:
* ppd:ephemeral
* ppd:indefinite
ppd:ephemeral means the handling is not intended to result in durable
persistence beyond the immediate handling context.
ppd:indefinite means no bounded upper retention limit is expressed in
the rule.
Bounded retention periods are expected to require more specific
quantitative refinements, including explicit duration values and
units, in later revisions or deployment profiles. The baseline
compact participant-facing form defined here therefore standardizes
only the categorical retention values above. Retention therefore
uses its own family-specific categorical or quantitative comparison
semantics rather than the broader-than/narrower-than hierarchy used
by field families such as data_type, purpose, source, or
handling_context.
6.7.2. Processing Boundary
Processing Boundary qualifies where a processing operation may
execute or remain. It is classified by where use or inference may
execute within the applicable handling context. This family is most
natural for use and inference. It is not the primary semantic
mechanism for describing transfer recipients, because
handling_context already identifies the transfer target context.
In the baseline model, processing_boundary is therefore primarily a
qualifier on use and inference dataflows rather than a general
qualifier on transfer.
Smullen & Scriber Expires 23 November 2026 [Page 16]
Internet-Draft PPDTaxonomy May 2026
processing_boundary does not replace handling_context. Handling
Context identifies the target handling context to which the dataflow
applies. processing_boundary further constrains where a use or
inference operation may execute within that context. For example, a
use dataflow with handling_context=ppd:householdContext can still be
further narrowed by processing_boundary=ppd:onDeviceOnly or
processing_boundary=ppd:inHomeOnly.
The initial core term set is:
* ppd:onDeviceOnly: the relevant processing is constrained to
execute on the participant device itself.
* ppd:inHomeOnly: the relevant processing is constrained to execute
within the household-local trust boundary rather than in a remote
service environment.
* ppd:approvedRemoteProcessing: the relevant processing is allowed
to occur in an approved remote service environment.
Processing Boundary participates in semantic comparison and can
support broader-than/narrower-than relationships.
6.7.3. Jurisdiction
Jurisdiction qualifies the legal or regulatory domain relevant to the
dataflow. It is intended for cases where a policy needs to declare
which jurisdictions matter for a handling step or storage context,
not to model the substance of those jurisdictions' laws and
regulations. It is classified by the scoped handling step or storage
context being constrained, together with the declared jurisdiction
codes attached to that scope.
Jurisdiction is a structured qualifier family, not a single flat
label. For baseline participant-facing use, a jurisdiction qualifier
identifies:
* a scope; and
* one or more jurisdiction codes.
The scope identifies which handling step or storage context the
qualifier constrains. The baseline scope values are:
* collection
* use
Smullen & Scriber Expires 23 November 2026 [Page 17]
Internet-Draft PPDTaxonomy May 2026
* inference
* transfer
* storage
The first four values align with baseline handling actions. storage
is a distinct handling-related context used when the constraint
applies to retained data rather than to a specific action step.
For baseline participant-facing use, the jurisdiction codes use
existing IETF-defined code formats:
* countrycode for ISO 3166-1 alpha-2 country codes in lowercase
[RFC8006]; and
* subdivisioncode for ISO 3166-2 subdivision codes in lowercase
[RFC9388].
For example:
* a collection-scoped jurisdiction qualifier can constrain the
jurisdictions in which collection may occur;
* a transfer-scoped jurisdiction qualifier can constrain the
jurisdictions to which a transfer recipient may belong; and
* a storage-scoped jurisdiction qualifier can constrain the
jurisdictions in which retained data may be kept.
Jurisdiction does not use generic taxonomy subsumption. Baseline
comparison is family-specific:
* scope compares by exact identity;
* countrycode values compare by exact identifier matching;
* subdivisioncode values compare by exact identifier matching; and
* a countrycode also contains subdivisioncode values within that
country.
For example, countrycode=us contains subdivisioncode=us-ca, but a
jurisdiction qualifier scoped to transfer does not automatically
compare as equivalent to the same jurisdiction codes scoped to
storage.
Smullen & Scriber Expires 23 November 2026 [Page 18]
Internet-Draft PPDTaxonomy May 2026
7. Subsumption and Comparison
Baseline comparison is not limited to exact token equality.
For comparison-relevant fields and qualifier families that
participate in subsumption:
* a term can be broader than another term;
* a term can be narrower than another term; and
* two terms are equivalent when each subsumes the other.
Only the following baseline fields and qualifier families participate
in subsumption:
* data_type
* purpose
* source
* handling_context
* processing_boundary
The following do not use baseline subsumption:
* action, which remains a flat enumerable family and therefore
compares by exact identity or exact reduction to a core action
value; and
* retention, which uses its own categorical or quantitative
comparison semantics rather than a generic taxonomy hierarchy; and
* jurisdiction, which uses the family-specific scope and code-
containment semantics defined above rather than a generic taxonomy
hierarchy.
This document does not define a full conflict-resolution procedure.
It defines the semantic basis that allows comparison to remain
computable and interoperable.
8. Identifier Model
Smullen & Scriber Expires 23 November 2026 [Page 19]
Internet-Draft PPDTaxonomy May 2026
8.1. Stable Term Identifiers
Stable term identifiers are the primary semantic hook in this
taxonomy. The baseline core vocabulary uses the reserved prefix
ppd:. A term such as ppd:sensorData or ppd:householdContext derives
its meaning from the stable taxonomy definition associated with that
identifier.
A taxonomy release identifier can identify the vocabulary snapshot
used for validation, reproducibility, or documentation. For example,
a deployment might use a release identifier such as ppd-core-2026-05.
However, release metadata does not replace the term identifier itself
as the source of meaning.
8.2. Stability of Term Meanings
Once published, a stable term identifier MUST NOT be silently
reassigned an incompatible meaning in a later taxonomy release.
Later releases MAY:
* add new terms;
* clarify the prose associated with an existing term when the
clarification does not change its comparison semantics; and
* deprecate a term for future use while preserving its published
meaning for reproducibility and comparison of existing content.
If a later release needs materially different semantics, it MUST
define a new term identifier rather than repurposing the old one.
8.3. Compact Wire Form
[I-D.draft-dsmullen-ppd-protocol] defines compact term identifiers as
the participant-facing wire format. The protocol's Taxonomy Context
Object carries:
* a taxonomy release identifier; and
* any required non-core prefix declarations.
This keeps participant-facing messages compact while preserving
stable semantics.
Smullen & Scriber Expires 23 November 2026 [Page 20]
Internet-Draft PPDTaxonomy May 2026
8.4. Extension Namespaces and Core-Primitive Mapping
Organizations MAY define additional terms outside the baseline ppd:
vocabulary. When such terms appear in participant-facing protocol
messages, the sender MUST provide the required non-core prefix
declarations through the protocol's taxonomy context.
For comparison-relevant fields and qualifier families, namespace
declaration alone is not enough. When a non-core term fills
data_type, purpose, action, source, or handling_context, or supplies
a non-core retention, processing_boundary, or scoped jurisdiction
qualifier value, that term MUST be defined with the semantic
relationship or exact reduction by which it is reduced to the shared
core comparison basis for that family.
A non-core term that does not satisfy the semantic validity
conditions above is invalid taxonomy content for baseline
participant-facing use, even if the identifier syntax and namespace
declaration are otherwise well-formed.
Non-core terms also MUST NOT introduce policy modality into the
taxonomy layer. An extension term can refine a field or qualifier
concept, but it cannot turn that concept into an encoded policy
effect such as "prohibited" or "required". Those meanings belong in
policy rules, not in taxonomy terms.
That relationship can include equivalence or broader/narrower
placement where the field participates in subsumption, or exact
reduction where it does not, so long as it preserves computable
comparison against the shared core floor. For jurisdiction, that
comparison basis is the qualifier's declared scope together with the
countrycode and subdivisioncode model defined above.
For field families that participate in subsumption, a non-core
refinement MUST identify exactly one immediate broader term and MUST
remain reducible by repeated application of that relationship to one
core term in the same family. For field families that do not
participate in subsumption, exact reduction or the family-specific
comparison rules defined by this document apply.
For example, an organization might define:
* vendorx:temperatureReading as a narrower data_type under
ppd:sensorData;
* vendorx:userRequestedRemoteViewing as a narrower purpose under
ppd:coreFunctionality;
Smullen & Scriber Expires 23 November 2026 [Page 21]
Internet-Draft PPDTaxonomy May 2026
* vendorx:cameraSensor as a narrower source under
ppd:participantObserved; or
* vendorx:edgeHubOnly as a narrower processing_boundary under
ppd:inHomeOnly.
Handling-context refinements follow the same rule. For example:
* vendorx:vendorCloudService can be a narrower handling_context
under ppd:vendorContext;
* vendorx:dataBrokerService can be a narrower handling_context under
ppd:thirdPartyContext; and
* a named entity such as vendorx:exampleServices is only meaningful
if the refinement defines which handling-context role is involved.
The same organization might reduce to ppd:vendorContext when
acting as the participant's own vendor service, or to
ppd:thirdPartyContext when acting as an unrelated recipient.
Such terms can be useful, but they remain baseline-interoperable only
when their relationship to the relevant core fields is explicit
enough that participants and household policy services can compare
them meaningfully.
This document does not define who is authorized to publish extension
vocabularies, how ecosystems vet them, or what registry or profile
structure may later be used to manage them. Those governance and
publication-trust questions are out of scope for this revision. The
focus here is narrower: what participant-facing terms and refinements
are semantically valid for baseline interoperable computation.
9. 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 handling contexts 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.
Smullen & Scriber Expires 23 November 2026 [Page 22]
Internet-Draft PPDTaxonomy May 2026
The protocol wire object for qualifiers is named constraints, but the
semantics described here are qualifier semantics on those atomic
dataflows.
When those objects use non-core comparison-relevant terms, the
objects remain baseline-computable only if those terms are reducible
to the shared core model through the extension and mapping rules
above.
A declaration statement example is:
{
"statement_id": "temperature-product-improvement",
"data_type": "ppd:sensorData",
"purpose": "ppd:analyticsAndImprovement",
"action": "ppd:transfer",
"source": "ppd:participantObserved",
"handling_context": "ppd:vendorContext",
"constraints": {
"retention": "ppd:indefinite"
}
}
A corresponding effective-policy rule example is:
{
"rule_id": "r1",
"data_type": "ppd:contentData",
"purpose": "ppd:security",
"action": "ppd:use",
"source": "ppd:participantObserved",
"handling_context": "ppd:householdContext",
"effect": "allow",
"constraints": {
"processing_boundary": "ppd:onDeviceOnly"
}
}
The taxonomy defines the meaning of the identifiers in these objects.
The protocol defines how those objects are carried, validated,
acknowledged, and kept current.
Smullen & Scriber Expires 23 November 2026 [Page 23]
Internet-Draft PPDTaxonomy May 2026
10. Relationship to Richer Semantic Frameworks
Implementations MAY maintain richer local semantic artifacts,
mappings, or tool-specific representations where useful. However,
baseline participant- facing interoperability does not depend on
carrying a full ontology or graph model on the wire. The
participant-facing contract remains the compact term identifiers and
taxonomy context defined by [I-D.draft-dsmullen-ppd-protocol], backed
by the shared semantic floor defined here.
11. Security Considerations
Semantic drift, ambiguous extensions, and unresolved terms can
undermine privacy signaling even when transport security is strong.
Organizations publishing extension vocabularies for comparison-
relevant fields need stable meanings and explicit reduction back to
the shared core primitives. Participant-facing services and
participants SHOULD NOT silently treat unresolved, unmapped, or
unusable taxonomy terms as equivalent to known terms.
When comparison-relevant extension terms cannot be reduced to the
shared core, the correct baseline result is failure or indeterminate
handling, not silent fallback to a broader local guess.
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.
12. IANA Considerations
This document requests no IANA actions.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Smullen & Scriber Expires 23 November 2026 [Page 24]
Internet-Draft PPDTaxonomy May 2026
13.2. Informative References
[I-D.draft-dsmullen-ppd-architecture]
Smullen, D. and B. Scriber, "Privacy Preference
Declaration for Home Networks", Work in Progress,
Internet-Draft, draft-dsmullen-ppd-architecture-08, 20 May
2026, <https://datatracker.ietf.org/doc/html/draft-
dsmullen-ppd-architecture-08>.
[I-D.draft-dsmullen-ppd-protocol]
Smullen, D. and B. Scriber, "Privacy Preference
Declaration Protocol Specification", Work in Progress,
Internet-Draft, draft-dsmullen-ppd-protocol-02, 20 May
2026, <https://datatracker.ietf.org/doc/html/draft-
dsmullen-ppd-protocol-02>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<https://www.rfc-editor.org/rfc/rfc8006>.
[RFC9388] Sopher, N. and S. Mishra, "Content Delivery Network
Interconnection (CDNI) Footprint Types: Country
Subdivision Code and Footprint Union", RFC 9388,
DOI 10.17487/RFC9388, July 2023,
<https://www.rfc-editor.org/rfc/rfc9388>.
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
Daniel Smullen
CableLabs
Email: d.smullen@cablelabs.com
Brian Scriber
CableLabs
Email: brian.scriber@computer.org
Smullen & Scriber Expires 23 November 2026 [Page 25]