Enhanced privacy for SDF proxy operations
draft-tudor-asdf-proxy-privacy-00
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 | Valentin Tudor , Ari Keränen , Martina Stein | ||
| Last updated | 2026-07-03 | ||
| 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-tudor-asdf-proxy-privacy-00
ASDF V. Tudor
Internet-Draft A. Keränen
Intended status: Standards Track M. Stein
Expires: 3 January 2027 Ericsson
2 July 2026
Enhanced privacy for SDF proxy operations
draft-tudor-asdf-proxy-privacy-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 January 2027.
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
Tudor, et al. Expires 3 January 2027 [Page 1]
Internet-Draft SDF proxy privacy July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. System Architecture . . . . . . . . . . . . . . . . . . . . . 3
4. Privacy Extension for SDF . . . . . . . . . . . . . . . . . . 4
4.1. The sdfPrivacy Quality . . . . . . . . . . . . . . . . . 4
4.2. Processing Sensitive Definitions . . . . . . . . . . . . 6
4.3. Privacy Algorithm Requirements . . . . . . . . . . . . . 6
4.4. Namespace Considerations . . . . . . . . . . . . . . . . 7
4.5. Padding Affordances . . . . . . . . . . . . . . . . . . . 7
4.6. Indicating Privacy-Preserving Processing . . . . . . . . 7
4.7. Example: Privacy-Preserving Output . . . . . . . . . . . 7
5. Operation Modes . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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.
Tudor, et al. Expires 3 January 2027 [Page 2]
Internet-Draft SDF proxy privacy July 2026
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.
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.
In addition to terms defined in [RFC9880] 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.
3. 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).
Tudor, et al. Expires 3 January 2027 [Page 3]
Internet-Draft SDF proxy privacy July 2026
* 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.
4. 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.
4.1. 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:
Tudor, et al. Expires 3 January 2027 [Page 4]
Internet-Draft SDF proxy privacy July 2026
{
"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": {
Tudor, et al. Expires 3 January 2027 [Page 5]
Internet-Draft SDF proxy privacy July 2026
"removeMeta": true
},
"key": "base64-encoded-key-here"
}
}
}
}
4.2. Processing Sensitive Definitions
When "sensitive" is true and "sensitiveDefinitions" lists only some
definitions, the document is split into:
1. A document containing the sensitive definitions with the
namespace modified according to the privacy algorithm.
2. 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").
4.3. 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.
Tudor, et al. Expires 3 January 2027 [Page 6]
Internet-Draft SDF proxy privacy July 2026
* Add padding affordances (see Section 4.5).
4.4. 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.
4.5. 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:
1. Unused (present only to alter document structure).
2. Used to invoke fake activity that the device ignores.
3. Used to map multiple SDF affordances to a single device
affordance, hiding activity patterns from the SDF Proxy.
4.6. 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.
4.7. Example: Privacy-Preserving Output
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:
Tudor, et al. Expires 3 January 2027 [Page 7]
Internet-Draft SDF proxy privacy July 2026
{
"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.
Tudor, et al. Expires 3 January 2027 [Page 8]
Internet-Draft SDF proxy privacy July 2026
5. 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.
6. 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.
Tudor, et al. Expires 3 January 2027 [Page 9]
Internet-Draft SDF proxy privacy July 2026
7. IANA Considerations
TBD
8. Normative References
[I-D.ietf-asdf-sdf-protocol-mapping]
Mohan, R., Brinckman, B., and L. Corneo, "SDF Protocol
Mapping", Work in Progress, Internet-Draft, draft-ietf-
asdf-sdf-protocol-mapping-09, 29 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-asdf-
sdf-protocol-mapping-09>.
[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>.
[RFC9880] Koster, M., Ed., Bormann, C., Ed., and A. Keränen,
"Semantic Definition Format (SDF) for Data and
Interactions of Things", RFC 9880, DOI 10.17487/RFC9880,
January 2026, <https://www.rfc-editor.org/rfc/rfc9880>.
Acknowledgments
TBD
Authors' Addresses
Valentin Tudor
Ericsson
Email: valentin.tudor@ericsson.com
Ari Keränen
Ericsson
Email: ari.keranen@ericsson.com
Martina Stein
Ericsson
Email: martina.stein@ericsson.com
Tudor, et al. Expires 3 January 2027 [Page 10]