Extending SDF and CoAP for AI Agent Interaction with IoT Devices

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 7 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 and restrictions with respect to this document.¶

Table of Contents

1. Introduction

AI agents — software systems that combine large language models with tool use and autonomous decision-making — are increasingly used to interact with networked services on behalf of users. In the IoT domain, devices expose their capabilities through machine-readable descriptions such as SDF [RFC9880]. Agents that want to discover, understand, and actuate IoT devices need to consume these descriptions and communicate with the devices, often over CoAP [RFC7252].¶

Two gaps exist in the current protocol landscape:¶

1. CoAP has no mechanism for a client to declare that it is an AI agent, nor to carry an authenticated agent identity. Servers cannot distinguish an autonomous agent from a human-operated application, limiting their ability to apply agent-specific policies.¶

2. SDF documents are JSON-based and machine-readable, but they lack explicit guidance for LLM consumption. Missing or terse descriptions can cause agents to misinterpret device capabilities, leading to incorrect actions — a problem that ranges from wasted API calls to safety hazards when physical actuators are involved.¶

This document outlines approaches to address both gaps. It is informational and intended to frame discussion; it does not define protocol extensions or registrations.¶

2. Terminology

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

SDF:

Semantic Definition Format, a JSON-based language for describing IoT device capabilities [RFC9880].¶

AI Agent:

A software system that uses a large language model in a loop with external tools to achieve a goal autonomously.¶

LLM:

Large Language Model; a neural network trained on text that generates token sequences given an input context.¶

Resource Directory (RD):

A CoAP-based directory where endpoints register their resources [RFC9176].¶

3. AI Agent Identification for CoAP

On the web, work is underway to authenticate automated clients through HTTP Message Signatures [RFC9421] and related mechanisms such as [I-D.meunier-web-bot-auth-architecture]. These approaches let servers verify what software is making a request and apply appropriate policies.¶

In parallel, the IETF WIMSE (Workload Identity in Multi-System Environments) working group is defining identity credentials for workloads, including autonomous agents. The Workload Identity Token (WIT) [I-D.ietf-wimse-workload-creds] is a signed token that represents a workload's identity, and the Workload Proof Token (WPT) [I-D.ietf-wimse-wpt] lets a workload prove possession of the key bound to its WIT on a per-request basis. Together these represent the current state of the art for authenticated agent identity, but they are defined for HTTP and JSON-based environments.¶

CoAP has no equivalent. The protocol authenticates devices via DTLS or OSCORE [RFC8613], but these mechanisms establish device identity, not the nature of the client software. A CoAP server receiving a GET request cannot tell whether the client is a firmware update agent, a user's mobile app, or an autonomous AI agent exploring device capabilities.¶

GET /sensors/temperature
Agent-ID: h'a4012667...' (COSE_Sign1, keyid "sig1")
Accept: 60 (application/cbor)

2.05 Content
Content-Format: 60 (application/cbor)

22.5

4. SDF Content Negotiation for AI Agents

SDF documents are designed for toolchains and developers. An AI agent requesting an SDF model receives a JSON structure that it can parse, but may not correctly interpret — particularly when optional description fields are absent or terse. The agent has no way to signal that it would prefer a representation optimized for language model consumption.¶

GET /models/thermometer
Accept: text/sdf

GET /sdf?rt=ai

GET /sdf/thermometer
Accept: 434 (application/sdf+json)

2.05 Content
Content-Format: 434 (application/sdf+json)

{
  "sdfObject": {
    "thermometer": {
      "sdfProperty": {
        "temperature": { "type": "number", "unit": "Cel" }
      }
    }
  }
}

GET /sdf/thermometer
Accept: TBD (text/sdf)

2.05 Content
Content-Format: TBD (text/sdf)

Temperature sensor. Property @T is the reading in Celsius.
GET /temperature to read it.

5. LLM-Friendly SDF Descriptions

Even when an AI agent successfully retrieves and parses an SDF document, it may misinterpret the semantics. Tests show that agents make errors when critical optional fields (like description) are missing, or when the relationship between properties, actions, and events is not obvious from the JSON structure alone.¶

{
  "sdfBot": "Temperature sensor. @T is the reading in Celsius.",
  "sdfObject": {
    "thermometer": {
      "sdfProperty": {
        "temperature": {
          "description": "Measured temperature",
          "type": "number",
          "unit": "Cel",
          "botRef": "T",
          "sdfBot": "Read-only. GET /temperature (Celsius)."
        }
      }
    }
  }
}

{
  "sdfStructuredExamples": [
    {
      "task": "Get temperature notifications every 3s for 60s.",
      "action": "Execute sdfAction/startMonitor",
      "parameters": {
        "interval": 3,
        "duration": 60
      }
    }
  ]
}

{
  "sdfStructuredExamples": [
    {
      "task": "Update firmware of the device to version 2",
      "steps": [
        {
          "action": "Set sdfProperty/firmware to v2 image",
          "parameters": "<new firmware file>"
        },
        {
          "action": "Execute sdfAction/startFirmwareUpdate"
        },
        {
          "action": "Observe sdfProperty/firmwareVersion",
          "readyWhen": "sdfProperty/firmwareVersion has version 2"
        }
      ]
    }
  ]
}

6. Security Considerations

Agent identification introduces the question of trust: a server must decide which agent identities to accept and what policies to associate with them. The cryptographic signature in the Agent-ID option prevents impersonation but does not establish authorization. Servers need a policy framework to map verified agent identities to permitted actions.¶

The sdfBot and sdfStructuredExamples qualities expose instructions that agents will follow. Malicious or poorly written content could cause agents to perform unintended actions, and structured examples are especially risky because they name concrete actions and parameters, so an agent may execute them with little further reasoning. Developers should treat both qualities as security-relevant, similar to API documentation that automated systems act on without human review. A server or intermediary that assembles the text/sdf representation should only incorporate content from trusted SDF sources.¶

Content usage restrictions signaled via agent-aware responses are advisory. Enforcement depends on the agent honoring them; a malicious agent can ignore any declared restrictions. Servers holding sensitive data should not rely solely on declared agent identity for access control.¶

7. IANA Considerations

This document requests no IANA actions. If the mechanisms discussed here were pursued, they would require registrations for a CoAP option number for Agent-ID, a media type and CoAP Content-Format for the agent-oriented SDF representation, and a resource type value.¶

8. References

Authors' Addresses