Enhanced privacy for SDF proxy operations

Introduction The Semantic Definition Format (SDF) describes IoT device interaction capabilities and data models in an ecosystem-independent manner. SDF defines interaction affordances classified as properties, events, and actions, grouped into Objects and Things. In deployments where a proxy mediates communication between applications and constrained devices, the proxy uses SDF definitions to translate application-level affordance API calls into device-specific ecosystem characteristics (e.g., Bluetooth Low Energy GATT services and characteristics). While payload values can be end-to-end encrypted, the SDF definitions and ecosystem characteristics mappings used by the proxy are typically in plaintext. SDF definitions can describe sensitive aspects of devices. For example, a medical sensor's SDF model reveals the nature of health data being collected. When communicating directly, both endpoints are within the same trust domain. However, a mediating proxy may not be equally trusted and should not have visibility into the type of interaction performed through it. This document defines:

An "sdfPrivacy" extension for marking sensitive SDF definitions with privacy-preserving algorithm and parameter information.
A mechanism for generating privacy-preserving SDF definitions and ecosystem characteristics mappings for proxy use.
Procedures for proxy operation with privacy-preserving SDF definitions.

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 when, and only when, they appear in all capitals, as shown here. In addition to terms defined in the following terms are used in this document:

Ecosystem Characteristics:: Protocol-specific parameters and identifiers for communicating with a device in a particular ecosystem (e.g., BLE service and characteristic UUIDs).
Privacy-Preserving SDF Definitions:: SDF definitions processed by a privacy algorithm to obfuscate sensitive information while remaining valid SDF that enables proxy translation.
Padding Affordances:: Additional affordances inserted into privacy-preserving SDF definitions to resist correlation with known SDF documents based on the number and type of affordances.
SDF Proxy:: A system that translates application-level SDF affordance API calls into device-specific ecosystem characteristics.

System Architecture The system consists of:

Application: Accesses device information via SDF affordance APIs.
SDF Proxy: Translates SDF affordance API calls to device-specific ecosystem characteristics. May optionally include a Trusted Execution Environment (TEE).
Device: A (typically constrained) device communicating using ecosystem-specific protocols.

In normal operation, the Application sends SDF definitions and ecosystem characteristics to the SDF Proxy, which translates API calls into ecosystem-specific calls toward the Device and translates responses back. With the privacy extension defined in , the Application instead performs privacy-preserving processing of the original SDF definitions and ecosystem characteristics before transmitting them to the SDF Proxy. The SDF Proxy operates as in normal mode, but without visibility into the sensitive original definitions. The entities performing setup and data retrieval MAY differ. For example, a management entity may perform setup while a separate application performs data retrieval.

Privacy Extension for SDF This section defines the "sdfPrivacy" quality that can be included within an sdfObject or sdfThing grouping to indicate privacy-sensitive definitions and specify how they should be protected.

The sdfPrivacy Quality The "sdfPrivacy" quality contains the following sub-qualities:

sensitive:: Boolean indicating whether the enclosing definitions are privacy-sensitive. When true, definitions MUST be processed by the specified privacy algorithm before sharing with untrusted intermediaries.
sensitiveDefinitions:: Array of sensitive definition names within the enclosing grouping. If absent, ALL definitions in scope MUST be considered sensitive.
privacyAlgorithm:: String identifying the algorithm used to transform sensitive definitions into privacy-preserving versions.
privacyAlgorithmParameters:: Object containing algorithm-specific parameters.
key:: Cryptographic key used by the privacy algorithm, or an indication that the key is distributed out-of-band.

The following example shows an SDF object with the sdfPrivacy extension:

Processing Sensitive Definitions When "sensitive" is true and "sensitiveDefinitions" lists only some definitions, the document is split into:

A document containing the sensitive definitions with the namespace modified according to the privacy algorithm.
A document retaining the original namespace with only the non-sensitive definitions.

A document with the original namespace may leak information about sensitive definitions (e.g., through missing entries). It is RECOMMENDED that all definitions within a grouping be treated as sensitive by default (i.e., by omitting "sensitiveDefinitions").

Privacy Algorithm Requirements A privacy algorithm transforms sensitive SDF definitions into a privacy-preserving version. The output MUST be valid SDF usable by an SDF Proxy for translation. A privacy algorithm SHOULD:

Replace definition names with obfuscated versions (e.g., using encryption with a shared key).
Remove human-readable qualities ("label", "description").
Remove or sanitize the "info" block.
Replace the namespace with a non-conflicting, non-revealing URI.

A privacy algorithm MAY additionally:

Retain non-sensitive qualities that affect communication (e.g., data type information).
Transform rather than remove quality values.
Add padding affordances (see ).

Namespace Considerations The namespace in a privacy-preserving SDF document MUST NOT conflict with other namespaces in use and MUST NOT reveal information about the device or its capabilities. Options include:

A special sub-domain/path from the manufacturer's domain (e.g., "https://private.example.com/asfdbvex").
A common domain designated for privacy-preserving SDF namespaces, when the manufacturer's domain should not be disclosed.

Padding Affordances Padding affordances MAY be added to privacy-preserving SDF definitions to hinder correlation with known SDF documents based on affordance count and type. Padding affordances can be:

Unused (present only to alter document structure).
Used to invoke fake activity that the device ignores.
Used to map multiple SDF affordances to a single device affordance, hiding activity patterns from the SDF Proxy.

Indicating Privacy-Preserving Processing A privacy-preserving SDF document MAY include an sdfPrivacy quality to indicate it has been processed. The block could contain:

A "processed" quality set to true.
A "description" quality with non-sensitive processing information (e.g., for debugging).

An SDF Proxy can use "processed: true" as a hint that definition names are obfuscated and not useful for UI display.

Example: Privacy-Preserving Output The following shows the result of applying a privacy algorithm to the example in . Definition names are obfuscated, human-readable qualities removed, namespace replaced, info block cleared, and padding actions ("foo4", "foo5") added: This example retains the data type ("number") to allow the SDF Proxy to handle different data types. A stricter algorithm could remove this as well.

Operation Modes Privacy-preserving SDF translation can operate with or without a Trusted Execution Environment (TEE) at the SDF Proxy. In both modes, the Application first performs a setup phase where the SDF Proxy receives privacy-preserving SDF definitions and ecosystem characteristics, and the Device receives algorithm-dependent means for mapping between original and privacy-preserving identifiers. Affordances not marked as sensitive operate normally using plaintext mappings regardless of the mode. In the mode without a TEE, the SDF Proxy translates privacy-preserving affordance API calls to their corresponding privacy-preserving ecosystem characteristics and forwards them to the Device. The Device then maps the privacy-preserving characteristics back to its actual resources using the mapping received during setup. The SDF Proxy never sees the original definitions. The mapping between ecosystem characteristics and their privacy-preserving counterparts MAY be updated at any time by repeating the setup phase, allowing periodic rotation of obfuscated identifiers. In the mode with a TEE, the SDF Proxy hosts a trusted enclave that holds the plaintext SDF definitions and performs the translation internally. The TEE communicates with the Device via a tunneled channel, providing stronger privacy since the untrusted portion of the SDF Proxy never observes the actual ecosystem characteristics. If a tunnel is used, plaintext ecosystem characteristics MAY be employed within it since the tunnel provides confidentiality.

Security Considerations The privacy mechanisms protect against an SDF Proxy learning the nature of interactions between an application and a device. The mechanisms depend on the secrecy of the privacy algorithm key. A compromised key allows an attacker to reverse the obfuscation. Padding affordances provide limited traffic analysis protection. An adversary observing patterns over time may still infer interaction types despite obfuscated names. Without a TEE, the device must handle privacy-preserving ecosystem characteristics, and the mapping must be protected during setup (e.g., via end-to-end encryption between Application and Device). With a TEE, security guarantees depend on TEE implementation integrity and tunnel confidentiality between TEE and Device.

IANA Considerations TBD