



Network Working Group                                         D. Smullen
Internet-Draft                                                B. Scriber
Intended status: Informational                                 CableLabs
Expires: 10 June 2026                                    7 December 2025


            Privacy Preference Declaration for Home Networks
                   draft-dsmullen-ppd-architecture-04

Abstract

   This document proposes a framework that empowers users to define and
   enforce privacy policies within their home networks through a Privacy
   Preference Declaration (PPD) protocol and architecture.  As connected
   devices proliferate, this approach enhances user control by enabling
   user-defined privacy settings for different data types, automatic
   policy discovery by new devices, and accountability measures such as
   notifications, network restrictions, or perhaps reporting non-
   compliance with users' defined preferences to designated authorities.
   The framework aims to cultivate a privacy-conscious home network
   environment through clear, enforceable privacy governance.

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-architecture/draft-
   dsmullen-ppd-architecture.html.  Status information for this document
   may be found at https://datatracker.ietf.org/doc/draft-dsmullen-ppd-
   architecture/.

   Source for this draft and an issue tracker can be found at
   https://github.com/drspangle/draft-dsmullen-ppd-architecture.

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 10 June 2026                  [Page 1]

Internet-Draft                   PPDArch                   December 2025


   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 10 June 2026.

Copyright Notice

   Copyright (c) 2025 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
     2.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Transparency  . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  User Control  . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Limitations of Existing Mechanisms  . . . . . . . . . . . . .   5
     3.1.  Device-specific Configurations  . . . . . . . . . . . . .   6
     3.2.  Ineffective and Unusable User Interfaces  . . . . . . . .   6
     3.3.  DNT and P3P . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Vision  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Use Case: Smart Thermostat with Location Tracking . . . .   7
     4.2.  Use Case: Smart Speaker with Selective Voice Recording
           Retention . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Use Case: Home Security Camera with Facial Recognition  .   8
   5.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Enhance User Control  . . . . . . . . . . . . . . . . . .   9
     5.2.  Promote Interoperability  . . . . . . . . . . . . . . . .   9
     5.3.  Enable Flexibility  . . . . . . . . . . . . . . . . . . .   9
     5.4.  Facilitate Transparency . . . . . . . . . . . . . . . . .   9
   6.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Architecture Overview . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  10
     7.2.  Key Components  . . . . . . . . . . . . . . . . . . . . .  12
     7.3.  Data Flows  . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14



Smullen & Scriber         Expires 10 June 2026                  [Page 2]

Internet-Draft                   PPDArch                   December 2025


     8.1.  Secure Policy Dissemination . . . . . . . . . . . . . . .  14
     8.2.  Anonymity and Metadata Protection . . . . . . . . . . . .  14
     8.3.  Policy Integrity  . . . . . . . . . . . . . . . . . . . .  15
     8.4.  Device Authentication . . . . . . . . . . . . . . . . . .  15
     8.5.  Policy Agreement and Enforcement  . . . . . . . . . . . .  15
   9.  Policy Language . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Language Requirements . . . . . . . . . . . . . . . . . .  16
     9.2.  Proposed Approach . . . . . . . . . . . . . . . . . . . .  16
   10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Policy Taxonomy and Semantics  . . . . . . . . . . . . .  17
     10.2.  Protocol Specification and Message Formats . . . . . . .  17
     10.3.  Consent Request Workflow Design Specifications . . . . .  17
     10.4.  Enforcement and Policy Compliance  . . . . . . . . . . .  18
     10.5.  User Interface Design Specifications . . . . . . . . . .  18
     10.6.  Internationalization and Identifier Comparison . . . . .  18
     10.7.  Interoperability Testing and Reference
            Implementations  . . . . . . . . . . . . . . . . . . . .  19
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     12.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   The rapid growth of Internet-connected devices in the home has
   introduced new and often overwhelming challenges to personal privacy.
   While many of these devices collect sensitive data by design, the
   tools offered to users to understand or control that collection are
   fragmented, confusing, or entirely absent.  When privacy settings do
   exist, they are often buried in obscure menus, expressed in legal or
   technical jargon, and lack the contextual clarity needed to support
   meaningful decision-making.

   This results in a deeply flawed model: users are expected to defend
   their own privacy across a chaotic landscape of inconsistent, ad hoc
   controls—many of which are ineffective or misleading.  At the same
   time, device vendors face growing pressure to meet user expectations
   and comply with evolving privacy regulations.  In response, they
   often develop bespoke privacy mechanisms that are complex to
   implement, difficult to maintain, and ultimately fail to provide
   users with clarity or confidence.  These mechanisms are typically
   built in isolation, without shared patterns or cross-device
   consistency, leading to privacy interfaces that are overengineered,
   underused, and poorly aligned with real user needs.





Smullen & Scriber         Expires 10 June 2026                  [Page 3]

Internet-Draft                   PPDArch                   December 2025


   [RFC7258] frames mass data collection as a technical threat, urging
   protocol designers to limit exposure through encryption and data
   minimization.  While this principle is crucial in adversarial,
   internet-scale contexts, the model proposed in this document takes a
   different approach: rather than hiding data flows, it seeks to govern
   them.  Privacy here is not achieved by making devices blind, but by
   ensuring they are accountable to user-defined preferences.

   This shift benefits both users and developers.  End users gain the
   ability to make contextual, informed privacy decisions without being
   overwhelmed by constant prompts or opaque controls.  Developers, in
   turn, are provided with a clearer, more predictable way to meet
   privacy expectations—reducing the need to reinvent complex and often
   inadequate consent and configuration systems.  What is needed is not
   more prompts or disclaimers, but a coherent mechanism for devices to
   retrieve, interpret, and respect user-directed privacy choices.

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.

   Privacy, as framed in this document, is not centered on anonymity or
   data minimization in the abstract, but rather on empowering users to
   understand and shape how their data is collected, used, and shared
   within their home networks.  This framework introduces a definition
   of privacy grounded in two core pillars: transparency and user
   control.  Transparency requires individuals to be provided with a
   clear and comprehensive understanding of what data is being collected
   by devices in their environment, how that data is processed and
   shared, and under what conditions.  This understanding must be
   accessible and meaningful to non-expert users, ensuring that privacy
   decisions are made with full awareness of their implications.  User
   control refers to the ability of individuals to define and enforce
   privacy preferences across the entire device ecosystem within their
   home.  Control must be both actionable and enforceable, enabling
   users to express nuanced policies—such as permitting temperature data
   collection while prohibiting third-party sharing—and ensuring that
   devices are held accountable to these expectations.

   The perspective of this document stands in contrast to the approach
   taken in [RFC6973], which emphasizes privacy as the reduction of
   observability, linkability, and identifiability within protocol
   design.  [RFC6973] recommends minimizing data collection and
   anonymizing information wherever possible, framing privacy primarily



Smullen & Scriber         Expires 10 June 2026                  [Page 4]

Internet-Draft                   PPDArch                   December 2025


   as a technical safeguard against unwanted inference.  In this
   framework, by contrast, privacy is not defined solely by what is
   withheld, but by what is understood and governed by the user.  In
   emphasizing user agency and data governance, this work finds
   conceptual alignment with [RFC8280], which frames privacy as a
   fundamental human right that protocol designers should consider.
   [RFC8280] underscores the importance of enabling user autonomy and
   informed decision-making, values that resonate strongly with this
   document’s goals.  However, the perspective of this document is more
   operationally focused: rather than advocating for abstract rights-
   respecting design principles, it proposes a concrete architectural
   approach to operationalize those rights within the home environment.
   Where [RFC8280] calls for privacy-supportive capabilities in protocol
   design, this document seeks to instantiate those capabilities through
   specific, enforceable mechanisms that allow users to express,
   distribute, and apply their privacy preferences in practice.
   Ultimately, this framework reconceives privacy not as a static
   property to be preserved by systems, but as a dynamic relationship
   between users and their devices—one that must be actively mediated
   through transparency and meaningful control.

2.1.  Privacy

   Privacy is not about anonymity, but about providing end users with
   the ability to be aware of how their data is being collected, used,
   and shared.  It aims to empower users with the knowledge and tools
   necessary to manage their personal information effectively.

2.2.  Transparency

   Transparency holds that users possess a clear and comprehensive
   understanding of what data is collected, how it is utilized, and how
   it is shared by devices within their network.  It involves making the
   data practices of devices visible and comprehensible to ensure users
   are fully informed.

2.3.  User Control

   User control empowers users to exert meaningful influence over the
   data collection and dissemination practices of these devices.  It
   ensures that users have the capability to define their privacy
   preferences and enforce policies that align with their comfort levels
   and expectations.

3.  Limitations of Existing Mechanisms

   Current mechanisms for managing data privacy within the home
   environment exhibit limitations.



Smullen & Scriber         Expires 10 June 2026                  [Page 5]

Internet-Draft                   PPDArch                   December 2025


3.1.  Device-specific Configurations

   Individual devices often employ unique privacy settings, thereby
   complicating user management of privacy across the entire network.
   This complexity can inadvertently lead to unintended data sharing

3.2.  Ineffective and Unusable User Interfaces

   Navigating and configuring privacy settings on individual devices can
   be a time-consuming and frustrating experience for users.  These
   ineffective interfaces often lead users to habitually agree to relax
   their privacy preferences without fully understanding the
   implications of their decisions.  This fosters a general resignation
   towards privacy management, making it difficult for users to exert
   meaningful control over their personal data and ultimately
   compromising their privacy expectations.

3.3.  DNT and P3P

   Protocols like Do Not Track (DNT) and Platform for Privacy
   Preferences Project (P3P) have not achieved widespread adoption and
   have proven inadequate for addressing nuanced privacy needs.  These
   protocols lack the granularity required to express fine-grained user
   preferences and may not effectively prevent unintended data
   collection or sharing.  For instance, consider a smart security
   camera within a home network.  While DNT or P3P can signal a user's
   general preference not to be tracked or share data, they do not
   enable users to specify detailed privacy settings, such as allowing
   the camera to record video but not audio, or restricting data sharing
   to only within the home network.  Users need more precise control
   options to manage their privacy effectively and ensure their
   preferences are respected across different devices and contexts.
   These limitations, coupled with the increasing complexity of the IoT
   ecosystem, hinder the effective exercise of user control over their
   data within the home environment and pose a significant threat to
   user privacy.

4.  Vision

   This document proposes a framework aimed at changing how users
   express their privacy preferences within their home network.  The new
   paradigm aspires to achieve a seamless and user-friendly experience,
   where privacy settings do not hinder the use of devices, reduce the
   burden of configuration management, and eliminate the need to
   navigate through long, unintelligible legal-language privacy
   policies.  By simplifying the process for defining privacy
   preferences, this approach aims to alleviate privacy fatigue and
   combat the pervasive feelings of resignation that users often



Smullen & Scriber         Expires 10 June 2026                  [Page 6]

Internet-Draft                   PPDArch                   December 2025


   experience regarding their privacy choices.  This will empower users
   to make informed decisions without duress, fostering greater trust
   and confidence in integrating internet-of-things devices into their
   homes.  In essence, the vision is to provide users with intuitive
   mechanisms for expressing privacy preferences, thus ensuring their
   concerns are addressed effectively and promoting a more private home
   environment.

4.1.  Use Case: Smart Thermostat with Location Tracking

   Scenario: A user purchases a smart thermostat that offers location-
   based temperature adjustments.

   User Preference: The user desires temperature adjustments based on
   their presence at home but wishes to prevent the thermostat from
   collecting and transmitting precise location data.

   Expected Outcome: The PPD protocol allows the user to define a policy
   where the thermostat can only determine presence/absence within the
   home without collecting precise GPS coordinates.  The thermostat must
   clearly inform the user of this limitation and any potential impact
   on functionality (e.g., less precise temperature adjustments).
   Regulatory frameworks such as the General Data Protection Regulation
   (GDPR) in the EU and the California Consumer Privacy Act (CCPA) in
   the U.S. already require companies to obtain explicit consent before
   collecting and processing sensitive personal data, including precise
   location information.  The PPD protocol ensures that consent is
   gathered in a manner that is transparent and comprehensible to the
   user, preventing scenarios where users might feel pressured or
   overwhelmed by the decision-making process.

   This protocol empowers individuals to make educated choices regarding
   their privacy settings by offering clear and concise information
   about data collection practices, potential risks, and benefits.  It
   places the user in control, fostering an environment where privacy
   decisions are made without duress, thus promoting confidence and
   trust in integrating internet-of-things devices into their daily
   lives.

4.2.  Use Case: Smart Speaker with Selective Voice Recording Retention

   Scenario: A user gets a smart speaker that can record and store voice
   data.

   User Preference: The user wants to keep general conversations for
   service improvement but prefers sensitive information to be
   selectively deleted and not retained.




Smullen & Scriber         Expires 10 June 2026                  [Page 7]

Internet-Draft                   PPDArch                   December 2025


   Expected Outcome: The PPD protocol enables the user to configure the
   speaker to identify and delete recordings containing sensitive
   information while retaining other voice data as long as necessary.
   The speaker must inform the user about its data collection and
   storage practices, providing an option to manage selective deletion.

   This outcome significantly enhances the user experience by ensuring
   privacy preferences are respected seamlessly within the context of
   their own network.  Users can manage their sensitive information
   without needing to reveal details to the smart speaker service, which
   means the user's privacy is upheld.  The smart speaker service only
   sees the retention preferences, avoiding the risks associated with
   handling sensitive data, including the preferences themselves which
   may be considered sensitive.

   Moreover, this streamlined approach means that device manufacturers
   do not need to expend resources on developing special user interfaces
   for managing these preferences.  Instead, the preferences are
   integrated within the home network, allowing for a cohesive and user-
   friendly experience.  This integration prevents the need for users to
   navigate separate interfaces or endure educational prompts to manage
   their privacy settings, fostering a smoother and more intuitive
   interaction with the device.

4.3.  Use Case: Home Security Camera with Facial Recognition

   Scenario: A user installs a home security camera with facial
   recognition capabilities.

   User Preference: The user desires facial recognition for security
   purposes but wishes to restrict the storage of captured images and
   the use of facial recognition data for any purpose other than
   security within the home.

   Expected Outcome: The PPD protocol allows the user to configure the
   camera to only store and process facial recognition data for security
   purposes within the home network and prohibits the sharing of this
   data with third parties.

   This approach provides numerous benefits for both the camera
   manufacturer and the user.  For the user, it ensures that their
   privacy preferences are respected and that their personal data is
   used solely for the intended security purposes.  By having control
   over the storage and usage of their facial recognition data, users
   can feel more secure and confident in their privacy being upheld.
   This can lead to a higher level of trust in the device and its
   manufacturer.




Smullen & Scriber         Expires 10 June 2026                  [Page 8]

Internet-Draft                   PPDArch                   December 2025


   For the camera manufacturer, implementing such a protocol reduces the
   risk of data breaches and the misuse of sensitive facial recognition
   data, which can lead to legal complications and damage to their
   reputation.  It streamlines the development process, as they do not
   need to create complex user interfaces for managing these
   preferences.  Instead, integrating the PPD protocol within the home
   network allows for seamless and user-friendly privacy management.
   This approach can also make the product more attractive to privacy-
   conscious consumers, increasing its marketability and potentially
   leading to higher sales.  This outcome showcases a mutually
   beneficial relationship where user privacy is prioritized, and
   manufacturers can offer a more privacy-preserving and appealing
   product.

5.  Goals

5.1.  Enhance User Control

   *  Empower users with the ability to define and enforce clear,
      concise, and easily understandable privacy policies for their home
      networks.

   *  Provide users with the means to effectively exercise control over
      the collection, use, and dissemination of their personal data by
      devices within their home network.

5.2.  Promote Interoperability

   *  Establish a standardized mechanism for devices from diverse
      manufacturers to discover and adhere to user-defined privacy
      policies, thereby facilitating consistent privacy management
      across the home network.

5.3.  Enable Flexibility

   *  Provide a framework that allows for the customization of privacy
      policies to accommodate the unique privacy requirements and
      preferences of individual users and households.

5.4.  Facilitate Transparency

   *  Ensure that devices within the home network are obligated to
      provide clear and concise information regarding their data
      collection and usage practices to users.

   *  Establish a mechanism for users to easily understand the
      implications of their privacy policy settings on the functionality
      of devices within their home network.



Smullen & Scriber         Expires 10 June 2026                  [Page 9]

Internet-Draft                   PPDArch                   December 2025


6.  Scope

   This document focuses on defining a high-level architectural
   framework for a Privacy Preference Declaration (PPD) protocol
   specifically designed for home network environments.  This document
   concentrates on the conceptual framework, key architectural
   components, and fundamental principles for enabling users to express
   and enforce their privacy preferences on devices within their home
   networks.

   This document does not delve into specific implementation details,
   such as message formats, data structures, security algorithms, or
   user interface design.  Furthermore, this document does not address
   enforcement mechanisms, legal and regulatory considerations, or
   specific security protocols.

   Specific implementation details and message formats will be addressed
   in subsequent RFCs.  This document aims to be complementary to
   existing and future standards related to home networking, IoT
   security, and data privacy.

   This document provides the foundation for subsequent work, including:

   *  Privacy Preference Declaration Taxonomy: This document will define
      a taxonomy of privacy preference categories and attributes,
      including a mechanism for registration and management of these
      categories.

   *  Privacy Preference Declaration Protocol Specification: This
      document will specify the message formats, data structures, and
      communication procedures for the PPD protocol, including
      mechanisms for device discovery, policy retrieval, and compliance
      reporting.

7.  Architecture Overview

7.1.  Assumptions

   This document makes the following assumptions:

   *  User Control: It is assumed that users have a reasonable level of
      control over their home network infrastructure.  This includes the
      ability to configure routers, install software updates, and manage
      device access to the network.  This control is essential for users
      to effectively manage their privacy preferences and enforce them
      on devices within their home network.





Smullen & Scriber         Expires 10 June 2026                 [Page 10]

Internet-Draft                   PPDArch                   December 2025


   *  Resource Constraints: It is assumed that the home network
      environment and devices operating therein have resource
      limitations, such as limited processing power and bandwidth.  We
      limit this assumption by considering that the PPD protocol and its
      associated mechanisms should be designed with these constraints in
      mind, minimizing overhead and ensuring efficient operation even on
      resource-constrained devices.

   *  Security Considerations: It is assumed that home networks in scope
      of this document are susceptible to typical security threats,
      including insider threats (or non-malicious misconfiguration) and
      vulnerability to local attacks.  We limit this assumption by
      considering specific security threats to protect user privacy and
      the integrity of the privacy policy.  This includes considerations
      for secure policy dissemination, device authentication, and
      protection against unauthorized access and modification of privacy
      preferences.

   *  Single User Policy: This document assumes that each device
      implementing the protocol is governed by a single, unified privacy
      policy defined by its primary user.  While other individuals
      within the same physical environment (e.g., household) may have
      different privacy preferences, the protocol is designed with the
      expectation that a device conforms to the policy established by
      its primary user.  Future extensions could explore mechanisms for
      managing and reconciling multiple user-defined policies on a
      single device, particularly in shared or multi-user environments.

   *  Policy Agreement: It is assumed that devices joining the network
      are expected not only to retrieve the household privacy policy but
      also to explicitly agree to abide by its terms.  This agreement
      forms a crucial part of the association process and is essential
      for ensuring device compliance with user privacy preferences.
      Failing to agree to the policy is a failure to adhere to the
      protocol.

   *  Policy Enforcement: At a minimum, devices must acknowledge that
      they have received and reviewed the user's privacy policy.  This
      acknowledgment provides a basic mechanism for users to ensure
      device accountability and decide whether to onboard it onto the
      network.  Future extensions could introduce more robust
      enforcement mechanisms to address non-compliance, such as network
      access restrictions or reporting to a designated authority.  These
      measures would enhance the integrity of the privacy framework and
      reinforce user trust.






Smullen & Scriber         Expires 10 June 2026                 [Page 11]

Internet-Draft                   PPDArch                   December 2025


7.2.  Key Components

   User Interface: A user-friendly interface (e.g., mobile app, web
   portal) for creating and managing privacy preferences.

   Preference Repository: A secure and reliable mechanism for storing
   user preferences (e.g., local device, cloud service).

   Declaration Protocol: A standardized protocol for devices to:

   *  Discover and retrieve user-defined privacy policies.

   *  Report their data collection and sharing practices.

   *  Request user consent for specific data uses.

   Enforcement Mechanisms: Mechanisms for devices to enforce user-
   defined privacy restrictions.

7.3.  Data Flows

   This section outlines the high-level data interactions between users,
   devices, and the Preference Repository in the Privacy Preference
   Declaration (PPD) framework.  It describes how privacy preferences
   are defined by users, retrieved by devices, and used to guide
   behavior in a home network environment.

   The process begins when a user defines a set of privacy preferences
   that apply to their household.  These preferences may express rules
   such as which types of data may be collected, under what conditions
   data may be processed or shared, or which retention practices are
   acceptable.  The design of the user interface used to author these
   preferences, including its presentation, usability, or input
   modalities, is out of scope for this document, and will be addressed
   separately.  Likewise, the underlying vocabulary and structure of the
   privacy preferences, including data categories and associated
   constraints, is specified in (Privacy Preference Declaration
   Taxonomy).













Smullen & Scriber         Expires 10 June 2026                 [Page 12]

Internet-Draft                   PPDArch                   December 2025


   Once created, the user’s preferences are stored in a secure
   Preference Repository, which may reside locally on a networked
   controller or be accessible through other trusted infrastructure.
   When a new device joins the home network, it initiates an onboarding
   process during which it discovers the repository and establishes a
   secure channel.  Following onboarding, the device performs
   association, which involves retrieving the household privacy policy
   and issuing a formal acknowledgment of its terms.  Devices may
   optionally report their data handling declarations to the repository
   at this stage.

   If a device seeks to perform actions not permitted under the baseline
   policy, for example, collecting or sharing data beyond what the user
   has authorized may initiate a consent request workflow.  However, the
   design and behavior of this consent mechanism is explicitly out of
   scope for this document.  Inappropriate or poorly designed consent
   flows, such as those that involve excessive prompting, ambiguous
   language, or misleading options, can inadvertently pressure users
   into accepting data practices that conflict with their preferences.
   Even without malicious intent, these experiences may degrade trust
   and lead to outcomes inconsistent with user expectations.  Future
   specifications should ensure that consent interactions are clear,
   proportionate, and respectful, helping users make informed decisions
   without friction or fatigue.

   When the household policy is updated, or when a device’s previous
   association has expired, the device is required to re-associate by
   re-retrieving and accepting the latest version of the policy.
   Reassociation ensures that devices remain accountable to current user
   expectations over time.  Devices are not expected to re-collect
   consent for data uses already covered by existing, valid consent.

   To support efficient transmission of privacy policies, consent
   records, and compliance data (particularly in constrained
   environments typical of home IoT systems) a compact, machine-readable
   encoding is recommended.  [RFC8949], offers an efficient format for
   structured data that is well-suited for this context.  CBOR balances
   low-overhead serialization with the ability to represent extensible
   and semantically rich policy structures.  While this document does
   not mandate any specific encoding, CBOR should be considered as a
   candidate for future protocol-level message formats.

   It is important to note that the minimum requirement under this
   architecture is limited to the discovery, retrieval, and formal
   acknowledgment of the user’s privacy policy.  This acknowledgment
   provides a foundational mechanism for establishing device
   accountability.  However, this document does not define how policy
   enforcement must be carried out by the device, nor does it specify



Smullen & Scriber         Expires 10 June 2026                 [Page 13]

Internet-Draft                   PPDArch                   December 2025


   how to handle cases where a device cannot fully comply with a given
   policy.  These aspects, including runtime enforcement, conflict
   resolution, or auditing, may be addressed in future work.

   Finally, while this document defines the overall data flow and
   interaction sequence, it does not define message formats,
   communication protocol details, or consent interface specifications.
   These elements will be specified in a companion document, (Privacy
   Preference Declaration Protocol Specification).

8.  Security Considerations

   For a privacy framework to be effective, it must not only support the
   expression of user preferences but also ensure that those preferences
   are protected during transmission, retrieval, and enforcement.  This
   section outlines the necessary safeguards for ensuring the
   confidentiality, authenticity, and integrity of the privacy policy,
   as well as the anonymity of the household during key protocol
   operations.

8.1.  Secure Policy Dissemination

   Communication between devices and the Preference Repository must be
   protected against unauthorized access and tampering.  Cryptographic
   mechanisms such as encryption and mutual authentication should be
   employed to ensure that only legitimate devices can retrieve privacy
   policies and that those policies are delivered without modification.

8.2.  Anonymity and Metadata Protection

   Even when privacy policies themselves do not contain sensitive
   personal information, the act of retrieving or acknowledging a policy
   may reveal characteristics about the household—such as the types of
   devices in use, specific user preferences, or behavioral patterns
   over time.  [RFC7258] cautions against protocol designs that expose
   unnecessary metadata, treating the accumulation of such information
   as a legitimate technical threat.  This framework takes that warning
   seriously: metadata exposure during policy retrieval and device
   onboarding must be minimized to avoid turning privacy infrastructure
   into a new source of privacy leakage.  Concepts from [RFC9577] may
   help inform this effort.  [RFC9577] introduces techniques for
   authorization without identification, enabling a client to prove it
   is authorized without revealing who it is.  While [RFC9577] is
   optimized for pseudonymous web authentication over the public
   internet, and assumes a centralized token issuer model, its core
   ideas—particularly around unlinkable token presentation—could be
   adapted to the PPD protocol to reduce metadata correlation and
   minimize household identifiability during policy exchanges.  However,



Smullen & Scriber         Expires 10 June 2026                 [Page 14]

Internet-Draft                   PPDArch                   December 2025


   this must be done carefully, as the assumptions of [RFC9577] do not
   fully align with the goals or context of a local, user-governed home
   network.

8.3.  Policy Integrity

   Devices must be guaranteed that the policy retrieved is authentic and
   unaltered.  Integrity protections, such as digital signatures, are
   necessary to ensure that users’ preferences cannot be tampered
   with—either in transit or at rest—by other devices, malicious actors,
   or misconfigurations.

8.4.  Device Authentication

   Devices participating in the privacy framework must authenticate
   themselves before accessing the Preference Repository.  This ensures
   that policy dissemination is limited to known, authorized devices,
   and that users can maintain trust in the integrity of their home
   network's privacy relationships.  By aligning with the concerns
   raised in [RFC7258] and incorporating ideas from [RFC9577] where
   appropriate, this framework seeks to protect users not only from
   overt data collection, but also from silent inference and passive
   metadata surveillance.  At the same time, it avoids treating
   anonymity as an end in itself.  The goal is to support privacy with
   accountability—where user-defined preferences are respected, devices
   are identifiable only as much as necessary, and no more, and the user
   retains ultimate visibility and influence over what occurs within
   their domain.

8.5.  Policy Agreement and Enforcement

   Devices must not only acknowledge receipt of the privacy policy but
   also explicitly agree to abide by its terms.  This agreement should
   be recorded and verifiable.  Enforcement mechanisms should be in
   place to address non-compliance, including network access
   restrictions or reporting to a designated authority.

9.  Policy Language

   The specific details of the Privacy Policy Language, including its
   syntax, structure, and extensibility mechanisms, are considered out
   of scope for this document, which focuses on the overall framework.
   The Privacy Policy Language, along with a taxonomy of privacy
   concepts and attributes, will be fully defined in a separate RFC, the
   "Privacy Preference Declaration Taxonomy," allowing for more detailed
   exploration and development of this crucial component of the PPD
   framework.




Smullen & Scriber         Expires 10 June 2026                 [Page 15]

Internet-Draft                   PPDArch                   December 2025


9.1.  Language Requirements

   *  Human-readable: Policies should be easily understandable by users.

   *  Machine-readable: Policies should be machine-processable for
      automated enforcement.

   *  Extensible: The language should be flexible enough to accommodate
      evolving privacy needs and technologies.

   *  Internationalization-compatible: Policies and identifiers used
      within them may need to support multilingual environments and non-
      ASCII characters.

   To ensure consistent interpretation and comparison of string-based
   policy elements, such as device names, labels, or category identifier
   string handling practices should align with the guidelines defined in
   [RFC7564].  This is particularly important when identifiers or user-
   facing labels are created, stored, or matched across vendors or
   systems that operate in different locales or character encodings.

9.2.  Proposed Approach

   Consider leveraging existing privacy policy languages (e.g., P3P) or
   drawing lessons from privacy labeling systems used in modern
   application ecosystems—such as Apple’s App Privacy Labels and
   Google’s Data Safety section for Android apps.  While these
   approaches are not protocols per se, they demonstrate how structured,
   declarative privacy metadata can be communicated to users and systems
   in a consistent way.

   Alternatively, a new, concise, and user-friendly privacy policy
   language may be developed specifically for the PPD framework.  One
   possibility is to define an intermediate representation—similar in
   spirit to the intermediate representation used in compilers such as
   LLVM—that captures the fundamental privacy constraints and regulatory
   considerations (e.g., from GDPR, CCPA) in a machine-readable form.
   This representation would support automated enforcement while being
   straightforward to translate into human-readable language.

   Future specifications should also define guidance for how string
   identifiers—such as device roles, policy tags, or consent status
   labels—are formatted, compared, and stored, to avoid ambiguities
   across systems.  In contexts where internationalized strings are
   involved, alignment with [RFC7564] should be considered to ensure
   interoperability and consistency.





Smullen & Scriber         Expires 10 June 2026                 [Page 16]

Internet-Draft                   PPDArch                   December 2025


10.  Future Work

   This document defines an architectural framework for enabling users
   to express and enforce privacy preferences within home network
   environments.  Several aspects critical to a fully operational
   implementation are intentionally left out of scope here and are
   expected to be addressed in future specifications or companion
   documents.

10.1.  Policy Taxonomy and Semantics

   A separate document, tentatively titled "Privacy Preference
   Declaration Taxonomy", will define:

   *  A common vocabulary and set of categories for expressing privacy
      preferences.

   *  Attributes and semantics for data types, sharing constraints, and
      processing conditions.

   *  An extensibility model for incorporating future data types and
      policy dimensions.

   This taxonomy is foundational for consistent policy interpretation
   across heterogeneous devices and vendors.

10.2.  Protocol Specification and Message Formats

   A companion document, "Privacy Preference Declaration Protocol
   Specification", is expected to define:

   *  Message formats for device onboarding, policy retrieval,
      acknowledgment, and compliance reporting.

   *  Optional mechanisms for consent request flows.

   *  Transport-layer considerations and discovery mechanisms.

   *  Recommended encoding formats, such as [RFC8949], for efficient
      representation of structured data.

10.3.  Consent Request Workflow Design Specifications

   The mechanism by which devices request additional user consent for
   data uses not covered by the baseline policy is out of scope.
   However, future specifications should:





Smullen & Scriber         Expires 10 June 2026                 [Page 17]

Internet-Draft                   PPDArch                   December 2025


   *  Define clear constraints to prevent manipulative or fatiguing
      consent flows (e.g., dark patterns).

   *  Ensure that consent interactions are transparent, infrequent,
      proportionate, and user-respecting.

   *  Explore user interface standards or API affordances to preserve
      meaningful choice.

   This is a particularly sensitive area and must balance user
   experience, privacy expectations, and implementation feasibility.

10.4.  Enforcement and Policy Compliance

   This architecture does not define how privacy policies are to be
   enforced by devices or how non-compliance is to be detected or
   remediated.  Future work may include:

   *  Runtime enforcement models and device-side implementation
      expectations.

   *  Auditing mechanisms for verifying compliance.

   *  Deconfliction strategies for devices unable to meet all user-
      defined constraints.

   *  Options for escalation (e.g., network access restrictions,
      notifications, or isolation).

10.5.  User Interface Design Specifications

   The user-facing interface used to author, modify, and review privacy
   preferences is out of scope.  Future design guidance may address:

   *  User experience design principles for presenting privacy concepts
      clearly and accessibly.

   *  Models for progressive disclosure of policy impact.

   *  Multi-user and household-role-specific control models (e.g.,
      parental vs. administrative roles).

10.6.  Internationalization and Identifier Comparison

   In contexts where privacy preferences or taxonomy elements involve
   user-facing or vendor-defined string identifiers, additional work may
   be required to:




Smullen & Scriber         Expires 10 June 2026                 [Page 18]

Internet-Draft                   PPDArch                   December 2025


   *  Define string normalization and comparison rules, particularly for
      internationalized text.

   *  Ensure identifier consistency across diverse vendors and locales.

   *  Consider alignment with the [RFC7564] for handling Unicode-aware
      identifiers in a secure and interoperable way.

10.7.  Interoperability Testing and Reference Implementations

   Future work may also include:

   *  Development of reference implementations of the PPD protocol and
      repository components.

   *  Interoperability testing across devices and vendors.

   *  Conformance guidelines and self-certification procedures.

11.  IANA Considerations

   This document has no IANA actions.

12.  References

12.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>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

12.2.  Informative References

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6973>.



Smullen & Scriber         Expires 10 June 2026                 [Page 19]

Internet-Draft                   PPDArch                   December 2025


   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/rfc/rfc7258>.

   [RFC7564]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
              Preparation, Enforcement, and Comparison of
              Internationalized Strings in Application Protocols",
              RFC 7564, DOI 10.17487/RFC7564, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7564>.

   [RFC8280]  ten Oever, N. and C. Cath, "Research into Human Rights
              Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
              October 2017, <https://www.rfc-editor.org/rfc/rfc8280>.

   [RFC9577]  Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
              HTTP Authentication Scheme", RFC 9577,
              DOI 10.17487/RFC9577, June 2024,
              <https://www.rfc-editor.org/rfc/rfc9577>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Daniel Smullen
   CableLabs
   Email: d.smullen@cablelabs.com


   Brian Scriber
   CableLabs
   Email: brian.scriber@computer.org


















Smullen & Scriber         Expires 10 June 2026                 [Page 20]
