| Internet-Draft | SDF proxy privacy | July 2026 |
| Tudor, et al. | Expires 3 January 2027 | [Page] |
The Semantic Definition Format (SDF) enables ecosystem-independent descriptions of IoT device interaction capabilities. When a proxy mediates communication between applications and devices, it requires SDF definitions and ecosystem-specific mappings for translation. These definitions may contain privacy-sensitive information about devices and their interactions. This document defines an SDF extension for marking sensitive definitions and specifies mechanisms for generating privacy-preserving SDF documents that enable proxy operation without exposing sensitive information.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 January 2027.¶
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.¶
The Semantic Definition Format (SDF) [RFC9880] 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 [I-D.ietf-asdf-sdf-protocol-mapping] 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.¶
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.¶
In addition to terms defined in [RFC9880] the following terms are used in this document:¶
Protocol-specific parameters and identifiers for communicating with a device in a particular ecosystem (e.g., BLE service and characteristic UUIDs).¶
SDF definitions processed by a privacy algorithm to obfuscate sensitive information while remaining valid SDF that enables proxy translation.¶
Additional affordances inserted into privacy-preserving SDF definitions to resist correlation with known SDF documents based on the number and type of affordances.¶
A system that translates application-level SDF affordance API calls into device-specific ecosystem characteristics.¶
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 Section 4, 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.¶
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 contains the following sub-qualities:¶
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.¶
Array of sensitive definition names within the enclosing grouping. If absent, ALL definitions in scope MUST be considered sensitive.¶
String identifying the algorithm used to transform sensitive definitions into privacy-preserving versions.¶
Object containing algorithm-specific parameters.¶
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:¶
{
"info": {
"title": "Example health sensor",
"version": "1.0"
},
"namespace": {
"example": "https://example.com/sensors/"
},
"defaultNamespace": "example",
"sdfObject": {
"HeartSensor": {
"sdfProperty": {
"heartRate": {
"sdfRef": "#/sdfObject/HeartSensor/sdfData/heartRate",
"description": "Current heart rate measurement",
"writable": false
},
"maxRate": {
"sdfRef": "#/sdfObject/HeartSensor/sdfData/heartRate",
"description": "Maximum measured heart rate"
},
"minRate": {
"sdfRef": "#/sdfObject/HeartSensor/sdfData/heartRate",
"description": "Minimum measured heart rate"
}
},
"sdfAction": {
"calibrate": {
"description": "Calibrate the sensor",
"sdfInputData": {
"sdfRef": "#/sdfObject/HeartSensor/sdfData/heartRate"
}
}
},
"sdfData": {
"heartRate": {
"type": "number",
"minimum": 0,
"maximum": 250
}
},
"sdfPrivacy": {
"sensitive": true,
"sensitiveDefinitions": [
"heartRate", "calibrate", "maxRate", "minRate"
],
"privacyAlgorithm": "obfuscate-names-v1",
"privacyAlgorithmParameters": {
"removeMeta": true
},
"key": "base64-encoded-key-here"
}
}
}
}
¶
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").¶
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 Section 4.5).¶
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:¶
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:¶
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.¶
The following shows the result of applying a privacy algorithm to the example in Section 4. Definition names are obfuscated, human-readable qualities removed, namespace replaced, info block cleared, and padding actions ("foo4", "foo5") added:¶
{
"namespace": {
"foons": "https://private.example.com/asfdbvex"
},
"defaultNamespace": "foons",
"sdfObject": {
"fhnbjskla": {
"sdfProperty": {
"xartd": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct",
"writable": false
},
"foo1": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct"
},
"foo2": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct"
}
},
"sdfAction": {
"foo3": {
"sdfInputData": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct"
}
},
"foo4": {
"sdfInputData": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct"
}
},
"foo5": {
"sdfInputData": {
"sdfRef": "#/sdfObject/fhnbjskla/sdfData/rfxct"
}
}
},
"sdfData": {
"rfxct": {
"type": "number"
}
}
}
}
}
¶
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.¶
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.¶
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.¶
TBD¶