# drafts

name: draft-cui-dmsc-agent-cdi
rev: 00
title: Cross-Domain Interoperability Framework for AI Agent Collaboration
time: 2026-02-11T02:13:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-15T02:13:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.590964+00:00
source: ietf
abstract:
  This document defines a framework for enabling seamless cross-domain
     interoperability among AI agents operating across different networks,
     administrative domains, and heterogeneous platforms.  The framework
     addresses the challenges of identity federation, trust establishment,
     policy harmonization, and secure communication that arise when AI
     agents from distinct administrative realms need to collaborate on
     shared tasks.  It specifies mechanisms for agent discovery,
     capability negotiation, trust delegation, and federated policy
     enforcement, enabling scalable and secure multi-domain AI
     collaboration without requiring centralized control.

full_text:
  WG Working Group                                                  Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                          11 February 2026
  Expires: 15 August 2026


     Cross-Domain Interoperability Framework for AI Agent Collaboration
                        draft-cui-dmsc-agent-cdi-00

  Abstract

     This document defines a framework for enabling seamless cross-domain
     interoperability among AI agents operating across different networks,
     administrative domains, and heterogeneous platforms.  The framework
     addresses the challenges of identity federation, trust establishment,
     policy harmonization, and secure communication that arise when AI
     agents from distinct administrative realms need to collaborate on
     shared tasks.  It specifies mechanisms for agent discovery,
     capability negotiation, trust delegation, and federated policy
     enforcement, enabling scalable and secure multi-domain AI
     collaboration without requiring centralized control.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-dmsc-agent-cdi/.

     Discussion of this document takes place on the WG Working Group
     mailing list (mailto:WG@example.com), which is archived at
     https://example.com/WG.

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




  Cui                      Expires 15 August 2026                 [Page 1]


  Internet-Draft                  CDI-Agent                  February 2026


     This Internet-Draft will expire on 15 August 2026.

  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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Cross-Domain Interoperability Framework . . . . . . . . . . .   6
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  *Architecture Components* . . . . . . . . . . . . . . . .   6
         4.2.1.  Interoperability Gateway  . . . . . . . . . . . . . .   7
         4.2.2.  Agent Registry and Directory  . . . . . . . . . . . .   7
         4.2.3.  Cross-Domain Agent Runtime  . . . . . . . . . . . . .   8
     5.  Trust Establishment Framework . . . . . . . . . . . . . . . .   8
       5.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.  Trust Establishment Protocols . . . . . . . . . . . . . .   9
         5.2.1.  Domain Federation Protocol  . . . . . . . . . . . . .   9
         5.2.2.  Agent Delegation Protocol . . . . . . . . . . . . . .  10
     6.  Identity and Access Management  . . . . . . . . . . . . . . .  10
       6.1.  Federated Identity Model  . . . . . . . . . . . . . . . .  10
         6.1.1.  Agent Identifiers . . . . . . . . . . . . . . . . . .  10
         6.1.2.  Credential Types  . . . . . . . . . . . . . . . . . .  11
       6.2.  Access Control Framework  . . . . . . . . . . . . . . . .  11
         6.2.1.  Multi-Domain Policy Model . . . . . . . . . . . . . .  11
         6.2.2.  Policy Negotiation Protocol . . . . . . . . . . . . .  11
         6.2.3.  Attribute-Based Access Control (ABAC) . . . . . . . .  12
     7.  Capability Discovery and Negotiation  . . . . . . . . . . . .  12
       7.1.  Capability Description Language . . . . . . . . . . . . .  12
       7.2.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . .  13
         7.2.1.  Directory-Based Discovery . . . . . . . . . . . . . .  13
         7.2.2.  Peer-to-Peer Discovery  . . . . . . . . . . . . . . .  14
       7.3.  Capability Negotiation Protocol . . . . . . . . . . . . .  14
     8.  Communication Protocols . . . . . . . . . . . . . . . . . . .  15
       8.1.  Cross-Domain Message Format . . . . . . . . . . . . . . .  15



  Cui                      Expires 15 August 2026                 [Page 2]


  Internet-Draft                  CDI-Agent                  February 2026


       8.2.  Communication Patterns  . . . . . . . . . . . . . . . . .  16
         8.2.1.  Direct Agent-to-Agent Communication . . . . . . . . .  16
         8.2.2.  Gateway-Mediated Communication  . . . . . . . . . . .  17
         8.2.3.  Store-and-Forward Communication . . . . . . . . . . .  17
       8.3.  Protocol Layering . . . . . . . . . . . . . . . . . . . .  17
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
       9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  18
       9.2.  Security Controls . . . . . . . . . . . . . . . . . . . .  18
         9.2.1.  Authentication and Authorization  . . . . . . . . . .  18
         9.2.2.  Data Protection . . . . . . . . . . . . . . . . . . .  19
         9.2.3.  Monitoring and Detection  . . . . . . . . . . . . . .  19
       9.3.  Security Assurance  . . . . . . . . . . . . . . . . . . .  19
         9.3.1.  Trust Verification  . . . . . . . . . . . . . . . . .  19
         9.3.2.  Audit and Accountability  . . . . . . . . . . . . . .  20
     10. Performance and Scalability . . . . . . . . . . . . . . . . .  20
       10.1.  Performance Metrics  . . . . . . . . . . . . . . . . . .  20
       10.2.  Scalability Considerations . . . . . . . . . . . . . . .  20
         10.2.1.  Horizontal Scaling . . . . . . . . . . . . . . . . .  20
         10.2.2.  Federation Scaling . . . . . . . . . . . . . . . . .  21
       10.3.  Resource Management  . . . . . . . . . . . . . . . . . .  21
         10.3.1.  Computational Resources  . . . . . . . . . . . . . .  21
         10.3.2.  Network Resources  . . . . . . . . . . . . . . . . .  21
     11. Deployment Considerations . . . . . . . . . . . . . . . . . .  22
       11.1.  Deployment Models  . . . . . . . . . . . . . . . . . . .  22
         11.1.1.  Centralized Gateway Model  . . . . . . . . . . . . .  22
         11.1.2.  Distributed Gateway Model  . . . . . . . . . . . . .  22
         11.1.3.  Hybrid Model . . . . . . . . . . . . . . . . . . . .  22
       11.2.  Integration with Existing Systems  . . . . . . . . . . .  23
         11.2.1.  Legacy Agent Systems . . . . . . . . . . . . . . . .  23
         11.2.2.  Cloud and Edge Deployments . . . . . . . . . . . . .  23
       11.3.  Operational Considerations . . . . . . . . . . . . . . .  23
         11.3.1.  Monitoring and Management  . . . . . . . . . . . . .  23
         11.3.2.  Update and Maintenance . . . . . . . . . . . . . . .  24
     12. Use Cases and Examples  . . . . . . . . . . . . . . . . . . .  24
       12.1.  Cross-Enterprise Supply Chain Optimization . . . . . . .  24
       12.2.  Smart City Federation  . . . . . . . . . . . . . . . . .  25
       12.3.  Cross-Border Financial Services Collaboration  . . . . .  25
       12.4.  Cross-Domain Emergency Response System . . . . . . . . .  26
       12.5.  Multi-Cloud AI Workload Orchestration  . . . . . . . . .  28
       12.6.  International Research Data Commons  . . . . . . . . . .  29
       12.7.  Smart Manufacturing Supply Chain . . . . . . . . . . . .  30
       12.8.  Cross-Jurisdictional Law Enforcement Collaboration . . .  31
       12.9.  Global Energy Grid Coordination  . . . . . . . . . . . .  32
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     14. Normative References  . . . . . . . . . . . . . . . . . . . .  33
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  34
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  34




  Cui                      Expires 15 August 2026                 [Page 3]


  Internet-Draft                  CDI-Agent                  February 2026


  1.  Introduction

     The proliferation of AI agents across different organizational
     boundaries has created a need for mechanisms that enable these agents
     to collaborate effectively across domains.  Traditional agent systems
     are typically designed to operate within a single administrative
     domain, where trust relationships, identity management, and policy
     enforcement are centrally controlled.  However, real-world
     applications increasingly require AI agents to work together across
     organizational boundaries, such as in supply chain optimization,
     cross-enterprise workflow automation, smart city coordination, and
     distributed scientific research.

     Cross-domain interoperability for AI agents presents several unique
     challenges:

     1.  *Trust Establishment*: How to establish and verify trust between
         agents from different administrative domains without a central
         authority.

     2.  *Identity Federation*: How to manage agent identities and
         credentials across domains while preserving privacy and
         sovereignty.

     3.  *Policy Harmonization*: How to reconcile potentially conflicting
         policies from different domains to enable collaborative
         operations.

     4.  *Capability Discovery*: How agents can discover and understand
         the capabilities of foreign agents while respecting domain
         boundaries.

     5.  *Secure Communication*: How to establish secure communication
         channels that cross domain boundaries with appropriate security
         guarantees.

     6.  *Accountability and Auditing*: How to maintain accountability for
         actions taken by federated agents while respecting domain
         autonomy.

     This document proposes a framework that addresses these challenges
     through a combination of federated trust mechanisms, standardized
     capability descriptions, policy negotiation protocols, and secure
     communication patterns.  The framework is designed to be
     incrementally deployable and compatible with existing single-domain
     agent architectures.





  Cui                      Expires 15 August 2026                 [Page 4]


  Internet-Draft                  CDI-Agent                  February 2026


  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119] .

  3.  Terminology

     The following terms are defined in this draft

     *  *MCP (Model Context Protocol)*: A protocol that standardizes tool
        invocation and data interaction between AI agents and external
        hosts using JSON-RPC over stdio or HTTP.

     *  *Host*: The process or service that provides tools or resources to
        the agent via MCP, typically running as a backend process or
        plugin.

     *  *Agent*: An AI entity that uses MCP to invoke external tools to
        accomplish tasks.

     *  *Security Enhancement Layer (SEL)*: An external security layer
        that provides transparent security controls for MCP communication
        without protocol modification.

     *  *Client Shield*: The security component deployed on the MCP client
        (Host) side, responsible for protecting user interests.

     *  *Server Shield*: The security component deployed on the MCP server
        (tool provider) side, responsible for protecting service provider
        interests.

     *  *Data Backflow*: The transmission of sensitive data from the agent
        environment to external tools beyond authorized scope or without
        proper safeguards.

     *  *Dual Authorization*: An authorization model requiring both
        platform policy validation and explicit user consent for sensitive
        operations.

     *  *Trace ID*: A globally unique identifier used to correlate events
        across the MCP communication chain for auditing and
        troubleshooting.

     The following abbreviations are used in this document:

     *  *CDI*: Cross-Domain Interoperability




  Cui                      Expires 15 August 2026                 [Page 5]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *CDA*: Cross-Domain Agent

     *  *FIM*: Federated Identity Management

     *  *ABAC*: Attribute-Based Access Control

     *  *REST*: Representational State Transfer

     *  *JWT*: JSON Web Token

     *  *OIDC*: OpenID Connect

     *  *SAML*: Security Assertion Markup Language

     *  *DID*: Decentralized Identifier

     *  *VC*: Verifiable Credential

  4.  Cross-Domain Interoperability Framework

  4.1.  Overview

     The Cross-Domain Interoperability Framework for AI Agents is designed
     as a federated architecture that enables secure and scalable
     collaboration between agents from different administrative domains.
     The framework operates on several key principles:

     1.  *Domain Autonomy*: Each administrative domain maintains control
         over its own agents, policies, and resources.

     2.  *Minimal Trust Assumptions*: Domains establish trust
         relationships only as needed for specific collaborations.

     3.  *Graduated Interoperability*: Domains can choose different levels
         of integration based on trust and requirements.

     4.  *Auditability*: All cross-domain interactions are logged and
         auditable by all participating domains.

     5.  *Fail-Safe Design*: System failures or malicious actions in one
         domain should not compromise other domains.

  4.2.  *Architecture Components*

     The framework consists of the following core components:






  Cui                      Expires 15 August 2026                 [Page 6]


  Internet-Draft                  CDI-Agent                  February 2026


    +----------------+       +------------------+       +----------------+
    | Domain A       |       | Interoperability |       | Domain B       |
    | Administration |<----->|   Gateway        |<----->| Administration |
    | & Control      |       |   Federation     |       | & Control      |
    +----------------+       +------------------+       +----------------+
         |                         |                       |
         | (Home Domain)           |(Gateway-mediated)     |(Home Domain)
         v                         v                       v
    +----------------+       +------------------+       +----------------+
    | Agent Registry |       |   Trust Broker   |       | Agent Registry |
    | & Directory    |       |   & Policy Engine|       | & Directory    |
    +----------------+       +------------------+       +----------------+
         |                         |                       |
         | (Local Agents)          |(Cross-Domain Agents)  |(Local Agents)
         v                         v                       v
    +----------------+       +------------------+       +----------------+
    | AI Agent A1    |<----->|   AI Agent A2    |<----->| AI Agent B1    |
    | (Domain A)     |       |   (Domain A,     |       | (Domain B)     |
    |                |       |    operating in  |       |                |
    | AI Agent A3    |       |    Domain B)     |       | AI Agent B2    |
    | (Domain A)     |       +------------------+       | (Domain B)     |
    +----------------+                                  +----------------+

  4.2.1.  Interoperability Gateway

     The Interoperability Gateway serves as the primary interface between
     domains, providing:

     *  *Trust Brokerage*: Mediates trust establishment between domains
        using verifiable credentials and reputation systems.

     *  *Policy Mediation*: Translates and reconciles policies between
        domains to enable collaborative operations.

     *  *Agent Discovery*: Facilitates discovery of agents and their
        capabilities across domain boundaries.

     *  *Communication Routing*: Routes messages between agents in
        different domains with appropriate security.

     *  *Audit Collection*: Collects and correlates audit trails from
        cross-domain interactions.

  4.2.2.  Agent Registry and Directory

     Each domain maintains an Agent Registry that provides:





  Cui                      Expires 15 August 2026                 [Page 7]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Local Agent Directory*: Catalog of agents within the domain with
        their capabilities and status.

     *  *Foreign Agent Cache*: Cached information about agents from other
        domains that have been authorized to operate locally.

     *  *Capability Repository*: Structured descriptions of agent
        capabilities using standardized schemas.

     *  *Policy Repository*: Storage for domain-specific policies
        governing agent behavior.

  4.2.3.  Cross-Domain Agent Runtime

     Agents operating in foreign domains require enhanced runtime
     components:

     *  *Policy Compliance Engine*: Ensures agent behavior complies with
        both home and foreign domain policies.

     *  *Context Adaptation Module*: Adapts agent behavior based on the
        operating context and domain-specific requirements.

     *  *Secure Communication Module*: Implements cross-domain
        communication protocols with end-to-end security.

     *  *Audit Logging Module*: Maintains detailed logs of all cross-
        domain operations for accountability.

  5.  Trust Establishment Framework

  5.1.  Trust Model

     The framework employs a multi-layered trust model:

     1.  *Domain-to-Domain Trust*: Established through bilateral
         agreements, verifiable credentials, or reputation systems.

     2.  *Agent-to-Agent Trust*: Derived from domain trust but enhanced
         with agent-specific credentials and behavioral attestations.

     3.  *Task-Specific Trust*: Limited trust established for specific
         collaborative tasks with clearly defined boundaries.

     4.  *Revocable Trust*: All trust relationships are time-bound and
         revocable by any participating domain.





  Cui                      Expires 15 August 2026                 [Page 8]


  Internet-Draft                  CDI-Agent                  February 2026


  5.2.  Trust Establishment Protocols

  5.2.1.  Domain Federation Protocol

     Domains establish trust relationships through a multi-phase protocol:

     Phase 1: Discovery and Introduction

     +-----------+         +-----------+         +-----------+
     |  Domain A |         | Discovery |         |  Domain B |
     |           |         |  Service  |         |           |
     +-----------+         +-----------+         +-----------+
          |                        |                        |
          | 1. Query for compatible|                        |
          |    partners            |                        |
          |----------------------->|                        |
          |                        |                        |
          | 2. Return list of      |                        |
          |    potential partners  |                        |
          |<-----------------------|                        |
          |                        |                        |
          | 3. Request introduction|                        |
          |    to Domain B         |                        |
          |----------------------->|                        |
          |                        |                        |
          | 4. Forward introduction|                        |
          |    request             |                        |
          |                        |----------------------->|
          |                        |                        |

     Phase 2: Capability and Policy Exchange

          |                        |                        |
          | 5. Send capability     |                        |
          |    profile and policy  |                        |
          |    assertions          |                        |
          |<------------------------------------------------|
          |                        |                        |
          | 6. Evaluate compatibility|                      |
          |    and risk            |                        |
          |------------------------------------------------>|
          |                        |                        |

     Phase 3: Trust Agreement

          |                        |                        |
          | 7. Propose trust       |                        |
          |    agreement with terms|                        |



  Cui                      Expires 15 August 2026                 [Page 9]


  Internet-Draft                  CDI-Agent                  February 2026


          |    and conditions      |                        |
          |<------------------------------------------------|
          |                        |                        |
          | 8. Negotiate and       |                        |
          |    finalize agreement  |                        |
          |------------------------------------------------>|
          |                        |                        |
          | 9. Exchange signed     |                        |
          |    trust certificates  |                        |
          |<------------------------------------------------|
          |                        |                        |

  5.2.2.  Agent Delegation Protocol

     Once domains establish trust, agents can be delegated to operate in
     foreign domains:

     1.  *Delegation Request*: Home domain requests delegation for
         specific agents with defined capabilities and constraints.

     2.  *Policy Alignment*: Foreign domain evaluates the request against
         its policies and may negotiate constraints.

     3.  *Credential Issuance*: Home domain issues verifiable credentials
         to agents for use in the foreign domain.

     4.  *Local Registration*: Agents register with the foreign domain's
         Agent Registry using their credentials.

     5.  *Periodic Revalidation*: Delegated credentials are periodically
         revalidated and can be revoked at any time.

  6.  Identity and Access Management

  6.1.  Federated Identity Model

     The framework employs a federated identity model with the following
     components:

  6.1.1.  Agent Identifiers

     Each agent has multiple identifiers for different contexts:

     *  *Home Domain Identifier*: Unique identifier within the home domain
        (e.g., UUID, email-style address).

     *  *Federated Identifier*: Globally unique identifier for cross-
        domain recognition (e.g., DID, URN).



  Cui                      Expires 15 August 2026                [Page 10]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Session Identifiers*: Temporary identifiers for specific
        collaborative sessions.

  6.1.2.  Credential Types

     *  *Domain Identity Credentials*: Verifiable credentials issued by
        the home domain attesting to the agent's identity and basic
        attributes.

     *  *Capability Credentials*: Credentials attesting to specific agent
        capabilities and skill levels.

     *  *Delegation Credentials*: Credentials authorizing an agent to
        operate in a foreign domain with specific permissions.

     *  *Task Credentials*: Limited-scope credentials for specific
        collaborative tasks.

  6.2.  Access Control Framework

  6.2.1.  Multi-Domain Policy Model

     Access control decisions consider policies from multiple domains:

     Access Decision = f(Home Domain Policy, Foreign Domain Policy,
     Collaborative Task Policy, Dynamic Context Factors)

  6.2.2.  Policy Negotiation Protocol

     When policies conflict, domains negotiate to find acceptable
     compromises:

     1.  *Policy Disclosure*: Domains share relevant policy fragments (not
         necessarily complete policies).

     2.  *Conflict Detection*: Identify conflicts between policies from
         different domains.

     3.  *Resolution Proposal*: Propose policy modifications or exceptions
         to resolve conflicts.

     4.  *Agreement Finalization*: Domains agree on a merged policy for
         the specific collaboration.

     5.  *Policy Enforcement*: The agreed policy is enforced by all
         participating domains.





  Cui                      Expires 15 August 2026                [Page 11]


  Internet-Draft                  CDI-Agent                  February 2026


  6.2.3.  Attribute-Based Access Control (ABAC)

     The framework uses ABAC with attributes from multiple sources:

     *  *Agent Attributes*: Identity, capabilities, reputation score, home
        domain.

     *  *Resource Attributes*: Sensitivity, ownership, location,
        classification.

     *  *Environmental Attributes*: Time, network location, threat level.

     *  *Collaboration Attributes*: Task type, participating domains,
        trust level.

  7.  Capability Discovery and Negotiation

  7.1.  Capability Description Language

     Agents describe their capabilities using a structured language based
     on JSON Schema:






























  Cui                      Expires 15 August 2026                [Page 12]


  Internet-Draft                  CDI-Agent                  February 2026


     {
       "agent_capability_profile": {
         "version": "1.0",
         "agent_id": "did:example:agent123",
         "home_domain": "example.com",
         "capabilities": [
           {
             "capability_id": "natural_language_processing",
             "category": "ai_processing",
             "subcategories": ["text_analysis", "sentiment_analysis"],
             "performance_metrics": {
               "accuracy": 0.92,
               "latency_ms": 150,
               "throughput_rps": 100
             },
             "input_formats": ["text/plain", "application/json"],
             "output_formats": ["application/json"],
             "privacy_attributes": {
               "data_retention": "ephemeral",
               "data_sharing": "none"
             },
             "resource_requirements": {
               "compute_units": 2,
               "memory_mb": 512,
               "network_bandwidth_mbps": 10
             }
           }
         ],
         "constraints": {
           "max_concurrent_tasks": 5,
           "supported_domains": ["example.com", "partner.org"],
           "geographic_restrictions": ["US", "EU"],
           "compliance_frameworks": ["GDPR", "HIPAA"]
         }
       }
     }

  7.2.  Discovery Mechanisms

  7.2.1.  Directory-Based Discovery

     Domains publish authorized agent capabilities in federated
     directories:

     1.  *Local Directory Registration*: Agents register capabilities with
         their home domain directory.





  Cui                      Expires 15 August 2026                [Page 13]


  Internet-Draft                  CDI-Agent                  February 2026


     2.  *Federated Directory Sync*: Domain directories synchronize
         authorized capability information.

     3.  *Query Interface*: Agents query directories to discover
         capabilities across domains.

     4.  *Privacy-Preserving Queries*: Support for capability discovery
         without revealing specific agent identities when not needed.

  7.2.2.  Peer-to-Peer Discovery

     For dynamic or ad-hoc collaborations:

     1.  *Capability Advertisement*: Agents broadcast capability summaries
         within trusted networks.

     2.  *Matchmaking Services*: Third-party services match agents with
         complementary capabilities.

     3.  *Reputation-Based Discovery*: Discover agents based on reputation
         scores from previous collaborations.

  7.3.  Capability Negotiation Protocol

     When agents with complementary capabilities are identified:


























  Cui                      Expires 15 August 2026                [Page 14]


  Internet-Draft                  CDI-Agent                  February 2026


    +-----------+                +-----------+               +-----------+
    | Agent A   |                | Gateway   |               | Agent B   |
    | (Domain X)|                |           |               | (Domain Y)|
    +-----------+                +-----------+               +-----------+
          |                            |                           |
          | 1. Initiate collaboration  |                           |
          |    request                 |                           |
          |--------------------------->|                           |
          |                            |                           |
          |                            |  2. Forward to suitable   |
          |                            |      partner (Agent B)    |
          |                            |-------------------------->|
          |                            |  3. Return capability     |
          |                            |     requirements and      |
          |                            |      constraints          |
          |                            |<--------------------------|
          |                            |                           |
          | 4. Check compatibility and |                           |
          |    policy compliance       |                           |
          |<---------------------------|                           |
          |                            |                           |
          | 5. Negotiate specific      |                           |
          |    parameters (quality,    |                           |
          |    cost, timing)           |                           |
          |--------------------------->|                           |
          |                            |-------------------------->|
          |                            | 6. Reach agreement        |
          |                            |                           |
          |                            |<--------------------------|
          |                            |                           |
          | 7. Finalize collaboration  |                           |
          |    contract                |                           |
          |<---------------------------|                           |
          |                            |                           |

  8.  Communication Protocols

  8.1.  Cross-Domain Message Format

     All cross-domain messages use a standardized envelope format:











  Cui                      Expires 15 August 2026                [Page 15]


  Internet-Draft                  CDI-Agent                  February 2026


     {
       "message_envelope": {
         "version": "1.0",
         "message_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
         "timestamp": "2024-01-15T10:30:00Z",
         "sender": {
           "agent_id": "did:example:sender123",
           "domain": "example.com",
           "credentials": ["vc:example:credential456"]
         },
         "recipient": {
           "agent_id": "did:example:recipient789",
           "domain": "partner.org"
         },
         "routing": {
           "path": ["gateway.example.com", "gateway.partner.org"],
           "hops": 2,
           "ttl": 3600
         },
         "security": {
           "encryption": "A256GCM",
           "signature": "ES256",
           "integrity_protection": true
         },
         "payload": {
           "type": "task_request",
           "content": "Base64-encoded encrypted payload",
           "content_type": "application/json"
         },
         "metadata": {
           "priority": "normal",
           "response_required": true,
           "audit_trail_id": "audit:example:trail123"
         }
       }
     }

  8.2.  Communication Patterns

  8.2.1.  Direct Agent-to-Agent Communication

     For high-trust, high-performance scenarios:

     1.  *Tunnel Establishment*: Establish secure tunnels through domain
         gateways.

     2.  *Peer Authentication*: Mutual authentication using domain-issued
         credentials.



  Cui                      Expires 15 August 2026                [Page 16]


  Internet-Draft                  CDI-Agent                  February 2026


     3.  *End-to-End Encryption*: Application-layer encryption independent
         of transport security.

     4.  *Heartbeat Monitoring*: Continuous monitoring of connection
         health and security.

  8.2.2.  Gateway-Mediated Communication

     For enhanced security and policy enforcement:

     1.  *Message Inspection*: Gateways inspect messages for policy
         compliance.

     2.  *Content Transformation*: Gateways may transform content to meet
         domain requirements.

     3.  *Quality of Service*: Gateways provide QoS guarantees for cross-
         domain communication.

     4.  *Load Balancing*: Gateways distribute traffic across multiple
         agent instances.

  8.2.3.  Store-and-Forward Communication

     For disconnected or asynchronous operations:

     1.  *Message Queuing*: Gateways queue messages when recipients are
         unavailable.

     2.  *Delivery Guarantees*: Configurable delivery guarantees (at-most-
         once, at-least-once, exactly-once).

     3.  *Priority Handling*: Priority-based message scheduling and
         delivery.

     4.  *Dead Letter Handling*: Processing of undeliverable messages.

  8.3.  Protocol Layering

     The communication protocol stack for cross-domain agent interaction:











  Cui                      Expires 15 August 2026                [Page 17]


  Internet-Draft                  CDI-Agent                  February 2026


     +-----------------------------------------------------+
     |           Application-Specific Protocols            |
     |  (Task coordination, data exchange, collaboration)  |
     +-----------------------------------------------------+
     |         Cross-Domain Agent Messaging Protocol       |
     |    (Envelope format, routing, reliability, QoS)     |
     +-----------------------------------------------------+
     |              Security Layer Protocol                |
     |    (Authentication, encryption, integrity, nonce)   |
     +-----------------------------------------------------+
     |              Trust Layer Protocol                   |
     |    (Credential verification, policy enforcement)    |
     +-----------------------------------------------------+
     |             Transport Layer Protocol                |
     |        (HTTP/2, WebSocket, MQTT, AMQP)             |
     +-----------------------------------------------------+

  9.  Security Considerations

  9.1.  Threat Model

     The framework addresses the following threat vectors:

     1.  *Impersonation Attacks*: Malicious agents pretending to be
         legitimate agents from trusted domains.

     2.  *Policy Bypass Attacks*: Attempts to circumvent domain policies
         through technical or procedural means.

     3.  *Data Exfiltration*: Unauthorized transfer of sensitive data
         across domain boundaries.

     4.  *Denial of Service*: Attacks targeting the availability of cross-
         domain collaboration services.

     5.  *Trust Exploitation*: Abuse of trust relationships to gain
         unauthorized access or privileges.

     6.  *Audit Tampering*: Attempts to modify or delete audit logs to
         conceal malicious activities.

  9.2.  Security Controls

  9.2.1.  Authentication and Authorization

     *  *Multi-Factor Authentication*: Require multiple credentials for
        sensitive operations.




  Cui                      Expires 15 August 2026                [Page 18]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Continuous Authentication*: Re-authenticate agents periodically
        during long sessions.

     *  *Context-Aware Authorization*: Adjust permissions based on dynamic
        risk assessments.

     *  *Least Privilege Enforcement*: Grant minimal necessary permissions
        for each task.

  9.2.2.  Data Protection

     *  *End-to-End Encryption*: Encrypt sensitive data throughout its
        lifecycle.

     *  *Data Minimization*: Transfer only necessary data for each
        collaboration.

     *  *Privacy-Preserving Computation*: Use techniques like federated
        learning and secure multi-party computation.

     *  *Data Sovereignty*: Respect data sovereignty requirements of each
        domain.

  9.2.3.  Monitoring and Detection

     *  *Behavioral Analytics*: Monitor agent behavior for anomalies
        indicative of compromise.

     *  *Cross-Domain Correlation*: Correlate security events across
        multiple domains.

     *  *Real-Time Threat Intelligence*: Integrate threat intelligence
        feeds from all participating domains.

     *  *Automated Response*: Automated containment and mitigation of
        detected threats.

  9.3.  Security Assurance

  9.3.1.  Trust Verification

     *  *Credential Chain Validation*: Verify the complete chain of
        credentials from root authorities.

     *  *Revocation Checking*: Continuously check credential revocation
        status.





  Cui                      Expires 15 August 2026                [Page 19]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Reputation Scoring*: Use reputation systems to assess agent
        trustworthiness.

     *  *Behavioral Attestation*: Use remote attestation to verify agent
        integrity.

  9.3.2.  Audit and Accountability

     *  *Immutable Audit Logs*: Store audit logs in tamper-evident
        storage.

     *  *Cross-Domain Audit Correlation*: Enable correlation of audit
        trails across domains.

     *  *Non-Repudiation*: Ensure agents cannot deny actions they have
        taken.

     *  *Forensic Readiness*: Maintain evidence for potential legal or
        investigative proceedings.

  10.  Performance and Scalability

  10.1.  Performance Metrics

     The framework defines the following performance metrics:

     1.  *Discovery Latency*: Time to discover suitable collaboration
         partners (target: < 5 seconds for 95% of queries).

     2.  *Trust Establishment Time*: Time to establish trust between
         previously unknown domains (target: < 30 seconds).

     3.  *Message Delivery Latency*: End-to-end latency for cross-domain
         messages (target: < 100ms for 95% of messages within same
         region).

     4.  *Policy Evaluation Time*: Time to evaluate access control
         policies (target: < 10ms per decision).

     5.  *Agent Registration Time*: Time for an agent to register in a
         foreign domain (target: < 2 seconds).

  10.2.  Scalability Considerations

  10.2.1.  Horizontal Scaling

     *  *Stateless Design*: Design components to be stateless where
        possible for easy scaling.



  Cui                      Expires 15 August 2026                [Page 20]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Load Distribution*: Distribute load across multiple instances of
        each component.

     *  *Geographic Distribution*: Deploy components in multiple
        geographic regions.

     *  *Caching Strategy*: Implement multi-level caching to reduce
        backend load.

  10.2.2.  Federation Scaling

     *  *Hierarchical Federation*: Organize domains into hierarchies to
        reduce pairwise trust relationships.

     *  *Transitive Trust*: Support transitive trust with appropriate
        safeguards.

     *  *Partial Mesh Networks*: Optimize trust relationships based on
        collaboration patterns.

     *  *Domain Clustering*: Group domains with frequent collaborations to
        reduce overhead.

  10.3.  Resource Management

  10.3.1.  Computational Resources

     *  *Elastic Scaling*: Automatically scale resources based on demand.

     *  *Resource Quotas*: Enforce resource quotas per domain and per
        agent.

     *  *Efficient Algorithms*: Use computationally efficient algorithms
        for cryptographic operations.

     *  *Hardware Acceleration*: Leverage hardware acceleration for
        performance-critical operations.

  10.3.2.  Network Resources

     *  *Bandwidth Management*: Prioritize cross-domain traffic based on
        importance.

     *  *Connection Pooling*: Reuse connections to reduce connection
        establishment overhead.

     *  *Compression*: Compress messages to reduce bandwidth usage.




  Cui                      Expires 15 August 2026                [Page 21]


  Internet-Draft                  CDI-Agent                  February 2026


     *  *Adaptive Protocols*: Use protocols that adapt to network
        conditions.

  11.  Deployment Considerations

  11.1.  Deployment Models

  11.1.1.  Centralized Gateway Model

     *  *Description*: All cross-domain traffic flows through centralized
        interoperability gateways.

     *  *Advantages*: Simplified management, consistent policy
        enforcement, comprehensive auditing.

     *  *Disadvantages*: Single point of failure, potential performance
        bottleneck, higher latency.

     *  *Use Cases*: Highly regulated environments, initial deployments,
        domains with limited technical resources.

  11.1.2.  Distributed Gateway Model

     *  *Description*: Each domain operates its own gateway, with gateways
        forming a peer-to-peer network.

     *  *Advantages*: No single point of failure, better performance,
        preserves domain autonomy.

     *  *Disadvantages*: More complex to manage, requires inter-gateway
        trust establishment.

     *  *Use Cases*: Large-scale deployments, domains with technical
        expertise, performance-sensitive applications.

  11.1.3.  Hybrid Model

     *  *Description*: Combination of centralized and distributed elements
        based on requirements.

     *  *Advantages*: Flexibility to optimize for different use cases,
        incremental deployment.

     *  *Disadvantages*: Increased complexity, potential consistency
        challenges.

     *  *Use Cases*: Evolving deployments, heterogeneous domain
        environments, transitional architectures.



  Cui                      Expires 15 August 2026                [Page 22]


  Internet-Draft                  CDI-Agent                  February 2026


  11.2.  Integration with Existing Systems

  11.2.1.  Legacy Agent Systems

     *  *Wrapper Components*: Develop wrappers that enable legacy agents
        to participate in cross-domain collaborations.

     *  *Protocol Translation*: Translate between legacy protocols and the
        cross-domain interoperability protocols.

     *  *Policy Mapping*: Map legacy policy mechanisms to the framework's
        policy model.

     *  *Gradual Migration*: Support gradual migration from legacy systems
        to native implementations.

  11.2.2.  Cloud and Edge Deployments

     *  *Cloud-Native Design*: Design components as cloud-native
        microservices.

     *  *Edge Optimization*: Optimize for edge deployments with limited
        resources.

     *  *Hybrid Cloud Support*: Support deployments spanning multiple
        cloud providers and on-premises infrastructure.

     *  *Containerization*: Package components as containers for easy
        deployment.

  11.3.  Operational Considerations

  11.3.1.  Monitoring and Management

     *  *Unified Dashboard*: Provide a unified dashboard for monitoring
        cross-domain collaborations.

     *  *Health Checks*: Implement comprehensive health checks for all
        components.

     *  *Alerting System*: Configurable alerting for security events and
        performance issues.

     *  *Capacity Planning*: Tools for capacity planning and resource
        allocation.






  Cui                      Expires 15 August 2026                [Page 23]


  Internet-Draft                  CDI-Agent                  February 2026


  11.3.2.  Update and Maintenance

     *  *Rolling Updates*: Support rolling updates without disrupting
        ongoing collaborations.

     *  *Version Compatibility*: Maintain compatibility between different
        versions of the framework.

     *  *Backward Compatibility*: Ensure new versions don't break existing
        deployments.

     *  *Migration Tools*: Provide tools for migrating between framework
        versions.

  12.  Use Cases and Examples

  12.1.  Cross-Enterprise Supply Chain Optimization

     *Scenario*: Multiple companies in a supply chain need to collaborate
     using AI agents to optimize inventory, logistics, and production
     scheduling.

     *Challenges*:

     *  Each company has its own systems, policies, and data sovereignty
        requirements.

     *  Sensitive business information must not be exposed to competitors.

     *  Real-time coordination is needed across organizational boundaries.

     *Solution using CDI Framework*:

     1.  Each company deploys an interoperability gateway.

     2.  Supply chain partners establish limited trust relationships for
         specific collaboration areas.

     3.  Agents are delegated with carefully constrained capabilities for
         supply chain optimization.

     4.  Privacy-preserving techniques (like federated learning) are used
         to train optimization models without sharing raw data.

     5.  Audit trails are maintained for compliance and dispute
         resolution.





  Cui                      Expires 15 August 2026                [Page 24]


  Internet-Draft                  CDI-Agent                  February 2026


  12.2.  Smart City Federation

     *Scenario*: Multiple municipalities want to collaborate on smart city
     initiatives while maintaining control over their own infrastructure
     and data.

     *Challenges*:

     *  Different municipalities have different regulations and policies.

     *  Citizens' privacy must be protected across jurisdictional
        boundaries.

     *  Emergency situations require rapid coordination.

     *Solution using CDI Framework*:

     1.  Each municipality operates as an independent domain.

     2.  A federation agreement establishes baseline trust and policies.

     3.  Specialized agents for traffic management, emergency response,
         and utility optimization can operate across municipalities.

     4.  Data sharing follows strict privacy-preserving protocols.

     5.  During emergencies, trust levels can be temporarily elevated to
         enable faster coordination.

  12.3.  Cross-Border Financial Services Collaboration

     *Scenario*: Financial institutions across different regulatory
     jurisdictions need AI agents to collaborate on fraud detection, risk
     assessment, and compliance monitoring while adhering to strict
     regulatory requirements.

     *Challenges*:

     *  Different countries have different financial regulations and
        compliance requirements.

     *  Sensitive customer financial data cannot be freely shared across
        borders.

     *  Real-time fraud detection requires rapid information exchange
        while maintaining data privacy.





  Cui                      Expires 15 August 2026                [Page 25]


  Internet-Draft                  CDI-Agent                  February 2026


     *  Audit trails must be comprehensive and legally admissible in
        multiple jurisdictions.

     *Solution using CDI Framework*:

     1.  Each financial institution operates within its regulatory domain
         with institution-specific policies.

     2.  Cross-border trust agreements are established with legal and
         regulatory compliance baked into the trust parameters.

     3.  Specialized agents for fraud pattern recognition can operate
         across institutions using privacy-preserving techniques like
         federated learning.

     4.  Regulatory compliance agents ensure all cross-border operations
         adhere to applicable laws (e.g., GDPR, CCPA, Basel III).

     5.  All transactions are logged with cryptographic proofs that can be
         verified by regulators in any jurisdiction.

     *Key Technical Features*:

     *  *Regulatory Policy Engines*: Each domain includes policy engines
        that encode jurisdictional regulations.

     *  *Privacy-Preserving Analytics*: Use of homomorphic encryption for
        cross-institution fraud pattern analysis without exposing raw
        transaction data.

     *  *Multi-Jurisdictional Audit*: Audit logs structured to meet
        requirements of multiple regulatory bodies simultaneously.

     *  *Emergency Override Protocols*: Controlled mechanisms for
        temporary policy relaxation during financial crises or systemic
        risk events.

  12.4.  Cross-Domain Emergency Response System

     *Scenario*: During natural disasters, public health emergencies, or
     cybersecurity incidents, AI agents from different organizations need
     to coordinate rapid response while maintaining security boundaries
     and respecting organizational autonomy.

     *Challenges*:

     *  Time-critical operations requiring collaboration establishment
        within minutes.



  Cui                      Expires 15 August 2026                [Page 26]


  Internet-Draft                  CDI-Agent                  February 2026


     *  Different organizations have varying command hierarchies and
        decision-making processes.

     *  Sensitive information must be shared only within necessary scope.

     *  Resource constraints during emergencies may affect communication
        reliability.

     *  Post-emergency accountability and after-action analysis
        requirements.

     *Solution using CDI Framework*:

     1.  *Pre-Established Trust Frameworks*: Organizations establish
         baseline trust relationships and policies during peacetime.

     2.  *Emergency Trust Elevation*: During declared emergencies, trust
         levels can be temporarily elevated with appropriate safeguards
         and post-event review requirements.

     3.  *Dynamic Policy Adaptation*: Emergency-specific policies override
         normal operating policies temporarily.

     4.  *Resource Pooling Coordination*: AI agents coordinate resource
         allocation across organizational boundaries while maintaining
         ownership tracking.

     5.  *Situational Awareness Sharing*: Secure sharing of situational
         data with granular access controls based on role and need-to-
         know.

     *Implementation Components*:

     *  *Emergency Declaration Protocol*: Standardized mechanism for
        organizations to declare emergencies and activate enhanced
        collaboration modes.

     *  *Priority Communication Channels*: Dedicated, high-priority
        communication paths for emergency coordination.

     *  *Resource Discovery and Allocation*: Dynamic discovery of
        available resources (personnel, equipment, facilities) across
        participating organizations.

     *  *Common Operational Picture*: Federated data aggregation to create
        unified situational awareness without centralizing sensitive
        information.




  Cui                      Expires 15 August 2026                [Page 27]


  Internet-Draft                  CDI-Agent                  February 2026


     *Example Flow - Natural Disaster Response*:

     1.  Earthquake occurs affecting multiple jurisdictions.

     2.  Emergency services from affected areas declare emergencies
         through their interoperability gateways.

     3.  Trust levels are automatically elevated based on pre-configured
         emergency protocols.

     4.  AI agents from different emergency services discover each other's
         capabilities through federated directories.

     5.  Resource coordination agents negotiate allocation of search-and-
         rescue teams, medical supplies, and evacuation routes.

     6.  Privacy-preserving techniques allow sharing of victim location
         data while protecting personally identifiable information.

     7.  Post-event, all actions are audited, trust levels revert to
         normal, and after-action reports are generated from the
         comprehensive audit logs.

  12.5.  Multi-Cloud AI Workload Orchestration

     *Scenario*: Enterprises running AI workloads across multiple cloud
     providers need agents to manage resources, optimize costs, and ensure
     compliance while avoiding vendor lock-in.

     *Challenges*:

     *  Different cloud providers have proprietary APIs and management
        interfaces.

     *  Data sovereignty requirements may restrict where workloads can
        run.

     *  Cost optimization requires dynamic workload migration across
        providers.

     *  Security policies must be consistently enforced across
        heterogeneous environments.

     *Solution using CDI Framework*:

     1.  Each cloud environment operates as a separate domain with cloud-
         specific policies and capabilities.




  Cui                      Expires 15 August 2026                [Page 28]


  Internet-Draft                  CDI-Agent                  February 2026


     2.  Enterprise governance domain defines overarching policies that
         apply across all cloud domains.

     3.  Orchestration agents operate across cloud domains to optimize
         workload placement based on cost, performance, and compliance
         requirements.

     4.  Data movement agents manage secure data transfer between cloud
         environments with appropriate encryption and access controls.

     5.  Compliance monitoring agents ensure consistent policy enforcement
         regardless of where workloads execute.

     *Technical Implementation*:

     *  *Cloud Abstraction Layer*: Standardized interface that abstracts
        cloud provider differences.

     *  *Cost Optimization Engine*: AI agents that analyze pricing models
        and performance metrics to recommend optimal workload placement.

     *  *Data Gravity Management*: Intelligent agents that minimize data
        movement costs by colocating computation with data.

     *  *Compliance Mapping*: Automated mapping of cloud provider
        compliance certifications to enterprise regulatory requirements.

  12.6.  International Research Data Commons

     *Scenario*: Global research collaborations need to share and analyze
     sensitive research data (e.g., genomic data, climate data,
     epidemiological data) while protecting participant privacy and
     respecting national data sovereignty laws.

     *Challenges*:

     *  Research data often contains sensitive personal information with
        strict privacy requirements.

     *  Different countries have different data protection laws and
        ethical review requirements.

     *  Researchers need to collaborate on analysis while maintaining
        control over their contributed data.

     *  Funding agencies require accountability for data usage and
        research outputs.




  Cui                      Expires 15 August 2026                [Page 29]


  Internet-Draft                  CDI-Agent                  February 2026


     *Solution using CDI Framework*:

     1.  Each research institution operates as an independent domain with
         institutional review board (IRB) approved policies.

     2.  Research consortia establish collaboration domains with
         consortium-specific policies that respect all member
         institutions' requirements.

     3.  Data analysis agents operate on federated data without needing to
         centralize sensitive information.

     4.  Publication agents coordinate multi-institution authorship and
         ensure proper attribution.

     5.  Data usage tracking agents monitor compliance with data use
         agreements across all participating institutions.

     *Key Features*:

     *  *Ethical Compliance Engine*: Automated checks for compliance with
        ethical research standards across jurisdictions.

     *  *Differential Privacy Integration*: Built-in differential privacy
        mechanisms for aggregate analysis.

     *  *Data Provenance Tracking*: Complete lineage tracking for research
        data from collection through analysis to publication.

     *  *Automated Institutional Review*: Streamlined process for cross-
        institutional research approval.

  12.7.  Smart Manufacturing Supply Chain

     *Scenario*: Manufacturers, suppliers, and logistics providers in a
     smart manufacturing ecosystem need to coordinate production,
     inventory, and delivery using AI agents while protecting intellectual
     property and competitive information.

     *Challenges*:

     *  Competitors may be part of the same supply chain, requiring
        information boundaries.

     *  Real-time coordination needed for just-in-time manufacturing and
        inventory management.





  Cui                      Expires 15 August 2026                [Page 30]


  Internet-Draft                  CDI-Agent                  February 2026


     *  Quality control data needs to flow upstream to suppliers without
        revealing proprietary manufacturing processes.

     *  Cybersecurity threats targeting interconnected industrial control
        systems.

     *Solution using CDI Framework*:

     1.  Each company in the supply chain operates as an independent
         domain with competitive boundary policies.

     2.  Supply chain collaboration domains establish limited information
         sharing agreements for specific coordination tasks.

     3.  Production planning agents coordinate across organizations while
         preserving competitive intelligence.

     4.  Quality monitoring agents share defect information with suppliers
         without revealing manufacturing process details.

     5.  Cybersecurity monitoring agents collaborate on threat detection
         while protecting each company's security posture information.

     *Implementation Approach*:

     *  *Need-to-Know Information Sharing*: Granular controls on what
        information is shared with which partners.

     *  *Competitive Boundary Management*: Clear policies defining what
        constitutes competitive information that should not be shared.

     *  *Real-Time Coordination Protocols*: Low-latency communication for
        time-sensitive manufacturing coordination.

     *  *Industrial IoT Security*: Specialized security protocols for
        industrial control system integration.

  12.8.  Cross-Jurisdictional Law Enforcement Collaboration

     *Scenario*: Law enforcement agencies from different jurisdictions
     need to collaborate on investigations while respecting legal
     boundaries, privacy laws, and chain of evidence requirements.

     *Challenges*:

     *  Different legal systems have different requirements for evidence
        collection and sharing.




  Cui                      Expires 15 August 2026                [Page 31]


  Internet-Draft                  CDI-Agent                  February 2026


     *  Privacy laws restrict sharing of personal information across
        borders.

     *  Chain of custody must be maintained for digital evidence.

     *  Need for rapid information sharing in time-sensitive
        investigations (e.g., kidnapping, terrorism).

     *Solution using CDI Framework*:

     1.  Each law enforcement agency operates within its jurisdictional
         domain with legally compliant policies.

     2.  Mutual legal assistance treaty (MLAT) frameworks are encoded into
         trust agreements between domains.

     3.  Investigation coordination agents facilitate information sharing
         within legal boundaries.

     4.  Evidence handling agents maintain chain of custody across
         jurisdictional transfers.

     5.  Legal compliance agents ensure all cross-jurisdictional
         operations adhere to applicable laws.

     *Technical Considerations*:

     *  *Legal Authority Verification*: Automated verification of legal
        authority for specific investigative actions.

     *  *Privacy-Preserving Matching*: Techniques for matching persons of
        interest without sharing full identity information.

     *  *Digital Evidence Chain of Custody*: Cryptographic proof of
        evidence integrity and custody chain.

     *  *Automated Legal Documentation*: Generation of legally required
        documentation for cross-jurisdictional operations.

  12.9.  Global Energy Grid Coordination

     *Scenario*: Energy providers, grid operators, and renewable energy
     producers across regions need to coordinate energy production,
     distribution, and consumption while maintaining grid stability and
     respecting commercial interests.

     *Challenges*:




  Cui                      Expires 15 August 2026                [Page 32]


  Internet-Draft                  CDI-Agent                  February 2026


     *  Different grid operators have proprietary control systems and
        protocols.

     *  Renewable energy sources introduce variability requiring real-time
        coordination.

     *  Commercial energy trading requires secure transaction mechanisms.

     *  Grid cybersecurity requires collaborative threat detection without
        revealing vulnerability information.

     *Solution using CDI Framework*:

     1.  Each energy provider and grid operator operates as an independent
         domain.

     2.  Regional coordination domains establish protocols for grid
         stability management.

     3.  Energy trading agents facilitate secure transactions across
         organizational boundaries.

     4.  Grid optimization agents coordinate production and consumption
         across regions.

     5.  Cybersecurity agents collaborate on threat detection while
         protecting proprietary system information.

     *Key Components*:

     *  *Grid Stability Protocols*: Standardized protocols for maintaining
        grid stability across interconnected systems.

     *  *Renewable Integration Management*: Coordination of variable
        renewable energy sources across the grid.

     *  *Secure Energy Trading*: Privacy-preserving mechanisms for energy
        market transactions.

     *  *Grid Resilience Coordination*: Collaborative response to grid
        disturbances and failures.

  13.  IANA Considerations

     This document has no IANA actions.

  14.  Normative References




  Cui                      Expires 15 August 2026                [Page 33]


  Internet-Draft                  CDI-Agent                  February 2026


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

  Acknowledgments

  Author's Address

     Yong Cui
     Tsinghua University
     Beijing, 100084
     China
     Email: cuiyong@tsinghua.edu.cn
     URI:   http://www.cuiyong.net/




































  Cui                      Expires 15 August 2026                [Page 34]


name: draft-chang-agent-context-interaction
rev: 01
title: Agent Context Interaction Optimizations
time: 2026-02-13T02:26:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-17T02:26:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.623503+00:00
source: ietf
abstract:
  The context distribution is important in a multi-agent system, which
     will impact the execution latency, token consumption, and task
     completion success rate, especially in a complex and multi-round
     workflow.

     This document specifies the scenarios and procedures of agent context
     distribution as well as the corresponding optimization during the
     procedures in order to provide precise control of the context
     distribution among the multiple agents.

full_text:
  Working Group                                                   Z. Chang
  Internet-Draft                                                   S. Peng
  Intended status: Standards Track                     Huawei Technologies
  Expires: 16 August 2026                                 12 February 2026


                  Agent Context Interaction Optimizations
                  draft-chang-agent-context-interaction-01

  Abstract

     The context distribution is important in a multi-agent system, which
     will impact the execution latency, token consumption, and task
     completion success rate, especially in a complex and multi-round
     workflow.

     This document specifies the scenarios and procedures of agent context
     distribution as well as the corresponding optimization during the
     procedures in order to provide precise control of the context
     distribution among the multiple agents.

  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 16 August 2026.

  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.  Code Components



  Chang & Peng             Expires 16 August 2026                 [Page 1]


  Internet-Draft                  PCECC-SR                   February 2026


     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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
       2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Agent Context Interaction Optimizations . . . . . . . . . . .   6
       4.1.  Overview of Agent Context Interaction Optimizations . . .   6
       4.2.  Context Isolation Strategy  . . . . . . . . . . . . . . .   7
     5.  JSON Specifications . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  TaskContext Schema  . . . . . . . . . . . . . . . . . . .   7
       5.2.  AgentContext Schema . . . . . . . . . . . . . . . . . . .   8
       5.3.  Interaction Process of Agent Context Interaction
             Optimizations . . . . . . . . . . . . . . . . . . . . . .  10
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
     Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     In a multi-agent system, contexts such as agents' capabilities,
     metadata, and intermediate results are exchanged among agents through
     an Agent2Agent protocol to support task execution.

     At present, agent context interaction commonly occurs in two
     scenarios: interaction among independent agents and interaction among
     collaborative agents.  In both scenarios, context information is
     typically distributed in a raw or unfiltered manner, without task-
     aware or relevance-based processing.  As a result, large volumes of
     redundant or irrelevant context are propagated across agents, leading
     to excessive token consumption.

     Furthermore, existing agent interaction protocols generally lack
     explicit task management mechanisms, such as task state tracking and
     progress awareness, for complex tasks that require multi-turn
     interactions and the coordinated invocation of multiple agents.  In
     the absence of structured task context, the LLM’s attention may drift
     across interaction rounds, which can significantly increase execution
     latency and reduce overall task success rates.




  Chang & Peng             Expires 16 August 2026                 [Page 2]


  Internet-Draft                  PCECC-SR                   February 2026


     In this document, we assume a task-oriented multi-agent control model
     in which a designated Master Agent is responsible for global task
     orchestration, while other agents are invoked on demand to execute
     specific subtasks.  The Master Agent receives the user request,
     constructs the overall task, decomposes it into subtasks, and
     coordinates their execution by selectively invoking appropriate
     agents.

     Invoked agents operate under the control of the Master Agent and
     focus exclusively on the execution of assigned subtasks.  They do not
     maintain a global view of the task and do not directly interact with
     end users or other invoked agents unless explicitly mediated by the
     Master Agent.  This master–invoked agent architecture establishes a
     clear separation between global task management and localized task
     execution.

     Efficient context distribution is a critical capability in such a
     master–invoked multi-agent system and is largely determined by the
     design of the agent context interaction protocol.  The protocol
     directly controls how much context is exchanged, how it is
     structured, and how it is propagated across agents.  As a result, it
     has a direct and measurable impact on execution latency, token
     consumption, and task completion success rate, particularly in
     complex and multi-round agent workflows.

     This document specifies the scenarios and procedures for agent
     context distribution and introduces corresponding optimization
     mechanisms applied during these procedures.  The goal is to provide
     precise and task-aware control over context dissemination among
     multiple agents, thereby improving execution efficiency, reducing
     unnecessary token usage, and enhancing task completion success rates.

  2.  Terminology

  2.1.  Conventions and Terminology

     TaskContext: A structured state object that is created and maintained
     exclusively by the Master Agent throughout the lifecycle of a complex
     task.  It provides a persistent and machine-interpretable
     representation of task progress, enabling the Master agent to manage
     attention across multiple subtasks and prevent unintended context
     drift during multi-step execution.









  Chang & Peng             Expires 16 August 2026                 [Page 3]


  Internet-Draft                  PCECC-SR                   February 2026


     AgentContext: The execution state that is specific to an individual
     agent within a multi-agent workflow.  It is strictly isolated between
     subtasks; during each subtask invocation, only the AgentContext
     instance corresponding to the target agent is delivered.  Upon
     completion, the corresponding agent returns exclusively its own
     updated AgentContext

     SynchronousContextInteraction: A context sharing mode in which an
     agent MUST wait for the completion of the current interaction round,
     including context exchange and result feedback, before proceeding to
     the next task or interaction.  In this mode, context distribution and
     task execution are strictly ordered, ensuring deterministic task
     progression and explicit dependency resolution among agents.

     AsynchronousContextInteraction: A context sharing mode in which an
     agent MAY exchange contexts with multiple agents concurrently without
     waiting for the completion of other ongoing interactions.  This mode
     allows parallel context distribution and task execution, enabling
     higher system throughput and reduced overall execution latency in
     multi-agent collaborative workflows.

     Master Agent: The agent responsible for receiving user requests,
     maintaining the global TaskContext, decomposing complex tasks into
     subtasks, invoking other agents, and evaluating subtask execution
     results.

     Invoked Agent: An agent that is invoked by the Master Agent to
     execute a specific subtask.  An Invoked Agent operates on an isolated
     AgentContext and returns only its updated execution state to the
     Master Agent upon completion.

  2.2.  Requirements Language

     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.

  3.  Scenarios

     There are two main scenarios when comes to the context distribution
     among agents, that is, (1) Context Distribution among Independent
     Agents and (2) Context Distribution among Collaborative Agents.







  Chang & Peng             Expires 16 August 2026                 [Page 4]


  Internet-Draft                  PCECC-SR                   February 2026


                         +-------------+
                         |    Master   |
                         |    Agent    |
                       / +-------------+ \
                   1 /        1 |        1 \
                   / 2          |2           \2
                 /              |              \
         +------------+  +-------------+  +------------+
         |   Agent 1  |  |   Agent 2   |  |   Agent 3  |
         +------------+  +-------------+  +------------+

        (1) Context Distribution among Independent Agents

                         +-------------+
                         |    Master   |
                         |    Agent    |
                       / +-------------+ \
                   1 /        3 |        5 \
                   / 2          |4           \6
                 /              |              \
         +------------+  +-------------+  +------------+
         |   Agent 1  |  |   Agent 2   |  |   Agent 3  |
         +------------+  +-------------+  +------------+

        (2) Context Distribution among Collaborative Agents



                 Figure 1: Agent Context Distribution Scenarios

     In the first scenario, i.e. Context Distribution among Independent
     Agents, the agents in the multi-agent system are independent.  The
     Master Agent receives the request, creates a main task and breaks
     down into several sub-tasks, and distribute those sub-tasks to
     correponding agents.  The discover of the correponding agents is out
     of the scope of this draft.  This could be for a tour-plan task,
     which could involve the agents of hotel-booking, flight-booking, and
     weather-checking.  When the Master Agent receives the tour-plan task,
     it will break it down into sub-tasks and distribute context to each
     agent to accomplish the task.

     In the second scenario, i.e. Context Distribution among Collaborative
     Agents, the agents in the multi-agent system are collaborative, that
     is, the input of the latter agent in a workflow will depend upon the
     former agent.  The Master Agent receives the request, creates a main
     task and breaks down into several sub-tasks.  It will distribute the
     sub-tasks to correponding agents in an order.  The discover of the
     correponding agents is out of the scope of this draft.  This could be



  Chang & Peng             Expires 16 August 2026                 [Page 5]


  Internet-Draft                  PCECC-SR                   February 2026


     for a see-a-doctor task, which could involve the agents of disease-
     diagnosis, prescription, and buy-medicine.  When the Master Agent
     receives the see-a-doctor task, it will break it down into sub-tasks
     and distribute context to the first agent, and then depending upon
     the output of the first agent, the second accomplishes its
     corresponding tasks, and then the next agent follows the same
     procedure.

  4.  Agent Context Interaction Optimizations

  4.1.  Overview of Agent Context Interaction Optimizations



          +--------------------------------------------------------------+
          |                          Data Layer                          |
          +--------------------------------------------------------------+
          |                                                              |
          | TaskContext  AgentContext  DeviceContext  EnvironmentContext |
          |                                                              |
          +--------------------------------------------------------------+

          +--------------------------------------------------------------+
          |                       Operation Layer                        |
          +--------------------------------------------------------------+
          |                                                              |
          | SynchronousContextInteraction  AsynchronousContextInteraction|
          |                                                              |
          +--------------------------------------------------------------+

          +--------------------------------------------------------------+
          |                      Transport Layer                         |
          +--------------------------------------------------------------+
          |                                                              |
          |    STDIO     StreamablrHTTP     WebSocket    SoftBus         |
          |                                                              |
          +--------------------------------------------------------------+




    Figure 2: Architecture of the Agent Context Interaction Optimizations

     We design a structured context interaction format to optimize context
     exchange in multi-agent systems across several key dimensions.






  Chang & Peng             Expires 16 August 2026                 [Page 6]


  Internet-Draft                  PCECC-SR                   February 2026


     Agent context interaction optimizations are designed across three
     layers: the data layer, the operation layer, and the transport layer.
     At the data layer, we introduce structured context formats, including
     the TaskContext and AgentContext, to precisely capture and represent
     task and agent states.  The detailed design of DeviceContext and
     EnvironmentContext will be done later.  SynchronousContextInteraction
     and AsynchronousContextInteraction are desined for both scenarios
     mentioned in Section 3, respecitively.  The corresponding transport
     protocols are designed to support different sceanrios.

     A context isolation strategy is introduced to ensure that, during
     collaborative task execution, each agent receives only the context
     strictly relevant to its assigned task.  Relevant context is
     precisely distributed to the corresponding agent in a well-structured
     manner, which reduces interference caused by unnecessary or unrelated
     contextual information.

     A fine-grained task management mechanism is defined for both the
     Master Agent and invoked agents.  Clear task progress monitoring and
     handling procedures are specified, which mitigate attention drift
     within the model and improve overall task completion success rates.

     An efficient two-layer task evaluation mechanism is further
     established.  The Master Agent evaluates the outputs of the invoked-
     agent based on specific fields in the structured context, avoiding
     the need to process or transmit full-context outputs and thereby
     reducing excessive token consumption.

     Support for context offloading is also provided.  Both the Master
     agent and invoked agents are allowed to store or offload full context
     data to external storage systems, while only structured task
     descriptions and references to the full context are exchanged.  This
     approach significantly reduces the overall token consumption of the
     multi-agent system.

  4.2.  Context Isolation Strategy

  5.  JSON Specifications

  5.1.  TaskContext Schema

     The TaskContext schema defines a structured state object that is
     created and maintained exclusively by the Master Agent throughout the
     lifecycle of a complex task.  Its purpose is to provide a persistent
     and machine-interpretable representation of task progress, enabling
     the Master Agent to manage attention across multiple subtasks and
     prevent unintended context drift during multi-step execution.




  Chang & Peng             Expires 16 August 2026                 [Page 7]


  Internet-Draft                  PCECC-SR                   February 2026


      "TaskContext": {
         "TaskID": "",
         "UserQuery": "",
         "TaskName": "",
         "TaskDescription": "",
         "GoalStatus": [
             {"Goal": "", "Status": ""},
             {"Goal": "", "Status": ""},
             {"Goal": "", "Status": ""}
         ],
         "OverallStatus": "",
         "StartTime": "",
         "EndTime": "",
         "Optional": ["StartTime", "EndTime"]
         },



                      Figure 3: JSON Format - TaskContext

     The TaskContext schema includes fundamental identification and intent
     fields such as TaskID, UserQuery, TaskName, and TaskDescription,
     which collectively capture the origin and semantic scope of the task.
     The GoalStatus array records the progress of individual goals using
     explicit {Goal, Status} tuples, allowing the Master Agent to track
     partial completion and reason over intermediate milestones.  An
     aggregated OverallStatus field reflects the global execution state
     derived from these goals.

     Temporal attributes StartTime and EndTime provide optional lifecycle
     metadata for auditing and scheduling purposes.  These fields are
     listed in the Optional array to indicate that their inclusion is not
     mandatory for functional correctness and may be omitted to reduce
     token overhead when time information is not required.

     By maintaining this structured context, the Master Agent can
     explicitly steer the model’s focus toward active objectives, mitigate
     attention fragmentation across turns, and ensure consistent task
     execution semantics in long-running multi-agent workflows.

  5.2.  AgentContext Schema

     The AgentContext schema represents the execution state that is
     specific to an individual agent within a multi-agent workflow.  The
     messages of different agents are strictly isolated between subtasks;
     during each subtask invocation, only the AgentContext instance
     corresponding to the target agent is delivered.  Likewise, upon
     completion, the corresponding agent returns exclusively its own



  Chang & Peng             Expires 16 August 2026                 [Page 8]


  Internet-Draft                  PCECC-SR                   February 2026


     updated AgentContext to the Master Agent, without access to contexts
     belonging to other agents.  This design enforces information
     isolation and prevents unintended cross-agent context contamination.

     "AgentContext": {
             "AgentID": "",
             "AgentName": "",
             "SubTaskID": "",
             "SubTaskName": "",
             "Dependencies": [],
             "Context/ContextURI": "",
             "todoItems": [
                 {"itemId": "", "description": ""},
                 {"itemId": "", "description": ""},
                 {"itemId": "", "description": ""}
             ],
             "ItemstateUpdates": [
                 {"itemId": "", "state": 0},
                 {"itemId": "", "state": 1},
                 {"itemId": "", "state": 0}
             ],
             "KeyInformation": [
                 {"itemId": "", "outputabstract": ""},
                 {"itemId": "", "outputabstract": ""},
                 {"itemId": "", "outputabstract": ""}
             ],
             "LastUpdated": "",
             "Optional": ["LastUpdated"]
         },


                      Figure 4: JSON Format - AgentContext

     The AgentContext schema contains identification fields including
     AgentID, AgentName, SubTaskID, and SubTaskName, which bind the
     context to a concrete subtask instance.  The Dependencies array
     expresses prerequisite relations among subtasks, enabling the Master
     Agent to reason about execution ordering and blocking conditions.

     The field Context/ContextURI specifies the address of external or
     long-term context required for each agent to perform its task, such
     as retrieved documents, knowledge bases, or cached intermediate
     results.  This indirection avoids embedding large artifacts directly
     in the messages and supports scalable context management.

     Task execution is modelled through three coordinated structures.  The
     todoItems array enumerates actionable steps assigned to each agent.
     The ItemstateUpdates array records the completion state of each item



  Chang & Peng             Expires 16 August 2026                 [Page 9]


  Internet-Draft                  PCECC-SR                   February 2026


     using a binary code where 0 denotes not completed and 1 denotes
     completed.  The KeyInformation array provides concise output
     abstracts generated by the agent for each item, capturing the
     semantic evidence necessary for result validation.

     After receiving the updated AgentContext, the Master Agent evaluates
     subtask completion in a two-phase manner.  It first inspects
     ItemstateUpdates for a preliminary decision; items marked as 0 are
     considered unfinished and bypass further assessment.  For items
     marked as 1, the Master Agent performs a second-stage verification
     based on the corresponding KeyInformation, ensuring that the produced
     outputs satisfy the intent of the subtask.

     The optional field LastUpdated records the timestamp of the most
     recent modification and is listed in the Optional array to indicate
     that its inclusion is not required for functional correctness.

  5.3.  Interaction Process of Agent Context Interaction Optimizations




  +------+   User Query+   +------+              +------+         +------+
  |      |  Sysytem Prompt |      |              |      |         |      |
  |      <-----------------+      |              |      |         |      |
  |      |   TaskContext   |      |              |      |         |      |
  |      +----------------->      |              |      |         |      |
  |      |                 |      |              |      |         |      |
  |      |  TaskContext+   |      |              |      |         |      |
  |      |  System Prompt  |      |              |      |         |      |
  |      <-----------------+      |              |      |         |      |
  |Master|   AgentContext  | ACI  |     Send     | ACI  |         |Server|
  |Agent +----------------->Client| AgentContext |Server|         |Agent |
  |      |                 |      +-------------->      |todoItems|      |
  |      |                 |      |              |      +--------->      |
  |      |                 |      |    return    |      | Results |      |
  |      |ItemStateUpdates+|      | AgentContext |      <---------+      |
  |      |KeyInformation   |      <--------------+      |         |      |
  |      <-----------------+      |              |      |         |      |
  |      |                 |      |              |      |         |      |
  |      |     Evaluation  |      |              |      |         |      |
  |      |      Results    |      |              |      |         |      |
  |      +----------------->      |              |      |         |      |
  |      |                 |      +---+          |      |         |      |
  |      |                 |      |   |          |      |         |      |
  |      |                 |      <---+          |      |         |      |
  +------+                 +------+ Updated      +------+         +------+
                                    TaskContext



  Chang & Peng             Expires 16 August 2026                [Page 10]


  Internet-Draft                  PCECC-SR                   February 2026


     Figure 5: Interaction Flowchart of the Agent Context Interaction
                              Optimizations

     Figure 5 illustrates the interaction flow of the proposed Agent
     Context Interaction (ACI) optimizations in a multi-agent system.  The
     workflow begins when the Master Agent receives a user query together
     with the system prompt, forming an initial TaskContext.  The
     TaskContext is exchanged with the ACI Client, which acts as the
     interface for context transmission.

     It is worth mentioning that the ACI Client and ACI Server are
     conceptual entities utilized to illustrate the logical connection
     between the Master Agent and the invoked agents.  In practice, these
     components can be realized by an Agent2Agent (A2A) client and an A2A
     server, without introducing additional architectural constraints.

     Based on the task decomposition, the Master Agent generates an
     isolated AgentContext corresponding to a specific sub-task and sends
     it through the ACI Client and ACI Server to the target Server Agent.
     Only task-relevant information, including todoItems and the
     associated context reference, is delivered to the Server Agent,
     ensuring precise and minimal context distribution.

     After executing the assigned sub-task, the Server Agent returns an
     updated AgentContext containing ItemStateUpdates and KeyInformation.
     These updates reflect task completion status and summarized outputs
     rather than full execution traces.  The Master Agent then evaluates
     the returned information to assess task progress and correctness.

     Upon evaluation, the Master Agent updates the global TaskContext
     accordingly, enabling subsequent task scheduling or further agent
     interactions.  This flow demonstrates how structured context
     isolation, incremental state updates, and layered evaluation
     collectively reduce token consumption, control attention drift, and
     improve overall execution efficiency in multi-agent collaboration.

  6.  Security Considerations

     Agent Context Interaction Optimazation defines structured context
     exchange mechanisms among cooperating agents.  While we do not
     introduce a new transport protocol, improper handling of context data
     may lead to security and privacy risks.









  Chang & Peng             Expires 16 August 2026                [Page 11]


  Internet-Draft                  PCECC-SR                   February 2026


     AgentContext messages may contain sensitive information, including
     user queries, intermediate reasoning artifacts, task metadata, and
     execution results.  Implementations MUST ensure confidentiality and
     integrity of AgentContext messages by relying on secure underlying
     transport mechanisms, such as TLS-protected channels, and appropriate
     authentication and access control between agents.

     The protocol promotes context isolation by design, where each agent
     receives only the context strictly required for its assigned task.
     Failure to enforce this isolation may result in unintended
     information disclosure or cross-task data leakage.

     This document does not define agent identity formats or trust
     establishment procedures.  Deployments are expected to rely on out-
     of-band mechanisms for agent authentication, authorization, and trust
     management.

  7.  IANA Considerations

     This document does not require any immediate actions by IANA.  Future
     extensions of the protocol may define registries or code points that
     require IANA assignment.

  8.  Acknowledgments

     We would like to thank Yiyang Shao, Jinyang Li and Tao Liu for useful
     discussion and ideas.

  9.  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/info/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/info/rfc8174>.

  Appendix A.  Contributor Addresses











  Chang & Peng             Expires 16 August 2026                [Page 12]


  Internet-Draft                  PCECC-SR                   February 2026


     Yiyang Shao
     Huawei
     China

     EMail: shaoyiyang@huawei.com

     Tao Liu
     Huawei
     China

     Email: liutao417@huawei.com

     Jinyang Li
     Huawei
     China

     EMail: lijinyang9@huawei.com



                                    Figure 6

  Authors' Addresses

     Zeze Chang
     Huawei Technologies
     No. 3 Shangdi Information Rd.
     Beijing
     100085
     China
     Email: changzeze@huawei.com


     Shuping Peng
     Huawei Technologies
     Huawei Bld., No.156 Beiqing Rd.
     Beijing
     100095
     China
     Email: pengshuping@huawei.com











  Chang & Peng             Expires 16 August 2026                [Page 13]


name: draft-agent-gw
rev: 01
title: Agent Communication Gateway for Semantic Routing and Working Memory
time: 2026-03-04T15:11:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-05T15:11:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.631121+00:00
source: ietf
abstract:
  This document presents an architectural framework for an Agent
     Communication Gateway (Agent-GW), designed to support large-scale,
     heterogeneous, and dynamic multi-agent collaboration across
     administrative and protocol boundaries.

     As agents evolve from isolated entities to a collaborative digital
     workforce, the infrastructure must transition from rigid, endpoint-
     based connectivity to intent-based interaction.  This draft proposes
     Agent-GW as an infrastructure hub that provides native primitives for
     Semantic Routing (dispatching tasks by intent and capability),
     Working Memory (shared structured context across multi-step
     workflows), automated protocol adaptation (normalizing heterogeneous
     interfaces into a unified agent-facing protocol), oracle-free agent
     evaluation, and collaborative inference acceleration via a Knowledge
     Delivery Network (KDN).

full_text:
  Agent-GW                                                    Xiaohui. Xie
  Internet-Draft                                       Tsinghua University
  Intended status: Standards Track                              Zian. Wang
  Expires: 20 August 2026Beijing University of Posts and Telecommunications
                                                              Tianshuo. Hu
                                                       Tsinghua University
                                                          16 February 2026


    Agent Communication Gateway for Semantic Routing and Working Memory
                             draft-agent-gw-00

  Abstract

     This document presents an architectural framework for an Intelligent
     Agent Communication Gateway (Agent-GW), designed to support large-
     scale, heterogeneous, and dynamic multi-agent collaboration.  As
     agents evolve from isolated software entities to a collaborative
     digital workforce, the underlying infrastructure must transition from
     rigid, host-based connectivity to flexible, intent-based interaction.

     This document outlines the requirements for such a transition and
     proposes the Agent-GW as a unified infrastructure hub.  The gateway
     provides native primitives for Semantic Routing—dispatching tasks
     based on intent and capability—and Working Memory, which manages
     structured context for multi-step workflows.  Furthermore, it defines
     mechanisms for automated protocol adaptation, oracle-free agent
     evaluation, and collaborative inference acceleration (KDN).  The
     architecture aims to enable agents and legacy systems to interoperate
     through standardized protocols while ensuring observability,
     security, and operational scalability.

  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 20 August 2026.



  Xie, et al.              Expires 20 August 2026                 [Page 1]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


  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.  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 used in this document . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Network and Infrastructure Requirements . . . . . . . . . . .   4
     5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
       5.1.  Architectural Model . . . . . . . . . . . . . . . . . . .   4
     6.  Infrastructure Functions Enabling Active Network
             Participation . . . . . . . . . . . . . . . . . . . . . .   5
       6.1.  Agent Identification and Capability Directory . . . . . .   6
       6.2.  Automated Protocol Adaptation and Interface
             Normalization . . . . . . . . . . . . . . . . . . . . . .   6
       6.3.  Infrastructure-Level Agent Evaluation and Compliance  . .   6
       6.4.  Dynamic Orchestration and Semantic Routing Mechanism  . .   7
       6.5.  Evolutionary Knowledge Management . . . . . . . . . . . .   7
       6.6.  Collaborative Inference Acceleration (KDN)  . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     The rapid advancement of Large Language Models (LLMs) has catalyzed
     the emergence of the "Internet of Agents," a paradigm where
     autonomous software entities and tool-like services interconnect to
     form collaborative workflows.  Unlike traditional microservices,
     these agents possess varying degrees of autonomy, reasoning
     capabilities, and diverse interface standards.  Early agent
     deployments were typically siloed within proprietary frameworks,
     limiting their ability to collaborate across administrative domains



  Xie, et al.              Expires 20 August 2026                 [Page 2]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


     or heterogeneous platforms.

     As these systems scale, the fundamental bottleneck shifts from basic
     network connectivity to context management and efficient
     orchestration.  Delivering the right context to the right agent at
     the right time—while managing the high computational cost of
     inference—becomes a critical infrastructure challenge.  Existing
     network/application gateways, designed for static endpoints and
     stateless packet forwarding, lack the semantic awareness required to
     interpret agent intents or manage the lifecycle of a collaborative
     task.

     This document introduces the Agent Communication Gateway (Agent-GW),
     an architectural entity situated between agents and external tools or
     services.  The Agent-GW elevates the network's role from a passive
     transport layer to an active semantic intermediary.  It introduces
     two core primitives: Semantic Routing, which decouples task execution
     from physical endpoints by routing based on capabilities and runtime
     state; and Working Memory, which provides a shared, incrementally
     updated context layer to support multi-step reasoning.

  2.  Conventions used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  3.  Terminology

     The following terms are defined in this draft:

     Agent-GW (Agent-GW)  Agent Communication Gateway; the infrastructure
        component coordinating multi-agent communication, responsible for
        protocol translation, semantic routing, and context management.

     Semantic Routing  The process of routing a request based on the
        semantic intent of the task and the capabilities of available
        agents.

     Working Memory  A structured, temporary storage mechanism within the
        gateway that maintains the context and state of a multi-turn agent
        interaction.

     KDN (Knowledge Delivery Network)  A mechanism that treats inference
        states (e.g., LLM KV caches) as reusable and distributable
        artifacts.

     MCP  Model Context Protocol; a reference standard for connecting AI



  Xie, et al.              Expires 20 August 2026                 [Page 3]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


        assistants to systems/data.

  4.  Network and Infrastructure Requirements

     The proliferation of intelligent agents fundamentally reshapes
     interaction patterns in future networks.  Agent interactions are
     typically short-lived, context-heavy, and driven by high-level goals
     rather than explicit commands.  To support this, the infrastructure
     must satisfy the following requirements:

     *Intent-Based Addressing:* The network must support addressing
     schemes based on what constitutes the service (Capability) rather
     than where it is located (Topology).

     *Stateful Context Management:* Unlike stateless HTTP requests,
     agentic workflows often involve multi-turn reasoning where context
     accumulates.

     *Heterogeneous Interoperability:* The ecosystem comprises diverse
     entities.  The infrastructure must provide automated adaptation
     layers.

     *Dynamic Capability Discovery:* The network requires a dynamic
     discovery mechanism that can match task needs with agent capabilities
     in real-time.

     *Inference Efficiency:* Mechanisms to cache and share intermediate
     inference states (such as KV caches) are required.

  5.  Architecture Overview

     This section describes the reference architecture of the Agent
     Communication Gateway (Agent-GW).  It functions as a Semantic
     Intermediary operating at the application and cognitive layers.

  5.1.  Architectural Model

     Figure 1 illustrates the logical components and their interactions
     within the Agent-GW.












  Xie, et al.              Expires 20 August 2026                 [Page 4]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


  [ Northbound: User / Client Agents ]
                                               |
    +------------------------------------------+------------------------------------------+
    |                      1. Access & Adaptation Plane (Ingress)                         |
    | +-----------------------+   +-------------------------+   +-----------------------+ |
    | |   Protocol Sniffer    |   |  Auto-Adapter Engine    |   |   Trust Enforcer      | |
    | | (Transport Detection) |-->| (Schema -> MCP Transform)|-->| (Auth / Sandboxing)   | |
    | +-----------------------+   +-------------------------+   +-----------------------+ |
    +------------------------------------------+------------------------------------------+
                                               | Normalized Semantic Request
    +------------------------------------------v------------------------------------------+
    |                     2. Cognitive Orchestration Plane (Control)                      |
    | +---------------------------------------------------------------------------------+ |
    | |                            Semantic Router & Planner                            | |
    | | +------------------+     +------------------------+     +---------------------+ | |
    | | |   Intent Parser  |---->|   Task DAG Decomposer  |---->|  Dynamic Dispatcher | | |
    | | +------------------+     +------------------------+     +---------------------+ | |
    | +----------------------------------------+----------------------------------------+ |
    |                                          |                                          |
    |          +-------------------------------+-------------------------------+          |
    |          v (Read/Write)                  v (Cache Hit)                   v (Sync)   |
    +----------+-------------------------------+-------------------------------+----------+
    |                      3. Knowledge & State Plane (Data & Compute)                    |
    | +-----------------------+   +---------------------------+   +---------------------+ |
    | |    Working Memory     |   |    Evolutionary Memory    |   |    KDN Accelerator    | |
    | |   (Session Context)   |   |   (Experience/Feedback)   |   | (KV Cache Sharing)  | |
    | +-----------------------+   +---------------------------+   +---------------------+ |
    +------------------------------------------+------------------------------------------+
                                               | Executable Actions / Payloads
    +------------------------------------------v------------------------------------------+
    |                   4. Ecosystem Interface Plane (Egress/Southbound)                  |
    | +---------------------------------------------------------------------------------+ |
    | |                            Unified Driver Layer                                 | |
    | +-----------+--------------------+---------------------+--------------------+-----+ |
    |             |                    |                     |                    |       |
    |             v                    v                     v                    v       |
    |   +------------------+  +------------------+  +------------------+  +-------------+ |
    |   |  Legacy Systems  |  |  Native Agents   |  |  Physical World  |  |  Peer Mesh  | |
    |   | (REST/RPC Wrappers)| | (MCP Servers)    |  | (ROS/IoT Bridge) |  | (Agent-GW Sync) | |
    |   +------------------+  +------------------+  +------------------+  +-------------+ |
    +-------------------------------------------------------------------------------------+

                Figure 1: Agent-GW Reference Architecture

  6.  Infrastructure Functions Enabling Active Network Participation






  Xie, et al.              Expires 20 August 2026                 [Page 5]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


  6.1.  Agent Identification and Capability Directory

     This function establishes the "Root of Trust" for the agent network,
     shifting security from network-layer spoofing prevention to
     application-layer Capability Spoofing mitigation.  The Agent-GW
     maintains a dynamic, verified directory where agent entries are not
     static records but active, verified states.

     *Cryptographic Identity and Verification:* Participating agents MUST
     possess a Cryptographic Agent ID (AID) derived from an X.509v3
     digital certificate.  Upon registration, the agent submits an
     AgentCard binding its identity to a specific capability hash.  To
     prevent the registration of malicious entities, the Agent-GW
     implements a Capability Claim and Verification (CCV) mechanism.
     Utilizing Metamorphic Testing principles, the gateway issues
     "Challenge-Response" queries (e.g., semantic variants of a task) to
     verify the agent's functional consistency without accessing its
     internal model weights (Zero-Knowledge verification).

     *Semantic Heartbeat and Dynamic Pruning:* To maintain directory
     freshness, the Agent-GW enforces a Semantic Heartbeat.  Unlike
     traditional Layer 3 keep-alives that only confirm network
     reachability, this mechanism periodically verifies Layer 7 functional
     integrity.  Agents that fail these semantic challenges (indicating
     they are "Zombie Agents" or functionally impaired) are dynamically
     pruned from the directory.

  6.2.  Automated Protocol Adaptation and Interface Normalization

     Residing within the Access & Adaptation Plane, this function serves
     as the "Semantic Edge" that normalizes heterogeneous external
     protocols (e.g., HTTP, MQTT, gRPC) into the unified Model Context
     Protocol (MCP) used by the internal Orchestration Plane.

     To handle unstructured or poorly documented interfaces, the Agent-GW
     implements a Generative Adaptation Mechanism with Active Probing.
     Instead of relying on static drivers, an LLM-based engine ingests raw
     interface descriptions to generate preliminary bindings.  These
     bindings are iteratively refined through a self correcting feedback
     loop.

  6.3.  Infrastructure-Level Agent Evaluation and Compliance

     Agents are often deployed as "black-box" entities where internal
     logic is opaque.  The Agent-GW introduces an infrastructure-level
     evaluation mechanism to ensure reliability and compliance without
     requiring access to model weights.




  Xie, et al.              Expires 20 August 2026                 [Page 6]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


     This function employs Metamorphic Testing protocols: the gateway
     generates semantic variations of task instructions (e.g., rewriting
     the prompt or injecting noise) and evaluates the consistency of the
     agent's responses.  This "Oracle-free" approach allows the gateway to
     assign a dynamic reliability score to each agent.

  6.4.  Dynamic Orchestration and Semantic Routing Mechanism

     Static routing tables are insufficient for dynamic multi-agent
     collaboration.  The Agent-GW implements Semantic Routing, a mechanism
     that dispatches tasks based on high-level intent, real-time
     capability matching, and operational constraints.

     The Cognitive Orchestration Plane decomposes complex user intents
     into a Directed Acyclic Graph (DAG) of sub-tasks.  The Dynamic
     Dispatcher then assigns these sub-tasks to the most suitable agents
     based on Capability Match, Trust Score, and Operational Metrics.

  6.5.  Evolutionary Knowledge Management

     To improve collaboration efficiency over time, the Agent-GW
     incorporates Evolutionary Memory.  This function transforms the
     gateway from a stateless forwarder into a learning infrastructure.

     The gateway captures execution traces, success/failure feedback, and
     user corrections from passing traffic.  In local or edge deployments,
     this allows the Agent-GW to build a localized knowledge base to
     refine routing policies and provide "Feedback Guidance" to terminal
     agents.

  6.6.  Collaborative Inference Acceleration (KDN)

     Multi-agent workflows frequently involve redundant reasoning over
     shared contexts.  To address the computational inefficiency, the
     architecture proposes a Knowledge Delivery Network (KDN).

     The KDN function enables the sharing of intermediate inference
     states, specifically the Key-Value (KV) cache of the LLM, across co-
     located agents or peer gateways.  This significantly reduces the
     Time-to-First-Token (TTFT) and overall computational load.

  7.  Security Considerations

     The introduction of an active Agent-GW introduces specific security
     challenges: Agent Identity Spoofing, Capability Poisoning, Context
     Leakage, and Inference Artifact Security.





  Xie, et al.              Expires 20 August 2026                 [Page 7]


  Internet-Draft  Agent Communication Gateway for Semantic   February 2026


  8.  IANA Considerations

     This document has no IANA actions at this time.

  9.  Acknowledgement

     TBD

  10.  References

  10.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/info/rfc2119>.

  Authors' Addresses

     Xiaohui Xie
     Tsinghua University
     Email: xiexiaohui@tsinghua.edu.cn


     Zian Wang
     Beijing University of Posts and Telecommunications
     Email: zianwang@bupt.edu.cn


     Tianshuo Hu
     Tsinghua University
     Email: huts22@mails.tsinghua.edu.cn



















  Xie, et al.              Expires 20 August 2026                 [Page 8]


name: draft-birkholz-verifiable-agent-conversations
rev: 00
title: Verifiable Agent Conversation Records
time: 2026-02-25T18:48:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T18:48:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.635236+00:00
source: ietf
abstract:
  Autonomous agents based on large language models increasingly perform
     consequential tasks on behalf of humans and other agents.
     Demonstrating that recorded agent behavior truthfully represents
     actual behavior is essential for accountability, compliance, and
     human oversight.  This document defines a data format for verifiable
     agent conversation records using CDDL, with representations in both
     JSON and CBOR.  The format captures session metadata, message
     exchanges, tool invocations, reasoning traces, and system events in a
     structured, extensible CDDL definition for verifiable agent
     conversation records.  COSE is used as the signing method to allow
     for native interoperability in SCITT Transparency Services and the
     CDDL definition allows for seemless integration in Evidence as
     specified in RFC 9334.  The specification supports cross-vendor
     interoperability by defining a common representation that
     accommodates translation from multiple existing agent implementations
     with distinct data structure layouts that are typically represented
     in JSON.

full_text:
  Network Working Group                                        H. Birkholz
  Internet-Draft                                                          
  Intended status: Standards Track                                T. Heldt
  Expires: 29 August 2026                                                 
                                                                 O. Steele
                                                          25 February 2026


                   Verifiable Agent Conversation Records
              draft-birkholz-verifiable-agent-conversations-00

  Abstract

     Autonomous agents based on large language models increasingly perform
     consequential tasks on behalf of humans and other agents.
     Demonstrating that recorded agent behavior truthfully represents
     actual behavior is essential for accountability, compliance, and
     human oversight.  This document defines a data format for verifiable
     agent conversation records using CDDL, with representations in both
     JSON and CBOR.  The format captures session metadata, message
     exchanges, tool invocations, reasoning traces, and system events in a
     structured, extensible CDDL definition for verifiable agent
     conversation records.  COSE is used as the signing method to allow
     for native interoperability in SCITT Transparency Services and the
     CDDL definition allows for seemless integration in Evidence as
     specified in RFC 9334.  The specification supports cross-vendor
     interoperability by defining a common representation that
     accommodates translation from multiple existing agent implementations
     with distinct data structure layouts that are typically represented
     in JSON.

  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 29 August 2026.




  Birkholz, et al.         Expires 29 August 2026                 [Page 1]


  Internet-Draft               Verifiable ACRs               February 2026


  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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   6
     2.  Compliance Requirements for AI Agent Conversation Records . .   6
       2.1.  Applicable Requirement Frameworks . . . . . . . . . . . .   6
       2.2.  Common Requirements Intersection  . . . . . . . . . . . .   8
         2.2.1.  REQ-1: Automatic Event Logging  . . . . . . . . . . .   8
         2.2.2.  REQ-2: Timestamp Requirements . . . . . . . . . . . .   8
         2.2.3.  REQ-3: Actor Identification . . . . . . . . . . . . .   9
         2.2.4.  REQ-4: Action/Event Type Recording  . . . . . . . . .  10
         2.2.5.  REQ-5: Input/Output Recording (AI-Specific) . . . . .  10
         2.2.6.  REQ-6: Retention Period Requirements  . . . . . . . .  11
         2.2.7.  REQ-7: Tamper-Evidence and Integrity Protection . . .  12
         2.2.8.  REQ-8: Incident Response Support  . . . . . . . . . .  12
         2.2.9.  REQ-9: Anomaly and Risk Detection Support . . . . . .  13
         2.2.10. REQ-10: Human Oversight Enablement  . . . . . . . . .  14
         2.2.11. REQ-11: Traceability and Reproducibility  . . . . . .  14
       2.3.  Framework-Specific Requirements . . . . . . . . . . . . .  15
         2.3.1.  EU AI Act (High-Risk Systems) . . . . . . . . . . . .  15
         2.3.2.  ETSI TS 104 223 Session Logging Requirements  . . . .  16
         2.3.3.  PCI DSS AI-Specific Guidance  . . . . . . . . . . . .  16
         2.3.4.  Financial Sector Requirements (FFIEC, BSI)  . . . . .  17
       2.4.  Compliance Mapping Table  . . . . . . . . . . . . . . . .  17
       2.5.  Security Requirements addressing Regulatory Compliance  .  18
         2.5.1.  Log Integrity . . . . . . . . . . . . . . . . . . . .  18
         2.5.2.  Access Control  . . . . . . . . . . . . . . . . . . .  19
         2.5.3.  Data Protection . . . . . . . . . . . . . . . . . . .  19
       2.6.  Related Standards and Emerging Work . . . . . . . . . . .  19
     3.  CDDL Definitions for Agent Conversations Records  . . . . . .  19
       3.1.  Common Types  . . . . . . . . . . . . . . . . . . . . . .  19
       3.2.  The verifiable-agent-record Map . . . . . . . . . . . . .  20
       3.3.  The session-trace Map . . . . . . . . . . . . . . . . . .  21
       3.4.  The agent-meta Map  . . . . . . . . . . . . . . . . . . .  22



  Birkholz, et al.         Expires 29 August 2026                 [Page 2]


  Internet-Draft               Verifiable ACRs               February 2026


       3.5.  The recording-agent Map . . . . . . . . . . . . . . . . .  23
       3.6.  The environment Map . . . . . . . . . . . . . . . . . . .  23
       3.7.  The vcs-context Map . . . . . . . . . . . . . . . . . . .  24
       3.8.  Entry Types . . . . . . . . . . . . . . . . . . . . . . .  24
         3.8.1.  The message-entry Map . . . . . . . . . . . . . . . .  25
         3.8.2.  The tool-call-entry Map . . . . . . . . . . . . . . .  26
         3.8.3.  The tool-result-entry Map . . . . . . . . . . . . . .  26
         3.8.4.  The reasoning-entry Map . . . . . . . . . . . . . . .  27
         3.8.5.  The event-entry Map . . . . . . . . . . . . . . . . .  28
       3.9.  The token-usage Map . . . . . . . . . . . . . . . . . . .  29
       3.10. File Attribution Types  . . . . . . . . . . . . . . . . .  30
         3.10.1.  The file-attribution-record Map  . . . . . . . . . .  30
         3.10.2.  The file Map . . . . . . . . . . . . . . . . . . . .  31
         3.10.3.  The conversation Map . . . . . . . . . . . . . . . .  31
         3.10.4.  The range Map  . . . . . . . . . . . . . . . . . . .  32
         3.10.5.  The contributor Map  . . . . . . . . . . . . . . . .  32
         3.10.6.  The resource Map . . . . . . . . . . . . . . . . . .  33
       3.11. Signing Envelope Types  . . . . . . . . . . . . . . . . .  33
         3.11.1.  The signed-agent-record Structure  . . . . . . . . .  33
         3.11.2.  The trace-metadata Map . . . . . . . . . . . . . . .  34
     4.  Collated CDDL Definition for generic Agent Conversations  . .  35
     5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  40
       5.1.  Information Disclosure  . . . . . . . . . . . . . . . . .  40
       5.2.  Sensitive Content in Records  . . . . . . . . . . . . . .  40
       5.3.  Retention Considerations  . . . . . . . . . . . . . . . .  41
       5.4.  Correlation and Inference . . . . . . . . . . . . . . . .  41
       5.5.  Authority Access  . . . . . . . . . . . . . . . . . . . .  41
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  42
       6.1.  Record Integrity  . . . . . . . . . . . . . . . . . . . .  42
       6.2.  Signing Key Protection  . . . . . . . . . . . . . . . . .  42
       6.3.  Timestamp Integrity . . . . . . . . . . . . . . . . . . .  42
       6.4.  Adversarial Content . . . . . . . . . . . . . . . . . . .  43
       6.5.  Non-Repudiation . . . . . . . . . . . . . . . . . . . . .  43
       6.6.  Detection and Trust Boundaries  . . . . . . . . . . . . .  43
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
       7.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  44
       7.2.  CoAP Content Format . . . . . . . . . . . . . . . . . . .  45
       7.3.  CBOR Tag  . . . . . . . . . . . . . . . . . . . . . . . .  45
       7.4.  COSE Header Parameter . . . . . . . . . . . . . . . . . .  45
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  46
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  49
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  50
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50







  Birkholz, et al.         Expires 29 August 2026                 [Page 3]


  Internet-Draft               Verifiable ACRs               February 2026


  1.  Introduction

     The question of whether the recorded output of an autonomous agent
     faithfully represents an agent's actual behavior has found new
     urgency as the number of consequential tasks that are delegated to
     agents increases rapidly.  Autonomous Agents--typically workload
     instances of agentic artificial intelligence (AI) based on large
     language models (LLM)--interact with other actors by design.  This
     creates an interconnected web of agent interactions and conversations
     that is currently rarely supervised in a systemic manner.  In
     essence, the two main types of actors interacting with autonomous
     agents are humans and machines (e.g., other autonomous agents), or a
     mix of them.  In agentic AI systems, machine actors interact with
     other machine actors.  The number of interactions between machine
     actors grows significantly more than the number of interactions
     between human actors and machine actors.  While the responsible
     parties for agent actions ultimately are humans--whether a natural
     legal entity or an organization--agents act on behalf of humans and
     on behalf of other agents.  To demonstrate due diligence, responsible
     human parties require records of agent behavior to demonstrate policy
     compliant behavior for agents acting under their authority.  These
     increasingly complex interactions between multiple actors that can
     also be triggered by machines (recursively) increase the need to
     understand decision making and the chain of thoughts (CoT) of
     autonomous agents, retroactively (i.e., accountability and
     auditability after the fact).

     The verifiable records of agent conversations that are specified in
     this document provide an essential basis for operators to detect
     divergences between intended and actual agent behavior after the
     interaction has concluded.

     For example:

     *  An agent authorized to read files might invoke tools to modify
        production systems or exfiltrate sensitive data beyond its
        authorization scope.

     *  An agent's visible CoT output might diverge from the reasoning
        that actually produced its actions.

     *  An agent might deliberately underperform during capability
        evaluations while performing at full capacity during deployment.

     This document defines conversation records representing activities of
     autonomous agents such that long-term preservation of the evidentiary
     value of these records across chains of custody (CoC) is possible.




  Birkholz, et al.         Expires 29 August 2026                 [Page 4]


  Internet-Draft               Verifiable ACRs               February 2026


     This document defines verifiable records of agent conversations as a
     building block towards seven dedicated goals:

     1.  The first goal is to assure that the recording of an agent
         conversation (a distinct segment of the interaction with an
         autonomous agent) being proffered is the same as the agent
         conversation that actually occurred.

     2.  The second goal is to provide a general structure of agent
         conversations that can represent most common types of agent
         conversation frames, is extensible, and allows for future
         evolution of agent conversation complexity and corresponding
         actor interaction.

     3.  The third goal is to use existing IETF building blocks to present
         believable evidence about how an agent conversation is recorded
         utilizing Evidence generation as laid out in the Remote
         ATtestation ProcedureS architecture [RFC9334].

     4.  The fourth goal is to use existing IETF building blocks to render
         conversation records auditable after the fact and enable non-
         repudiation as laid out in the Supply Chain Integrity,
         Transparency, and Trust architecture
         [I-D.ietf-scitt-architecture].

     5.  The fifth goal is to enable detection of behavioral anomalies in
         agent interactions, including unauthorized tool invocations,
         inconsistencies between reasoning traces and actions, and
         performance modulation across evaluation and deployment contexts,
         through structured, comparable conversation records.

     6.  The sixth goal is to enable cross-vendor interoperability by
         defining a common representation for agent conversations that can
         be translated from multiple existing agent implementations with
         distinct native formats.

     7.  The seventh goal is to produce records suitable for demonstrating
         compliance with emerging regulatory requirements for AI system
         documentation, traceability, and human oversight.

     Most agent conversations today are represented in "human-readable"
     text formats.  For example, JSON [STD90] is considered to be "human-
     readable" as it can be presented to humans in human-computer-
     interfaces (HCI) via off-the-shelf tools, e.g., pre-installed text
     editors that allow such data to be consumed or modified by humans.
     The Concise Binary Object Representation (CBOR [STD94]) is used as an
     alternative representation next to the established representation
     that is JSON.



  Birkholz, et al.         Expires 29 August 2026                 [Page 5]


  Internet-Draft               Verifiable ACRs               February 2026


     In this version of the document the signing of JSON payloads is done
     via [STD90].  Using [STD90] enables interoperability with
     Transparency Services specified by the IETF
     [I-D.ietf-scitt-architecture] and enables low-threshold cross-
     application and cross-stakeholder interoperability across the
     Internet.

     Note: further improvements in support of in-memory processing,
     further compacting human-readable text strings, and using CBOR as an
     alternative representation for verifiable records of agent
     conversations will follow.

  1.1.  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 this document, CDDL [RFC8610] is used to describe the data formats
     of agent conversations for JSON and CBOR (with no optimization for
     CBOR, currently).

     The reader is assumed to be familiar with the vocabulary and concepts
     defined in [RFC9334] and [I-D.ietf-scitt-architecture].

  2.  Compliance Requirements for AI Agent Conversation Records

     This section identifies the intersection of logging, traceability,
     and record-keeping requirements across major compliance frameworks
     applicable to AI systems.  The verifiable agent conversation format
     defined in this document addresses these requirements by providing a
     standardized, cryptographically verifiable record of AI agent
     interactions.

  2.1.  Applicable Requirement Frameworks

     The following frameworks were analyzed for their requirements on AI
     agent traceability and session logging:











  Birkholz, et al.         Expires 29 August 2026                 [Page 6]


  Internet-Draft               Verifiable ACRs               February 2026


      +==========================+=============+=============+==========+
      | Framework                |Jurisdiction |Sector       |Status    |
      +==========================+=============+=============+==========+
      | EU AI Act                |EU           |Cross-sector |In force  |
      | [EU_AI_ACT_2024]         |             |             |Aug 2024  |
      +--------------------------+-------------+-------------+----------+
      | Cyber Resilience Act     |EU           |Products with|In force  |
      | [EU_CRA_2024]            |             |digital      |Dec 2024  |
      |                          |             |elements     |          |
      +--------------------------+-------------+-------------+----------+
      | NIS2 Directive           |EU           |Essential/   |Transposed|
      | [EU_NIS2_2022]           |             |important    |Oct 2024  |
      |                          |             |entities     |          |
      +--------------------------+-------------+-------------+----------+
      | ETSI TS 104 223          |EU/          |AI systems   |Published |
      | [ETSI_TS_104223_2025]    |International|             |Apr 2025  |
      +--------------------------+-------------+-------------+----------+
      | SOC 2 Trust Services     |US/          |Service      |Active    |
      | Criteria                 |International|organizations|          |
      | [AICPA_TSC_2017]         |             |             |          |
      +--------------------------+-------------+-------------+----------+
      | FedRAMP                  |US           |Federal cloud|Active    |
      | [NIST_SP_800_53_R5]      |             |services     |          |
      | [OMB_M_21_31]            |             |             |          |
      +--------------------------+-------------+-------------+----------+
      | PCI DSS [PCI_DSS_V4_0_1] |International|Payment card |Mandatory |
      |                          |             |industry     |Mar 2025  |
      +--------------------------+-------------+-------------+----------+
      | ISO/IEC 42001            |International|AI management|Published |
      | [ISO_IEC_42001_2023]     |             |systems      |2023      |
      +--------------------------+-------------+-------------+----------+
      | FFIEC IT Handbook        |US           |Financial    |Updated   |
      | [FFIEC_IT_HANDBOOK_2024] |             |institutions |2024      |
      +--------------------------+-------------+-------------+----------+
      | BSI AI Finance Test      |Germany      |Financial    |Published |
      | Criteria                 |             |sector AI    |2024      |
      | [BSI_AI_FINANCE_2024]    |             |             |          |
      +--------------------------+-------------+-------------+----------+
      | NIST AI 100-2            |US           |Cross-sector |Published |
      | [NIST_AI_100_2_E2025]    |             |             |2025      |
      +--------------------------+-------------+-------------+----------+

                                    Table 1








  Birkholz, et al.         Expires 29 August 2026                 [Page 7]


  Internet-Draft               Verifiable ACRs               February 2026


  2.2.  Common Requirements Intersection

     The analysis of the frameworks listed above results in eleven
     categories of requirements that appear across ALL or MOST frameworks.
     These categories frame and represent a minimum baseline that
     verifiable agent conversation records MUST support.

  2.2.1.  REQ-1: Automatic Event Logging

     All frameworks require automatic, system-generated logging of events
     without reliance on manual recording.  Explicit requirements are
     listed as follows:

     +===================+===============================================+
     | Framework         | Requirement                                   |
     +===================+===============================================+
     | EU AI Act Art.    | "High-risk AI systems shall technically allow |
     | 12                | for the automatic recording of events (logs)" |
     +-------------------+-----------------------------------------------+
     | ETSI TS 104223    | "System Operators shall log system and user   |
     | 5.4.2-1           | actions"                                      |
     +-------------------+-----------------------------------------------+
     | SOC 2 CC7.2       | "Complete and chronological record of all     |
     |                   | user actions and system responses"            |
     +-------------------+-----------------------------------------------+
     | FedRAMP AU-12     | "Audit Record Generation" control requirement |
     +-------------------+-----------------------------------------------+
     | PCI DSS 4.0       | "Audit logs implemented to support detection  |
     | Req 10            | of anomalies"                                 |
     +-------------------+-----------------------------------------------+
     | ISO 42001         | "AI system recording of event logs"           |
     | A.6.2.8           |                                               |
     +-------------------+-----------------------------------------------+

                                    Table 2

     Mapping to this specification: The entries array in session-trace
     captures all events automatically.  Each entry represents a discrete,
     system-recorded event with structured metadata.

  2.2.2.  REQ-2: Timestamp Requirements

     Most frameworks require precise temporal information for each logged
     event.  Explicit requirements are listed as follows:







  Birkholz, et al.         Expires 29 August 2026                 [Page 8]


  Internet-Draft               Verifiable ACRs               February 2026


         +======================+====================================+
         | Framework            | Requirement                        |
         +======================+====================================+
         | EU AI Act Art. 12(2) | "Precise timestamps for each usage |
         |                      | session" (biometric systems)       |
         +----------------------+------------------------------------+
         | PCI DSS 4.0 Req 10.6 | "Time-synchronization mechanisms   |
         |                      | support consistent time settings"  |
         +----------------------+------------------------------------+
         | SOC 2                | "When the activity was performed   |
         |                      | via timestamp"                     |
         +----------------------+------------------------------------+
         | NIS2                 | "Precise logging of when an        |
         |                      | incident was first detected"       |
         +----------------------+------------------------------------+

                                    Table 3

     Mapping to this specification: The timestamp field in each entry uses
     abstract-timestamp which accepts both RFC 3339 strings and POSIX
     Seconds since Epoch, ensuring interoperability across
     implementations.

  2.2.3.  REQ-3: Actor Identification

     Most frameworks require some attribution of actions to identifiable
     actors (human or system).  Explicit requirements are listed as
     follows:

         +===============+==========================================+
         | Framework     | Requirement                              |
         +===============+==========================================+
         | EU AI Act     | "Identification of the natural persons   |
         | Art. 12(3)(d) | involved in the verification of results" |
         +---------------+------------------------------------------+
         | SOC 2         | "The process or user who initiated the   |
         |               | activity (Who)"                          |
         +---------------+------------------------------------------+
         | PCI DSS 4.0   | Attribution to "Who" performed each      |
         |               | action                                   |
         +---------------+------------------------------------------+
         | FedRAMP AC-2  | Account management and identification    |
         +---------------+------------------------------------------+

                                   Table 4






  Birkholz, et al.         Expires 29 August 2026                 [Page 9]


  Internet-Draft               Verifiable ACRs               February 2026


     Mapping to this specification: The contributor type captures actor
     attribution with type (human/ai/mixed/unknown) and optional model-id.
     Session-level agent-meta identifies the AI system.

  2.2.4.  REQ-4: Action/Event Type Recording

     All frameworks require recording of what action or event occurred.
     Explicit requirements are listed as follows:

       +===================+==========================================+
       | Framework         | Requirement                              |
       +===================+==========================================+
       | EU AI Act Art. 12 | "Events relevant for identifying         |
       |                   | situations that may result in...risk"    |
       +-------------------+------------------------------------------+
       | ETSI TS 104223    | "Audit log of changes to system prompts  |
       | 5.2.4-3           | or other model configuration"            |
       +-------------------+------------------------------------------+
       | SOC 2             | "The action they performed such as file  |
       |                   | transferred, created, or deleted (What)" |
       +-------------------+------------------------------------------+
       | PCI DSS 4.0       | "What" component of audit trail          |
       +-------------------+------------------------------------------+

                                   Table 5

     Mapping to this specification: The type field in each entry
     discriminates event types: user, assistant, tool-call, tool-result,
     reasoning, system-event.

  2.2.5.  REQ-5: Input/Output Recording (AI-Specific)

     All AI-specific frameworks require recording of inputs (prompts) and
     outputs (responses).  Explicit requirements are listed as follows:

















  Birkholz, et al.         Expires 29 August 2026                [Page 10]


  Internet-Draft               Verifiable ACRs               February 2026


         +================+==========================================+
         | Framework      | Requirement                              |
         +================+==========================================+
         | EU AI Act Art. | "The input data for which the search has |
         | 12(3)(c)       | led to a match"                          |
         +----------------+------------------------------------------+
         | PCI DSS AI     | "Logging should be sufficient to audit   |
         | Guidance       | the prompt inputs and reasoning process" |
         +----------------+------------------------------------------+
         | ETSI TS 104223 | "Operation, and lifecycle management of  |
         | 5.1.2-3        | models, datasets and prompts"            |
         +----------------+------------------------------------------+
         | FFIEC VII.D    | "Lack of explainability...unclear how    |
         |                | inputs are translated into outputs"      |
         +----------------+------------------------------------------+

                                    Table 6

     Mapping to this specification:

     *  message-entry (type: "user"): User/system input (prompt)

     *  message-entry (type: "assistant"): Model response

     *  tool-call-entry.input: Tool invocation parameters

     *  tool-result-entry.output: Tool execution results

     *  reasoning-entry.content: Chain-of-thought (where available)

  2.2.6.  REQ-6: Retention Period Requirements

     Most frameworks specify minimum retention periods for audit logs.
     Explicit requirements are listed as follows:

      +===================+============================================+
      | Framework         | Minimum Retention                          |
      +===================+============================================+
      | EU AI Act Art. 19 | 6 months (longer for financial services)   |
      +-------------------+--------------------------------------------+
      | FedRAMP (M-21-31) | 12 months active + 18 months cold storage  |
      +-------------------+--------------------------------------------+
      | PCI DSS 4.0       | 12 months total, 3 months immediate access |
      +-------------------+--------------------------------------------+
      | NIS2              | Per member state law                       |
      +-------------------+--------------------------------------------+

                                   Table 7



  Birkholz, et al.         Expires 29 August 2026                [Page 11]


  Internet-Draft               Verifiable ACRs               February 2026


     Recommendation: Implementations SHOULD retain verifiable agent
     conversation records for at least 12 months to satisfy the most
     common requirement threshold.

  2.2.7.  REQ-7: Tamper-Evidence and Integrity Protection

     All frameworks require some protection against unauthorized
     modification of logs.  Explicit requirements are listed as follows:

         +======================+===================================+
         | Framework            | Requirement                       |
         +======================+===================================+
         | PCI DSS 4.0 Req 10.5 | "Tamper-proof audit trails...logs |
         |                      | cannot be altered retroactively"  |
         +----------------------+-----------------------------------+
         | FedRAMP              | "Effective chain of evidence to   |
         |                      | ensure integrity"                 |
         +----------------------+-----------------------------------+
         | SOC 2                | Log integrity as security control |
         +----------------------+-----------------------------------+
         | CRA                  | "Tamper-proof SBOMs and           |
         |                      | vulnerability disclosures"        |
         +----------------------+-----------------------------------+

                                   Table 8

     Mapping to this specification: The signed-agent-record type
     (COSE_Sign1 envelope) provides cryptographic integrity protection.
     The content-hash field in trace-metadata enables verification of
     payload integrity.

  2.2.8.  REQ-8: Incident Response Support

     All frameworks require some logs to support incident investigation
     and response.  Explicit requirements are listed as follows:
















  Birkholz, et al.         Expires 29 August 2026                [Page 12]


  Internet-Draft               Verifiable ACRs               February 2026


     +================+==================================================+
     | Framework      | Requirement                                      |
     +================+==================================================+
     | NIS2 Art. 23   | 24-hour initial notification,                    |
     |                | 72-hour assessment                               |
     +----------------+--------------------------------------------------+
     | CRA            | 24-hour vulnerability notification               |
     |                | to ENISA                                         |
     +----------------+--------------------------------------------------+
     | ETSI TS 104223 | Logs for "incident investigations,               |
     | 5.4.2-1        | and vulnerability remediation"                   |
     +----------------+--------------------------------------------------+
     | FedRAMP        | Incident reporting and continuous                |
     |                | monitoring                                       |
     +----------------+--------------------------------------------------+

                                    Table 9

     Mapping to this specification: The structured format enables rapid
     extraction of relevant entries by timestamp range, event type, or
     tool invocation for incident reconstruction.

  2.2.9.  REQ-9: Anomaly and Risk Detection Support

     All frameworks require some logs to enable detection of anomalous or
     risky behavior.  Explicit requirements are listed as follows:

       +=========================+====================================+
       | Framework               | Requirement                        |
       +=========================+====================================+
       | EU AI Act Art. 12(2)(a) | "Identifying situations that may   |
       |                         | result in...risk"                  |
       +-------------------------+------------------------------------+
       | ETSI TS 104223 5.4.2-2  | "Detect anomalies, security        |
       |                         | breaches, or unexpected behaviour" |
       +-------------------------+------------------------------------+
       | FedRAMP SI-4            | "Anomaly detection"                |
       +-------------------------+------------------------------------+
       | SOC 2                   | "Anomaly detection" for security   |
       |                         | monitoring                         |
       +-------------------------+------------------------------------+

                                   Table 10

     Mapping to this specification: The standardized entry types and
     structured tool-call/tool-result pairs enable automated analysis for
     detecting:




  Birkholz, et al.         Expires 29 August 2026                [Page 13]


  Internet-Draft               Verifiable ACRs               February 2026


     *  Unusual tool invocation patterns

     *  Failed operations (via status and is-error fields)

     *  Unexpected reasoning patterns

     *  Token usage anomalies

  2.2.10.  REQ-10: Human Oversight Enablement

     All AI-specific frameworks require logs to support human review and
     oversight.  Explicit requirements are listed as follows:

     +======================+============================================+
     | Framework            | Requirement                                |
     +======================+============================================+
     | EU AI Act Art.       | "Monitoring the operation of high-risk AI  |
     | 26(5)                | systems"                                   |
     +----------------------+--------------------------------------------+
     | ETSI TS 104223       | "Capabilities to enable human oversight"   |
     | 5.1.4-1              |                                            |
     +----------------------+--------------------------------------------+
     | ISO 42001            | Human responsibility and accountability    |
     +----------------------+--------------------------------------------+
     | FFIEC VII.D          | "Dynamic updating...challenges to          |
     |                      | monitoring and independently reviewing AI" |
     +----------------------+--------------------------------------------+

                                    Table 11

     Mapping to this specification: The reasoning-entry type captures
     chain-of-thought content (where available), enabling human reviewers
     to understand AI decision-making processes.  The hierarchical
     children field preserves conversation structure.

  2.2.11.  REQ-11: Traceability and Reproducibility

     All frameworks require some ability to trace system behavior and
     reconstruct events.  Explicit requirements are listed as follows:












  Birkholz, et al.         Expires 29 August 2026                [Page 14]


  Internet-Draft               Verifiable ACRs               February 2026


      +===========+====================================================+
      | Framework | Requirement                                        |
      +===========+====================================================+
      | EU AI Act | "Level of traceability of the                      |
      | Art. 12   | functioning...appropriate to the intended purpose" |
      +-----------+----------------------------------------------------+
      | ISO 42001 | "Traceability" as key factor including "data       |
      |           | provenance, model traceability"                    |
      +-----------+----------------------------------------------------+
      | CRA       | "Traceability in the software supply chain"        |
      +-----------+----------------------------------------------------+
      | ETSI TS   | "Track, authenticate, manage version control"      |
      | 104223    |                                                    |
      | 5.2.1-2   |                                                    |
      +-----------+----------------------------------------------------+

                                   Table 12

     Mapping to this specification:

     *  session-id: Links entries to sessions

     *  entry-id and parent-id: Enables conversation tree reconstruction

     *  vcs-context: Git commit/branch for code state

     *  agent-meta: Model version and CLI version

     *  file-attribution: Code provenance tracking

  2.3.  Framework-Specific Requirements

  2.3.1.  EU AI Act (High-Risk Systems)

     For AI systems classified as high-risk under Annex III of the EU AI
     Act [EU_AI_ACT_2024], additional requirements apply:

     1.  Biometric identification systems (Annex III, 1(a)) require
         logging of:

         *  Precise timestamps for start/end of each usage session

         *  Reference database used during input data validation

         *  Input data leading to matches

         *  Natural persons involved in result verification




  Birkholz, et al.         Expires 29 August 2026                [Page 15]


  Internet-Draft               Verifiable ACRs               February 2026


     2.  Log retention: Minimum 6 months; financial services may require
         longer per sector-specific regulation.

     3.  Authority Access: Art. 19 of [EU_AI_ACT_2024] requires provision
         of logs to competent authorities upon reasoned request.

  2.3.2.  ETSI TS 104 223 Session Logging Requirements

     ETSI TS 104 223 [ETSI_TS_104223_2025] provides the most detailed AI-
     specific logging requirements:

      +===========+=================================+==================+
      | Provision | Requirement                     | This Spec        |
      |           |                                 | Mapping          |
      +===========+=================================+==================+
      | 5.1.2-3   | Audit trail for "operation, and | session-trace,   |
      |           | lifecycle management of models, | agent-meta       |
      |           | datasets and prompts"           |                  |
      +-----------+---------------------------------+------------------+
      | 5.2.4-1   | "Document and maintain a clear  | recording-agent, |
      |           | audit trail of their system     | open maps        |
      |           | design"                         |                  |
      +-----------+---------------------------------+------------------+
      | 5.2.4-3   | "Audit log of changes to system | event-entry with |
      |           | prompts or other model          | prompt changes   |
      |           | configuration"                  |                  |
      +-----------+---------------------------------+------------------+
      | 5.4.2-1   | "Log system and user actions to | entries array    |
      |           | support security compliance,    |                  |
      |           | incident investigations"        |                  |
      +-----------+---------------------------------+------------------+
      | 5.4.2-2   | "Analyse their logs to          | Structured       |
      |           | ensure...desired outputs and to | format enables   |
      |           | detect anomalies"               | analysis         |
      +-----------+---------------------------------+------------------+
      | 5.4.2-3   | "Monitor internal states of     | reasoning-entry, |
      |           | their AI systems"               | token-usage      |
      +-----------+---------------------------------+------------------+

                                   Table 13

  2.3.3.  PCI DSS AI-Specific Guidance

     The PCI Security Standards Council has published guidance on AI in
     payment environments [PCI_DSS_V4_0_1]: "Where possible, logging
     should be sufficient to audit the prompt inputs and reasoning process
     used by the AI system that led to the output provided."




  Birkholz, et al.         Expires 29 August 2026                [Page 16]


  Internet-Draft               Verifiable ACRs               February 2026


     This specification directly addresses this requirement through:

     *  message-entry (type: "user"): Captures prompt inputs

     *  reasoning-entry: Captures chain-of-thought (where available)

     *  message-entry (type: "assistant"): Captures model outputs

     *  tool-call-entry / tool-result-entry: Captures agentic actions

  2.3.4.  Financial Sector Requirements (FFIEC, BSI)

     Financial institutions face additional scrutiny for AI systems per
     [FFIEC_IT_HANDBOOK_2024] and [BSI_AI_FINANCE_2024]:

      +================+===========================+===================+
      | Requirement    | FFIEC                     | BSI AI Finance    |
      | Area           |                           |                   |
      +================+===========================+===================+
      | Explainability | "Lack of transparency or  | Test criteria for |
      |                | explainability" risk      | explainability    |
      +----------------+---------------------------+-------------------+
      | Dynamic        | "Challenges to monitoring | Continuous        |
      | updating       | and independently         | validation        |
      |                | reviewing AI"             |                   |
      +----------------+---------------------------+-------------------+
      | Audit trail    | Log management (VI.B.7)   | Complete audit    |
      |                |                           | trail             |
      +----------------+---------------------------+-------------------+

                                   Table 14

  2.4.  Compliance Mapping Table

     The following table maps this specification's data elements to
     compliance requirements:















  Birkholz, et al.         Expires 29 August 2026                [Page 17]


  Internet-Draft               Verifiable ACRs               February 2026


      +=============+========+=========+=====+=======+=====+=======+====+
      |Data Element |EU AI   |ETSI     |SOC 2|FedRAMP|PCI  |ISO    |NIS2|
      |             |Act     |104223   |     |       |DSS  |42001  |    |
      +=============+========+=========+=====+=======+=====+=======+====+
      |timestamp    |Art.    |5.4.2-1  |CC7.2|AU-8   |10.6 |A.6.2.8|Art.|
      |             |12(2)   |         |     |       |     |       |23  |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |session-id   |Art. 12 |5.2.4-1  |CC7.2|AU-3   |10.2 |A.6.2.8|-   |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |entry.type   |Art.    |5.4.2-1  |CC7.2|AU-3   |10.2 |A.6.2.8|-   |
      |             |12(2)   |         |     |       |     |       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |contributor  |Art.    |5.1.4    |CC6.1|AC-2   |10.2 |A.6.2.8|-   |
      |             |12(3)(d)|         |     |       |     |       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |message-     |Art.    |5.1.2-3  |-    |-      |AI   |-      |-   |
      |entry.content|12(3)(c)|         |     |       |Guide|       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |reasoning-   |Art. 12 |5.4.2-3  |-    |-      |AI   |A.7.1  |-   |
      |entry        |        |         |     |       |Guide|       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |tool-call-   |Art. 12 |5.4.2-1  |CC7.2|AU-12  |10.2 |A.6.2.8|-   |
      |entry / tool-|        |         |     |       |     |       |    |
      |result-entry |        |         |     |       |     |       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |signed-agent-|Art. 19 |5.2.4-1.2|CC6.1|AU-9   |10.5 |-      |-   |
      |record       |        |         |     |       |     |       |    |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |vcs-context  |-       |5.2.1-2  |-    |CM-3   |-    |A.6.2.8|-   |
      +-------------+--------+---------+-----+-------+-----+-------+----+
      |token-usage  |-       |5.4.2-4  |-    |-      |-    |-      |-   |
      +-------------+--------+---------+-----+-------+-----+-------+----+

                                    Table 15

  2.5.  Security Requirements addressing Regulatory Compliance

  2.5.1.  Log Integrity

     Per PCI DSS [PCI_DSS_V4_0_1] Req 10.5 and FedRAMP [NIST_SP_800_53_R5]
     AU-9, logs MUST be protected against modification.  Implementations
     SHOULD:

     1.  Use the signed-agent-record envelope for cryptographic integrity

     2.  Store the content-hash for offline verification

     3.  Implement write-once storage for log archives



  Birkholz, et al.         Expires 29 August 2026                [Page 18]


  Internet-Draft               Verifiable ACRs               February 2026


  2.5.2.  Access Control

     Per FedRAMP [NIST_SP_800_53_R5] AC-3 and ETSI [ETSI_TS_104223_2025]
     5.2.2-1, access to logs MUST be controlled:

     1.  Logs containing sensitive prompts or outputs require access
         control

     2.  Reasoning content may contain confidential information

     3.  Authority access (EU AI Act Art. 19) requires audit of log access
         itself

  2.5.3.  Data Protection

     Logs may contain personal data subject to GDPR/privacy regulations:

     1.  message-entry.content may contain PII

     2.  tool-result-entry.output may contain query results with PII

     3.  Retention periods must balance compliance requirements with data
         minimization

  2.6.  Related Standards and Emerging Work

     The ISO/IEC JTC 1/SC 42 committee is developing [ISO_IEC_DIS_24970],
     a draft international standard specifically addressing AI system
     logging requirements.  This work aligns with and complements the
     verifiable agent conversation format defined in this document.

     Research on emergent misalignment [EMERGENT_MISALIGNMENT_2025]
     demonstrates that narrow fine-tuning can produce broadly misaligned
     LLMs, underscoring the importance of comprehensive conversation
     logging for detecting behavioral anomalies that may not be apparent
     from individual interactions.

  3.  CDDL Definitions for Agent Conversations Records

     This section defines each complex data type specified in the
     verifiable agent conversation record CDDL data definition.  Each
     subsection illustrates a CDDL fragment for one type, a brief
     description, and per-member documentation.

  3.1.  Common Types

     The schema uses the following generic type definitions throughout.




  Birkholz, et al.         Expires 29 August 2026                [Page 19]


  Internet-Draft               Verifiable ACRs               February 2026


     abstract-timestamp:  An RFC 3339 date-time string or numeric epoch
        milliseconds.  New implementations SHOULD use RFC 3339 strings;
        consumers MUST accept both forms.

     session-id:  An opaque string uniquely identifying a conversation
        session.  Values may be UUID v4, UUID v7, SHA-256 hashes, or other
        formats.

     entry-id:  A per-entry unique reference within a session, enabling
        parent-child linking and tool call-result correlation.

  3.2.  The verifiable-agent-record Map

     The CDDL definition for the verifiable-agent-record map is specified
     as follows:

     verifiable-agent-record = {
         version: tstr
         id: tstr
         session: session-trace
         ? created: abstract-timestamp
         ? file-attribution: file-attribution-record
         ? vcs: vcs-context
         ? recording-agent: recording-agent
         * tstr => any
     }

     The verifiable-agent-record is the top-level container for all data
     produced by or about an agent conversation.  It unifies two
     complementary perspectives: the session trace captures how code was
     produced (the full conversation replay), while file attribution
     captures what code was produced (which files were modified and by
     whom).

     The following describes each member of this map.

     version:  The schema version string following semantic versioning
        (e.g., "3.0.0-draft").  Consumers use this field to select the
        appropriate parser or validation logic.

     id:  A unique identifier for this record, typically a UUID.
        Distinguishes records when multiple are stored or transmitted
        together.

     session:  The full conversation trace including all entries, tool
        calls, reasoning steps, and system events.

     created:  The timestamp when this record was generated.  Distinct



  Birkholz, et al.         Expires 29 August 2026                [Page 20]


  Internet-Draft               Verifiable ACRs               February 2026


        from session timestamps, which record when the conversation
        occurred.

     file-attribution:  Structured data about which files were modified
        and which line ranges were written by the agent.

     vcs:  Version control metadata at the record level (repository,
        branch, revision).

     recording-agent:  Identifies the tool or agent that generated this
        record, as distinct from the agent that conducted the
        conversation.

  3.3.  The session-trace Map

     The CDDL definition for the session-trace map is specified as
     follows:

     session-trace = {
         ? format: tstr
         session-id: session-id
         ? session-start: abstract-timestamp
         ? session-end: abstract-timestamp
         agent-meta: agent-meta
         ? environment: environment
         entries: [* entry]
         * tstr => any
     }

     A session-trace captures the full conversation between a user and an
     autonomous agent.  It contains an ordered array of entries
     representing messages, tool invocations, reasoning steps, and system
     events.  The session-trace preserves the complete interaction history
     including all native agent metadata, enabling both replay and audit
     of the conversation.

     The following describes each member of this map.

     format:  Classifies the session style, such as "interactive" (human-
        in-the-loop) or "autonomous" (fully automated).  Informative only;
        does not change the structure.

     session-id:  Unique identifier for this session.

     session-start:  When the session began.

     session-end:  When the session ended.




  Birkholz, et al.         Expires 29 August 2026                [Page 21]


  Internet-Draft               Verifiable ACRs               February 2026


     agent-meta:  Metadata about the agent and model that conducted this
        conversation.

     environment:  Execution environment context, such as working
        directory and version control state.

     entries:  An ordered array of conversation entries.

  3.4.  The agent-meta Map

     The CDDL definition for the agent-meta map is specified as follows:

     agent-meta = {
         model-id: tstr
         model-provider: tstr
         ? models: [* tstr]
         ? cli-name: tstr
         ? cli-version: tstr
         * tstr => any
     }

     The agent-meta type identifies the coding agent and language model
     used during a conversation session.  Agent identification is
     essential for provenance tracking: knowing which model produced which
     output enables auditing, capability assessment, and compliance
     verification.

     The following describes each member of this map.

     model-id:  The primary language model identifier, using the naming
        convention of the provider (e.g., "claude-opus-4-5-20251101",
        "gemini-2.0-flash").

     model-provider:  The provider of the primary model (e.g.,
        "anthropic", "google", "openai").

     models:  List of all model identifiers used during the session.
        Relevant for multi-model sessions where the agent switches between
        models.

     cli-name:  The name of the CLI tool or agent framework (e.g.,
        "claude-code", "gemini-cli", "codex-cli").

     cli-version:  The version of the CLI tool.







  Birkholz, et al.         Expires 29 August 2026                [Page 22]


  Internet-Draft               Verifiable ACRs               February 2026


  3.5.  The recording-agent Map

     The CDDL definition for the recording-agent map is specified as
     follows:

     recording-agent = {
         name: tstr
         ? version: tstr
         * tstr => any
     }

     The recording-agent map identifies the tool that generated this
     verifiable agent record, as distinct from the agent that conducted
     the conversation.  This distinction matters for provenance chains:
     the recording tool's version affects how native data is translated
     into the canonical CDDL data definition specified in this document.

     The following describes each member of this map.

     name:  The name of the recording tool or agent.

     version:  The version of the recording tool.

  3.6.  The environment Map

     The CDDL definition for the environment map is specified as follows:

     environment = {
         working-dir: tstr
         ? vcs: vcs-context
         ? sandboxes: [* tstr]
         * tstr => any
     }

     The environment type captures execution context for the conversation:
     where the agent was running, what version control state was active,
     and whether sandboxing was in effect.  This context is important for
     reproducibility and for understanding the scope of file
     modifications.

     The following describes each member of this map.

     working-dir:  The primary working directory path.  File paths in tool
        calls are typically relative to this directory.

     vcs:  Version control state at the time of the session (branch,
        revision, etc.).




  Birkholz, et al.         Expires 29 August 2026                [Page 23]


  Internet-Draft               Verifiable ACRs               February 2026


     sandboxes:  Paths to sandbox mount points.  Some agents run in
        sandboxed environments where the working directory is a temporary
        mount.

  3.7.  The vcs-context Map

     The CDDL definition for the vcs-context map is specified as follows:

     vcs-context = {
         type: tstr
         ? revision: tstr
         ? branch: tstr
         ? repository: tstr
         * tstr => any
     }

     The vcs-context type captures version control metadata for
     reproducibility.  Knowing the exact repository, branch, and commit at
     the time of a conversation enables consumers to reconstruct the
     codebase state and verify file attributions.

     The following describes each member of this map.

     type:  The version control system type (e.g., "git", "jj", "hg",
        "svn").

     revision:  The commit SHA or change identifier at session time.

     branch:  The active branch name.

     repository:  The repository URL.

  3.8.  Entry Types

     The CDDL definition specifies five entry types representing the
     different kinds of events in an agent conversation.  Each type uses a
     type field as the discriminator.  All entry types support optional
     children for hierarchical nesting and * tstr => any for preserving
     native agent fields that do not map to canonical fields.

     entry = message-entry
           / tool-call-entry
           / tool-result-entry
           / reasoning-entry
           / event-entry






  Birkholz, et al.         Expires 29 August 2026                [Page 24]


  Internet-Draft               Verifiable ACRs               February 2026


  3.8.1.  The message-entry Map

     The CDDL definition for the message-entry map is specified as
     follows:

     message-entry = {
         type: "user" / "assistant"
         ? content: any
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? model-id: tstr
         ? parent-id: entry-id
         ? token-usage: token-usage
         ? children: [* entry]
         * tstr => any
     }

     A message-entry represents a conversational turn: either human input
     (type: "user") or agent response (type: "assistant").  This is the
     most common entry type, carrying the primary dialogue content of a
     session.  For assistant messages, additional metadata may be present:
     the model that generated the response and token usage statistics.

     The following describes each member of this map.

     type:  The message direction. "user" indicates human (or upstream
        agent) input; "assistant" indicates the agent's response.

     content:  The message body.  May be a plain text string, an array of
        typed content parts, or absent when the agent places content
        exclusively in child entries.

     timestamp:  When this message was produced.

     id:  Unique identifier for this entry within the session.

     model-id:  The model that generated this response.  Present on
        assistant entries; absent on user entries.

     parent-id:  References the parent entry, enabling tree-structured
        conversations.

     token-usage:  Token consumption metrics for this response.

     children:  Nested entries within this message.  Used when the native
        format embeds tool calls or reasoning blocks inside an assistant
        message.




  Birkholz, et al.         Expires 29 August 2026                [Page 25]


  Internet-Draft               Verifiable ACRs               February 2026


  3.8.2.  The tool-call-entry Map

     The CDDL definition for the tool-call-entry map is specified as
     follows:

     tool-call-entry = {
         type: "tool-call"
         name: tstr
         input: any
         ? call-id: tstr
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [* entry]
         * tstr => any
     }

     A tool-call-entry represents a tool invocation: which tool was called
     and with what arguments.  Tool calls are central to agent
     conversation records because tool use is the primary mechanism by
     which agents interact with external environment.

     The following describes each member of this map.

     type:  Fixed discriminator value "tool-call".

     name:  The tool name (e.g., "Bash", "Edit", "Read", "apply_patch").

     input:  The arguments passed to the tool, preserved in their native
        structure.

     call-id:  Links this call to its corresponding result.

     timestamp:  When this tool call occurred.

     id:  Unique identifier for this entry.

     children:  Nested entries within this tool call.

  3.8.3.  The tool-result-entry Map

     The CDDL definition for the tool-result-entry map is specified as
     follows:









  Birkholz, et al.         Expires 29 August 2026                [Page 26]


  Internet-Draft               Verifiable ACRs               February 2026


     tool-result-entry = {
         type: "tool-result"
         output: any
         ? call-id: tstr
         ? status: tstr
         ? is-error: bool
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [* entry]
         * tstr => any
     }

     A tool-result-entry represents the output returned by a tool after
     execution.  It is linked to its corresponding tool-call-entry via the
     call-id field.  The result carries the tool's response data and
     optional status metadata indicating success or failure.

     The following describes each member of this map.

     type:  Fixed discriminator value "tool-result".

     output:  The tool's response, preserved in native structure.

     call-id:  Links this result to its corresponding call.

     status:  Outcome status of the tool execution, such as "success",
        "error", or "completed".

     is-error:  Boolean error flag, present when the tool execution
        failed.

     timestamp:  When this tool result was returned.

     id:  Unique identifier for this entry.

     children:  Nested entries within this tool result.

  3.8.4.  The reasoning-entry Map

     The CDDL definition for the reasoning-entry map is specified as
     follows:










  Birkholz, et al.         Expires 29 August 2026                [Page 27]


  Internet-Draft               Verifiable ACRs               February 2026


     reasoning-entry = {
         type: "reasoning"
         content: any
         ? encrypted: tstr
         ? subject: tstr
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [* entry]
         * tstr => any
     }

     A reasoning-entry captures CoT, thinking, or internal reasoning
     content from the agent.  Not all agents expose reasoning traces; when
     they do, the content may be plaintext, structured blocks, or
     encrypted.  Reasoning entries are valuable for auditing decision-
     making processes and understanding why an agent took particular
     actions.

     The following describes each member of this map.

     type:  Fixed discriminator value "reasoning".

     content:  The reasoning text or structured content.  May be an empty
        string when only encrypted content is available.

     encrypted:  Encrypted reasoning content.  Used where the model
        provider encrypts chain-of-thought output.

     subject:  A topic label for the reasoning block.

     timestamp:  When this reasoning was produced.

     id:  Unique identifier for this entry.

     children:  Nested entries within the reasoning block.

  3.8.5.  The event-entry Map

     The CDDL definition for the event-entry map is specified as follows:












  Birkholz, et al.         Expires 29 August 2026                [Page 28]


  Internet-Draft               Verifiable ACRs               February 2026


     event-entry = {
         type: "system-event"
         event-type: tstr
         ? data: { * tstr => any }
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [* entry]
         * tstr => any
     }

     An event-entry records system lifecycle events that are not part of
     the conversation dialogue but are relevant for understanding the
     session context.  Examples include session start/end markers, token
     usage summaries, permission changes, and configuration events.

     The following describes each member of this map.

     type:  Fixed discriminator value "system-event".

     event-type:  Classifies the event, such as "session-start", "session-
        end", "token-count", or "permission-change".  The values are not
        enumerated in the schema to accommodate vendor-specific event
        types.

     data:  Event-specific payload.  The structure varies by event type.

     timestamp:  When this event occurred.

     id:  Unique identifier for this entry.

     children:  Nested entries within this event.

  3.9.  The token-usage Map

     The CDDL definition for the token-usage map is specified as follows:

     token-usage = {
         ? input: uint
         ? output: uint
         ? cached: uint
         ? reasoning: uint
         ? total: uint
         ? cost: number
         * tstr => any
     }






  Birkholz, et al.         Expires 29 August 2026                [Page 29]


  Internet-Draft               Verifiable ACRs               February 2026


     The token-usage type captures token consumption metrics for a model
     response.  Token usage data is essential for cost tracking, quota
     management, and understanding model behavior.  All fields are
     optional because different agents report different subsets of token
     metrics.

     Editor's Note: add a non-empty generic here

     The following describes each member of this map.

     input:  The number of input tokens consumed by this response.

     output:  The number of output tokens generated.

     cached:  The number of input tokens served from cache rather than
        reprocessed.

     reasoning:  Tokens consumed by chain-of-thought or reasoning
        computation.

     total:  The total token count.

     cost:  The monetary cost in US dollars for this response.

  3.10.  File Attribution Types

     NOTE: This section is specified but not yet validated against real
     session data.  Implementation is pending.

     File attribution captures what code was produced: which files were
     modified, which line ranges were changed, and who authored them.

  3.10.1.  The file-attribution-record Map

     The CDDL definition for the file-attribution-record map is specified
     as follows:

     file-attribution-record = {
         files: [* file]
     }

     The file-attribution-record is the top-level container for file
     attribution data.  It holds an array of files, each with their
     attributed line ranges and contributor information.

     The following describes each member of this map.

     files:  Array of files with attributed ranges.



  Birkholz, et al.         Expires 29 August 2026                [Page 30]


  Internet-Draft               Verifiable ACRs               February 2026


  3.10.2.  The file Map

     The CDDL definition for the file map is specified as follows:

     file = {
         path: tstr
         conversations: [* conversation]
     }

     A file represents a single source file that was modified during the
     conversation.  It groups all conversations that contributed changes
     to this file.

     The following describes each member of this map.

     path:  The file path relative to the repository root.

     conversations:  The conversations that contributed modifications to
        this file.

  3.10.3.  The conversation Map

     The CDDL definition for the conversation map is specified as follows:

     conversation = {
         ? url: tstr .regexp uri-regexp
         ? contributor: contributor
         ranges: [* range]
         ? related: [* resource]
     }

     A conversation links a specific session to the line ranges it
     produced in a file.  This enables tracing from a line of code back to
     the conversation that generated it.

     The following describes each member of this map.

     url:  A URL pointing to the conversation source (e.g., a web UI
        permalink).

     contributor:  The default contributor for all ranges in this
        conversation.  Can be overridden per-range.

     ranges:  The line ranges in the file that were produced by this
        conversation.

     related:  External resources related to this conversation (e.g.,
        issue trackers, documentation).



  Birkholz, et al.         Expires 29 August 2026                [Page 31]


  Internet-Draft               Verifiable ACRs               February 2026


  3.10.4.  The range Map

     The CDDL definition for the range map is specified as follows:

     range = {
         start-line: uint
         end-line: uint
         ? content-hash: tstr
         ? content-hash-alg: tstr
         ? contributor: contributor
     }

     A range identifies a contiguous block of lines in a file that were
     produced by a specific conversation.  Line numbers are 1-indexed and
     inclusive.  The optional content hash enables position-independent
     tracking when lines move due to later edits.

     The following describes each member of this map.

     start-line:  The first line of the range (1-indexed).

     end-line:  The last line of the range (1-indexed, inclusive).

     content-hash:  A hash of the range content for position-independent
        identification.

     content-hash-alg:  The hash algorithm used (default: "sha-256").

     contributor:  Overrides the conversation-level contributor for this
        specific range.

  3.10.5.  The contributor Map

     The CDDL definition for the contributor map is specified as follows:

     contributor = {
         type: "human" / "ai" / "mixed" / "unknown"
         ? model-id: tstr
     }

     A contributor identifies who authored a range of code.  The type
     field distinguishes between human-authored, AI-generated, mixed, and
     unknown authorship.

     The following describes each member of this map.

     type:  The authorship category.




  Birkholz, et al.         Expires 29 August 2026                [Page 32]


  Internet-Draft               Verifiable ACRs               February 2026


     model-id:  The model identifier for AI-authored ranges.

  3.10.6.  The resource Map

     The CDDL definition for the resource map is specified as follows:

     resource = {
         type: tstr
         url: tstr .regexp uri-regexp
     }

     A resource represents an external reference related to a
     conversation, such as an issue tracker entry, a pull request, or a
     documentation page.

     The following describes each member of this map.

     type:  The resource type (e.g., "issue", "pr", "documentation").

     url:  The URL of the resource.

  3.11.  Signing Envelope Types

     The signing envelope provides cryptographic integrity protection for
     verifiable agent records using COSE_Sign1 ([STD96]).

  3.11.1.  The signed-agent-record Structure

     The CDDL definition for a signed-agent-record structure is specified
     as follows:

     signed-agent-record = #6.18([
         protected: bstr .cbor protected-header
         unprotected: unprotected-header
         payload: bstr / null
         signature: bstr
     ])

     A signed-agent-record is a COSE_Sign1 envelope (CBOR Tag 18) that
     wraps a verifiable agent record with a cryptographic signature.
     Signing provides data provenance and tamper evidence, satisfying some
     requirements of RATS Evidence generation ([RFC9334]) and SCITT
     auditability ([I-D.ietf-scitt-architecture]) requirements.  The
     payload may be included or detached (null); in detached mode, the
     record is supplied separately during verification.

     The following describes each element of this structure.




  Birkholz, et al.         Expires 29 August 2026                [Page 33]


  Internet-Draft               Verifiable ACRs               February 2026


     protected:  The serialized protected header containing the algorithm
        identifier, content type, and CWT claims.

     unprotected:  The unprotected header carrying trace metadata at label
        100.

     payload:  The serialized record bytes, or null for detached payloads.

     signature:  The cryptographic signature over the protected header and
        payload.

  3.11.2.  The trace-metadata Map

     The CDDL definition for the trace-metadata map is specified as
     follows:

     trace-metadata = {
         session-id: session-id
         agent-vendor: tstr
         trace-format: trace-format-id
         timestamp-start: abstract-timestamp
         ? timestamp-end: abstract-timestamp
         ? content-hash: tstr
         ? content-hash-alg: tstr
     }

     The trace-metadata type carries summary information about the signed
     record in the COSE_Sign1 unprotected header.  This enables consumers
     to inspect key properties of a signed record without deserializing
     the full payload.

     The following describes each member of this map.

     session-id:  The session identifier from the signed record.

     agent-vendor:  The agent provider name (e.g., "anthropic", "google").

     trace-format:  Identifies the format of the signed payload (e.g.,
        "ietf-vac-v3.0" for canonical records).

     timestamp-start:  When the session began.

     timestamp-end:  When the session ended.

     content-hash:  SHA-256 hex digest of the payload bytes, enabling
        integrity checking independent of the COSE signature.

     content-hash-alg:  The hash algorithm used (default: "sha-256").



  Birkholz, et al.         Expires 29 August 2026                [Page 34]


  Internet-Draft               Verifiable ACRs               February 2026


  4.  Collated CDDL Definition for generic Agent Conversations

     start = verifiable-agent-record / signed-agent-record

     ; RFC 3339 string OR epoch milliseconds (for interop).
     abstract-timestamp = tstr .regexp date-time-regexp / uint

     ; Opaque string: UUID, SHA-256 hash in base64url, etc.
     session-id = tstr / bstr

     ; Per-entry unique reference within a session.
     entry-id = tstr

     ; RFC 3339 date-time pattern
     date-time-regexp = "([0-9]{4})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):([0-5][0-9]):(60|[0-5][0-9])([.][0-9]+)?(Z|[+-]([01][0-9]|2[0-3]):[0-5][0-9])"

     ; URI pattern (RFC 3986)
     uri-regexp = "(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?"

     verifiable-agent-record = {
         version: tstr                       ; Schema version (semver)
         id: tstr                            ; Record identifier
         session: session-trace              ; Conversation trace (required)
         ? created: abstract-timestamp       ; Record creation time
         ? file-attribution: file-attribution-record
         ? vcs: vcs-context                  ; Record-level VCS context
         ? recording-agent: recording-agent  ; Tool that generated this record
         * tstr => any
     }

     session-trace = {
         ? format: tstr                      ; "interactive" / "autonomous" / vendor
         session-id: session-id
         ? session-start: abstract-timestamp
         ? session-end: abstract-timestamp
         agent-meta: agent-meta
         ? environment: environment
         entries: [* entry]
         * tstr => any
     }

     agent-meta = {
         model-id: tstr                      ; e.g., "claude-opus-4-5-20251101"
         model-provider: tstr                ; e.g., "anthropic", "google"
         ? models: [ * tstr ]                  ; All models (multi-model sessions)
         ? cli-name: tstr                    ; e.g., "claude-code", "gemini-cli"
         ? cli-version: tstr
         * tstr => any



  Birkholz, et al.         Expires 29 August 2026                [Page 35]


  Internet-Draft               Verifiable ACRs               February 2026


     }

     recording-agent = {
         name: tstr
         ? version: tstr
         * tstr => any
     }

     environment = {
         working-dir: tstr
         ? vcs: vcs-context
         ? sandboxes: [ * tstr ]               ; Sandbox mount paths
         * tstr => any
     }

     vcs-context = {
         type: tstr                          ; "git" / "jj" / "hg" / "svn"
         ? revision: tstr                    ; Commit SHA or change ID
         ? branch: tstr
         ? repository: tstr                  ; Repository URL
         * tstr => any
     }

     entry = message-entry
           / tool-call-entry
           / tool-result-entry
           / reasoning-entry
           / event-entry

     message-entry = {
         type: "user" / "assistant"
         ? content: any                      ; Text string or structured content blocks
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? model-id: tstr                    ; Model (assistant only)
         ? parent-id: entry-id              ; Parent message reference
         ? token-usage: token-usage
         ? children: [ * entry ]
         * tstr => any
     }

     tool-call-entry = {
         type: "tool-call"
         name: tstr                          ; Tool name (e.g., "Bash", "Edit", "Read")
         input: any                          ; Tool arguments
         ? call-id: tstr                     ; Links call ↔ result
         ? timestamp: abstract-timestamp
         ? id: entry-id



  Birkholz, et al.         Expires 29 August 2026                [Page 36]


  Internet-Draft               Verifiable ACRs               February 2026


         ? children: [ * entry ]
         * tstr => any
     }

     tool-result-entry = {
         type: "tool-result"
         output: any                         ; Tool output
         ? call-id: tstr                     ; Links call ↔ result
         ? status: tstr                      ; "success" / "error" / "completed"
         ? is-error: bool
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [ * entry ]
         * tstr => any
     }

     reasoning-entry = {
         type: "reasoning"
         content: any                        ; Plaintext reasoning or structured
         ? encrypted: tstr                   ; Encrypted content (provider-protected)
         ? subject: tstr                     ; Topic label
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [ * entry ]
         * tstr => any
     }

     event-entry = {
         type: "system-event"
         event-type: tstr                    ; Event classifier
         ? data: { * tstr => any }           ; Event-specific payload
         ? timestamp: abstract-timestamp
         ? id: entry-id
         ? children: [ * entry ]
         * tstr => any
     }

     token-usage = {
         ? input: uint                       ; Input tokens
         ? output: uint                      ; Output tokens
         ? cached: uint                      ; Cached input tokens
         ? reasoning: uint                   ; Reasoning/thinking tokens
         ? total: uint                       ; Total tokens
         ? cost: number                      ; Dollar cost
         * tstr => any
     }

     file-attribution-record = {



  Birkholz, et al.         Expires 29 August 2026                [Page 37]


  Internet-Draft               Verifiable ACRs               February 2026


         files: [* file]
     }

     file = {
         path: tstr                          ; Relative path from repo root
         conversations: [* conversation]
     }

     conversation = {
         ? url: tstr .regexp uri-regexp
         ? contributor: contributor          ; Default contributor for ranges
         ranges: [* range]
         ? related: [* resource]
     }

     range = {
         start-line: uint                    ; 1-indexed
         end-line: uint                      ; 1-indexed, inclusive
         ? content-hash: tstr
         ? content-hash-alg: tstr            ; Default: "sha-256"
         ? contributor: contributor          ; Override for this range
     }

     contributor = {
         type: "human" / "ai" / "mixed" / "unknown"
         ? model-id: tstr
     }

     resource = {
         type: tstr
         url: tstr .regexp uri-regexp
     }

     ; SCITT-interoperable COSE Envelope
     ; including from draft-ietf-cose-merkle-tree-proofs and
     ; draft-ietf-scitt-architecture for validation

     signed-agent-record = #6.18([           ; COSE_Sign1 tag
         protected: bstr .cbor protected-header ; {alg, content-type, scitt-stuff}
         unprotected: unprotected-header     ; Trace metadata
         payload: bstr / null                ; Detached if null
         signature: bstr
     ])

     protected-header = {
       &(CWT_Claims: 15) => CWT_Claims
       ? &(alg: 1) => int
       ? &(content_type: 3) => tstr / uint



  Birkholz, et al.         Expires 29 August 2026                [Page 38]


  Internet-Draft               Verifiable ACRs               February 2026


       ? &(kid: 4) => bstr
       ? &(x5t: 34) => COSE_CertHash
       ? &(x5chain: 33) => COSE_X509
       * label => any
     }

     CWT_Claims = {
       &(iss: 1) => tstr
       &(sub: 2) => tstr
       * label => any
     }

     unprotected-header = {
       ? &(trace-metadata-key: 100) => trace-metadata ; 100 is placeholder
       ? &(x5chain: 33) => COSE_X509
       ? &(receipts: 394)  => [ + Receipt ]
       * label => any
     }

     trace-metadata = {
         session-id: session-id
         agent-vendor: tstr
         trace-format: trace-format-id
         timestamp-start: abstract-timestamp
         ? timestamp-end: abstract-timestamp
         ? content-hash: tstr                ; SHA-256 hex digest of payload
         ? content-hash-alg: tstr
     }

     ; Known values: "ietf-vac-v3.0" (canonical), "claude-jsonl", "gemini-json",
     ; "codex-jsonl", "opencode-json", "cursor-jsonl". Extensible via tstr.
     trace-format-id = tstr

     COSE_X509 = bstr / [ 2*certs: bstr ]
     COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
     label = int / tstr

     ; COSE Receipt CDDL for use in SCITT compliant COSE Envelope

     Receipt = #6.18(COSE_Sign1)

     cose-label = int / tstr
     cose-value = any

     Protected_Header = {
       * cose-label => cose-value
     }




  Birkholz, et al.         Expires 29 August 2026                [Page 39]


  Internet-Draft               Verifiable ACRs               February 2026


     Unprotected_Header = {
       &(receipts: 394)  => [+ bstr .cbor Receipt]
       * cose-label => cose-value
     }

     COSE_Sign1 = [
       protected   : bstr .cbor Protected_Header,
       unprotected : Unprotected_Header,
       payload     : bstr / null,
       signature   : bstr
     ]

           Figure 1: CDDL definition of an Agent Conversation Record

  5.  Privacy Considerations

     Verifiable agent conversation records reveal substantial information
     about agent behavior, system state, and user interactions.  The
     privacy considerations of [RFC6973] apply.

  5.1.  Information Disclosure

     User prompts captured in message entries may contain personal
     identifiers, business confidential information, credentials
     inadvertently included in prompts, or behavioral patterns.  Agent
     responses and reasoning traces may reveal inference results that
     expose information about users not explicitly provided, confidential
     information retrieved by tools, or system architecture details
     through tool names and parameters.  Implementations MUST treat user-
     provided content as potentially containing personally identifiable
     information.

     Record metadata exposes operational details that may have privacy
     implications.  Model identifiers reveal AI capabilities, CLI versions
     enable targeted attacks against known vulnerabilities, working
     directories expose file system structure, and VCS context discloses
     repository names and commit timing.  Token usage patterns may enable
     inference about conversation content even when the content itself is
     protected.

  5.2.  Sensitive Content in Records

     Reasoning entries may contain inferences that constitute special
     category data, including health-related inferences from user queries,
     political opinions derived from conversation context, or biometric
     data processed by AI systems.  The reasoning-entry.encrypted field
     reflects that some model providers encrypt chain-of-thought content;
     when reasoning is encrypted, audit capabilities depend on the



  Birkholz, et al.         Expires 29 August 2026                [Page 40]


  Internet-Draft               Verifiable ACRs               February 2026


     provider's cooperation.

     Tool inputs and outputs warrant particular attention.  Tool call
     inputs may contain credentials, API keys, or file contents.  Tool
     results may contain query results with personal data from databases
     or external services.  Implementations SHOULD provide configurable
     redaction rules for common patterns and support selective entry type
     recording based on deployment requirements.

  5.3.  Retention Considerations

     Multiple frameworks impose retention requirements that may conflict
     with data minimization principles.  Organizations must balance
     compliance obligations requiring extended retention against privacy
     principles requiring timely deletion.

     Compliant data management may require separating raw personal data
     from audit trail metadata, implementing automated deletion for
     personal data after compliance-minimum periods, and maintaining
     cryptographic commitments enabling verification without retaining
     content.

  5.4.  Correlation and Inference

     Presentations of the same record to multiple parties can be
     correlated by matching on the signature component.  Session
     identifiers enable linking of records across time, potentially
     revealing long-term behavioral patterns or organizational structure.
     Implementations SHOULD use unlinkable session identifiers where
     correlation is not required.

     Without accessing record content, observers may infer conversation
     frequency and duration patterns, types of tools used, error rates, or
     timing correlations with external events.  Metadata exposure in
     unprotected headers warrants careful consideration; the trace-
     metadata in the COSE unprotected header reveals session identifiers,
     agent vendor, and timestamps even when the payload is encrypted.

  5.5.  Authority Access

     Regulatory frameworks may require provision of records to authorities
     upon request.  Access to records has to be logged, capturing who
     accessed which records, when access occurred, what legal basis
     justified access, and what data was disclosed.  This creates a
     recursive consideration: access logs may themselves contain personal
     data requiring protection.





  Birkholz, et al.         Expires 29 August 2026                [Page 41]


  Internet-Draft               Verifiable ACRs               February 2026


  6.  Security Considerations

  6.1.  Record Integrity

     The signed-agent-record envelope provides cryptographic integrity
     protection for the serialized record payload.  A valid signature
     establishes that the claimed signer produced the record but does not
     guarantee the truthfulness of its contents.  Modifications to the
     record structure after signing invalidate the signature, but
     modifications before signing cannot be detected.  Implementations
     generating records incrementally during a conversation MUST sign only
     after the conversation concludes or at defined checkpoints.

  6.2.  Signing Key Protection

     The security of signed records depends critically on the protection
     of private signing keys.  If an attacker obtains a signing key, they
     can forge records indistinguishable from genuine ones.  Protection
     mechanisms range from operating system process isolation in
     development environments to hardware security modules with physical
     tampering resistance in high-assurance deployments.  Compromised
     signing keys require rejection of records signed after the compromise
     date and notification to Relying Parties.

     Key provisioning processes must guarantee that exclusively valid
     attestation key material is established.  Off-device key generation
     requires confidentiality protection during transmission, creating
     recursive security dependencies.  On-device key generation eliminates
     transmission risks but requires chain-of-custody integrity to prevent
     attackers from obtaining endorsement for keys they control.

  6.3.  Timestamp Integrity

     Timestamps establish temporal ordering of events within records.
     Attackers who can manipulate timestamps can backdate records, freeze
     participants in chosen time periods to evade freshness checks, or
     manipulate perceived temporal relationships between entries.
     Timestamps within records are attested by the signer, not
     independently verified.  Implementations requiring independent
     timestamp verification SHOULD use external timestamping services or
     transparency logs such as those defined in
     [I-D.ietf-scitt-architecture].









  Birkholz, et al.         Expires 29 August 2026                [Page 42]


  Internet-Draft               Verifiable ACRs               February 2026


  6.4.  Adversarial Content

     Processing verifiable agent conversation records involves parsing
     content that may be produced by adversaries.  This applies both to
     user-supplied prompts and to model outputs that may have been
     influenced by adversarial inputs.  The open extensibility (* tstr =>
     any) in record types allows arbitrary additional fields;
     implementations MUST NOT assume that unrecognized fields are safe to
     process or display.

     Records may contain content designed to exploit downstream systems.
     Malicious prompts preserved in records may execute if records are
     subsequently processed by AI systems.  Tool results may contain
     executable content that executes if rendered unsafely in web
     interfaces.  File paths in tool calls or file attribution entries may
     attempt directory traversal.  Implementations MUST apply appropriate
     sanitization before rendering content, executing it in agent
     contexts, or using paths for file system operations.

  6.5.  Non-Repudiation

     The signed-agent-record envelope alone provides authenticity and
     integrity, not non-repudiation.  A signer can claim key compromise or
     dispute the signing time without independent evidence.  Non-
     repudiation requires additional infrastructure such as transparency
     services [I-D.ietf-scitt-architecture] that provide independent
     timestamp proof via registration receipts, append-only logs
     preventing retroactive denial, and third-party witnesses to the
     signing event.

  6.6.  Detection and Trust Boundaries

     Verifiable agent conversation records primarily enable detection of
     anomalous behavior rather than prevention.  Detection requires that
     records accurately reflect actual agent behavior; an agent that
     controls its own recording can omit or falsify entries.  The
     recording-agent field distinguishes the recording tool from the
     conversing agent, enabling Relying Parties to assess trust in the
     recording process.

     Trust boundaries exist between the agent runtime and recording
     system, between the recording system and storage, between storage and
     verification, and between verification and decision-making.  Attacks
     at any boundary may compromise record integrity or confidentiality.







  Birkholz, et al.         Expires 29 August 2026                [Page 43]


  Internet-Draft               Verifiable ACRs               February 2026


  7.  IANA Considerations

  7.1.  Media Type

     IANA is requested to add "application/agent-conversation" as a new
     media type for Verifiable Agent Conversation Records to the "Media
     Types" registry [IANA.media-types] in the Standards Tree [RFC6838]:

      +====================+================================+===========+
      | Name               | Template                       | Reference |
      +====================+================================+===========+
      | agent-conversation | application/agent-conversation | RFCthis   |
      +--------------------+--------------------------------+-----------+

           Table 16: Verifiable Agent Conversation Record Media Type

     Type name:  application

     Subtype name:  agent-conversation

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  byte string

     Security considerations:  See Security Considerations {secconsec}

     Interoperability considerations:  N/A

     Published specification:  RFCthis

     Applications that use this media type:  Applications that need to
        describe AI agent conversation for verification and auditability.

     Fragment identifier considerations:  N/A

     Additional information:  Deprecated alias names for this type:  N/A

                              Magic number(s):  N/A

                              File extension(s):  acr

                              Macintosh file type code(s):  N/A

     Person/email address to contact for further information:  TBD

     Intended usage:  COMMON



  Birkholz, et al.         Expires 29 August 2026                [Page 44]


  Internet-Draft               Verifiable ACRs               February 2026


     Restriction on usage:  none

     Author:  See Author's Addresses section

     Change controller:  IETF

     Provisional registration:  no

  7.2.  CoAP Content Format

     IANA is requested to assign a Content-Format ID for Verifiable Agent
     Conversation Records in the "CoAP Content-Formats" registry, within
     the "Constrained RESTful Environments (CoRE) Parameters" registry
     group [IANA.core-parameters]:

          +====================+================+======+===========+
          | Content-Type       | Content Coding | ID   | Reference |
          +====================+================+======+===========+
          | application/agent- | -              | TBD1 | RFCthis   |
          | conversation       |                |      |           |
          +--------------------+----------------+------+-----------+

            Table 17: Verifiable Agent Conversation Record Content
                                    Format

     If possible, TBD1 should be assigned in the 256...9999 range.

  7.3.  CBOR Tag

     IANA is requested to allocate a tag for Verifiable Agent Conversation
     Records in the "CBOR Tags" registry [IANA.cbor-tags], preferably with
     the specific value requested:

             +======+===========+===============================+
             | Tag  | Data Item | Semantics                     |
             +======+===========+===============================+
             | 4149 | binary    | Verifiable Agent Conversation |
             |      |           | Records as defined in RFCthis |
             +------+-----------+-------------------------------+

                Table 18: Verifiable Agent Conversation Record
                                   CBOR Tag

  7.4.  COSE Header Parameter

     IANA is requested to allocated the COSE header parameter defined in
     Table 19 in the "COSE Header Parameters" registry
     [IANA.cose_header-parameters].



  Birkholz, et al.         Expires 29 August 2026                [Page 45]


  Internet-Draft               Verifiable ACRs               February 2026


     +================+=====+=====+==========+==============+===========+
     | Name           |Label|Value| Value    | Description  | Reference |
     |                |     |Type | Registry |              |           |
     +================+=====+=====+==========+==============+===========+
     | trace-metadata |TBD  |CBOR | -        | A metadata   | RFCthis,  |
     |                |     |map  |          | summary of   | Section   |
     |                |     |     |          | an Agent     | 3.11.2    |
     |                |     |     |          | Conversation |           |
     |                |     |     |          | Record       |           |
     +----------------+-----+-----+----------+--------------+-----------+

                     Table 19: New COSE Header Parameters

  8.  References

  8.1.  Normative References

     [AICPA_TSC_2017]
                American Institute of Certified Public Accountants and
                Chartered Institute of Management Accountants, "Trust
                Services Criteria for Security, Availability, Processing
                Integrity, Confidentiality, and Privacy (With Revised
                Points of Focus - 2022)", AICPA Trust Services Criteria,
                2017, <https://www.aicpa-cima.com/resources/download/2017-
                trust-services-criteria-with-revised-points-of-focus-
                2022>.

     [BCP26]    Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://doi.org/10.17487/RFC8126>.

     [BSI_AI_FINANCE_2024]
                Bundesamt fuer Sicherheit in der Informationstechnik,
                "Test Criteria Catalogue for AI Systems in Finance",
                BSI AI Finance Test Criteria, 2024,
                <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/
                AI-Finance_Test-Criteria.pdf>.

     [ETSI_TS_104223_2025]
                European Telecommunications Standards Institute, "Securing
                Artificial Intelligence (SAI); Baseline Cyber Security
                Requirements for AI Models and Systems", ETSI TS 104 223,
                V1.1.1, April 2025, <https://www.etsi.org/deliver/
                etsi_ts/104200_104299/104223/01.01.01_60/
                ts_104223v010101p.pdf>.





  Birkholz, et al.         Expires 29 August 2026                [Page 46]


  Internet-Draft               Verifiable ACRs               February 2026


     [EU_AI_ACT_2024]
                European Parliament and Council of the European Union,
                "Regulation (EU) 2024/1689 (Artificial Intelligence Act)",
                CELEX: 32024R1689, Official Journal of the European
                Union L 2024/1689, July 2024,
                <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

     [EU_CRA_2024]
                European Parliament and Council of the European Union,
                "Regulation (EU) 2024/2847 (Cyber Resilience Act)",
                CELEX: 32024R2847, Official Journal of the European
                Union L 2024/2847, November 2024,
                <https://eur-lex.europa.eu/eli/reg/2024/2847/oj>.

     [EU_NIS2_2022]
                European Parliament and Council of the European Union,
                "Directive (EU) 2022/2555 (NIS 2 Directive)",
                CELEX: 32022L2555, Official Journal of the European
                Union L 333, December 2022.

     [FFIEC_IT_HANDBOOK_2024]
                Federal Financial Institutions Examination Council,
                "Information Technology Examination Handbook", FFIEC IT
                Examination Handbook, August 2024,
                <https://ithandbook.ffiec.gov/>.

     [IANA.cbor-tags]
                IANA, "Concise Binary Object Representation (CBOR) Tags",
                <https://www.iana.org/assignments/cbor-tags>.

     [IANA.core-parameters]
                IANA, "Constrained RESTful Environments (CoRE)
                Parameters",
                <https://www.iana.org/assignments/core-parameters>.

     [IANA.cose_header-parameters]
                IANA, "COSE Header Parameters",
                <https://www.iana.org/assignments/cose>.

     [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
                <https://www.iana.org/assignments/cwt>.

     [IANA.jwt] IANA, "JSON Web Token (JWT)",
                <https://www.iana.org/assignments/jwt>.

     [IANA.media-types]
                IANA, "Media Types",
                <https://www.iana.org/assignments/media-types>.



  Birkholz, et al.         Expires 29 August 2026                [Page 47]


  Internet-Draft               Verifiable ACRs               February 2026


     [ISO_IEC_42001_2023]
                International Organization for Standardization and
                International Electrotechnical Commission, "Information
                technology - Artificial intelligence - Management system",
                ISO/IEC 42001:2023, December 2023,
                <https://www.iso.org/standard/42001>.

     [NIST_AI_100_2_E2025]
                National Institute of Standards and Technology,
                "Adversarial Machine Learning: A Taxonomy and Terminology
                of Attacks and Mitigations", NIST AI 100-2 E2025, March
                2025, <https://csrc.nist.gov/pubs/ai/100/2/e2025/final>.

     [NIST_SP_800_53_R5]
                National Institute of Standards and Technology, "Security
                and Privacy Controls for Information Systems and
                Organizations", NIST Special Publication 800-53, Revision
                5, September 2020,
                <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final>.

     [OMB_M_21_31]
                Office of Management and Budget, "Improving the Federal
                Government's Investigative and Remediation Capabilities
                Related to Cybersecurity Incidents", OMB
                Memorandum M-21-31, August 2021,
                <https://www.whitehouse.gov/wp-content/uploads/2021/08/
                M-21-31-Improving-the-Federal-Governments-Investigative-
                and-Remediation-Capabilities-Related-to-Cybersecurity-
                Incidents.pdf>.

     [PCI_DSS_V4_0_1]
                PCI Security Standards Council, "Payment Card Industry
                Data Security Standard", PCI DSS Version 4.0.1, June 2024,
                <https://www.pcisecuritystandards.org/document_library/>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://doi.org/10.17487/RFC2119>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://doi.org/10.17487/RFC4648>.








  Birkholz, et al.         Expires 29 August 2026                [Page 48]


  Internet-Draft               Verifiable ACRs               February 2026


     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://doi.org/10.17487/RFC5280>.

     [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
                Specifications and Registration Procedures", BCP 13,
                RFC 6838, DOI 10.17487/RFC6838, January 2013,
                <https://doi.org/10.17487/RFC6838>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://doi.org/10.17487/RFC7252>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://doi.org/10.17487/RFC7515>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://doi.org/10.17487/RFC7519>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://doi.org/10.17487/RFC8174>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://doi.org/10.17487/RFC8610>.

     [STD90]    Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://doi.org/10.17487/RFC8259>.

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

  8.2.  Informative References






  Birkholz, et al.         Expires 29 August 2026                [Page 49]


  Internet-Draft               Verifiable ACRs               February 2026


     [EMERGENT_MISALIGNMENT_2025]
                Betley, J., Tan, D., Warncke, N., Sztyber-Betley, A., Bao,
                X., Soto, M., Labenz, N., and O. Evans, "Emergent
                Misalignment: Narrow finetuning can produce broadly
                misaligned LLMs", PMLR 267:4043-4068, arXiv 2502.17424,
                February 2025, <https://arxiv.org/abs/2502.17424>.

     [I-D.ietf-scitt-architecture]
                Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
                Y., and S. Lasker, "An Architecture for Trustworthy and
                Transparent Digital Supply Chains", Work in Progress,
                Internet-Draft, draft-ietf-scitt-architecture-22, 10
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-scitt-architecture-22>.

     [ISO_IEC_DIS_24970]
                International Organization for Standardization and
                International Electrotechnical Commission, "Artificial
                intelligence - AI system logging", ISO/IEC DIS 24970,
                2025, <https://www.iso.org/standard/88723.html>.

     [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://doi.org/10.17487/RFC6973>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://doi.org/10.17487/RFC9334>.

     [STD96]    Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://doi.org/10.17487/RFC9052>.

  Acknowledgments

     The authors would like to thank: xor-hardener

  Authors' Addresses

     Henk Birkholz
     Email: henk.birkholz@ietf.contact


     Tobias Heldt



  Birkholz, et al.         Expires 29 August 2026                [Page 50]


  Internet-Draft               Verifiable ACRs               February 2026


     Email: tobias@xor.tech


     Orie Steele
     Email: orie@or13.io














































  Birkholz, et al.         Expires 29 August 2026                [Page 51]


name: draft-mishra-oauth-agent-grants
rev: 01
title: Delegated Agent Authorization Protocol (DAAP)
time: 2026-03-02T14:16:54Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T14:16:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.642223+00:00
source: ietf
abstract:
  Artificial intelligence (AI) agents increasingly take autonomous
     actions -- submitting forms, initiating payments, and sending
     communications -- on behalf of human users across third-party
     services.  This document defines the Delegated Agent Authorization
     Protocol (DAAP), an open, model-neutral, framework-agnostic protocol
     that specifies: cryptographic agent identity using Decentralized
     Identifiers (DIDs); a human-consent-based grant authorization flow
     modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token
     format with agent-specific claims; a revocation model with online
     verification; a hash-chained append-only audit trail; a policy engine
     for automated authorization decisions; a multi-agent delegation model
     with cascade revocation; budget controls for spending limits; real-
     time event streaming; a credential vault for secure secret storage;
     and external policy backend integration with OPA and Cedar.  DAAP
     fills a gap unaddressed by existing OAuth 2.0 extensions: verifying
     that a specific human authorized a specific AI agent to perform a
     specific action, revoking that authorization in real time, and
     producing a tamper-evident record of what the agent did.

full_text:
  Web Authorization Protocol                                      S. Kumar
  Internet-Draft                                                   Grantex
  Intended status: Informational                          27 February 2026
  Expires: 31 August 2026


               Delegated Agent Authorization Protocol (DAAP)
                     draft-mishra-oauth-agent-grants-00

  Abstract

     Artificial intelligence (AI) agents increasingly take autonomous
     actions — submitting forms, initiating payments, and sending
     communications — on behalf of human users across third-party
     services.  This document defines the Delegated Agent Authorization
     Protocol (DAAP), an open, model-neutral, framework-agnostic protocol
     that specifies: cryptographic agent identity using Decentralized
     Identifiers (DIDs); a human-consent-based grant authorization flow
     modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token
     format with agent-specific claims; a revocation model with online
     verification; a hash-chained append-only audit trail; a policy engine
     for automated authorization decisions; and a multi-agent delegation
     model with cascade revocation.  DAAP fills a gap unaddressed by
     existing OAuth 2.0 extensions: verifying that a specific human
     authorized a specific AI agent to perform a specific action, revoking
     that authorization in real time, and producing a tamper-evident
     record of what the agent did.

  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 31 August 2026.







  Kumar                    Expires 31 August 2026                 [Page 1]


  Internet-Draft                    DAAP                     February 2026


  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.  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
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.  DID Format  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  Identity Document . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Key Management  . . . . . . . . . . . . . . . . . . . . .   6
     3.  Scope Format and Registry . . . . . . . . . . . . . . . . . .   7
       3.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Standard Scope Registry . . . . . . . . . . . . . . . . .   7
       3.3.  Custom Scopes . . . . . . . . . . . . . . . . . . . . . .   8
       3.4.  Scope Display Requirements  . . . . . . . . . . . . . . .   9
     4.  Grant Authorization Flow  . . . . . . . . . . . . . . . . . .   9
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Authorization Request . . . . . . . . . . . . . . . . . .   9
       4.3.  Consent UI Requirements . . . . . . . . . . . . . . . . .  10
       4.4.  Token Exchange  . . . . . . . . . . . . . . . . . . . . .  11
     5.  Grant Token Format  . . . . . . . . . . . . . . . . . . . . .  11
       5.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .  11
       5.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .  11
       5.3.  Token Validation  . . . . . . . . . . . . . . . . . . . .  13
       5.4.  Token Lifetime Guidance . . . . . . . . . . . . . . . . .  13
     6.  Token Revocation  . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.  Revoke a Grant  . . . . . . . . . . . . . . . . . . . . .  13
       6.2.  Revoke a Specific Token . . . . . . . . . . . . . . . . .  14
       6.3.  Online Verification . . . . . . . . . . . . . . . . . . .  14
       6.4.  JTI Replay Prevention . . . . . . . . . . . . . . . . . .  14
     7.  Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . .  15
       7.1.  Log Entry Schema  . . . . . . . . . . . . . . . . . . . .  15
       7.2.  Hash Chain  . . . . . . . . . . . . . . . . . . . . . . .  15
       7.3.  Audit Log Requirements  . . . . . . . . . . . . . . . . .  15
     8.  Multi-Agent Delegation  . . . . . . . . . . . . . . . . . . .  16



  Kumar                    Expires 31 August 2026                 [Page 2]


  Internet-Draft                    DAAP                     February 2026


       8.1.  Delegation Token Claims . . . . . . . . . . . . . . . . .  16
       8.2.  Delegation Rules  . . . . . . . . . . . . . . . . . . . .  16
       8.3.  Delegation Endpoint . . . . . . . . . . . . . . . . . . .  17
       8.4.  Cascade Revocation  . . . . . . . . . . . . . . . . . . .  17
     9.  Conformance Requirements  . . . . . . . . . . . . . . . . . .  18
     10. Policy Engine . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.2.  Effects  . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.3.  Condition Fields . . . . . . . . . . . . . . . . . . . .  19
       10.4.  Evaluation Order . . . . . . . . . . . . . . . . . . . .  20
     11. Anomaly Detection . . . . . . . . . . . . . . . . . . . . . .  20
       11.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . .  20
       11.2.  Non-Blocking Requirement . . . . . . . . . . . . . . . .  20
       11.3.  Anomaly Types  . . . . . . . . . . . . . . . . . . . . .  21
       11.4.  Severity Levels  . . . . . . . . . . . . . . . . . . . .  21
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  21
       12.1.  Algorithm Restrictions . . . . . . . . . . . . . . . . .  21
       12.2.  Token Replay Prevention  . . . . . . . . . . . . . . . .  21
       12.3.  CSRF and Redirect URI Security . . . . . . . . . . . . .  22
       12.4.  Scope Reduction for Delegation . . . . . . . . . . . . .  22
       12.5.  Revocation Propagation . . . . . . . . . . . . . . . . .  22
       12.6.  Consent UI Integrity . . . . . . . . . . . . . . . . . .  22
       12.7.  Audit Log Integrity  . . . . . . . . . . . . . . . . . .  22
       12.8.  Enterprise Identity Security . . . . . . . . . . . . . .  23
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
       13.1.  JWT Claims Registration  . . . . . . . . . . . . . . . .  23
       13.2.  Well-Known URI Registration  . . . . . . . . . . . . . .  25
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       14.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Comparison with OAuth 2.0 Extensions . . . . . . . .  27
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

     Deployed AI agents operate across arbitrary third-party services
     using credentials and permissions that belong to the human users they
     serve.  Today, no interoperable standard exists for:

     1.  Verifying that an agent is who it claims to be

     2.  Confirming that a specific human authorized a specific agent to
         perform a specific action

     3.  Revoking that authorization in real time across all active tokens

     4.  Producing a tamper-evident record of agent activity



  Kumar                    Expires 31 August 2026                 [Page 3]


  Internet-Draft                    DAAP                     February 2026


     OAuth 2.0 [RFC6749] and its extensions address authorization for
     applications acting on behalf of users, but were not designed for the
     AI agent use case, which introduces distinct requirements:

     *  *Agent identity*: Unlike OAuth clients, AI agents are runtime
        entities that may be spawned dynamically and must carry a
        persistent cryptographic identity independent of the authorization
        server.

     *  *Multi-agent delegation*: An agent may spawn sub-agents, each of
        which requires a grant scoped to a subset of the parent's
        permissions, with the entire delegation tree revocable by the
        original principal.

     *  *Tamper-evident audit trail*: Regulated environments require a
        cryptographically linked record of agent activity that is
        verifiable without trust in the audit log operator.

     *  *Policy-driven automation*: High-volume agent deployments require
        automated authorization decisions (auto-approve, auto-deny)
        without per-request human interaction, while preserving the human
        principal's ability to revoke at any time.

     DAAP addresses these requirements as a layered extension to OAuth 2.0
     concepts, reusing RFC-standard JWT and JWK primitives wherever
     possible.

  1.1.  Requirements Language

     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.

  1.2.  Terminology

     The following terms are used throughout this document:

     Agent:
        An AI-powered software process that takes autonomous actions on
        behalf of a Principal.  An Agent has a persistent cryptographic
        identity (DID) and must obtain an explicit grant from its
        Principal before acting on their behalf.

     Principal:





  Kumar                    Expires 31 August 2026                 [Page 4]


  Internet-Draft                    DAAP                     February 2026


        The human user who authorizes an Agent to act on their behalf.
        The Principal is the subject (sub) of any Grant Token issued by
        the authorization server.

     Developer:
        The organization or individual who built and operates the Agent.
        The Developer authenticates to the authorization server using an
        API key.

     Authorization Server:
        A server implementing this specification that issues Grant Tokens,
        maintains the grant registry, and provides the JWKS endpoint for
        offline verification.

     Service:
        Any API or platform that receives requests from an Agent.
        Services MUST verify Grant Tokens before acting on agent requests.

     Grant:
        A persistent record of permission given by a Principal to an Agent
        for a specific set of Scopes.  A Grant is represented to the Agent
        as a Grant Token.

     Grant Token:
        A signed JWT [RFC7519] representing a valid, non-revoked Grant.
        Grant Tokens are short-lived credentials carrying agent-specific
        claims defined in Section 5.

     Scope:
        A named permission string following the format
        resource:action[:constraint] as defined in Section 3.

     DID:
        A Decentralized Identifier [DID-CORE] — the Agent's cryptographic
        identity.  In DAAP, Agent DIDs take the form
        did:grantex:<agent_id>.

     Policy:
        A rule evaluated by the Policy Engine (Section 10) that
        automatically approves or denies an authorization request before
        the consent UI is shown to the Principal.

     Anomaly:
        A behavioral deviation from an agent's established activity
        baseline, detected by the runtime monitoring system defined in
        Section 11.





  Kumar                    Expires 31 August 2026                 [Page 5]


  Internet-Draft                    DAAP                     February 2026


  2.  Agent Identity

  2.1.  DID Format

     Every Agent registered with a DAAP-compliant Authorization Server
     receives a Decentralized Identifier of the form:

     did:grantex:<agent_id>

     where <agent_id> is a ULID (Universally Unique Lexicographically
     Sortable Identifier) [ULID] prefixed with ag_.

     Example:

     did:grantex:ag_01HXYZ123abcDEF456ghi

  2.2.  Identity Document

     The DID resolves to an identity document at the Authorization Server.
     The document MUST contain the following fields:

     {
       "@context": "https://grantex.dev/v1/identity",
       "id": "did:grantex:ag_01HXYZ123abcDEF456ghi",
       "developer": "org_yourcompany",
       "name": "travel-booker",
       "description": "Books flights and hotels on behalf of users",
       "declaredScopes": ["calendar:read", "payments:initiate:max_500"],
       "status": "active",
       "createdAt": "2026-02-01T00:00:00Z",
       "verificationMethod": [{
         "id": "did:grantex:ag_01HXYZ123abcDEF456ghi#key-1",
         "type": "JsonWebKey2020",
         "publicKeyJwk": { "..." : "..." }
       }]
     }

  2.3.  Key Management

     Authorization Servers MUST adhere to the following key management
     requirements:

     *  Authorization Servers MUST use RS256 (RSASSA-PKCS1-v1_5 using SHA-
        256) [RFC7518] for signing Grant Tokens.

     *  Private signing keys MUST never be transmitted or stored outside
        the Authorization Server's trust boundary.




  Kumar                    Expires 31 August 2026                 [Page 6]


  Internet-Draft                    DAAP                     February 2026


     *  Public keys MUST be published at /.well-known/jwks.json as a JWK
        Set [RFC7517].

     *  Key rotation MUST be supported without changing the Agent's DID or
        invalidating existing, unexpired Grant Tokens.  Rotated keys MUST
        remain in the JWKS until all tokens signed with them have expired.

  3.  Scope Format and Registry

  3.1.  Format

     Scopes are permission strings of the form:

     resource:action[:constraint]

     where:

     *  resource identifies the data or service being accessed (e.g.,
        calendar, payments, email)

     *  action identifies the operation (e.g., read, write, send,
        initiate, delete)

     *  constraint is an optional limiting parameter (e.g., max_500 for a
        spending limit)

  3.2.  Standard Scope Registry

     The following scopes constitute the normative standard registry.
     Implementations MUST support all standard scopes that are relevant to
     the resources they expose:




















  Kumar                    Expires 31 August 2026                 [Page 7]


  Internet-Draft                    DAAP                     February 2026


          +=========================+==============================+
          | Scope                   | Description                  |
          +=========================+==============================+
          | calendar:read           | Read calendar events         |
          +-------------------------+------------------------------+
          | calendar:write          | Create, modify, and delete   |
          |                         | calendar events              |
          +-------------------------+------------------------------+
          | email:read              | Read email messages          |
          +-------------------------+------------------------------+
          | email:send              | Send emails on the           |
          |                         | Principal's behalf           |
          +-------------------------+------------------------------+
          | email:delete            | Delete email messages        |
          +-------------------------+------------------------------+
          | files:read              | Read files and documents     |
          +-------------------------+------------------------------+
          | files:write             | Create and modify files      |
          +-------------------------+------------------------------+
          | payments:read           | View payment history and     |
          |                         | balances                     |
          +-------------------------+------------------------------+
          | payments:initiate       | Initiate payments of any     |
          |                         | amount                       |
          +-------------------------+------------------------------+
          | payments:initiate:max_N | Initiate payments up to N in |
          |                         | the account's base currency  |
          +-------------------------+------------------------------+
          | profile:read            | Read profile and identity    |
          |                         | information                  |
          +-------------------------+------------------------------+
          | contacts:read           | Read address book and        |
          |                         | contacts                     |
          +-------------------------+------------------------------+

                                   Table 1

  3.3.  Custom Scopes

     Services MAY define custom scopes using reverse-domain notation per
     [RFC3986]:

     com.stripe.charges:create:max_5000
     io.github.issues:create

     Custom scopes MUST use reverse-domain notation to avoid collisions
     with the standard registry.




  Kumar                    Expires 31 August 2026                 [Page 8]


  Internet-Draft                    DAAP                     February 2026


  3.4.  Scope Display Requirements

     Authorization Servers MUST maintain a human-readable description for
     each scope in their registry.  Consent UIs MUST display human-
     readable descriptions to Principals, never raw scope strings.

  4.  Grant Authorization Flow

  4.1.  Overview

     The DAAP grant flow is modelled on the OAuth 2.0 Authorization Code
     flow [RFC6749] with the following adaptations: the client is always a
     Developer (identified by an API key), the resource owner is a
     Principal identified by the Developer's internal user identifier, and
     the resulting token carries agent-specific claims.

     Developer App          Authorization Server       Principal
          |                         |                      |
          | POST /v1/authorize       |                      |
          | {agentId, principalId,  |                      |
          |  scopes, redirectUri}    |                      |
          |------------------------>|                      |
          |                         |                      |
          |<------------------------|                      |
          | {authRequestId,          |                      |
          |  consentUrl}             |                      |
          |                         |                      |
          | redirect user --------------------------------->|
          |                         | consent UI displayed |
          |                         |<---------------------|
          |                         | Principal approves   |
          |                         |                      |
          |<------------------------------------------------|
          | redirectUri?code=AUTH_CODE                      |
          |                         |                      |
          | POST /v1/token           |                      |
          | {code, agentId}          |                      |
          |------------------------>|                      |
          |<------------------------|                      |
          | {grantToken,             |                      |
          |  refreshToken}           |                      |

  4.2.  Authorization Request

     The Developer initiates the flow by sending:






  Kumar                    Expires 31 August 2026                 [Page 9]


  Internet-Draft                    DAAP                     February 2026


     POST /v1/authorize
     Authorization: Bearer <api_key>
     Content-Type: application/json

     {
       "agentId": "ag_01HXYZ123abc",
       "principalId": "user_abc123",
       "scopes": ["calendar:read", "payments:initiate:max_500"],
       "expiresIn": "24h",
       "redirectUri": "https://yourapp.com/auth/callback",
       "state": "<csrf_token>",
       "audience": "https://api.targetservice.com"
     }

     The audience field is OPTIONAL.  When present, it MUST be embedded as
     the aud claim in the issued Grant Token.  The state parameter is
     REQUIRED and MUST be validated by the Developer's callback handler to
     prevent CSRF attacks.  The redirectUri MUST match a URI pre-
     registered for the Agent at the Authorization Server.

     Authorization Servers MUST reject requests whose redirectUri does not
     exactly match a pre-registered value for the specified agentId.

     Response 200 OK:

     {
       "authRequestId": "areq_01HXYZ...",
       "consentUrl": "https://consent.example.com/authorize?req=eyJ...",
       "expiresAt": "2026-02-01T00:15:00Z"
     }

  4.3.  Consent UI Requirements

     Authorization Servers MUST render a consent UI to the Principal that
     displays all of the following before the Principal approves or
     denies:

     1.  The Agent's registered name and description

     2.  The Developer's registered organization name

     3.  The full list of requested scopes with human-readable
         descriptions

     4.  The token expiry period

     5.  A prominent deny/cancel action that is at least as visually
         prominent as the approve action



  Kumar                    Expires 31 August 2026                [Page 10]


  Internet-Draft                    DAAP                     February 2026


  4.4.  Token Exchange

     After Principal approval, the Authorization Server calls
     redirectUri?code=AUTH_CODE&state=STATE.

     POST /v1/token
     Authorization: Bearer <api_key>
     Content-Type: application/json

     {
       "code": "AUTH_CODE",
       "agentId": "ag_01HXYZ123abc"
     }

     Response 200 OK:

     {
       "grantToken": "eyJhbGciOiJSUzI1NiJ9...",
       "refreshToken": "ref_01HXYZ...",
       "grantId": "grnt_01HXYZ...",
       "scopes": ["calendar:read", "payments:initiate:max_500"],
       "expiresAt": "2026-02-02T00:00:00Z"
     }

     Refresh tokens are single-use.  The Authorization Server MUST rotate
     the refresh token on every use.  Refresh tokens MUST be invalidated
     when the underlying Grant is revoked.

  5.  Grant Token Format

  5.1.  JOSE Header

     {
       "alg": "RS256",
       "typ": "JWT",
       "kid": "<key_id>"
     }

     The alg field MUST be RS256.  Authorization Servers MUST NOT issue
     tokens with any other algorithm.  Verifiers MUST explicitly reject
     tokens with any alg value other than RS256, including none and HS256.

  5.2.  JWT Claims








  Kumar                    Expires 31 August 2026                [Page 11]


  Internet-Draft                    DAAP                     February 2026


     {
       "iss": "https://as.example.com",
       "sub": "user_abc123",
       "aud": "https://api.targetservice.com",
       "agt": "did:grantex:ag_01HXYZ123abc",
       "dev": "org_yourcompany",
       "grnt": "grnt_01HXYZ...",
       "scp": ["calendar:read", "payments:initiate:max_500"],
       "iat": 1709000000,
       "exp": 1709086400,
       "jti": "tok_01HXYZ987xyz"
     }

     The following claims are defined by this specification:

         +=======+=============+==========+=========================+
         | Claim | Type        | Required | Description             |
         +=======+=============+==========+=========================+
         | iss   | string      | REQUIRED | Authorization Server    |
         |       |             |          | identifier URI          |
         +-------+-------------+----------+-------------------------+
         | sub   | string      | REQUIRED | Principal identifier    |
         +-------+-------------+----------+-------------------------+
         | aud   | string      | OPTIONAL | Intended audience       |
         |       |             |          | (target service URI)    |
         +-------+-------------+----------+-------------------------+
         | agt   | string      | REQUIRED | Agent DID               |
         +-------+-------------+----------+-------------------------+
         | dev   | string      | REQUIRED | Developer organization  |
         |       |             |          | identifier              |
         +-------+-------------+----------+-------------------------+
         | grnt  | string      | REQUIRED | Grant identifier (used  |
         |       |             |          | for revocation lookup)  |
         +-------+-------------+----------+-------------------------+
         | scp   | string[]    | REQUIRED | Array of granted scope  |
         |       |             |          | strings                 |
         +-------+-------------+----------+-------------------------+
         | iat   | NumericDate | REQUIRED | Issued-at time          |
         +-------+-------------+----------+-------------------------+
         | exp   | NumericDate | REQUIRED | Expiration time         |
         +-------+-------------+----------+-------------------------+
         | jti   | string      | REQUIRED | Unique token identifier |
         |       |             |          | (for replay prevention) |
         +-------+-------------+----------+-------------------------+

                                   Table 2





  Kumar                    Expires 31 August 2026                [Page 12]


  Internet-Draft                    DAAP                     February 2026


  5.3.  Token Validation

     Services receiving a Grant Token MUST verify all of the following:

     1.  The token signature is valid, verified using the JWK Set
         published at {iss}/.well-known/jwks.json, with the key identified
         by kid.

     2.  The alg header value is RS256.  Tokens with any other alg MUST be
         rejected.

     3.  The exp claim has not passed (allowing for a reasonable clock
         skew of no more than 300 seconds).

     4.  If the service has a registered audience identifier, the aud
         claim matches that identifier.

     5.  The scp array contains all scopes required for the requested
         operation.

     6.  For high-stakes operations (see Section 5.4), the token has not
         been revoked via the online verification endpoint.

  5.4.  Token Lifetime Guidance

     +=========================================+=========================+
     | Use Case                                | Recommended             |
     |                                         | Maximum TTL             |
     +=========================================+=========================+
     | High-stakes actions (payments:initiate, | 1 hour                  |
     | email:send, files:write)                |                         |
     +-----------------------------------------+-------------------------+
     | Standard agent tasks                    | 8 hours                 |
     +-----------------------------------------+-------------------------+
     | Long-running background agents          | 24 hours                |
     +-----------------------------------------+-------------------------+

                                    Table 3

     Implementations caching revocation state MUST NOT cache for longer
     than 300 seconds (5 minutes).  Services processing high-stakes scopes
     (payments:initiate, email:send, files:write) SHOULD perform online
     verification for each token use.

  6.  Token Revocation

  6.1.  Revoke a Grant




  Kumar                    Expires 31 August 2026                [Page 13]


  Internet-Draft                    DAAP                     February 2026


     DELETE /v1/grants/{grantId}
     Authorization: Bearer <principal_token>

     Effect: all active Grant Tokens issued under this Grant are
     immediately invalidated.  The Grant record is marked revoked with a
     timestamp.

  6.2.  Revoke a Specific Token

     POST /v1/tokens/revoke
     Authorization: Bearer <api_key>
     Content-Type: application/json

     {
       "jti": "tok_01HXYZ987xyz"
     }

     Response: 204 No Content.

  6.3.  Online Verification

     POST /v1/tokens/verify
     Authorization: Bearer <api_key>
     Content-Type: application/json

     {
       "token": "eyJhbGciOiJSUzI1NiJ9..."
     }

     Response 200 OK:

     {
       "valid": true,
       "grantId": "grnt_01HXYZ...",
       "scopes": ["calendar:read"],
       "principal": "user_abc123",
       "agent": "did:grantex:ag_01HXYZ123abc",
       "expiresAt": "2026-02-02T00:00:00Z"
     }

  6.4.  JTI Replay Prevention

     Authorization Servers MUST track all issued jti values for the
     lifetime of the corresponding token.  If a jti value is presented for
     verification more than once within its validity window, the
     Authorization Server MUST return valid: false and SHOULD log an
     anomaly event.




  Kumar                    Expires 31 August 2026                [Page 14]


  Internet-Draft                    DAAP                     February 2026


  7.  Audit Trail

  7.1.  Log Entry Schema

     {
       "entryId": "alog_01HXYZ...",
       "agentId": "did:grantex:ag_01HXYZ123abc",
       "grantId": "grnt_01HXYZ...",
       "principalId": "user_abc123",
       "developerId": "org_yourcompany",
       "action": "payment.initiated",
       "status": "success",
       "metadata": {
         "amount": 420,
         "currency": "USD",
         "merchant": "Air India"
       },
       "timestamp": "2026-02-01T12:34:56.789Z",
       "hash": "sha256:abc123...",
       "prevHash": "sha256:xyz789..."
     }

     action values use the format resource.verb (e.g., payment.initiated,
     email.sent). status MUST be one of success, failure, or blocked.

  7.2.  Hash Chain

     Each entry's hash is computed as a SHA-256 digest [RFC4648] over a
     canonical representation of the entry:

     hash = SHA-256(canonical_json(entry_without_hash) || prevHash)

     where canonical_json serializes all fields as a JSON object [RFC8259]
     with keys sorted alphabetically, and prevHash is the null string for
     the first entry in a chain.  This construction makes any
     retrospective modification to a historical entry detectable, as it
     invalidates all subsequent hashes.

  7.3.  Audit Log Requirements

     *  Audit log entries MUST be append-only at the API level.  No update
        or delete endpoints for audit entries are permitted.

     *  The Authorization Server MUST reject requests to modify or delete
        audit entries.






  Kumar                    Expires 31 August 2026                [Page 15]


  Internet-Draft                    DAAP                     February 2026


     *  The complete audit log for a Grant MUST remain accessible after
        the Grant is revoked, for a minimum retention period determined by
        the deployment's compliance requirements.

  8.  Multi-Agent Delegation

  8.1.  Delegation Token Claims

     When Agent A spawns Agent B, B's Grant Token MUST carry delegation
     claims linking it to the original Principal's authorization:

     {
       "sub": "user_abc123",
       "agt": "did:grantex:ag_B_456",
       "parentAgt": "did:grantex:ag_A_123",
       "parentGrnt": "grnt_parentXYZ",
       "scp": ["email:read"],
       "delegationDepth": 1
     }

     Additional delegation claims:

     +=================+=========+======================================+
     | Claim           | Type    | Description                          |
     +=================+=========+======================================+
     | parentAgt       | string  | DID of the delegating (parent) Agent |
     +-----------------+---------+--------------------------------------+
     | parentGrnt      | string  | Grant ID of the parent Grant         |
     +-----------------+---------+--------------------------------------+
     | delegationDepth | integer | Number of hops from the root Grant;  |
     |                 |         | 0 for root Grants                    |
     +-----------------+---------+--------------------------------------+

                                   Table 4

  8.2.  Delegation Rules

     *  Sub-agent scopes MUST be a strict subset of the parent Grant's scp
        array.  Authorization Servers MUST reject delegation requests
        whose requested scopes are not fully contained in the parent
        token's scp claim.

     *  delegationDepth MUST be incremented by exactly 1 at each hop.

     *  Implementations MUST enforce a developer-configurable delegation
        depth limit.  The RECOMMENDED default limit is *3*.
        Implementations MUST enforce a hard cap of *10* regardless of
        developer configuration.



  Kumar                    Expires 31 August 2026                [Page 16]


  Internet-Draft                    DAAP                     February 2026


     *  The expiry of a delegated Grant Token MUST NOT exceed
        min(parent_token_exp, now + requested_expires_in).

  8.3.  Delegation Endpoint

     POST /v1/grants/delegate
     Authorization: Bearer <api_key>
     Content-Type: application/json

     {
       "parentGrantToken": "eyJhbGciOiJSUzI1NiJ9...",
       "subAgentId": "ag_01HXYZ_sub",
       "scopes": ["email:read"],
       "expiresIn": "1h"
     }

     The Authorization Server MUST:

     1.  Validate that the parent Grant has not been revoked.

     2.  Reject with 400 if any requested scope is not present in the
         parent token's scp claim.

     3.  Reject with 400 if the resulting delegationDepth would exceed the
         configured limit.

     4.  Reject with 404 if subAgentId does not belong to the
         authenticated Developer.

     5.  Compute expiry as min(parent token exp, now + expiresIn).

     Response 201 Created:

     {
       "grantToken": "eyJhbGciOiJSUzI1NiJ9...",
       "grantId": "grnt_01HXYZ_sub",
       "scopes": ["email:read"],
       "expiresAt": "2026-02-01T01:00:00Z"
     }

  8.4.  Cascade Revocation

     Revoking a Grant via DELETE /v1/grants/:id MUST atomically revoke all
     descendant Grants — that is, all Grants whose parent_grant_id traces
     back to the revoked Grant at any depth.  Authorization Servers SHOULD
     implement this as a single recursive database transaction to
     eliminate any window during which descendant tokens remain valid.




  Kumar                    Expires 31 August 2026                [Page 17]


  Internet-Draft                    DAAP                     February 2026


  9.  Conformance Requirements

     A conformant DAAP Authorization Server MUST expose the following
     endpoints:

     +====================+=============================================+
     | Endpoint           | Description                                 |
     +====================+=============================================+
     | POST /v1/agents    | Register an Agent                           |
     +--------------------+---------------------------------------------+
     | POST /v1/authorize | Initiate the grant authorization flow       |
     +--------------------+---------------------------------------------+
     | POST /v1/token     | Exchange authorization code for Grant Token |
     +--------------------+---------------------------------------------+
     | POST /v1/tokens/   | Online token verification                   |
     | verify             |                                             |
     +--------------------+---------------------------------------------+
     | POST /v1/tokens/   | Revoke a specific token by JTI              |
     | revoke             |                                             |
     +--------------------+---------------------------------------------+
     | GET /v1/grants     | List a Principal's active Grants            |
     +--------------------+---------------------------------------------+
     | GET /v1/grants/:id | Retrieve a single Grant                     |
     +--------------------+---------------------------------------------+
     | DELETE /v1/        | Revoke a Grant (cascades to all             |
     | grants/:id         | descendants)                                |
     +--------------------+---------------------------------------------+
     | POST /v1/grants/   | Issue a delegated sub-agent Grant           |
     | delegate           |                                             |
     +--------------------+---------------------------------------------+
     | POST /v1/audit/log | Write an audit log entry                    |
     +--------------------+---------------------------------------------+
     | GET /v1/audit/     | Query the audit log                         |
     | entries            |                                             |
     +--------------------+---------------------------------------------+
     | GET /v1/audit/:id  | Retrieve a single audit log entry           |
     +--------------------+---------------------------------------------+
     | GET /.well-known/  | JWK Set for offline token verification      |
     | jwks.json          |                                             |
     +--------------------+---------------------------------------------+
     | GET /health        | Health check                                |
     +--------------------+---------------------------------------------+

                                   Table 5

     The following endpoints are OPTIONAL.  Implementations that choose to
     support an optional extension MUST implement it as specified in this
     document:



  Kumar                    Expires 31 August 2026                [Page 18]


  Internet-Draft                    DAAP                     February 2026


     *  *Policy Engine*: POST /v1/policies, GET /v1/policies, GET /v1/
        policies/:id, PATCH /v1/policies/:id, DELETE /v1/policies/:id

     *  *Webhooks*: POST /v1/webhooks, GET /v1/webhooks, DELETE /v1/
        webhooks/:id

     *  *Anomaly Detection*: POST /v1/anomalies/detect, GET /v1/anomalies,
        PATCH /v1/anomalies/:id/acknowledge

     *  *Enterprise SCIM 2.0*: /scim/v2/ endpoints as defined in RFC
        7642/7643/7644

     *  *SSO (OIDC)*: POST /v1/sso/config, GET /sso/login, GET /sso/
        callback

  10.  Policy Engine

  10.1.  Purpose

     The Policy Engine evaluates developer-defined rules against each
     authorization request before the consent UI is displayed.  Policies
     enable developers to auto-approve routine low-risk requests and auto-
     deny requests that violate organizational constraints.

  10.2.  Effects

               +==============+================================+
               | Effect       | Description                    |
               +==============+================================+
               | auto_approve | Grant Token issued immediately |
               |              | without showing the consent UI |
               +--------------+--------------------------------+
               | auto_deny    | Authorization request rejected |
               |              | immediately with 403 Forbidden |
               +--------------+--------------------------------+

                                    Table 6

  10.3.  Condition Fields

         +=============+==========+=================================+
         | Field       | Type     | Description                     |
         +=============+==========+=================================+
         | scopes      | string[] | Matches when the requested      |
         |             |          | scopes are a subset of this     |
         |             |          | list                            |
         +-------------+----------+---------------------------------+
         | principalId | string   | Matches a specific Principal    |



  Kumar                    Expires 31 August 2026                [Page 19]


  Internet-Draft                    DAAP                     February 2026


         |             |          | identifier                      |
         +-------------+----------+---------------------------------+
         | agentId     | string   | Matches a specific Agent        |
         |             |          | identifier                      |
         +-------------+----------+---------------------------------+
         | timeWindow  | object   | Time constraint: { "startHour": |
         |             |          | N, "endHour": N, "days": [1..7] |
         |             |          | } where days are ISO weekday    |
         |             |          | integers (1=Monday, 7=Sunday)   |
         +-------------+----------+---------------------------------+

                                   Table 7

  10.4.  Evaluation Order

     Policy evaluation MUST follow this order:

     1.  auto_deny rules are evaluated first.  The first matching deny
         rule wins and the request is rejected immediately.

     2.  auto_approve rules are evaluated next.  The first matching allow
         rule causes the Grant Token to be issued.

     3.  If no rule matches, the consent UI is displayed to the Principal.

     This ordering ensures that restrictive policies cannot be bypassed by
     a conflicting allow rule.

  11.  Anomaly Detection

  11.1.  Purpose

     The anomaly detection system monitors Agent behavior at runtime
     against each Agent's established activity baseline.  It identifies
     behavioral deviations and surfaces them to Developers for review.

  11.2.  Non-Blocking Requirement

     Anomaly detection MUST NOT block token issuance.  Detection operates
     asynchronously as an advisory layer.  Authorization Servers MUST NOT
     delay Grant Token responses pending anomaly analysis.










  Kumar                    Expires 31 August 2026                [Page 20]


  Internet-Draft                    DAAP                     February 2026


  11.3.  Anomaly Types

         +======================+====================================+
         | Type                 | Description                        |
         +======================+====================================+
         | unusual_scope_access | Agent requested scopes outside its |
         |                      | established pattern                |
         +----------------------+------------------------------------+
         | high_frequency       | Token issuance rate significantly  |
         |                      | exceeds the agent's baseline       |
         +----------------------+------------------------------------+
         | off_hours_activity   | Activity detected outside the      |
         |                      | Principal's normal active hours    |
         +----------------------+------------------------------------+
         | new_principal        | Agent is requesting access for a   |
         |                      | previously unserved Principal      |
         +----------------------+------------------------------------+
         | cascade_delegation   | Delegation chain depth approaching |
         |                      | or exceeding configured limits     |
         +----------------------+------------------------------------+

                                    Table 8

  11.4.  Severity Levels

     Anomaly severity MUST be one of: low, medium, high, critical.

  12.  Security Considerations

  12.1.  Algorithm Restrictions

     All Grant Tokens MUST be signed with RS256 (RSASSA-PKCS1-v1_5 with
     SHA-256).  Symmetric signing algorithms, including HS256, are NOT
     PERMITTED.  All verifiers MUST explicitly reject tokens presenting
     alg: none or any symmetric algorithm, regardless of library defaults.
     This prevents algorithm confusion attacks as described in [RFC8725].

     RSA key moduli MUST be at least 2048 bits.  Authorization Servers
     generating or importing signing keys MUST enforce this minimum.

  12.2.  Token Replay Prevention

     Every issued Grant Token carries a unique jti claim.  Authorization
     Servers providing online verification MUST track issued jti values
     and reject any verification request presenting a jti that has already
     been used, for the full lifetime of the token.





  Kumar                    Expires 31 August 2026                [Page 21]


  Internet-Draft                    DAAP                     February 2026


  12.3.  CSRF and Redirect URI Security

     The state parameter in the authorization request MUST be a
     cryptographically random, unpredictable value generated per-request.
     Developer callback handlers MUST validate the returned state value
     against the value sent in the original request.

     Redirect URIs MUST be pre-registered by the Developer for each Agent.
     Authorization Servers MUST perform exact-match comparison of the
     redirectUri in each authorization request against the pre-registered
     set.  Prefix matching and wildcard matching are NOT PERMITTED.

  12.4.  Scope Reduction for Delegation

     Delegated Grant Tokens MUST carry a scope set that is a strict subset
     of the parent Grant's scope set.  Authorization Servers MUST enforce
     this at token issuance time; it MUST NOT be enforced only at
     verification time.

  12.5.  Revocation Propagation

     Authorization Servers MUST propagate grant revocation to all
     descendant grants atomically.  The maximum allowable latency between
     a revocation request and the invalidation of all descendant tokens
     via the online verification endpoint is implementation-defined, but
     implementations SHOULD target sub-second propagation.

     Implementations caching revocation state MUST NOT cache for longer
     than 300 seconds.

  12.6.  Consent UI Integrity

     Consent UIs MUST display the agent name, developer name, all
     requested scopes with human-readable descriptions, token expiry, and
     a prominent deny/cancel action.  This information MUST be sourced
     from the Authorization Server's registry, not from the authorization
     request itself, to prevent a malicious Developer from displaying
     misleading scope descriptions.

  12.7.  Audit Log Integrity

     The hash-chain construction defined in Section 7 ensures that any
     modification to a historical audit entry is detectable.
     Implementations MUST store audit log entries in an append-only manner
     and MUST expose no API for modification or deletion of audit entries.
     Audit log export implementations SHOULD verify the hash chain before
     serving exports.




  Kumar                    Expires 31 August 2026                [Page 22]


  Internet-Draft                    DAAP                     February 2026


  12.8.  Enterprise Identity Security

     SSO callback handlers MUST validate both the state (CSRF protection)
     and nonce (replay protection) parameters before establishing a
     session.  ID tokens received in the SSO callback MUST be
     cryptographically verified against the identity provider's JWKS
     endpoint before any claims are trusted.

     SCIM provisioning endpoints MUST authenticate via a credential (SCIM
     Bearer token) that is entirely separate from the Developer API key
     infrastructure.  Compromise of a Developer API key MUST NOT grant
     access to SCIM provisioning endpoints, and vice versa.

  13.  IANA Considerations

  13.1.  JWT Claims Registration

     This document requests registration of the following claims in the
     IANA "JSON Web Token Claims" registry established by [RFC7519]:

     agt:
        Claim Name: agt

    
        Claim Description: Agent Decentralized Identifier

    
        Change Controller: IETF

    
        Specification Document: This document, Section 5

     dev:
        Claim Name: dev

    
        Claim Description: Developer organization identifier

    
        Change Controller: IETF

    
        Specification Document: This document, Section 5

     grnt:
        Claim Name: grnt

    



  Kumar                    Expires 31 August 2026                [Page 23]


  Internet-Draft                    DAAP                     February 2026


        Claim Description: Grant identifier for revocation lookup

    
        Change Controller: IETF

    
        Specification Document: This document, Section 5

     scp:
        Claim Name: scp

    
        Claim Description: Array of granted authorization scope strings

    
        Change Controller: IETF

    
        Specification Document: This document, Section 5

     parentAgt:
        Claim Name: parentAgt

    
        Claim Description: DID of the delegating parent Agent

    
        Change Controller: IETF

    
        Specification Document: This document, Section 8

     parentGrnt:
        Claim Name: parentGrnt

    
        Claim Description: Grant identifier of the parent Grant

    
        Change Controller: IETF

    
        Specification Document: This document, Section 8

     delegationDepth:
        Claim Name: delegationDepth

    



  Kumar                    Expires 31 August 2026                [Page 24]


  Internet-Draft                    DAAP                     February 2026


        Claim Description: Number of delegation hops from the root Grant

    
        Change Controller: IETF

    
        Specification Document: This document, Section 8

  13.2.  Well-Known URI Registration

     No new Well-Known URIs are defined by this specification.
     Implementations use the existing /.well-known/jwks.json path
     established by [RFC8414].

  14.  References

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

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/rfc/rfc3986>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4648>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6750>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7517>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7518>.



  Kumar                    Expires 31 August 2026                [Page 25]


  Internet-Draft                    DAAP                     February 2026


     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [RFC7636]  Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
                for Code Exchange by OAuth Public Clients", RFC 7636,
                DOI 10.17487/RFC7636, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7636>.

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

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8414>.

  14.2.  Informative References

     [DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July
                2022, <https://www.w3.org/TR/did-core/>.

     [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
                2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
                August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

     [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
                RFC 7662, DOI 10.17487/RFC7662, October 2015,
                <https://www.rfc-editor.org/rfc/rfc7662>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/rfc/rfc8693>.

     [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
                Current Practices", BCP 225, RFC 8725,
                DOI 10.17487/RFC8725, February 2020,
                <https://www.rfc-editor.org/rfc/rfc8725>.






  Kumar                    Expires 31 August 2026                [Page 26]


  Internet-Draft                    DAAP                     February 2026


     [ULID]     Feerasta, A., "Universally Unique Lexicographically
                Sortable Identifier", 2016,
                <https://github.com/ulid/spec>.

  Appendix A.  Comparison with OAuth 2.0 Extensions

     DAAP shares OAuth 2.0's fundamental grant model but differs in the
     following respects:

     *versus RFC 6749 (OAuth 2.0):* OAuth 2.0 defines a general-purpose
     delegated authorization framework.  DAAP specializes this for AI
     agents by: adding cryptographic agent identity (DID); defining agent-
     specific JWT claims (agt, dev, grnt, scp); mandating RS256
     exclusively; and adding the delegation, audit, policy, and anomaly
     detection subsystems.

     *versus RFC 8693 (Token Exchange):* Token Exchange [RFC8693] enables
     a client to exchange one token for another, including impersonation
     and delegation use cases.  DAAP's delegation model serves a narrower
     purpose — chaining AI agent sub-authorizations back to a human
     principal — and adds depth-limiting and cascade revocation semantics
     not present in RFC 8693.

     *versus RFC 7662 (Token Introspection):* Token Introspection
     [RFC7662] defines an endpoint for resource servers to query token
     metadata.  DAAP's /v1/tokens/verify endpoint serves a similar purpose
     but returns DAAP-specific fields (agent, principal, scopes) and is
     used by agent-side SDKs rather than resource servers.

  Acknowledgements

     The authors thank the members of the IETF OAuth Working Group for
     prior art in delegated authorization, and the W3C Decentralized
     Identifier Working Group for the DID specification that DAAP builds
     upon for agent identity.

  Author's Address

     Sanjeev Kumar
     Grantex
     Email: mishra.sanjeev@gmail.com
     URI:   https://grantex.dev









  Kumar                    Expires 31 August 2026                [Page 27]


name: draft-sipos-dtn-bp-safe
rev: 00
title: Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)
time: 2025-12-07T07:09:02Z
group_uri: /api/v1/group/group/1027/
expires: 2025-12-06T19:27:17Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.705316+00:00
source: ietf
abstract:
  This document defines a protocol for negotiating scoped security
     associations between Bundle Protocol version 7 (BPv7) agents within a
     delay-tolerant network (DTN).  Security associations are used to
     amortize the costs of asymmetric-keyed security operations and allow
     for efficient and high-throughput BPv7 security within a public key
     infrastructure.

full_text:
  Delay-Tolerant Networking                                       B. Sipos
  Internet-Draft                                                   JHU/APL
  Intended status: Standards Track                             4 June 2025
  Expires: 6 December 2025


    Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)
                         draft-sipos-dtn-bp-safe-00

  Abstract

     This document defines a protocol for negotiating scoped security
     associations between Bundle Protocol version 7 (BPv7) agents within a
     delay-tolerant network (DTN).  Security associations are used to
     amortize the costs of asymmetric-keyed security operations and allow
     for efficient and high-throughput BPv7 security within a public key
     infrastructure.

  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 6 December 2025.

  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.



  Sipos                    Expires 6 December 2025                [Page 1]


  Internet-Draft                   BP SAFE                       June 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.  Use Cases Considered  . . . . . . . . . . . . . . . . . .   6
         1.2.1.  End-to-End Security . . . . . . . . . . . . . . . . .   7
         1.2.2.  One-Hop Security  . . . . . . . . . . . . . . . . . .   8
       1.3.  Use of CDDL . . . . . . . . . . . . . . . . . . . . . . .   8
       1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   9
     2.  General Protocol Description  . . . . . . . . . . . . . . . .  10
       2.1.  Relationship to EDHOC . . . . . . . . . . . . . . . . . .  11
       2.2.  Relationship to BPSec . . . . . . . . . . . . . . . . . .  11
       2.3.  Credential Sources  . . . . . . . . . . . . . . . . . . .  12
       2.4.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  12
     3.  Information Bases . . . . . . . . . . . . . . . . . . . . . .  12
       3.1.  Participating Peers . . . . . . . . . . . . . . . . . . .  13
       3.2.  Activity States . . . . . . . . . . . . . . . . . . . . .  14
       3.3.  Primary Security Associations . . . . . . . . . . . . . .  15
       3.4.  Secondary Security Associations . . . . . . . . . . . . .  17
     4.  Protocol Sub-Layers and Binding . . . . . . . . . . . . . . .  18
       4.1.  Activity Sequencing . . . . . . . . . . . . . . . . . . .  20
       4.2.  Message Structure . . . . . . . . . . . . . . . . . . . .  21
       4.3.  States, Deduplication, and Retransmission . . . . . . . .  22
       4.4.  Message Aggregation and Security  . . . . . . . . . . . .  25
       4.5.  PDU Transport . . . . . . . . . . . . . . . . . . . . . .  27
     5.  Activity Types  . . . . . . . . . . . . . . . . . . . . . . .  27
       5.1.  Initial Authentication (IA) . . . . . . . . . . . . . . .  27
         5.1.1.  EDHOC Requirements  . . . . . . . . . . . . . . . . .  28
         5.1.2.  PKIX Profile  . . . . . . . . . . . . . . . . . . . .  29
       5.2.  Capability Indication (CI)  . . . . . . . . . . . . . . .  29
       5.3.  SA Creation (SC)  . . . . . . . . . . . . . . . . . . . .  30
       5.4.  SA Rekey (SR) . . . . . . . . . . . . . . . . . . . . . .  32
       5.5.  SA Teardown (ST)  . . . . . . . . . . . . . . . . . . . .  33
       5.6.  Event Notification (EN) . . . . . . . . . . . . . . . . .  34
     6.  Data Item Types . . . . . . . . . . . . . . . . . . . . . . .  34
       6.1.  Error Type Enumeration (ETE)  . . . . . . . . . . . . . .  35
       6.2.  Concurrent Activity Support (CAS) . . . . . . . . . . . .  35
       6.3.  EID Scheme Support (ESS)  . . . . . . . . . . . . . . . .  35
       6.4.  BPSec Context Support (BCS) . . . . . . . . . . . . . . .  36
       6.5.  Security Association Identifier (SAI) . . . . . . . . . .  36
       6.6.  Additional Key Exchange (AKE) . . . . . . . . . . . . . .  36
       6.7.  Additional Random Nonce (ARN) . . . . . . . . . . . . . .  36
       6.8.  Security Mode Selector (SMS)  . . . . . . . . . . . . . .  37
       6.9.  Node Time Interval (NTI)  . . . . . . . . . . . . . . . .  37
       6.10. Endpoint Selectors (ESx)  . . . . . . . . . . . . . . . .  38
       6.11. Security Operation Selectors (SOS)  . . . . . . . . . . .  38
       6.12. Key Use Selectors (KUS) . . . . . . . . . . . . . . . . .  39
     7.  Activity Patterns . . . . . . . . . . . . . . . . . . . . . .  39



  Sipos                    Expires 6 December 2025                [Page 2]


  Internet-Draft                   BP SAFE                       June 2025


     8.  Shared Secret Derivations . . . . . . . . . . . . . . . . . .  41
       8.1.  Primary SA Creation . . . . . . . . . . . . . . . . . . .  41
       8.2.  Primary SA Rekey  . . . . . . . . . . . . . . . . . . . .  43
       8.3.  Secondary SA Creation . . . . . . . . . . . . . . . . . .  43
       8.4.  Secondary SA Rekey  . . . . . . . . . . . . . . . . . . .  44
     9.  Security Association Uses . . . . . . . . . . . . . . . . . .  44
       9.1.  SAFE Confidentiality  . . . . . . . . . . . . . . . . . .  45
         9.1.1.  Without a Primary SA  . . . . . . . . . . . . . . . .  45
         9.1.2.  With a Primary SA . . . . . . . . . . . . . . . . . .  45
       9.2.  Common BPSec Operation  . . . . . . . . . . . . . . . . .  48
       9.3.  Binding for BIB-HMAC-SHA2 Context . . . . . . . . . . . .  49
         9.3.1.  Secondary SA Information  . . . . . . . . . . . . . .  49
         9.3.2.  KUS Options . . . . . . . . . . . . . . . . . . . . .  49
         9.3.3.  Key Derivation  . . . . . . . . . . . . . . . . . . .  50
         9.3.4.  BPSec Operation . . . . . . . . . . . . . . . . . . .  50
       9.4.  Binding for BCB-AES-GCM Context . . . . . . . . . . . . .  51
         9.4.1.  Secondary SA Information  . . . . . . . . . . . . . .  51
         9.4.2.  KUS Options . . . . . . . . . . . . . . . . . . . . .  52
         9.4.3.  Key Derivation  . . . . . . . . . . . . . . . . . . .  52
         9.4.4.  BPSec Operation . . . . . . . . . . . . . . . . . . .  52
       9.5.  Binding for COSE Context  . . . . . . . . . . . . . . . .  53
         9.5.1.  Secondary SA Information  . . . . . . . . . . . . . .  54
         9.5.2.  KUS Options . . . . . . . . . . . . . . . . . . . . .  54
         9.5.3.  Key Derivation  . . . . . . . . . . . . . . . . . . .  55
         9.5.4.  BPSec Operation . . . . . . . . . . . . . . . . . . .  56
     10. PKIX Certificate Profile  . . . . . . . . . . . . . . . . . .  60
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  60
       11.1.  Threat: Passive Leak of Data . . . . . . . . . . . . . .  60
       11.2.  Threat: On-Path Modification . . . . . . . . . . . . . .  61
       11.3.  Threat: Denial of Service  . . . . . . . . . . . . . . .  61
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  61
       12.1.  Well-Known IPN Service . . . . . . . . . . . . . . . . .  62
       12.2.  EDHOC Registries . . . . . . . . . . . . . . . . . . . .  62
       12.3.  BP SAFE Registries . . . . . . . . . . . . . . . . . . .  62
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  68
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  68
       13.2.  Informative References . . . . . . . . . . . . . . . . .  70
     Appendix A.  Example Sequencing . . . . . . . . . . . . . . . . .  71
       A.1.  SAFE PDU #1 . . . . . . . . . . . . . . . . . . . . . . .  72
       A.2.  SAFE PDU #2 . . . . . . . . . . . . . . . . . . . . . . .  72
       A.3.  SAFE PDU #3 . . . . . . . . . . . . . . . . . . . . . . .  73
       A.4.  SAFE PDU #4 . . . . . . . . . . . . . . . . . . . . . . .  75
       A.5.  SAFE PDU #5 . . . . . . . . . . . . . . . . . . . . . . .  76
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  77
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  77






  Sipos                    Expires 6 December 2025                [Page 3]


  Internet-Draft                   BP SAFE                       June 2025


  1.  Introduction

     The combination of Bundle Protocol version 7 (BPv7) [RFC9171] and
     Bundle Protocol Security (BPSec) [RFC9172] enables security to be
     applied at a fine-grained level to individual blocks of a bundle.

     When operating within a Public Key Infrastructure Using X.509 (PKIX)
     [RFC5280] environment, in the absence of any kind of online protocol
     between the security source and expected acceptor(s) there are two
     extreme alternatives for the use of public keys for integrity and/or
     confidentiality:

     1.  The security source can use a public key of the security source
         directly for signing each target or use a public key of the
         security acceptor directly for each target (for either key
         agreement or key encapsulation).

         This is the strategy taken by the email security of S/MIME
         [RFC8551] and asymmetric algorithms of CBOR Object Signing and
         Encryption (COSE) [RFC9052].  While it ensures that each security
         operation can be processed independently it also introduces a
         large overhead because asymmetric-keyed algorithms are likely to
         be orders of magnitude more resource intensive than symmetric-
         keyed ones.

     2.  For key types which support key exchange, such as elliptic curve
         (EC) keys, the security source can use a public key from both the
         security source and acceptor to perform a one-time key derivation
         of a shared secret, and from that secret a pseudorandom function
         (PRF) can be used to derive symmetric keys known to both
         entities.

         This allows the cost of one-time key exchange and PRF operations
         to be amortized across all of the cryptographic operations using
         the derived symmetric keys.  But without any additional scoping
         added to the derived keys (_e.g._, valid time of use or volume of
         data processed, restriction to specific ciphersuites or
         algorithms, etc.), the keys themselves will be vulnerable to
         overuse or cross-use vulnerabilities.

         This technique alone also provides confidentiality of the derived
         symmetric keys but does not intrinsically provide any
         authentication of the peer entity (via some identity binding to
         the associated private key).  It also does not allow for forward
         secrecy because the original asymmetric keys need to be long-
         lived enough to handle all communications between the entities.





  Sipos                    Expires 6 December 2025                [Page 4]


  Internet-Draft                   BP SAFE                       June 2025


     In order to both amortize the costs of asymmetric-keyed algorithms
     and to provide a separate means of mutually authenticating a peer BP
     node, including a proof-of-possession for the private key associated
     with a known public key, this document defines the Security
     Associations with Few Exchanges (SAFE) protocol.

     The SAFE protocol operation is explained in detail in Section 2.  It
     operates as an "in-band" application over BPv7 as depicted in
     Figure 1.  This is similar to how the Internet Key Exchange Version 2
     (IKEv2) protocol of [RFC7296] operates as an application over UDP/IP.

               +-----------------------+
               | Security Associations | -\
               |         (SAFE)        |   |
               +-----------------------|   |
               |      BPv7 + BPSec     |   -> Application Layer
               +-----------------------+   |
               |   CL + opt. security  | -/
               +-----------------------+
               |      TCP/UDP/etc.     | ---> Transport Layer
               +-----------------------+
               |       IPv4/IPv6       | ---> Network Layer
               +-----------------------+
               |  Link-Layer Protocol  | ---> Link Layer
               +-----------------------+

           Figure 1: The Locations of SAFE and BP above the Internet
                                 Protocol Stack

  1.1.  Scope

     This document describes the format of the protocol data units passed
     between BP nodes for security association negotiation and defines
     behavior at message source and destination nodes.  It also defines
     how each participating node acts on those security associations to
     process BPSec security operations.

     This document does not address:

     *  The format of protocol data units of the Bundle Protocol, as those
        are defined elsewhere in [RFC9171].  This includes the concept of
        bundle fragmentation or bundle encapsulation.

     *  Logic for routing bundles along a path toward a bundle's endpoint.

     *  Uses of security associations outside of the use cases explained
        in Section 1.2 or when combined with other techniques such as
        bundle-in-bundle encapsulation (BIBE) [I-D.ietf-dtn-bibect].



  Sipos                    Expires 6 December 2025                [Page 5]


  Internet-Draft                   BP SAFE                       June 2025


     *  Policies or mechanisms for using BP extension blocks for purposes
        not defined in this document.  Some networks could require
        specific extension blocks to be present for valid traffic.

     *  Policies or mechanisms for issuing Public Key Infrastructure Using
        X.509 (PKIX) certificates; provisioning, deploying, or accessing
        certificates and private keys; deploying or accessing certificate
        revocation lists (CRLs); or configuring security parameters on an
        individual entity or across a network.

  1.2.  Use Cases Considered

     Based on terminology from Section 3.1 of [RFC9171], the four data
     plane interaction points between a BP Agent (BPA) and other entities
     are shown for two agents in Figure 2.  For simplicity that diagram
     shows a situation where there is reachability between the nodes in
     one direction, but typically reachability between nodes would be in
     both directions (via similar or dissimilar convergence layer types
     and/or hop counts).

     Two of the interaction points are with application(s) registered as
     endpoints in the BPA (transmit and deliver) and two are with
     underlying convergence layer(s) used to transport bundles between
     BPAs (forward and receive) for each hop.  Within a BPA there is logic
     about how and when to deliver, forward, retain, delete, discard, or
     some combination of those actions which are defined in Section 5 of
     [RFC9171].  This logic is indicated in later diagrams by the
     "(Decide)" label inside a BPA block.

              +---------------+                  +---------------+
              |   Registered  |                  |   Registered  |
              | Application(s)|                  | Application(s)|
              +---------------+                  +---------------+
                |           ^                      |           ^
        Transmit|           |Deliver       Transmit|           |Deliver
                v           |                      v           |
           +----------------+----+            +----------------+----+
           |                     |            |                     |
           |      BP Agent       |            |      BP Agent       |
           |                     |            |                     |
           +----------------+----+            +----------------+----+
                ^           |                      ^           |
         Receive|           |Forward        Receive|           |Forward
                |           v                      |           v
        ~---------+       +-----------~  ~---------+-+       +--------~
                  |       |     Forwarding Hop(s)    |       |
        ~---------+       +-----------~  ~-----------+       +--------~




  Sipos                    Expires 6 December 2025                [Page 6]


  Internet-Draft                   BP SAFE                       June 2025


                Figure 2: BP Agent data plane interaction points

     This document considers two principal use cases to narrow the scope
     of discussion, each described in the following subsections.  More
     complex use cases can be achieved by this protocol, either by more
     complex interaction with a BPSec entity or the use of techniques such
     as BIBE of [I-D.ietf-dtn-bibect] to perform secure tunneling between
     pairs of security gateway nodes.

  1.2.1.  End-to-End Security

     The end-to-end use case is where the SAFE entities negotiate
     secondary SAs which match endpoints on the participating nodes
     themselves.  This use case corresponds to the end-to-end mode of
     Security Mode Selector (SMS).

     For this mode the bundle flows and security processing will look like
     what is depicted in Figure 3.  The negotiated security service is
     sourced immediately upon bundle creation (after the corresponding ADU
     is transmitted by the source endpoint), has a lifetime equal to the
     bundle itself, and is accepted immediately before bundle delivery (of
     the ADU to the destination endpoint).

                |                                              ^
        Transmit|                                              |Deliver
                v                                              |
           +----+----------------+            +----------------+----+
           |  Source             |            |             Accept  |
           |       \             |            |             /       |
           |       (Decide)      |            |      (Decide)       |
           |              \      |            |      /              |
           |               \     |            |     /               |
           +----------------+----+            +----+----------------+
                            |                      ^
                            |Forward        Receive|
                            v                      |
                          +-----------~  ~---------+-+
                          |     Forwarding Hop(s)    |
                          +-----------~  ~-----------+

                      Figure 3: End-to-End security flows

     The purpose of this mode is to ensure that specific traffic has
     integrity or confidentiality protection for its entire lifetime,
     applied as close to the endpoints as possible.  This protection also
     includes any possible storage at the source and destination nodes.





  Sipos                    Expires 6 December 2025                [Page 7]


  Internet-Draft                   BP SAFE                       June 2025


  1.2.2.  One-Hop Security

     The one-hop use case is where the SAFE entities negotiate secondary
     SAs which match arbitrary endpoints but apply to bundles traversing a
     single hop with a neighbor node.  This use case corresponds to the
     one-hop mode of Security Mode Selector (SMS).

     For this mode the bundle flows and security processing will look like
     what is depicted in Figure 4.  The negotiated security service is
     sourced immediately before forwarding (specifically to the peer node
     of the SA), has a lifetime of just a single bundle hop, and is
     accepted immediately upon reception at that peer node.

                  |                                          ^
          Transmit|                                          |Deliver
                  v                                          |
             +----+----------------+        +----------------+----+
             |     \               |        |               /     |
             |      \              |        |              /      |
             |      (Decide)       |        |       (Decide)      |
             |      /       \      |        |      /       \      |
             |     /       Source  |        |  Accept       \     |
             +----+-----------+----+        +----+-----------+----+
                  ^           |                  ^           |
           Receive|           |Forward    Receive|           |Forward
                  |           v                  |           v
                            +--------------------+-+
                            |    Forwarding Hop    |
                            +----------------------+

                        Figure 4: One-Hop security flows

     The purpose of this mode is to supplement security mechanisms (if
     any) provided by the forwarding convergence layer adapter (CLA).
     This allows the receiving node to authenticate data from the previous
     node during reception, by transitively linking the one-hop security
     back to the mutual authentication and proof-of-possession from the
     Initial Authentication (IA) activity.

  1.3.  Use of CDDL

     This document defines CBOR structure using the Concise Data
     Definition Language (CDDL) of [RFC8610].  The entire CDDL structure
     can be extracted from the XML version of this document using the
     following XPath expression:

     '//sourcecode[@type="cddl"]'




  Sipos                    Expires 6 December 2025                [Page 8]


  Internet-Draft                   BP SAFE                       June 2025


     The following initial fragment defines the top-level symbols of this
     document's CDDL, including the PDU data structure with its parameter/
     result sockets.

     start = safe-pdu-seq / safe-msg / safe-msg-bstr

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

     Terminology used within the SAFE protocol includes the following:

     SAFE Bundle:  A bundle with a source or destination EID having a
        well-known service identifier allocated for SAFE (see Section 12).

     Participating node:  A BP node which sources and/or delivers SAFE
        Bundles via a BP Agent.

     Interaction point (of a BP Agent):  One of the four locations on the
        data plane by which a BP Agent interacts with other entities in a
        BP node.

     Security Association (SA):  An agreed state between two participating
        nodes which contains the result of an authenticated key exchange
        and some number of derived symmetric session keys.

     Activity:  Each SAFE activity consists of a sequence of data being
        exchanged, via protocol messaging, between two nodes to achieve a
        specific narrow goal.

     Message:  Each step of an activity is a message containing a specific
        set of data items.  Each message has a deterministic binary
        encoding using CBOR.  Some messages are constructed as responses
        to earlier messages in an activity and need to be interpreted in
        the context of the whole activity.

     Protocol Data Unit (PDU):  A sequence of messages are aggregated
        together into a single protocol data unit to be exchanged with the
        SAFE entity of a participating peer.  All SAFE PDUs have some kind
        of application-level confidentiality of the contained messages.

     Application Data Unit (ADU):  When supplied to a BP Agent, a SAFE PDU
        is handled as the ADU of a bundle.




  Sipos                    Expires 6 December 2025                [Page 9]


  Internet-Draft                   BP SAFE                       June 2025


     Endpoint Selector (ES):  A filter for BP traffic based on specific
        fields of the bundle primary block or well-known extension block
        types.

  2.  General Protocol Description

     The service of this protocol is the establishment and management of
     one or more secondary security association (SA) between two
     participating peer BP nodes (that may or may not be BP neighbors)
     which are used to inform a BPSec entity on each node how to secure
     specific traffic.

     The initial confidential channel with forward secrecy, mutual
     authentication, and proof-of-possession is provided by an Ephemeral
     Diffie-Hellman Over COSE (EDHOC) session [RFC9528].  The EDHOC
     session also allows using external authorization data (EAD) items to
     confidentially transport SAND messages.

     A side effect of the EDHOC session is the establishment of a primary
     SA between the two peers.  The primary SA provides message
     confidentiality after the initial authentication EDHOC session.
     After a primary SA is established, this protocol allows creating
     secondary SAs through a single 1.5 round-trip activity without re-
     authenticating.  It also allows managing established SAs, including
     symmetric key decommissioning and roll-over, in order to bound keys
     over time and over volume of processed data.

     The concepts and procedures of SAFE are similar in both form and
     function to the IP-level IKEv2 of [RFC7296] and MAC-level Port-Based
     Network Access Control (BPNAC) of [802.1X].  These earlier protocols
     assume a low enough latency that chaining two-way exchanges over time
     is not a resource burden or source of major delay, and that if
     retransmissions are needed they can easily be performed at the
     exchange initiator side.  Because SAFE is expected to operate in
     environments where one-way latency can be significant (see
     [RFC4838]), its structure in Section 4 is organized to avoid a
     sequence-of-exchanges pattern.

     Instead of a two-way request--response pattern where all
     retransmission occurs from the requesting entity, the SAFE pattern is
     an activity sequence where the final message is purely
     acknowledgement that the activity has finished.  SAFE separates its
     messaging sub-layer from its packetization sub-layer (see Section 4)
     to allow messages from multiple simultaneous activities to be
     aggregated together into a single protocol data unit (PDU).  For an
     individual activity sequence this is results in more messages than
     two-way exchanges, but it enables pipelining of messages and
     retransmission from either side of an activity conversation.



  Sipos                    Expires 6 December 2025               [Page 10]


  Internet-Draft                   BP SAFE                       June 2025


  2.1.  Relationship to EDHOC

     This protocol embeds EDHOC as the messaging structure and behavior of
     the Initial Authentication (IA) activity type.  Because the IA
     activity is the very beginning of a conversation between two SAFE
     entities, the packetization behavior during the IA activity is a
     special case containing a single EDHOC message in each PDU.  This
     also means that during the IA activity EDHOC is responsible for
     confidentiality of SAFE data.  After the IA has finished and a
     primary SA is established, confidentiality is provided by an
     application-layer use of COSE encryption (see Section 4.4).

  2.2.  Relationship to BPSec

     The reason for establishing SAs in the first place is to be able to
     provide symmetric session keys to be used by BPSec for security
     operations on individual target blocks within specific bundles as
     described in Section 1.2.  Part of the scoping of each SA includes a
     BPSec security context identifier and its options for which each
     derived symmetric key is authorized to be used.

     A secondary SA is scoped by the following aspects which inform BPSec
     policy on each peer node.

     Security Mode:
        This determines when and where security operations are sourced and
        accepted within the peers.

     Validity Time Interval:
        This bounds the SA to an interval of time.

     Endpoint Selectors:
        This is an EID pattern used to filter by the source and
        destination of bundle traffic.

     Security Operation Selectors:
        This determines the security service (integrity or
        confidentiality) and target block types to secure.

     Key Use Selectors:
        This is a specific BPSec security context and options for using
        that context.









  Sipos                    Expires 6 December 2025               [Page 11]


  Internet-Draft                   BP SAFE                       June 2025


  2.3.  Credential Sources

     In the typical use of IKEv2 [RFC7296], TLS [RFC8446], or DTLS
     [RFC9147] the full credentials (and in the case of PKIX certificates,
     full certificate chains) are carried in the protocol exchanges.
     Because the original target for EDHOC was constrained networks, the
     credentials themselves are purposefully omitted from the EDHOC
     messages and instead only credential identifiers are exchanged
     Section 3.5.3 of [RFC9528].

     Part of the configuration for each SAFE entity is a set of peer
     information (see Section 3.1), each of which contains a set of
     validated credentials and their root-of-trust for that peer.  It is
     still possible for SAFE entities to provide actual credential data,
     which itself is kept confidential as part of the secure channel
     established by EDHOC.

  2.4.  Extensibility

     The protocol defined in this document defines a basic set of modes
     and data types which are expected to be suitable for many bundle
     security use cases.  But the protocol uses extensible IANA registries
     (see Section 12.3) which allow future specifications to define
     additional well-known code points.  And each registry has a reserved
     block to allow private networks to make use of private code points
     tailored to their specific needs.

  3.  Information Bases

     BP SAFE operates by using an activity sequence of messages (see
     Section 5) to establish and maintain security associations between
     pairs of participating nodes.

     There are two logical tiers of SA, primary and secondary, which are
     treated here as two separate information tables.  How these are
     mapped to an actual internal data model is an implementation detail,
     as well as whether an entity treats all SAs together into one pool or
     separates primary and secondary SA data as indicated in this section.

     All private asymmetric key material and all derived PRK and symmetric
     key material is expected to be maintained outside of the SAFE entity
     in some form of trusted execution environment (TEE).  The key
     material is included in these information bases as a logical
     placeholder and to show its association with the other fields.







  Sipos                    Expires 6 December 2025               [Page 12]


  Internet-Draft                   BP SAFE                       June 2025


  3.1.  Participating Peers

     In order to set appropriate retransmission timers, the local entity
     needs to know expected timing information for each participating peer
     node.

        +============+================================================+
        | Name       | Description                                    |
        +============+================================================+
        | Peer EID   | The transport EID for the SAFE entity on the   |
        |            | peer node.                                     |
        +------------+------------------------------------------------+
        | Round-Trip | The expected full round-trip time between a    |
        | Time       | sent message and an acknowledgement.  This     |
        |            | value includes actual one-way-light time       |
        |            | (OWLT) of links as well as expected queuing    |
        |            | and processing delays.                         |
        +------------+------------------------------------------------+
        | Acceptable | A priority list of code points from the "EDHOC |
        | EDHOC      | Cipher Suites" registry of [IANA-EDHOC] which  |
        | Cipher     | are acceptable to use for EDHOC sessions with  |
        | Suites     | this peer.  This value is sent in Message 1    |
        |            | when acting as an EDHOC initiator and          |
        |            | validated when acting as an EDHOC responder.   |
        +------------+------------------------------------------------+
        | TX         | A priority list of acceptable COSE credential  |
        | Credential | types for EDHOC authentication of this node to |
        | Types      | the peer.  Details on this complex field are   |
        |            | described below.                               |
        +------------+------------------------------------------------+
        | Acceptable | A priority list of acceptable COSE credential  |
        | RX         | types for EDHOC authentication of the peer     |
        | Credential | node.  Details on this complex field are       |
        | Types      | described below.                               |
        +------------+------------------------------------------------+

                      Table 1: Participating Peer Columns

     For the two stores of credential types in the Participating Peers
     information base, the detailed information present consists of an
     ordered list of entries, each containing the following.

     Credential Type:
        One of the "COSE Header Parameters" registry values from
        [IANA-COSE] which identifies a credential type:

        *  c5t (22), c5u (23), c5c (25) to identify a C509 certificate
           following the profile of Section 5.1.2



  Sipos                    Expires 6 December 2025               [Page 13]


  Internet-Draft                   BP SAFE                       June 2025


        *  x5t (34), x5u (35), x5chain (33) to identify an X509
           certificate following the profile of Section 5.1.2
        *  kid (4) to identify a pre-shared symmetric key (PSK)
           // leave this in?

     Trust Anchors:
        One or more type-specific root authority credentials to use as
        trust anchors for validating end-entity credentials.

     Validated Credentials:
        A set of credentials which has already been validated in
        accordance with the profile in Section 5.1.2 against the trust
        anchors in this entry.  Each of these credentials is supplied from
        outside of the SAFE entity.  For TX credentials, this represents
        local identity configuration for the peer.  For RX credentials,
        this is from peer discovery or pre-agreement with the peer.

  3.2.  Activity States

     Each SAFE entity maintains a table of in-progress activities and
     their associated metadata, with logical columns as indicated in
     Table 2.

        +=============+==============================================+
        | Name        | Description                                  |
        +=============+==============================================+
        | Initiator   | The transport EID for the initiator of the   |
        |             | activity.  This may be a local endpoint or   |
        |             | remote.                                      |
        +-------------+----------------------------------------------+
        | Responder   | The transport EID for the responder of the   |
        |             | activity.  This will be the opposite site of |
        |             | conversation from the initiator endpoint.    |
        +-------------+----------------------------------------------+
        | Activity    | The index, unique to the initiator, for the  |
        | Index       | activity.                                    |
        +-------------+----------------------------------------------+
        | Last Step   | The step of the activity which is associated |
        | Transmitted | with the last message sent to the peer.      |
        | (LTX)       |                                              |
        +-------------+----------------------------------------------+
        | Last Step   | The step of the activity which is associated |
        | Received    | with the last message received from the      |
        | (LRX)       | peer.  This value is optional for activities |
        |             | initiated by the local entity.               |
        +-------------+----------------------------------------------+

                       Table 2: Activity State Columns



  Sipos                    Expires 6 December 2025               [Page 14]


  Internet-Draft                   BP SAFE                       June 2025


     While the last received step is less than the last sent step, it
     means that the local entity is waiting for an acknowledging message.
     After the final message of an activity is received, the associated
     table row is removed as there is no need to maintain long-term
     bookkeeping of finished activities.
     // TBD about row removal timer and ignoring late duplicate messages.

  3.3.  Primary Security Associations

     Each primary SA allows SAFE entities to provide PDU-level
     confidentiality and is used as the source of a shared secret from
     which secondary SAs can be derived.  The state of each primary SA
     known to the local entity has logical columns as indicated in
     Table 3.  The key information of a primary SA will contain exactly
     one key for each direction
     // TBD.  The primary SA has no specific endpoint selectors because
     each is used for security between the SAFE entities themselves rather
     than any other traffic.

































  Sipos                    Expires 6 December 2025               [Page 15]


  Internet-Draft                   BP SAFE                       June 2025


       +===============+===============================================+
       | Name          | Description                                   |
       +===============+===============================================+
       | Local SAI     | The locally-generated SA identifier for this  |
       |               | entry.                                        |
       +---------------+-----------------------------------------------+
       | Peer EID      | The transport EID for the SAFE entity on the  |
       |               | peer node.                                    |
       +---------------+-----------------------------------------------+
       | Peer SAI      | The peer-generated SA identifier for this     |
       |               | entry.                                        |
       +---------------+-----------------------------------------------+
       | AEAD          | The "application AEAD algorithm" from the     |
       | Algorithm     | EDHOC cipher suite negotiated as part of the  |
       |               | IA activity.  This applies to SAFE            |
       |               | confidential PDU processing defined in        |
       |               | Section 9.1.                                  |
       +---------------+-----------------------------------------------+
       | Hash          | The "application hash algorithm" from the     |
       | Algorithm     | EDHOC cipher suite negotiated as part of the  |
       |               | IA activity.  This applies to the SAFE_KDF    |
       |               | function defined in Section 8.3.              |
       +---------------+-----------------------------------------------+
       | TX Key        | The primary SA has a single symmetric key for |
       | Information   | outgoing PDUs to the Peer EID, as a COSE key  |
       |               | with contents as defined in Section 8.1.  The |
       |               | associated key material is derived from the   |
       |               | shared secret created during an Initial       |
       |               | Authentication (IA) activity.                 |
       +---------------+-----------------------------------------------+
       | RX Key        | The primary SA has a single symmetric key for |
       | Information   | incoming PDUs from the Peer EID, as a COSE    |
       |               | key with contents as defined in Section 8.1.  |
       |               | The associated key material is derived from   |
       |               | the shared secret created during an Initial   |
       |               | Authentication (IA) activity.                 |
       +---------------+-----------------------------------------------+
       | Primary       | Internal key material derived from the EDHOC  |
       | pseudo-random | session for this SA, as the byte string       |
       | key (PRK)     | PRK_SA1 defined in Section 8.1.  This is used |
       |               | to derive further values for secondary SAs as |
       |               | defined in Section 8.3 and context-specific   |
       |               | key derivations.                              |
       +---------------+-----------------------------------------------+

                 Table 3: Primary Security Association Columns





  Sipos                    Expires 6 December 2025               [Page 16]


  Internet-Draft                   BP SAFE                       June 2025


  3.4.  Secondary Security Associations

     Each secondary SA allows SAFE entities to provide key material and
     associated policy configuration to a BPSec entity on the same BP
     node.  The state of each secondary SA known to the local entity has
     logical columns as indicated in Table 4.

     +=============+====================================================+
     | Name        | Description                                        |
     +=============+====================================================+
     | Parent SA   | The primary SA (Table 3) from which this secondary |
     |             | SA was derived, which includes the Peer EID of the |
     |             | other SAFE entity.                                 |
     +-------------+----------------------------------------------------+
     | Local SAI   | The locally-generated SA identifier for this       |
     |             | entry, as defined in Section 6.5.                  |
     +-------------+----------------------------------------------------+
     | Peer SAI    | The peer-generated SA identifier for this entry,   |
     |             | as defined in Section 6.5.                         |
     +-------------+----------------------------------------------------+
     | Security    | This is a mode selector for this SA, as defined in |
     | Mode        | Section 6.8.                                       |
     | Selector    |                                                    |
     +-------------+----------------------------------------------------+
     | Validity    | An optional interval of time during which the SA   |
     | Time        | is valid.  The logic is consistent with the node   |
     | Interval    | time interval (NTI) of Section 6.9.  If absent,    |
     |             | the SA is valid for all time.                      |
     +-------------+----------------------------------------------------+
     | Local       | This is an unordered set of endpoint selector      |
     | Endpoint    | items for the local side of the SA, as described   |
     | Selectors   | below and in Section 6.10.                         |
     +-------------+----------------------------------------------------+
     | Peer        | This is an unordered set of endpoint selector      |
     | Endpoint    | items for the local side of the SA, as described   |
     | Selectors   | below and in Section 6.10.                         |
     +-------------+----------------------------------------------------+
     | Security    | This is a combination of information derived from  |
     | Operation   | the negotiated Security Operation Selectors (SOS)  |
     | Selector    | during the Section 5.3 activity.                   |
     +-------------+----------------------------------------------------+
     | BPSec       | This is a single code point from the "BPSec        |
     | Context ID  | Security Context Identifiers" registry at          |
     |             | [IANA-BUNDLE], which restricts the scope in which  |
     |             | the key can be used and provides context for the   |
     |             | Key Use Selector details below.                    |
     +-------------+----------------------------------------------------+
     | Key Use     | This field represents a set of context-specific    |



  Sipos                    Expires 6 December 2025               [Page 17]


  Internet-Draft                   BP SAFE                       June 2025


     | Options     | options which determine exactly how the SA and its |
     |             | keys are to be used by the BPSec entity on this    |
     |             | node.  The options are negotiated during SA        |
     |             | Creation (SC) as defined in Section 6.12 and per-  |
     |             | context specifications (see Section 9).            |
     +-------------+----------------------------------------------------+
     | Key         | This field represent a set of context-specific key |
     | Information | material and derived options for each direction    |
     |             | between the two peers.  The key material are       |
     |             | derived from the shared secret created during SA   |
     |             | Creation (SC) as defined in Section 8.3 and per-   |
     |             | context specifications (see Section 9).            |
     +-------------+----------------------------------------------------+

               Table 4: Secondary Security Association Columns

     Each endpoint selector item functions as a filter for the BP Agent to
     determine to which bundles the SA applies.  The order in which
     endpoint selectors and other filters are applied to filter bundles
     for security processing is an implementation matter and can be
     optimized to, for example, process the less expensive checks first to
     reduce the average expense of matching.  An implementation is also
     free to perform additional indexing of endpoint selectors across
     multiple SAs to reduce total processing expense.

     Each key use option contains fields necessary to restrict when and
     how the key can be used for BPSec security operations.  The fields of
     each item roughly correspond with a COSE Key from Section 7 of
     [RFC9052] and an implementation can choose to use a COSE Key
     representation if that is convenient.

  4.  Protocol Sub-Layers and Binding

     The SAFE protocol operates with three distinct sub-layers, each with
     a different structure and purpose.  They are described as follows,
     starting from the topmost sub-layer and working down toward the BP
     transport.

     Activity Data:  This sub-layer deals with the encoding of data items
        needed for each step of an activity and with how to progress an
        activity by taking received data from a peer from a previous step
        and generating data for a peer to be used in the next step.  The
        activity data items are handled as a CBOR map using integer
        labels, and each activity type defines the meaning of labels in
        its data items.

     Messaging:  This sub-layer is used to identify each step of each




  Sipos                    Expires 6 December 2025               [Page 18]


  Internet-Draft                   BP SAFE                       June 2025


        specific type of activity and provides the ability to acknowledge
        to a peer that a previous message was received and processed.
        Selective retransmission in SAFE occurs at the messaging sub-layer
        when a timer expires without receiving an acknowledgement.

     Aggregation and Security:  This sub-layer is related to aggregating
        SAFE messages into a single SAFE plaintext with optional padding,
        and then encrypting that into a single SAFE ciphertext.  The use
        of padding allows an entity to ensure that all SAFE plaintext (and
        thus SAFE ciphertext) are the same size and avoid on-path traffic
        analysis.

     Packetization:  This sub-layer is used to embed either a single EDHOC
        message or single SAFE ciphertext along with identification
        metadata into a PDU for transport between SAFE entities.

      +-------------------------------------------+
      | Data Item 1 |      ...      | Data Item N | <- Activity
      +-------------------------------------------+    Data
       \__________________________________       |
                                          \      |
      +-------------------------------------------+
      | Act. Idx. | Act. Step | Act. Type | Data  |
      +-------------------------------------------+
      |                 SAFE Message              | <- Messaging
      +-------------------------------------------+    and Retransmission
       \__           ____________________________/
          \         /
      +-------------------------------------+
      | Msg. 1 bstr |...| Msg. N bstr | pad |      <- Message Aggregation
      +-------------------------------------+
      |                 Plaintext           |
      + ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +
      |                 Ciphertext          + tag | <- Message Security
      +-------------------------------------------+
       \____________________                     |
                            \                    |
      +-------------------------------------------+
      | Version | PIV | SAI | EDHOC / Ciphertext  |
      +-------------------------------------------+
      |                 SAFE PDU                  | <- Packetization
      +-------------------------------------------+
       \___________________________              /
                                   \            /
      +-------------------------------------------+
      |  Bundle                 |  Payload Block  | <- Transport
      +-------------------------------------------+    and Security




  Sipos                    Expires 6 December 2025               [Page 19]


  Internet-Draft                   BP SAFE                       June 2025


                 Figure 5: Breakdown of sub-layers within SAFE

  4.1.  Activity Sequencing

     The contents of a SAFE message allow it to be correlated to a
     specific activity sequence and an individual step within that
     sequence (see Section 4.2 for details).  All steps are numbered
     starting with zero at the initiator of an activity.  The sending of a
     step number greater than zero is also used to acknowledge receipt and
     processing of the message with its preceding step number.  The final
     acknowledgement of an activity is sent without a corresponding data
     payload in order to indicate that it is the end of the sequence.

     Because SAFE allows messages to be aggregated into an PDU, this also
     enables explicit pipelining of multiple activities over a sequence of
     PDUs.  It is an implementation matter to determine when to aggregate
     messages but the patterns defined in Section 7 make use of
     aggregation.

     An example of this pipelining is shown in Figure 6, which depicts a
     series of PDUs sent in opposite direction between two peers "A" and
     "B".  A Initial Authentication (IA) is the first activity, followed
     by a Capability Indication (CI) initiated in the opposite direction,
     and finally a pair of SA Creation (SC) activities initiated opposite
     that.

                        Node A     A     A     A     A
                             |     ^     |     ^     |
                             v     |     v     |     v
                        Node B     B     B     B     B

                        PDU #1    #2    #3    #4    #5
                             |     |     |     |     |
                         (IA 0 --- 1 --- 2 --- 3)    |
                             | (CI 0 --- 1 --- 2)    |
                             |     | (SC 0 --- 1 --- 2)
                             |     | (SC 0 --- 1 --- 2)

                                  =----- time ----->

                       Figure 6: Pipelining of Activities










  Sipos                    Expires 6 December 2025               [Page 20]


  Internet-Draft                   BP SAFE                       June 2025


  4.2.  Message Structure

     Each encoded SAFE message SHOULD use CBOR core deterministic encoding
     requirements from Section 4.2.1 of [RFC8949].  Each SAFE message
     SHALL consist of a CBOR sequence containing the following items.

     Activity Index:  This item is an unsigned integer used to correlate
        multiple messages associated with the same activity.  Each
        activity SHALL be assigned a unique activity index when it is
        started by the initiator.  A default algorithm to assign an
        activity index is to start at index zero for the first activity of
        a conversation and increment by one for each subsequent activity
        in that conversation.

     Activity Step:  This item is an unsigned integer used to distinguish
        messages for each step of an activity.  The activity step value
        SHALL be limited to the inclusive range 0 to 65535.  It is
        expected that most activity types will only involve two or three
        steps with a final acknowledgement, so the meaningful range of
        this value is much lower than the required range.

     Activity Type:  This item is a signed integer used to distinguish the
        purpose of the associated activity and of the data payload which
        follows.  The activity type value SHALL be limited to the
        inclusive range -32768 to 32767.  As defined in Section 12.3,
        positive values are for well-known activities, zero is reserved
        for the IA pseudo-activity (Section 5.1), and negative values are
        reserved for experimental or private use.

     Data Payload:  This item is either a CBOR map or a byte string, used
        to contain data specific to the logical step in the activity
        corresponding to the containing message.

     The combination of Activity Index and Activity Step SHALL uniquely
     identify a message in an activity sequence independently of the type
     of activity being performed.

     The activity index SHALL be unique per initiator and transport
     conversation (_e.g._, unordered pair of source and destination EID).
     The first activity index for a conversation SHALL be zero, and each
     subsequent activity initiated by a peer SHALL increment the activity
     index by one.

     The first step of an activity SHALL be zero, and each subsequent step
     SHALL increment by one.  This means that the initiator of an activity
     can be identified implicitly because it will only send messages with
     an even step number and will only receive messages with an odd step
     number.



  Sipos                    Expires 6 December 2025               [Page 21]


  Internet-Draft                   BP SAFE                       June 2025


     The last message of an activity sequence SHALL NOT contain either an
     activity type or a data payload.  That last message is purely to
     acknowledge the message from the previous step and conclude the
     activity.

     This structure is indicated by the following CDDL for the general
     SAFE message structure and its data item payload.

     safe-msg-bstr = bstr .cborseq safe-msg

     safe-msg = $safe-msg .within safe-msg-struct
     safe-msg-struct = [
         msg-ident,
         ? (
             act-type: int16,
             data-map
         )
     ]

     ; Unique identifier for a single message (one step of one activity)
     msg-ident = (
         act-idx: uint,
         act-step: uint,
     )

     ; activity-type-specific data
     ; non-negative labels are well-known
     ; negative labels are private use
     data-map = {
         * label => value,
     }
     ; Generic map label
     label = int16
     ; Generic map value
     value = any

     ; Signed integer that fits in 16-bit two's complement form
     int16 = (-32768 .. 32767) .within int

  4.3.  States, Deduplication, and Retransmission

     As described in Section 3.2, the state kept by each entity about an
     activity includes the step of the message last sent by the entity
     (LTX) and the step last received from the peer entity (LRX).  Based
     on these two step states, each entity can determine how to make
     progress





  Sipos                    Expires 6 December 2025               [Page 22]


  Internet-Draft                   BP SAFE                       June 2025


     An example of this logic is shown in Figure 7.  The state notation of
     {LTX,LRX} indicates the LTX and LRX steps respectively and negative
     values are used as a placeholder for an invalid/absent step number.
     If a transition has a specific trigger, it is indicated by square
     bracket text.

                  Initiator                         Responder
             +-----------------+               +-----------------+
             |                 |               |                 |
             | {-1,-1} Start   |               | {-1,-1} Start   |
             |                 |     Step 0    |                 |
             +--------+--------+    Message    +--------+--------+
           Re-TX      |            ident+data     [RX 0]|
          +--------+  | TX 0    ~~~~~~~~~~~~~~>         |
          |        v  v                                 v
          |  +-----------------+               +-----------------+
          |  |                 |               |                 |
          +--+ { 0,-1} Wait    |               | {-1, 0} Process |
      [timer]|                 |     Step 1    |                 |
             +--------+--------+    Message    +--------+--------+
                      |[RX 1]      ident+data           |         Re-TX
                      |         <~~~~~~~~~~~~~~    TX 1 |  +--------+
                      v                                 v  v        |
             +-----------------+               +-----------------+  |
             |                 |               |                 |  |
             | { 0, 1} Process |               | { 1, 0} Wait    +--+
             |                 |     Step 2    |                 |[timer]
             +--------+--------+    Message    +--------+--------+
                      |              ident        [RX 2]|
                      | TX 2    ~~~~~~~~~~~~~~>         |
                      v                                 v
             +-----------------+               +-----------------+
             |                 |               |                 |
             | { 2, 1} Finished|               | { 1, 2} Finished|
             |                 |               |                 |
             +--------+--------+               +--------+--------+
                      |[timer]                   [timer]|
                      v                                 v
             +-----------------+               +-----------------+
             |                 |               |                 |
             | {-1,-1} Removed |               | {-1,-1} Removed |
             |                 |               |                 |
             +-----------------+               +-----------------+

           Figure 7: Example activity states for a two-step activity






  Sipos                    Expires 6 December 2025               [Page 23]


  Internet-Draft                   BP SAFE                       June 2025


     Based on an existing activity state (Section 3.2) when the last LTX
     step is less than the LRX step, or when the initiator starts the
     activity, or an associated retransmission timer expires, the entity
     SHALL perform the following:

     1.  Compute the next step number as one more than the LRX step, if
         valid, or zero if the initiator has just started the activity.

     2.  If the next step is within the number of steps for this activity
         type, generate type-specific data items based on the activity
         type and next step.

         Otherwise, only the message identity is present and no activity
         type or data items are needed.

     3.  Encode and store an encoded SAFE message.

     4.  Send the SAFE message within a PDU (possibly combining with other
         messages to the same peer entity).

     5.  Update the LTX step to correspond with the sent message.

     6.  If either the LTX or LRX step are beyond the number of steps for
         this activity type, the activity is in the finished state.

         Otherwise, begin a retransmission timer correlated to the
         activity index with a duration taken from the expected round-trip
         time between the peer node plus some optional additional margin.
         It is an implementation matter to determine the specific margin
         added to the expected round-trip duration.

     Upon receiving a SAFE message from a peer, an entity SHALL perform
     the following:

     1.  Decode at least the message identity (to be able to look up the
         activity state)

     2.  Determine which role this entity is performing by inspecting the
         step number: even steps are sent by the initiator and odd steps
         are sent by the responder

     3.  Use the peer EID and activity index to look up the specific
         activity state (Section 3.2) corresponding to the message

     4.  If the received message has a step less than or equal to the LRX
         of the activity state, it is ignored and this procedure is
         terminated




  Sipos                    Expires 6 December 2025               [Page 24]


  Internet-Draft                   BP SAFE                       June 2025


     5.  If present, decode and process the activity type and type-
         specific data items

     6.  Update the LRX step to correspond with the received message

     7.  If either the LTX or LRX step are beyond the number of steps for
         this activity type, the activity is in the finished state.

  4.4.  Message Aggregation and Security

     Because SAFE is used to provide BPSec key material, the security
     properties of a SAFE bundle are more complex than other BP flows
     might be.  For example, the bundles carrying Initialization messages
     need to be transported as plaintext payload (with intrinsic EDHOC
     protections) while other SAFE bundles need to be protected by the
     keys from a primary SA (negotiated as part of the EDHOC sequence).

     The structure of a SAFE PDU is a CBOR sequence of the SAFE version
     number followed by header items and then payload items.  The protocol
     in this document SHALL be identified by version number 1.  The
     version specific header defined in this document SHALL be the
     following:

     Partial IV:  A partial initialization vector (IV) byte string or null
        value

     Receiver SAI:  A receiver security association identifier (SAI) byte
        string or integer (based on EDHOC compressed byte string encoding)
        or true value

     When the Partial IV is null, the payload SHALL be one of the EDHOC
     messages defined in [RFC9528] and handled in accordance with
     Section 5.1.  When the Receiver SAI is true, the payload SHALL be a
     Message 1 as defined in Section 5.2 of [RFC9528].  All other Receiver
     SAI values SHALL be treated as a connection identifier, encoded in
     accordance with Section 3.3.2 of [RFC9528], used to correlate with an
     existing EDHOC session.

     When the Partial IV is a byte string, the payload SHALL be a SAFE
     ciphertext and handled in accordance with Section 9.1.2.  In this
     case, Receiver SAI values SHALL be decoded as and treated as a
     Security Association Identifier (SAI) used to correlate with the
     Local SAI of a Primary SA (see Table 3) on the receiving entity.

     This is indicated by the following CDDL for the SAFE bundle PDU
     sequence.





  Sipos                    Expires 6 December 2025               [Page 25]


  Internet-Draft                   BP SAFE                       June 2025


     ; Encoded to PDU as CBOR sequence
     safe-pdu-seq = [
         version: 1,
         ; PDU variants follow the same structure with unique prefix items
         safe-pdu-edhoc // safe-pdu-confidential,
     ]

     safe-pdu-edhoc //= (
         partial-iv: null,
         rx-sai: true,
         ; Group message_1 from RFC 9528
         message_1
     )
     safe-pdu-edhoc //= (
         partial-iv: null,
         rx-sai: safe-sai,
         edhoc_234 // error
     )
     ; Equivalent to (message_2 // message_3 // message_4) from RFC 9528
     ; Encoded SAFE messages can be present in EAD items
     edhoc_234 = bstr

     safe-pdu-confidential //= (
         partial-iv: bstr,
         rx-sai: safe-sai,
         ; Ciphertext data corresponding to safe-pdu-plaintext below
         ciphertext: bstr
     )

     ; A sequence of encoded-message bstr with optional tagged padding
     safe-pdu-plaintext = (+ safe-msg-bstr, ? safe-padding)
     safe-padding = #6.55799(bstr)

     safe-pdu-aad = (
       rx-sai: safe-sai
     )

                       Figure 8: SAFE PDU structure CDDL

     Within restrictions defined for each message type, multiple messages
     MAY be combined into a single PDU (as either EDHOC EAD or SAFE
     plaintext).  Due to the logic of the Initial Authentication (IA)
     sequencing, only one EDHOC session can make progress between two
     endpoints at any time so there is no concept of an EDHOC message
     embedded within an EAD item.






  Sipos                    Expires 6 December 2025               [Page 26]


  Internet-Draft                   BP SAFE                       June 2025


  4.5.  PDU Transport

     Each SAFE PDU is handled an application data unit (ADU) of a BPv7
     bundle, referred to as a "SAFE bundle" in this document.  Additional
     constraints, controllability, and visibility on transport parameters
     are defined in the following subsection.

     Both the source and destination EID, defined in Section 4.3.1 of
     [RFC9171], for a SAFE bundle SHALL be singleton.  The source EID for
     SAND bundles SHALL NOT be a null EID.  Each endpoint for SAND
     messaging needs to be an identified singleton.  The bundle source and
     destination EID for received bundles SHALL be exposed to the SAND
     application in order to support message exchange sequencing.

     When using the IPN scheme, the EIDs used as source and/or destination
     SHOULD use the well-known service number defined in Section 12.1.
     SAFE applications can use other schemes and service numbers, but such
     configuration is an implementation and deployment matter.

     The bundle creation timestamp (both DTN time and sequence number),
     defined in Timestamp Section 4.3.1 of [RFC9171], for received bundles
     SHALL be exposed to the SAND application to allow it to order
     received SAND bundles.

  5.  Activity Types

     This section defines the initial types of activity which make use of
     SAFE message (Section 4.2) sequencing to exchange data.

     Any current or future activity type SHALL define how many steps
     comprise a single sequence of messages and what is the required data
     payload of each step.

  5.1.  Initial Authentication (IA)

     This activity is used to establish an initial shared secret between
     two SAFE endpoints which don't already have a usable SA, or when re-
     authentication is deemed necessary by either side of an existing SA.

     Because this is the initializing activity for all other SAFE
     interactions, and occurs outside of any pre-existing SA, it does not
     follow the same message structure as other SAFE activities but it
     does use the same local progress bookkeeping and retransmission logic
     (from Section 4.3).  The retransmission logic and the BP transport of
     Section 4 satisfies the EDHOC requirements of Section 3.4 of
     [RFC9528].





  Sipos                    Expires 6 December 2025               [Page 27]


  Internet-Draft                   BP SAFE                       June 2025


     Even though the Initial Authentication (IA) activity does not follow
     the same messaging structure, it does have an activity identifier
     allocated to it in Table 22 to allow its state to be tracked in
     accordance with Section 3.2.  The IA activity SHALL be identified by
     activity type 0.

     Only one instance of this activity SHOULD be in progress at any time.
     The data of each PDU for the PI activity SHALL contain an EDHOC
     message as defined in Section 5 of [RFC9528].

     The sequence of steps and their data for this activity are the
     following:

     *  Step 0: The PDU payload is an EDHOC Message 1 sequence.

     *  Step 1: The PDU payload is an EDHOC Message 2 byte string.

     *  Step 2: The PDU payload is an EDHOC Message 3 byte string.

     *  Step 3: The PDU payload is an EDHOC Message 4 byte string.

     During transport, PI PDUs SHALL NOT be the target of a BPSec
     confidentiality operation between the participating (source and
     destination) nodes.  The use of application-level confidentiality
     ensures the security of information exchanged via this PDU.  There is
     no restriction on any intermediate security handling of SAFE PDUs
     between the participating nodes.

     The CDDL corresponding to this activity type are the first two
     variations of safe-pdu-data from Section 4.4.  Additionally, the
     _EAD_ payload of the EDHOC messages are extended to be able to carry
     encoded SAFE messages during the IA activity based on the safe-msg-
     bstr rule defined in Section 4.2.

  5.1.1.  EDHOC Requirements

     After receiving the ID_CRED_x values from a peer, each SAFE entity
     SHALL

     When the Message 2 payload is received by the initiator, both peers
     have established an EDHOC shared secret but only the responder has
     sent an identity to authenticate with the initiator.  When the
     Message 3 payload is received by the responder, both peers have
     authenticated each other and established an application AEAD
     symmetric key and exporter state.






  Sipos                    Expires 6 December 2025               [Page 28]


  Internet-Draft                   BP SAFE                       June 2025


     Upon the first reception or transmission of IA step 2 (_i.e._, EDHOC
     message_3), the entity SHALL create a primary SA based on the data
     derived in Section 8.1.

  5.1.2.  PKIX Profile


     // TBD based on Section 4 of [I-D.ietf-dtn-bpsec-cose]

  5.2.  Capability Indication (CI)

     This activity allows each entity to indicate its SAFE-related
     capabilities to its peer.  The Capability Indication (CI) activity
     SHALL be identified by activity type 2.

     The sequence of steps and their data for this activity are the
     following:

     *  Step 0: The payload is a map containing data items as defined
        below.  Each item expresses a capability of the initiator entity.

     *  Step 1: The payload is a map containing data items as defined
        below.  Each item expresses a capability of the responder entity.

     *  Step 2: No payload, message is acknowledgement.

             +=======+===========================================+
             | Label | Type                                      |
             +=======+===========================================+
             | 1     | A Concurrent Activity Support (CAS) limit |
             +-------+-------------------------------------------+
             | 2     | An EID Scheme Support (ESS) list          |
             +-------+-------------------------------------------+
             | 3     | A BPSec Context Support (BCS) list        |
             +-------+-------------------------------------------+

                             Table 5: CI Data Items

     ci-data = { * $$ci-data } .within data-map

     $$ci-data //= (1: concur-act-limit)
     $$ci-data //= (2: eid-scheme-list)
     $$ci-data //= (3: bpsec-ctxid-list)








  Sipos                    Expires 6 December 2025               [Page 29]


  Internet-Draft                   BP SAFE                       June 2025


  5.3.  SA Creation (SC)

     This activity is used to create a new SA from within the context of
     an existing primary SA.  The SA Creation (SC) activity SHALL be
     identified by activity type 3.

     The sequence of steps and their data for this activity are the
     following:

     *  Step 0: The payload is a map containing data items as defined
        below.  Some items (notably ESI, ESR, and KUS) MAY contain
        multiple proposals to allow the responder a selection.

     *  Step 1: The payload is a map containing data items as defined
        below.  All items SHALL contain only a single proposal each.

     *  Step 2: No payload, message is acknowledgement.

     The responder items with proposals SHALL be a logical subset of the
     initiator-provided proposals.  The Secondary SA SHALL be configured
     to use a logical intersection between the items provided by the
     initiator and by the responder.  For some cases of EID patterns, the
     intersection can be derived as a single pattern generated from the
     initiator and responder options.  But for more complex cases, the
     intersection needs to be represented as a logical AND between the two
     separate patterns.

























  Sipos                    Expires 6 December 2025               [Page 30]


  Internet-Draft                   BP SAFE                       June 2025


       +=======+======================================================+
       | Label | Type                                                 |
       +=======+======================================================+
       | 0     | Error indications per Section 6.1 for messages after |
       |       | step 0                                               |
       +-------+------------------------------------------------------+
       | 1     | The local SAI per Section 6.5 for the SA which does  |
       |       | not yet exist                                        |
       +-------+------------------------------------------------------+
       | Options for key material derivation                          |
       +-------+------------------------------------------------------+
       | 2     | An Additional Key Exchange (AKE) public key value    |
       +-------+------------------------------------------------------+
       | 3     | An Additional Random Nonce (ARN) value               |
       +-------+------------------------------------------------------+
       | Options for when to use the SA                               |
       +-------+------------------------------------------------------+
       | 9     | A Security Mode Selector (SMS) value                 |
       +-------+------------------------------------------------------+
       | 6     | One or more Endpoint Selectors (ESx) proposals for   |
       |       | the initiator side                                   |
       +-------+------------------------------------------------------+
       | 7     | One or more Endpoint Selectors (ESx) proposals for   |
       |       | the responder side                                   |
       +-------+------------------------------------------------------+
       | 8     | A Node Time Interval (NTI) used as the SA validity   |
       |       | time interval                                        |
       +-------+------------------------------------------------------+
       | Options for how to use the SA                                |
       +-------+------------------------------------------------------+
       | 4     | A Security Operation Selectors (SOS) with conditions |
       |       | for sourcing and accepting BPSec security            |
       +-------+------------------------------------------------------+
       | 5     | A Key Use Selectors (KUS) for a specific BPSec       |
       |       | context, which contains one or more set of key use   |
       |       | options as defined in Section 9                      |
       +-------+------------------------------------------------------+

                       Table 6: SA Creation Data Items












  Sipos                    Expires 6 December 2025               [Page 31]


  Internet-Draft                   BP SAFE                       June 2025


     sc-data = {* $$sc-data } .within data-map

     ; Error codes from the responder
     $$sc-data //= (0: safe-ete)
     ; SAI for the sender
     $$sc-data //= (1: safe-sai)

     ; Optional PRF parameters
     $$sc-data //= (2: safe-ake)
     $$sc-data //= (3: safe-arn)

     ; Initiator side endpoint selectors
     $$sc-data //= (6: safe-esx)
     ; Responder side endpoint selectors
     $$sc-data //= (7: safe-esx)
     ; Time limit for the SA
     $$sc-data //= (8: safe-nti)

     ; BPSec Context and its options for how to use the keys
     $$sc-data //= (4: safe-kus)

     Upon the first reception or transmission of SC step 1, the entity
     SHALL create a secondary SA based on the data derived in Section 8.3.

  5.4.  SA Rekey (SR)

     This activity is used to establish a new set of derived key (and
     possibly other) material within an existing SA without changing the
     other parameters of the SA (_e.g._, algorithm choice or endpoint
     selectors).  The SA Rekey (SR) activity SHALL be identified by
     activity type 4.

     The sequence of steps and their data for this activity are the
     following:

     *  Step 0: The payload is a map containing data items as defined
        below.

     *  Step 1: The payload is a map containing data items as defined
        below.

     *  Step 2: No payload, message is acknowledgement.









  Sipos                    Expires 6 December 2025               [Page 32]


  Internet-Draft                   BP SAFE                       June 2025


             +=======+===========================================+
             | Label | Type                                      |
             +=======+===========================================+
             | 1     | The local SAI per Section 6.5             |
             +-------+-------------------------------------------+
             | 2     | A key exchange public key per Section 6.6 |
             +-------+-------------------------------------------+
             | 3     | A random nonce per Section 6.7            |
             +-------+-------------------------------------------+

                          Table 7: SA Rekey Data Items

     sr-data = {* $$sr-data } .within data-map

     ; Error codes from the responder
     $$sr-data //= (0: safe-ete)
     ; SAI for the sender
     $$sr-data //= (1: safe-sai)

     ; Optional PRF parameters
     $$sr-data //= (2: safe-ake)
     $$sr-data //= (3: safe-arn)

     Upon the first reception or transmission of SR step 1, the entity
     SHALL correlate the Local SAI of a Primary SA or Secondary SA and
     rekey it based on the data derived in Section 8.2 or Section 8.4
     respectively.

  5.5.  SA Teardown (ST)

     This activity is used to negotiate removal of an established SA from
     both entities.  The SA Teardown (ST) activity SHALL be identified by
     activity type 5.

     The sequence of steps and their data for this activity are the
     following:

     *  Step 0: The payload is a map containing data items as defined
        below.

     *  Step 1: The payload is a map containing data items as defined
        below.

     *  Step 2: No payload, message is acknowledgement.







  Sipos                    Expires 6 December 2025               [Page 33]


  Internet-Draft                   BP SAFE                       June 2025


                   +=======+===============================+
                   | Label | Type                          |
                   +=======+===============================+
                   | 1     | The local SAI per Section 6.5 |
                   +-------+-------------------------------+

                        Table 8: SA Teardown Data Items

     st-data = {* $$st-data } .within data-map

     ; Error codes from the responder
     $$st-data //= (0: safe-ete)
     ; SAI for the sender
     $$st-data //= (1: safe-sai / true)

  5.6.  Event Notification (EN)


     // TBD This activity is used by the initiator to inform the peer
     entity of an event.  The Event Notification (EN) activity SHALL be
     identified by activity type 7.

     en-data = {* $$en-data } .within data-map

     $$en-data //= (1: en-cause)
     en-cause = [msg-ident]

  6.  Data Item Types

     This section defines the initial set of data items which can be
     present as the data payload of a SAFE message (Section 4.2).

     Some types of data item allow the activity initiator to provide
     multiple independent proposals, from which the responder can either
     choose one proposal or create a new single proposal which narrows
     down from one provided by the initiator.  It is the responsibility
     for each data item type to define detailed logic of acceptable
     responder proposals.  Each proposal SHALL take the form of a CBOR
     map.  When multiple proposals are present, they SHALL take the form
     of a CBOR array of proposal maps.

     safe-proposals = [data-map] / [+ data-map]









  Sipos                    Expires 6 December 2025               [Page 34]


  Internet-Draft                   BP SAFE                       June 2025


  6.1.  Error Type Enumeration (ETE)

     The Error Type Enumeration (ETE) data item is used by its sender to
     signal a failure to process a message or make progress in an
     activity.  The ETE value SHALL be an integer limited to the inclusive
     range -32768 to 32767.

     These values are used in many activities to indicate a failure in
     decoding, processing, or consistency of received message contents.
     Well-known error values are non-negative and registered in
     Section 12.3.  Private and experimental use error values are negative
     and not registered.

     safe-ete = [+ safe-error]
     safe-error = int16

  6.2.  Concurrent Activity Support (CAS)

     This data item indicates how many concurrent (pipelined) SAFE
     activities the sender of the item supports.  The minimum number of
     concurrent activities supported SHALL be 2.  This is necessary in
     order to enable the processing of Capability Indication (CI)
     containing this data item during the Initial Authentication (IA)
     messaging.  The maximum number of concurrent activities supported
     SHALL be 1024.  This is an arbitrary upper bound not expected to be
     encountered during normal operations.

     An attempt by a peer to send messages associated with more than this
     limit

     concur-act-limit = 2 .. 1024

  6.3.  EID Scheme Support (ESS)

     This data item indicates which EID schemes the sender of the item
     supports.  Schemes are identified by the code points from the "Bundle
     Protocol URI Scheme Types" registry at [IANA-BUNDLE], which includes
     a block reserved for private-use.  Expressing support for an EID
     scheme indicates that the node can handle EIDs of that scheme and EID
     Patterns with scheme-specific parts.

     eid-scheme-list = [+ eid-scheme]
     ; Unrestricted per RFC 9171
     eid-scheme = uint







  Sipos                    Expires 6 December 2025               [Page 35]


  Internet-Draft                   BP SAFE                       June 2025


  6.4.  BPSec Context Support (BCS)

     This data item indicates which BPSec contexts the sender of the data
     item supports.  Schemes are identified by the code points from the
     "BPSec Security Context Identifiers" registry at [IANA-BUNDLE], which
     includes a block of negative values reserved for private-use.
     Expressing support for a security context indicates that the node can
     handle sourcing, verifying, and accepting security blocks using that
     context.

     bpsec-ctxid-list = [+ bpsec-ctxid]
     ; Restricted domain per RFC 9172
     bpsec-ctxid = -32768 .. 32767

  6.5.  Security Association Identifier (SAI)

     The Security Association Identifier (SAI) data item is used by both
     sides of an SA to uniquely identify the SA within each entity.  This
     means that a single SA has two SAIs used to identify it, one from
     each entity.

     An SAI SHALL be treated as an opaque byte string as its internal
     representation and comparison logic.  An SAI SHALL have the same
     compressed encoding rules as EDHOC connection identifiers as defined
     in Section 3.3.2 of [RFC9528].

     safe-sai = bstr / -24..23

  6.6.  Additional Key Exchange (AKE)

     This data item indicates the public key of the sender for an
     additional ECDH exchange to add forward secrecy to a secondary SA.
     When sent by the activity initiator this is a request for additional
     key exchange, and when sent by the responder this is the confirmation
     that a key exchange is supported and desired.  The algorithm and
     parameters related to key exchange are taken from the cipher suite
     negotiated by the primary SA.

     ; The compressed public key for the same algorithm as the primary SA
     safe-ake = bstr

  6.7.  Additional Random Nonce (ARN)

     This data item provides a random nonce value from the sender to add
     entropy into the PRF used during SA Creation (Section 5.3) and SA
     Rekey (Section 5.4) to generate SA data.  The data value SHALL be a
     byte string with a size in the inclusive range 1 to 256 bytes.




  Sipos                    Expires 6 December 2025               [Page 36]


  Internet-Draft                   BP SAFE                       June 2025


     safe-arn = bstr .size (1..256)

  6.8.  Security Mode Selector (SMS)

     This data item controls how the secondary SA is used in the BP data
     plane by the BPSec entity in each participating node.  This data
     value SHALL be an integer limited to the inclusive range -32768 to
     32767.

     Based on the discussion in Section 1.2 this document defines two
     modes: end-to-end (1) and one-hop (2).  The behavior of these modes
     is defined in Section 9.2.  Future specifications can add additional
     mode code points with different behavior.

     safe-sms = secondary-sa-mode .within int16
     secondary-sa-mode = &(
         end-to-end: 1,
         one-hop: 2,
     )

  6.9.  Node Time Interval (NTI)

     This data item filters on the current DTN time of the node hosting
     the SAFE entity.  The type is used to limit the validity time of the
     associated SA, but requires synchronization of time between the two
     peers to perform properly.  The start time can be the current time to
     allow immediate use of the SA or can be in the future to pre-
     establish an SA meant to be used later on.  An entity can use NTI in
     multiple SCs, possibly using concurrent SC activities, to establish a
     chain of SAs each spanning a small time interval that together spans
     a large time interval.

     The NTI value SHALL consist of a start time and an end time.  The SA
     established with an NTI value SHALL be valid at an after the start
     time (inclusive), and only before the end time (exclusive).


     // relocate this to secondary SA info section?  Multiple SAs between
     the same two peers with the same mode and endpoint selectors MAY have
     validity NTIs which overlap in time.  In that case, it is an
     implementation matter to choose which SA to use for securing traffic.
     // prefer lexicographic lower SAI?

     ; Using DTN time as reported by the local BP node
     safe-nti = [
         begin: dtn-time,
         end: dtn-time
     ]



  Sipos                    Expires 6 December 2025               [Page 37]


  Internet-Draft                   BP SAFE                       June 2025


  6.10.  Endpoint Selectors (ESx)

     This data item is used to determine which individual bundles will
     correlate with a secondary SA by comparing their source and
     destination EIDs to patterns.  There is a separate endpoint selector
     applied to the initiator and responder side of a secondary SA, where
     each side selects on the source EID for traffic being forwarded from
     that node and destination EID for traffic being received by that
     node.

     This selector filters on the Source or Destination of the bundle
     contained in its primary block (see Section 4.3.1 of [RFC9171]).  The
     pattern can, but doesn't need to, include the EIDs from the node to
     which it applies (see Section 1.2).

     The value of this data item consists of one or more EID Pattern in
     accordance with [I-D.ietf-dtn-eid-pattern], as indicated by the
     following CDDL.  When multiple patterns are present they each
     represent an alternate proposal provided by the initiator and chosen
     by the responder of an activity.

     safe-esx = eid-selectors .within safe-proposals
     eid-selectors = embed-eid-pattern / [+ embed-eid-pattern]

  6.11.  Security Operation Selectors (SOS)

     This data item controls how the node of each SAFE endpoint applies
     BPSec security operations to traffic selected for handling by the
     secondary SA.

     The SOS value SHALL be an array with the following items.

     1.  A list of target block types to which the security will be
         applied.  Block type zero SHALL be used to refer to the primary
         block.

     2.  The type of security service being sourced by the forwarding
         entity and accepted by the receiving entity.  This value is
         either integrity (1) or confidentiality (2), as defined in
         [RFC9172].











  Sipos                    Expires 6 December 2025               [Page 38]


  Internet-Draft                   BP SAFE                       June 2025


     safe-sos = [
         target-block-types: [+ bpv7-block-type],
         service: bpsec-service,
     ]
     ; Type consistent with RFC 9171
     bpv7-block-type = uint
     ; Services available in RFC 9172
     bpsec-service = &(
         integrity: 1,
         confidentiality: 2,
     )

  6.12.  Key Use Selectors (KUS)

     This data item is used to negotiate the purpose(s) for which an SA-
     derived symmetric key can be used by each side of the SA.

     The KUS value is an array with the following items.

     1.  A single BPSec Context Identifier value in accordance with the
         registry in [IANA-BUNDLE].

     2.  One or more maps of context-specific options, each representing
         an alternate proposal provided by the initiator and chosen by the
         responder of an activity.  The interpretation of these options is
         specific to each BPSec Context ID.  The initial set of supported
         contexts is defined in Section 9.

     safe-kus = $safe-kus .within safe-kus-struct
     safe-kus-struct = [
         ctxid: bpsec-ctxid,
         options: data-map / [+ data-map] .within safe-proposals
     ]

     Some examples of what KUS options can be defined by each Context
     binding are: a specific algorithm identifier or an choice of
     additional authenticated data (AAD) outside the security target
     block.

  7.  Activity Patterns

     The packetization form defined in Section 4 allows multiple messages
     to be combined into a single ADU but this behavior is limited by
     support for the receiving entity, as defined and communicated in the
     Concurrent Activity Support (CAS) data item.  Two examples of how
     this parameter affects activity sequencing is shown in Figure 9 for a
     large CAS limit and Figure 10 for a constraining limit of two.




  Sipos                    Expires 6 December 2025               [Page 39]


  Internet-Draft                   BP SAFE                       June 2025


     PDU #1    #2    #3    #4    #5
          |     |     |     |     |
      (IA 0 --- 1 --- 2 --- 3)    |
          | (CI 0 --- 1 --- 2)    |
          |     | (SC 0 --- 1 --- 2)
          |     | (SC 0 --- 1 --- 2)
          |     | (SC 0 --- 1 --- 2)

               =----- time ----->

                   Figure 9: Pipelining with large CAS limit

     PDU #1    #2    #3    #4    #5    #6    #7    #8    #9    #10
          |     |     |     |     |     |     |     |     |     |
      (IA 0 --- 1 --- 2 --- 3)(SC 0 --- 1 --- 2)(SC 0 --- 1 --- 2)
          | (CI 0 --- 1 --- 2)(SC 0 --- 1 --- 2)

               =----- time ----->

                   Figure 10: Pipelining with small CAS limit

     Regardless of how activities are aggregated into specific ADUs, the
     following requirements apply to ordering of activities related to a
     single primary SA.

     When no primary SA exists between two SAFE application endpoints, the
     first messaging between those applications SHALL be Initial
     Authentication (IA) used to progress the activity state and establish
     a primary SA.  After a primary SA exists, either side of the SA MAY
     choose to initialize a new primary SA and re-authenticate with its
     peer.

     Only after the first step of the IA activity has been received, the
     responder for the IA activity SHALL begin a Capability Indication
     (CI) activity.  This CI activity MAY begin immediately upon sending
     of the second IA step, or MAY wait until after the IA activity has
     completed and a primary SA is established.

     Only after the first step of the CI activity has been received, the
     initiator for the IA activity SHOULD begin any number of needed SA
     Creation (SC) activities.  Only after the second step of the CI
     activity has been received, the responder for the IA activity SHOULD
     begin any number of needed SA Creation (SC) activities.  The number
     of concurrent SC activities allowed to be started at each step is
     limited by the CAS limit for the receiving peer.






  Sipos                    Expires 6 December 2025               [Page 40]


  Internet-Draft                   BP SAFE                       June 2025


                         +-----------+
                         |   Start   |
                         +-----+-----+
                     IA step 0 |
                               |
                       +-------v--------+
                       |                |
                       |  Initializing  <---.
                       |                |   |
                       +-------+---+----+   | IA step 1-2
                     IA step 3 |   |        |
                               |   '--------`
                               |
                       +-------v--------+
                       |                |
                       |   Established  <---.
                       |                |   | SA Rekey
                       +-------+------+-+   | (optional)
                     ST step 0 |      |     |
                               |      '-----`
                         +-----v-----+
                         | Half Down |
                         +-----------+
                     ST step 1 |
                         +-----v-----+
                         |  Removed  |
                         +-----------+

                   Figure 11: Notional States of a Primary SA

  8.  Shared Secret Derivations

     Within the Initial Authentication (IA) activity, a shared secret is
     established and internal pseudo-random keys (PRKs) for EDHOC
     processing are derived.  One of the final PRKs, the PRK_exporter, is
     used for "EDHOC application" purposes which in this case means SAFE
     entity use.

  8.1.  Primary SA Creation

     The primary SA is used to manage derived data for two independent
     purposes: key parameters for message security between the SAFE
     endpoints themselves, and as the PRK shared secret used to derive
     secondary SAs between the two SAFE entities.







  Sipos                    Expires 6 December 2025               [Page 41]


  Internet-Draft                   BP SAFE                       June 2025


     The primary SA key uses take the form of COSE key objects as defined
     in Section 7 of [RFC9052].  Because the acceptable algorithms are
     limited to AEAD encryption, the acceptable operations for each key in
     each entity are one of: encrypt (3), or decrypt (4).

     When the COSE algorithm is one of the AEAD algorithms, the COSE key
     SHALL contain the following parameters.  Notably, these keys do not
     contain a kid parameter because they are not intended to be
     referenced from outside of the SAFE entity managing the primary SA.

     kty (1):
        The value Symmetric (4).

     alg (3):
        The negotiated "application AEAD algorithm" from the IA activity.

     key_ops (4):
        Either encrypt (3) if this entity is the IA initiator and the key
        is for traffic from the initiator side, or decrypt (4) otherwise

     Base IV (5):
        Either BIV_IR (from Figure 12) if the key is for traffic from the
        initiator side, or BIV_RI otherwise

     k (-1):
        Either K_IR (from Figure 12) if the key is for traffic from the
        initiator side, or K_RI otherwise

     Pseudocode used to explain this is shown in Figure 12, where the
     named parameters are:

     key_length:  The length of the encryption key for the "application
        AEAD algorithm" of the EDHOC cipher suite.

     iv_length:  The length of the initialization vector for the
        "application AEAD algorithm" of the EDHOC cipher suite.

     hash_length:  The length of output size of the "application hash
        algorithm" of the EDHOC cipher suite.

     K_IR   = EDHOC_Exporter(TBA4, 'key_ir', key_length)
     BIV_IR = EDHOC_Exporter(TBA4, 'biv_ir', iv_length)

     K_RI   = EDHOC_Exporter(TBA4, 'key_ri', key_length)
     BIV_RI = EDHOC_Exporter(TBA4, 'biv_ri', iv_length)

     PRK_SA1 = EDHOC_Exporter(TBA4, 'prk_sa1', hash_length)




  Sipos                    Expires 6 December 2025               [Page 42]


  Internet-Draft                   BP SAFE                       June 2025


                         Figure 12: Primary SA Creation

     The "_ir" derived values apply to SAFE traffic from the initiator to
     the responder of the IA activity, and the "_ri" derived values apply
     to SAFE traffic in the other direction.

  8.2.  Primary SA Rekey

     This procedure is based on the example from Appendix H of [RFC9528].


     context_rekey = ARN(i) | ARN(r) | G_XY
     PRK_out, PRK_exporter = EDHOC_KeyUpdate(context_rekey)

                          Figure 13: Primary SA Rekey

  8.3.  Secondary SA Creation

     An application-level derivation function SAFE_KDF is defined with the
     same logic as the EDHOC_KDF in Section 4.1.2 of [RFC9528] except
     using the "application hash algorithm" of the EDHOC cipher suite.
     This KDF is used once per secondary SA to derive a seed PRK for the
     entire SA.

     Pseudocode used to explain this is shown in Figure 14, where the
     named parameters are:

     SAI(i) and SAI(r):  The Security Association Identifier (SAI) from
        the initiator and responder respectively

     ARN(i) and ARN(r):  The Additional Random Nonce (ARN) from the
        initiator and responder respectively, or the empty byte string if
        no such data item was received

     G_XY:  The shared secret derived from Additional Key Exchange (AKE)
        from both the initiator and responder, or the empty byte string if
        AKE was not received from both entities

     context_sa2 = SAI(i) | SAI(r) | ARN(i) | ARN(r) | G_XY
     PRK_SA2 = SAFE_KDF(PRK_SA1, 0, context_sa2, hash_length)

                      Figure 14: Secondary SA derived PRK









  Sipos                    Expires 6 December 2025               [Page 43]


  Internet-Draft                   BP SAFE                       June 2025


     Additional output key material (OKM) specific to the BPSec security
     context being used is then derived from the PRK_SA2 value with
     integer labels for different purposes.  It is part of the obligation
     of each BPSec key use to define what label values apply to key
     material needed by that context.  An IANA registry for recording
     these labels is defined in Section 12.3.

     Pseudocode used to explain this is shown in Figure 15, where the
     named parameters are:

     ctxid:  The BPSec Context Identifier as an unsigned integer

     context:  The BPSec-context-specific context byte string, which can
        be the empty byte string if not needed

     length:  The length of output key material being derived

     SAFE_OKM(ctxid, context, length)
       = SAFE_KDF(PRK_SA2, ctxid, context, length)

                      Figure 15: Secondary SA derived OKM

  8.4.  Secondary SA Rekey


     // TBD

  9.  Security Association Uses

     The ultimate point of establishing a SA is to make use of the derived
     symmetric keys for BPSec security operations as defined in [RFC9172].

     When BPSec contexts make use of SAs defined by this document they
     will require an explicit mapping from the algorithm and operation
     selectors from Section 3.4 onto the algorithm and operation
     identifiers specific to that context.  For example the default
     security contexts correspond to a subset of the AES-GCM algorithms of
     specific key lengths (see Section 9.4) and the HMAC-SHA2 algorithms
     of specific key lengths (see Section 9.3).

     All current and future BPSec context bindings SHALL define the
     following aspects:

     *  State to be managed by a SAFE entity under Key Use Options and Key
        Material fields of the Secondary Security Associations and how
        that key material is derived from the PRK of the secondary SA.





  Sipos                    Expires 6 December 2025               [Page 44]


  Internet-Draft                   BP SAFE                       June 2025


     *  Data items to be exchanged within the SA Creation (SC) messages to
        negotiate the Key Use Selectors.

     *  Detailed requirements about how the Key Material is derived from
        the SAFE_SA2 PRK from the secondary SA.

     *  Detailed requirements about how the secondary SA key information
        is used by the context in all BPSec roles: security source,
        verifier, and acceptor.

  9.1.  SAFE Confidentiality

     Part of the purpose of establishing a primary SA with a peer is to
     derive an encryption key (with associated base IV) to enable SAFE
     message confidentiality in each direction.  Similar to how EDHOC
     cryptographic functions make use of COSE primitives but not COSE
     message encodings, SAFE reuses COSE primitives for its own end-to-end
     security.

  9.1.1.  Without a Primary SA

     These conditions apply even if there is an existing Primary SA which
     is being superseded by a new IA activity.

     While an IA activity is in progress, outgoing SAFE messages SHALL be
     embedded as EAD items within an associated EDHOC message.  Each
     encoded message byte string SHALL be placed in a separate EAD value
     with corresponding EAD label TBA5 in accordance with Section 3.8 of
     [RFC9528].

     While an IA activity is in progress, incoming SAFE messages SHALL be
     extracted from the EAD of an associated EDHOC message.  These
     messages are not processed any differently than other received SAFE
     messages.

  9.1.2.  With a Primary SA

     After the IA activity has completed (initiator has sent, responder
     has received) step 3, a SAFE entity SHALL encrypt aggregated outgoing
     messages according to the following.

     1.  Increment the Partial IV counter associated with the peer entity.

     2.  Encode the Partial IV as a minimum-length byte string in network
         byte order.

     3.  Iterate through and encode a CBOR sequence of byte strings items
         for all messages in the plaintext.



  Sipos                    Expires 6 December 2025               [Page 45]


  Internet-Draft                   BP SAFE                       June 2025


     4.  Internally generate and encrypt a COSE_Encrypt0 object as defined
         in Section 5.3 of [RFC9052] using the following inputs:

         Protected Header:
            An empty byte string h''

         Unprotected Header:
            A map containing the following pairs:

            alg (1):
               The "application AEAD algorithm" of the EDHOC cipher suite
               from the Primary SA

            Partial IV (6):
               The Partial IV value computed in the previous step

         key:
            Either K_IR or K_RI of Section 8.1 from the Primary SA for the
            initiator or responder respectively, which will include a Base
            IV key parameter.

         plaintext:
            The encoded plaintext from above

         external_aad:
            A byte string encoding the CBOR Sequence safe-pdu-aad (as
            defined in Figure 8, and using the same encoding as the PDU)
            // No binding to transport source EID??

     5.  Use the result to construct the following PDU fields, named as in
         Section 4.4:

         partial-iv:  The Partial IV unprotected header byte string
            encoded in accordance with Section 3.3.2 of [RFC9528]

         rx-sai:  The Peer SAI field of the Primary SA

         ciphertext:  The COSE-encrypted ciphertext from the previous step

     Because this encoding does not use AAD to bind it to specific
     transport parameters, the entire PDU can be retained and
     retransmitted if necessary (see Section 4.3).









  Sipos                    Expires 6 December 2025               [Page 46]


  Internet-Draft                   BP SAFE                       June 2025


     Upon receiving an PDU containing a non-null partial-iv value, the
     SAFE entity SHALL decrypt the aggregated messages according to the
     following.

     1.  Use the provided rx-sai to match with the Local SAI of one
         Primary SA.

         If no match is found then
         // TBD.

     2.  Internally generate and decrypt a COSE_Encrypt0 object as defined
         in Section 5.3 of [RFC9052] using the following parameters:

         Protected Header:
            An empty byte string h''

         Unprotected Header:
            A map containing the following pairs:

            alg (1):
               The "application AEAD algorithm" of the EDHOC cipher suite
               from the Primary SA

            Partial IV (6):
               The partial-iv value from the SAFE PDU header

         key:
            Either K_IR or K_RI of Section 8.3 from the Secondary SA for
            the initiator or responder respectively.

         ciphertext:
            The ciphertext field of the PDU payload

         external_aad:
            A byte string encoding the CBOR Sequence safe-pdu-aad (as
            defined in Figure 8, and using the same encoding as the PDU)

         If decryption fails then
         // TBD.

     3.  Iterate through, decode, and process the CBOR sequence of byte
         strings items for all messages in the plaintext.

     For both encryption and decryption, the Base IV (defined in
     Section 8.1) present in the keys of the Primary SA is combined with
     the Partial IV byte string in accordance with Section 3.1 of
     [RFC9052].




  Sipos                    Expires 6 December 2025               [Page 47]


  Internet-Draft                   BP SAFE                       June 2025


  9.2.  Common BPSec Operation

     This section contains logic related to how the Security Mode Selector
     (SMS), Validity Time Interval, Endpoint Selectors, and Security
     Operation Selector (SOS) of the Secondary SA (as described in
     Section 3.4) inform the BPSec entity on both the Initiator and
     Responder nodes.

     The SMS value determines at which of the BP Agent interaction points
     (see Figure 2) the SA is applicable with logic as follows.

     1.  When the SMS value is end-to-end (1), the node SHALL apply the SA
         policy at bundle transmission (from endpoint application) as
         source and at bundle delivery (to endpoint application) as
         acceptor.

         When the SMS value is one-hop (2), the node SHALL apply the SA
         policy at bundle forwarding (to CLA) as source and at bundle
         reception (from CLA) as acceptor.

     2.  At the source interaction point, the node SHALL only apply the SA
         policy when the current DTN time of the node is within the
         Validity Time Interval of the SA.

         At the acceptor interaction point, the node SHALL only apply the
         SA policy when the DTN time from the Timestamp of the Primary
         Block (see Section 4.3.1 of [RFC9171]) is within the Validity
         Time Interval of the SA.

     3.  At each interaction point, the node SHALL compare the Source and
         Destination EID of the Primary Block (as defined in Section 4.3.1
         of [RFC9171]) of each bundle against one of the following.

         At the source interaction point, the Source EID is compared to
         the Local Endpoint Selectors field and the Destination EID is
         compared to the Peer Endpoint Selectors field.

         At the acceptor interaction point, the Source EID is compared to
         the Peer Endpoint Selectors field and the Destination EID is
         compared to the Local Endpoint Selectors field.

     4.  If the bundle has passed the above checks, the Security Operation
         Selector is used to determine which blocks to apply the SA as
         security source or acceptor.  If any of the target block types is
         not present in the bundle,
         // TBD failure?





  Sipos                    Expires 6 December 2025               [Page 48]


  Internet-Draft                   BP SAFE                       June 2025


     5.  For each of the target block numbers filtered-in by the previous
         step, the node SHALL apply the service identified by the SOS of
         the SA, using the Context ID, Key Use Options, and Key
         Information as defined for each context below.


  9.3.  Binding for BIB-HMAC-SHA2 Context

     This section defines how a secondary SA can be negotiated for and
     used by the integrity context of [RFC9173] with context identifier
     code point 1.

  9.3.1.  Secondary SA Information

     For the BIB-HMAC-SHA2 context the "Key Use Options" field of
     Section 3.4 is augmented to include the following information.

               +=============+================================+
               | Name        | Description                    |
               +=============+================================+
               | SHA Variant | One of the code points defined |
               |             | in Section 3.3.1 of [RFC9173]. |
               +-------------+--------------------------------+
               | Integrity   | A value with bit flags defined |
               | Scope Flags | in Section 3.3.3 of [RFC9173]. |
               +-------------+--------------------------------+

                                   Table 9

     For the BIB-HMAC-SHA2 context the "Key Information" field of
     Section 3.4 is augmented to include the following information.

           +=========+=============================================+
           | Name    | Description                                 |
           +=========+=============================================+
           | TX Key  | A byte string for the security source role. |
           +---------+---------------------------------------------+
           | RX Keys | One or more byte strings for the security   |
           |         | acceptor role.                              |
           +---------+---------------------------------------------+

                                    Table 10

  9.3.2.  KUS Options

     The BIB-HMAC-SHA2 context uses existing code points to identify key
     use options.




  Sipos                    Expires 6 December 2025               [Page 49]


  Internet-Draft                   BP SAFE                       June 2025


     $safe-kus /= [
         ctxid: 1,
         options: kus-options-ctxid1 .within safe-proposals
     ]
     kus-options-ctxid1 = kus-map-ctxid1 / [+ kus-map-ctxid1]
     kus-map-ctxid1 = {
         ; SHA Variant values from Section 3.3.1 of RFC 9173
         1: uint,
         ; Integrity Scope flags from Section 3.3.3 of RFC 9173
         2: uint,
     }

  9.3.3.  Key Derivation

     The secondary SA key uses for context 1 take the form of raw
     symmetric key data.  Because the acceptable algorithms are limited to
     HMAC, there are no other options beyond the symmetric key.

     The raw symmetric key SHALL be either CTX1_KEY_IR (from Figure 16) if
     the key is for traffic from the initiator side, or CTX1_KEY_RI
     otherwise.

     CTX1_KEY_IR = SAFE_OKM(1, 'key_ir', key_length)
     CTX1_KEY_RI = SAFE_OKM(1, 'key_ri', key_length)

           Figure 16: Secondary SA BIB-HMAC-SHA2 Context Derivations

  9.3.4.  BPSec Operation

     When each security operation for context 1 needs to be applied, as
     defined in Section 9.2, as the security source the node SHALL perform
     the following:

     1.  A BIB parameter for SHA Variant (1) SHALL be constructed from the
         SHA Variant option of the SA.

     2.  A BIB parameter for Integrity Scope Flags (3) SHALL be
         constructed from the Integrity Scope option of the SA.

     3.  A BIB result for Expected HMAC (1) SHALL be constructed in
         accordance with the structure of Section 3.4 of [RFC9173] and
         content of Section 3.8.1 of [RFC9173].

     When each security operation for context 1 needs to be applied, as
     defined in Section 9.2, as the security acceptor the node SHALL
     perform the following:





  Sipos                    Expires 6 December 2025               [Page 50]


  Internet-Draft                   BP SAFE                       June 2025


     1.  A BIB parameter for SHA Variant (1) SHALL be extracted and
         compared to the SHA Variant option of the SA.  If the received
         SHA Variant differs from the SA, the procedure is considered
         failed.

     2.  A BIB parameter for Integrity Scope Flags (3) SHALL be extracted
         and compared to the Integrity Scope option of the SA.  If the
         received Integrity Scope Flags differs from the SA, the procedure
         is considered failed.

     3.  A BIB result for Expected HMAC (1) SHALL be extracted and
         verified in accordance with Section 3.8.2 of [RFC9173].  If the
         verification fails, the procedure is considered failed.

  9.4.  Binding for BCB-AES-GCM Context

     This section defines how a secondary SA can be negotiated for and
     used by the confidentiality context of [RFC9173] with context
     identifier code point 2.

  9.4.1.  Secondary SA Information

     For the BCB-AES-GCM context the "Key Use Options" field of
     Section 3.4 is augmented to include the following information.

              +=============+==================================+
              | Name        | Description                      |
              +=============+==================================+
              | AES Variant | One of the code points defined   |
              |             | in Section 4.3.2 of [RFC9173].   |
              +-------------+----------------------------------+
              | AAD Scope   | A value with bit flags defined   |
              | Flags       | in Section 4.3.4 of [RFC9173].   |
              +-------------+----------------------------------+
              | IV Counter  | An integer counter which         |
              |             | initializes to 0 at SA creation. |
              +-------------+----------------------------------+

                                   Table 11

     For the BCB-AES-GCM context the "Key Information" field of
     Section 3.4 is augmented to include the following information.

        +===============+=============================================+
        | Name          | Description                                 |
        +===============+=============================================+
        | TX Key        | A byte string for the security source role. |
        +---------------+---------------------------------------------+



  Sipos                    Expires 6 December 2025               [Page 51]


  Internet-Draft                   BP SAFE                       June 2025


        | TX IV Counter | An integer counter which initializes to 0   |
        |               | at SA creation.                             |
        +---------------+---------------------------------------------+
        | RX Keys       | One or more byte strings for the security   |
        |               | acceptor role.                              |
        +---------------+---------------------------------------------+

                                    Table 12

  9.4.2.  KUS Options

     The BCB-AES-GCM context uses existing code points to identify key use
     options.

     $safe-kus /= [
         ctxid: 2,
         options: kus-options-ctxid2 .within safe-proposals
     ]
     kus-options-ctxid2 = kus-map-ctxid2 / [+ kus-map-ctxid2]
     kus-map-ctxid2 = {
         ; AES Variant values from Section 4.3.2 of RFC 9173
         1: uint,
         ; AAD Scope flags from Section 4.3.4 of RFC 9173
         2: uint,
     }

  9.4.3.  Key Derivation

     The secondary SA key uses for context 2 take the form of raw
     symmetric key data.  Because the acceptable algorithms are limited to
     AEAD, there are no other options beyond the symmetric key.

     The raw symmetric key SHALL be either CTX2_KEY_IR (from Figure 17) if
     the key is for traffic from the initiator side, or CTX2_KEY_RI
     otherwise.

     CTX2_KEY_IR = SAFE_OKM(2, 'key_ir', key_length)
     CTX2_KEY_RI = SAFE_OKM(2, 'key_ri', key_length)

            Figure 17: Secondary SA BCB-AES-GCM Context Derivations

  9.4.4.  BPSec Operation

     When each security operation for context 2 needs to be applied, as
     defined in Section 9.2, as the security source the node SHALL perform
     the following:





  Sipos                    Expires 6 December 2025               [Page 52]


  Internet-Draft                   BP SAFE                       June 2025


     1.  A BIB parameter for AES Variant (2) SHALL be constructed from the
         AES Variant option of the SA.

     2.  A BIB parameter for AAD Scope Flags (4) SHALL be constructed from
         the AAD Scope option of the SA.

     3.  Increment the TX IV Counter associated with the Key Information
         of the SA.

     4.  Encode the TX IV Counter as a fixed-length 12-byte string in
         network byte order.

     5.  A BIB parameter for Initialization Vector (1) SHALL be
         constructed from the encoded IV Counter of the previous step.

     6.  The encryption SHALL be performed, modifying the target block in
         place, in accordance with Section 4.8.1 of [RFC9173].

     7.  A BIB result for Authentication Tag (1) SHALL be constructed in
         accordance with the structure of Section 4.4.1 of [RFC9173] and
         content of Section 4.8.1 of [RFC9173].

     When each security operation for context 2 needs to be applied, as
     defined in Section 9.2, as the security acceptor the node SHALL
     perform the following:

     1.  A BCB parameter for AES Variant (2) SHALL be extracted and
         compared to the AES Variant option of the SA.  If the received
         AES Variant differs from the SA, the procedure is considered
         failed.

     2.  A BCB parameter for AAD Scope Flags (3) SHALL be extracted and
         compared to the AAD Scope option of the SA.  If the received AAD
         Scope Flags value differs from the SA, the procedure is
         considered failed.

     3.  A BCB result for Authentication Tag (1) SHALL be extracted and
         the decryption procedure of Section 4.8.2 of [RFC9173] performed.
         If the decryption fails, the procedure is considered failed.

  9.5.  Binding for COSE Context

     This section defines how a secondary SA can be negotiated for and
     used by the COSE context of [I-D.ietf-dtn-bpsec-cose] with context
     identifier code point 3.  The derived keys are suitable for use with
     COSE encryption or MAC operations between the nodes hosting the SAFE
     entities.




  Sipos                    Expires 6 December 2025               [Page 53]


  Internet-Draft                   BP SAFE                       June 2025


  9.5.1.  Secondary SA Information

     For the COSE context the "Key Use Options" field of Section 3.4 is
     augmented to include the following information.

          +===========+=============================================+
          | Name      | Description                                 |
          +===========+=============================================+
          | COSE      | One of the code points defined in the "COSE |
          | Algorithm | Algorithms" registry of [IANA-COSE] for     |
          |           | either AEAD encryption or MAC operation.    |
          +-----------+---------------------------------------------+
          | AAD Scope | A map structure defined in Section 2.2.2 of |
          |           | [I-D.ietf-dtn-bpsec-cose].                  |
          +-----------+---------------------------------------------+

                                    Table 13

     For the COSE context the "Key Information" field of Section 3.4 is
     augmented to include the following information.

           +============+=========================================+
           | Name       | Description                             |
           +============+=========================================+
           | TX COSE    | A COSE Key object for the security      |
           | Key        | source role.                            |
           +------------+-----------------------------------------+
           | TX Partial | An integer counter which initializes to |
           | IV Counter | 0 at SA creation.  This field is used   |
           |            | only for confidentiality services.      |
           +------------+-----------------------------------------+
           | RX COSE    | One or more COSE Key objects for the    |
           | Keys       | security acceptor role.                 |
           +------------+-----------------------------------------+

                                   Table 14

     The COSE key structure is defined in Section 7 of [RFC9052].

  9.5.2.  KUS Options

     The BPSec COSE context uses existing COSE code points to identify key
     use options.








  Sipos                    Expires 6 December 2025               [Page 54]


  Internet-Draft                   BP SAFE                       June 2025


            +=======+=============================================+
            | Label | Description                                 |
            +=======+=============================================+
            | 3     | One of the code points defined in the "COSE |
            |       | Algorithms" registry of [IANA-COSE] for     |
            |       | either AEAD encryption or MAC operation.    |
            +-------+---------------------------------------------+

                       Table 15: COSE Context KUS Options

     $safe-kus /= [
         ctxid: 3,
         options: kus-options-ctxid3 .within safe-proposals
     ]
     kus-options-ctxid3 = kus-map-ctxid3 / [+ kus-map-ctxid3]
     kus-map-ctxid3 = {
         ; COSE alg header values
         3: tstr / int,
     }

  9.5.3.  Key Derivation

     The secondary SA key uses for context 3 take the form of COSE key
     objects.  Because the acceptable algorithms are limited to AEAD
     encryption and MAC, the acceptable operations for each key in each
     entity are one of: encrypt (3), decrypt (4), MAC create (9), or MAC
     verify (10).

     When the COSE algorithm is one of the MAC algorithms, the COSE key
     SHALL contain the following parameters.

     kty (1):
        The value Symmetric (4).

     kid (2):

        // TBD

     alg (3):
        The negotiated algorithm from the KUS options.

     key_ops (4):
        Either MAC create (9) if this entity is the SC initiator and the
        key is for traffic from the initiator side, or MAC verify (10)
        otherwise






  Sipos                    Expires 6 December 2025               [Page 55]


  Internet-Draft                   BP SAFE                       June 2025


     k (-1):
        Either CTX3_KEY_IR (from Figure 18) if the key is for traffic from
        the initiator side, or CTX3_KEY_RI otherwise

     When the COSE algorithm is one of the AEAD algorithms, the COSE key
     SHALL contain the following parameters.

     kty (1):
        The value Symmetric (4).

     kid (2):

        // TBD

     alg (3):
        The negotiated algorithm from the KUS options.

     key_ops (4):
        Either encrypt (3) if this entity is the SC initiator and the key
        is for traffic from the initiator side, or decrypt (4) otherwise

     Base IV (5):
        Either CTX3_BIV_IR (from Figure 18) if the key is for traffic from
        the initiator side, or CTX3_BIV_RI otherwise

     k (-1):
        Either CTX3_KEY_IR (from Figure 18) if the key is for traffic from
        the initiator side, or CTX3_KEY_RI otherwise

     CTX3_KEY_IR = SAFE_OKM(3, 'key_ir', key_length)
     CTX3_BIV_IR = SAFE_OKM(3, 'biv_ir', iv_length)

     CTX3_KEY_RI = SAFE_OKM(3, 'key_ri', key_length)
     CTX3_BIV_RI = SAFE_OKM(3, 'biv_ri', iv_length)

                Figure 18: Secondary SA COSE Context Derivations

  9.5.4.  BPSec Operation

     When each security operation for context 3 needs to be applied, as
     defined in Section 9.2, as the security source and the COSE algorithm
     is one of the MAC algorithms, the node SHALL perform the following:

     1.  A BIB parameter for AAD Scope (5) SHALL be constructed from the
         AAD Scope option of the SA.






  Sipos                    Expires 6 December 2025               [Page 56]


  Internet-Draft                   BP SAFE                       June 2025


     2.  A BIB result for COSE_Mac0 (17) SHALL be constructed in
         accordance with Section 2.3.1 of [I-D.ietf-dtn-bpsec-cose]
         containing the following parameters.

         Protected Header:
            An encoded map containing the following pairs:

            alg (1):
               The COSE algorithm value from the SA

         Unprotected Header:
            A map containing the following pairs:

            kid (4):
               The kid parameter from the COSE Key of the TX Key
               Information of the SA

            kid context (10):
               The Peer SAI of the SA as a direct byte string

         key:
            The COSE Key of the TX Key Information of the SA.

         payload and external_aad:
            Taken from the target block and AAD Scope option in accordance
            with Section 2.3.1 of [I-D.ietf-dtn-bpsec-cose].  The actual
            payload will be detached and taken from the target block.

     When each security operation for context 3 needs to be applied, as
     defined in Section 9.2, as the security acceptor and the COSE
     algorithm is one of the MAC algorithms, the node SHALL perform the
     following:

     1.  A BIB parameter for AAD Scope (5) SHALL be extracted and compared
         to the AAD Scope option of the SA.  If the received AAD Scope
         value differs from the SA, the procedure is considered failed.

     2.  A BIB result for COSE_Mac0 (17) SHALL be extracted in accordance
         with Section 2.3.1 of [I-D.ietf-dtn-bpsec-cose] and verified to
         have the following minimum parameters.

         Protected Header:
            An encoded map containing the following pairs:

            alg (1):
               The COSE algorithm value matching that of the SA

         Unprotected Header:



  Sipos                    Expires 6 December 2025               [Page 57]


  Internet-Draft                   BP SAFE                       June 2025


            A map containing the following pairs:

            kid (4):
               A value matching a kid parameter from one of the COSE Key
               of the TX Key Information of the SA

         If the required header parameters are missing or invalid, the
         procedure is considered failed.

     3.  The extracted COSE_Mac0 is then verified using the following
         parameters:

         key:  The matching COSE Key from the TX Key Information of the
            SA.

         payload and external_aad:  Taken from the target block and AAD
            Scope option in accordance with Section 2.3.1 of
            [I-D.ietf-dtn-bpsec-cose].  The actual payload will be
            detached and taken from the target block.

         If the verification fails, the procedure is considered failed.

     When each security operation for context 3 needs to be applied, as
     defined in Section 9.2, as the security source and the COSE algorithm
     is one of the AEAD algorithms, the node SHALL perform the following:

     1.  A BCB parameter for AAD Scope SHALL be constructed from the AAD
         Scope option of the SA.

     2.  Increment the TX Partial IV Counter associated with the Key
         Information of the SA.

     3.  Encode the TX Partial IV Counter as a minimum-length byte string
         in network byte order.

     4.  A BCB result for COSE_Encrypt0 (16) SHALL be constructed in
         accordance with Section 2.3.2 of [I-D.ietf-dtn-bpsec-cose]
         containing the following parameters.

         Protected Header:
            An encoded map containing the following pairs:

            alg (1):
               The COSE algorithm value from the SA

         Unprotected Header:
            A map containing the following pairs:




  Sipos                    Expires 6 December 2025               [Page 58]


  Internet-Draft                   BP SAFE                       June 2025


            kid (4):
               The kid parameter from the COSE Key of the TX Key
               Information of the SA

            partial iv (6):
               The encoded Partial IV from the earlier step

         key:
            The COSE Key of the TX Key Information of the SA, which
            includes a Base IV parameter.

         payload and external_aad:
            Taken from the target block and AAD Scope option in accordance
            with Section 2.3.2 of [I-D.ietf-dtn-bpsec-cose].  The final
            payload will be detached.

     5.  The constructed COSE_Encrypt0 SHALL be encrypted, modifying the
         target block in place as a detached payload, in accordance with
         Section 2.3.2 of [I-D.ietf-dtn-bpsec-cose].

     When each security operation for context 3 needs to be applied, as
     defined in Section 9.2, as the security acceptor and the COSE
     algorithm is one of the AEAD algorithms, the node SHALL perform the
     following:

     1.  A BCB parameter for AAD Scope (5) SHALL be extracted and compared
         to the AAD Scope option of the SA.  If the received AAD Scope
         value differs from the SA, the procedure is considered failed.

     2.  A BCB result for COSE_Encrypt0 (16) SHALL be extracted in
         accordance with Section 2.3.2 of [I-D.ietf-dtn-bpsec-cose] and
         verified to have the following minimum parameters.

         Protected Header:
            An encoded map containing the following pairs:

            alg (1):
               The COSE algorithm value matching that of the SA

         Unprotected Header:
            A map containing the following pairs:

            kid (4):
               A value matching a kid parameter from one of the COSE Key
               of the RX Key Information of the SA

            partial iv (6):
               A byte string Partial IV value



  Sipos                    Expires 6 December 2025               [Page 59]


  Internet-Draft                   BP SAFE                       June 2025


         If the required header parameters are missing or invalid, the
         procedure is considered failed.

     3.  The extracted COSE_Encrypt0 is then processed to decrypt using
         the following parameters:

         key:  The COSE Key of the RX Key Information of the SA, which
            includes a Base IV parameter.

         payload and external_aad:  Taken from the target block and AAD
            Scope option in accordance with Section 2.3.2 of
            [I-D.ietf-dtn-bpsec-cose].  The final payload will be
            detached.

         The decryption modifies the target block in place as a detached
         payload.  If the authenticated decryption fails, the procedure is
         considered failed.

     The parameters of the derived COSE keys already intrinsically
     restrict their use based on the requirements of
     [I-D.ietf-dtn-bpsec-cose] and [RFC9053], so no additional checks are
     specified in this document.

  10.  PKIX Certificate Profile


     // TBD with a new extended key use for this protocol.  Profile of
     [RFC5280] allowing C509 [I-D.ietf-cose-cbor-encoded-cert].

  11.  Security Considerations

     This section separates security considerations into threat categories
     based on guidance of BCP 72 [RFC3552].

  11.1.  Threat: Passive Leak of Data

     Because the SAFE protocol uses EDHOC for its initial authentication
     activity and messaging and uses primary SA data for confidentiality
     afterward, the only information which is exposed in plaintext are the
     Security Association Identifier (SAI) values (which are also EDHOC
     connection identifiers) and SAFE confidentiality partial IV
     (Section 4.4) values.









  Sipos                    Expires 6 December 2025               [Page 60]


  Internet-Draft                   BP SAFE                       June 2025


     Both of these values are used strictly for uniqueness and can either
     be generated by a SAFE entity deterministically or randomly.  Neither
     value contains data derived from or correlated to any outside
     information, so visibility to a passive attacker is not useful to
     degrade SAFE security.  Their visibility could be used by a passive
     attacker for SAFE traffic analysis.

     The sizes of ciphertext values in all forms of SAFE PDU can be used
     by a passive attacker to estimate the types of SAFE activities being
     performed.  To mitigate this threat, it is possible for a SAFE entity
     to use EDHOC padding EAD (see Section 3.8.1 of [RFC9528]) during the
     IA activity or SAFE confidential PDU plaintext padding item (see
     Section 4.4).

  11.2.  Threat: On-Path Modification

     The SAI values are necessary to correlate EDHOC messages and to
     decrypt SAFE PDUs, so must be in plaintext and any on-path attacker
     modification of these values will cause either the EDHOC negotiation
     to fail or the SAFE decryption to fail.

     The IV values are already part of what would be sent with the
     associated ciphertext, and any modification will cause the SAFE
     decryption to fail.

     Both of these conditions are detectable by the receiver being
     attacked so there is no possibility of the attacker causing
     undetectable changes.

  11.3.  Threat: Denial of Service

     The behaviors described in this section all amount to a potential
     denial-of-service to a participating node.  The denial-of-service
     could be limited to an individual node, or could affect all entities
     on a host or network segment.


     // TBD

  12.  IANA Considerations

     Registration procedures referred to in this section are defined in
     [RFC8126].








  Sipos                    Expires 6 December 2025               [Page 61]


  Internet-Draft                   BP SAFE                       June 2025


  12.1.  Well-Known IPN Service

     Within the registry group of [IANA-URI], the registry titled "'ipn'
     Scheme URI Well-known Service Numbers for BPv7" has been updated to
     include the following entry.

            +=======+=====================+======================+
            | Value | Description         | Reference            |
            +=======+=====================+======================+
            | TBA3  | BPv7 SAFE Messaging | [This specification] |
            +-------+---------------------+----------------------+

                Table 16: 'ipn' Scheme URI Well-known Service
                               Numbers for BPv7

  12.2.  EDHOC Registries

     Within the registry group of [IANA-EDHOC], the registry titled "EDHOC
     Exporter Labels" has been updated to include the following entry.

          +=======+==========================+======================+
          | Label | Description              | Reference            |
          +=======+==========================+======================+
          | TBA4  | Derived BPv7 SAFE Secret | [This specification] |
          +-------+--------------------------+----------------------+

                        Table 17: EDHOC Exporter Labels

     Within the registry group of [IANA-EDHOC], the registry titled "EDHOC
     External Authorization Data" has been updated to include the
     following entry.

        +===========+=======+========================+================+
        | Name      | Label | Description            | Reference      |
        +===========+=======+========================+================+
        | BPv7 SAFE | TBA5  | Set of Create messages | [This          |
        |           |       | for BPv7 SAFE          | specification] |
        +-----------+-------+------------------------+----------------+

                  Table 18: EDHOC External Authorization Data

  12.3.  BP SAFE Registries

     A new registry group "Bundle Protocol (BP) Security Associations with
     Few Exchanges (SAFE)" has been created at [IANA-SAFE].






  Sipos                    Expires 6 December 2025               [Page 62]


  Internet-Draft                   BP SAFE                       June 2025


     Within the registry group of [IANA-SAFE], the registry titled "SAFE
     Security Modes" has been created with registration procedures from
     Table 19 and initial contents of Table 20.

                +==================+=========================+
                | Range            | Registration Procedures |
                +==================+=========================+
                | -32768 to -32641 | Experimental use        |
                +------------------+-------------------------+
                | -32640 to -1     | Private use             |
                +------------------+-------------------------+
                | 0 to 255         | RFC Required            |
                +------------------+-------------------------+
                | 256 to 32767     | Specification Required  |
                +------------------+-------------------------+

                  Table 19: SAFE Security Modes Registration

     +==================+===============================+================+
     | Value            | Name                          | Reference      |
     +==================+===============================+================+
     | -32768 to -32641 | Reserved for                  | [This          |
     |                  | experimental use              | specification] |
     +------------------+-------------------------------+----------------+
     | -32640 to -1     | Reserved for                  | [This          |
     |                  | private use                   | specification] |
     +------------------+-------------------------------+----------------+
     | 0                | _reserved_                    | [This          |
     |                  |                               | specification] |
     +------------------+-------------------------------+----------------+
     | 1                | end-to-end                    | [This          |
     |                  |                               | specification] |
     +------------------+-------------------------------+----------------+
     | 2                | one-hop                       | [This          |
     |                  |                               | specification] |
     +------------------+-------------------------------+----------------+
     | 3 to 32767       | _Unassigned_                  |                |
     +------------------+-------------------------------+----------------+

                         Table 20: SAFE Security Modes

     Within the registry group of [IANA-SAFE], the registry titled "SAFE
     Activity Types" has been created with registration procedures from
     Table 21 and initial contents of Table 22.







  Sipos                    Expires 6 December 2025               [Page 63]


  Internet-Draft                   BP SAFE                       June 2025


                +==================+=========================+
                | Range            | Registration Procedures |
                +==================+=========================+
                | -32768 to -32641 | Experimental use        |
                +------------------+-------------------------+
                | -32640 to -1     | Private use             |
                +------------------+-------------------------+
                | 0 to 255         | RFC Required            |
                +------------------+-------------------------+
                | 256 to 32767     | Specification Required  |
                +------------------+-------------------------+

                  Table 21: SAFE Activity Types Registration






































  Sipos                    Expires 6 December 2025               [Page 64]


  Internet-Draft                   BP SAFE                       June 2025


       +===========+======================+==========+================+
       | Value     | Description          | Notation | Reference      |
       +===========+======================+==========+================+
       | -32768 to | Reserved for         |          | [This          |
       | -32641    | experimental use     |          | specification] |
       +-----------+----------------------+----------+----------------+
       | -32640 to | Reserved for private |          | [This          |
       | -1        | use                  |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 0         | Reserved for Initial | IA       | Section 5.1 of |
       |           | Authentication       |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 1         | Capability           | CI       | Section 5.2 of |
       |           | Indication           |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 2         | SA Creation          | SC       | Section 5.3 of |
       |           |                      |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 3         | SA Rekey             | SR       | Section 5.4 of |
       |           |                      |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 4         | SA Teardown          | ST       | Section 5.5 of |
       |           |                      |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 5         | Event Notification   | EN       | Section 5.6 of |
       |           |                      |          | [This          |
       |           |                      |          | specification] |
       +-----------+----------------------+----------+----------------+
       | 6 to      | _Unassigned_         |          |                |
       | 32767     |                      |          |                |
       +-----------+----------------------+----------+----------------+

                        Table 22: SAFE Activity Types

     Within the registry group of [IANA-SAFE], the registry titled "SAFE
     Message Data Items" has been created with the following initial
     contents.  Each entry in the table indicates which messages are valid
     for containing the associated data item and the map label by which
     the item is identified.  The registration procedure for this registry
     is identical to the corresponding "SAFE Activity Types" entry from
     the first column.





  Sipos                    Expires 6 December 2025               [Page 65]


  Internet-Draft                   BP SAFE                       June 2025


     This registry includes only well-known data item types; private use
     labels can be used to include any other data items in a message.

     +==========+========+===================+==========+================+
     | Activity | Label  | Description       | Notation | Reference      |
     | Type     |        |                   |          |                |
     | Notation |        |                   |          |                |
     +==========+========+===================+==========+================+
     | _all     | -32768 | _Reserved for     |          | [This          |
     | types_   | to -1  | private use_      |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | _all     | 0      | Error Type        | ETE      | Section 6.1 of |
     | types_   |        | Enumeration       |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | IA       |        | _this             |          |                |
     |          |        | activity does     |          |                |
     |          |        | not use data      |          |                |
     |          |        | item labels_      |          |                |
     +----------+--------+-------------------+----------+----------------+
     | CI       | 1      | Concurrent        | CAS      | Section 6.2 of |
     |          |        | Activity          |          | [This          |
     |          |        | Support           |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | CI       | 2      | EID Scheme        | ESS      | Section 6.3 of |
     |          |        | Support           |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | CI       | 3      | BPSec Context     | BCS      | Section 6.4 of |
     |          |        | Support           |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 1      | Security          | SAI      | Section 6.5 of |
     |          |        | Association       |          | [This          |
     |          |        | Identifier        |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 2      | Additional        | AKE      | Section 6.6 of |
     |          |        | Key Exchange      |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 3      | Additional        | ARN      | Section 6.7 of |
     |          |        | Random Nonce      |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 9      | Security Mode     | SMS      | Section 6.8 of |
     |          |        | Selector          |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+



  Sipos                    Expires 6 December 2025               [Page 66]


  Internet-Draft                   BP SAFE                       June 2025


     | SC       | 6      | Endpoint          | ESI      | Section 6.10   |
     |          |        | Selector at       |          | of [This       |
     |          |        | Initiator         |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 7      | Endpoint          | ESR      | Section 6.10   |
     |          |        | Selector at       |          | of [This       |
     |          |        | Responder         |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 8      | Validity Node     | NTI      | Section 6.9 of |
     |          |        | Time Interval     |          | [This          |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 4      | Security          | SOS      | Section 6.11   |
     |          |        | Operation         |          | of [This       |
     |          |        | Selector          |          | specification] |
     +----------+--------+-------------------+----------+----------------+
     | SC       | 5      | Key Use           | KUS      | Section 6.12   |
     |          |        | Selector          |          | of [This       |
     |          |        |                   |          | specification] |
     +----------+--------+-------------------+----------+----------------+

                       Table 23: SAFE Message Data Items

     Within the registry group of [IANA-SAFE], the registry titled "SAFE
     Error Type Enumerations" has been created with the following initial
     contents.  These entries are distinct and separate from the "EDHOC
     Error Codes" registry of [IANA-EDHOC].
























  Sipos                    Expires 6 December 2025               [Page 67]


  Internet-Draft                   BP SAFE                       June 2025


       +===============+===========+==================+================+
       | Activity Type | Value     | Description      | Reference      |
       | Notation      |           |                  |                |
       +===============+===========+==================+================+
       | _all types_   | -32768 to | Reserved for     | [This          |
       |               | -32641    | experimental use | specification] |
       +---------------+-----------+------------------+----------------+
       | _all types_   | -32640 to | Reserved for     | [This          |
       |               | -1        | private use      | specification] |
       +---------------+-----------+------------------+----------------+
       | _all types_   | 1         | Invalid data     | [This          |
       |               |           | item label       | specification] |
       +---------------+-----------+------------------+----------------+
       | _all types_   | 2         | Unknown data     | [This          |
       |               |           | item label       | specification] |
       +---------------+-----------+------------------+----------------+
       | _all types_   | 3         | Invalid data     | [This          |
       |               |           | item value       | specification] |
       +---------------+-----------+------------------+----------------+
       | SR,ST         | 256       | Unknown security | [This          |
       |               |           | association      | specification] |
       +---------------+-----------+------------------+----------------+

                     Table 24: SAFE Error Type Enumerations

  13.  References

  13.1.  Normative References

     [IANA-BUNDLE]
                IANA, "Bundle Protocol",
                <https://www.iana.org/assignments/bundle/>.

     [IANA-COSE]
                IANA, "CBOR Object Signing and Encryption (COSE)",
                <https://www.iana.org/assignments/cose/>.

     [IANA-EDHOC]
                IANA, "Ephemeral Diffie-Hellman Over COSE (EDHOC)",
                <https://www.iana.org/assignments/edhoc/>.

     [IANA-SAFE]
                IANA, "Bundle Protocol (BP) Security Associations with Few
                Exchanges (SAFE)",
                <https://www.iana.org/assignments/bp-safe/>.

     [IANA-URI] IANA, "Uniform Resource Identifier (URI) Schemes",
                <https://www.iana.org/assignments/uri-schemes/>.



  Sipos                    Expires 6 December 2025               [Page 68]


  Internet-Draft                   BP SAFE                       June 2025


     [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/info/rfc2119>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

     [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/info/rfc8174>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/info/rfc8610>.

     [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/info/rfc8949>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/info/rfc9052>.

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/info/rfc9053>.

     [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
                Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
                January 2022, <https://www.rfc-editor.org/info/rfc9171>.

     [RFC9172]  Birrane, III, E. and K. McKeever, "Bundle Protocol
                Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
                2022, <https://www.rfc-editor.org/info/rfc9172>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/info/rfc9528>.





  Sipos                    Expires 6 December 2025               [Page 69]


  Internet-Draft                   BP SAFE                       June 2025


     [I-D.ietf-cose-cbor-encoded-cert]
                Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
                M. Furuhed, "CBOR Encoded X.509 Certificates (C509
                Certificates)", Work in Progress, Internet-Draft, draft-
                ietf-cose-cbor-encoded-cert-13, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-13>.

     [I-D.ietf-dtn-bibect]
                Burleigh, S., Montilla, A., Deaton, J., and C. Caini,
                "Bundle-in-Bundle Encapsulation", Work in Progress,
                Internet-Draft, draft-ietf-dtn-bibect-05, 15 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
                bibect-05>.

     [I-D.ietf-dtn-bpsec-cose]
                Sipos, B., "Bundle Protocol Security (BPSec) COSE
                Context", Work in Progress, Internet-Draft, draft-ietf-
                dtn-bpsec-cose-08, 3 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
                bpsec-cose-08>.

     [I-D.ietf-dtn-eid-pattern]
                Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in
                Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-02,
                13 May 2025, <https://datatracker.ietf.org/doc/html/draft-
                ietf-dtn-eid-pattern-02>.

  13.2.  Informative References

     [802.1X]   IEEE, "IEEE Standard for Local and Metropolitan Area
                Networks--Port-Based Network Access Control", IEEE 802-1x-
                2020, DOI 10.1109/IEEESTD.2020.9018454, 28 February 2020,
                <https://ieeexplore.ieee.org/document/9018454>.

     [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                DOI 10.17487/RFC3552, July 2003,
                <https://www.rfc-editor.org/info/rfc3552>.

     [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
                R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
                Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
                April 2007, <https://www.rfc-editor.org/info/rfc4838>.







  Sipos                    Expires 6 December 2025               [Page 70]


  Internet-Draft                   BP SAFE                       June 2025


     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/info/rfc5280>.

     [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
                Kivinen, "Internet Key Exchange Protocol Version 2
                (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
                2014, <https://www.rfc-editor.org/info/rfc7296>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/info/rfc7942>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

     [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
                Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
                Message Specification", RFC 8551, DOI 10.17487/RFC8551,
                April 2019, <https://www.rfc-editor.org/info/rfc8551>.

     [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
                Datagram Transport Layer Security (DTLS) Protocol Version
                1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
                <https://www.rfc-editor.org/info/rfc9147>.

     [RFC9173]  Birrane, III, E., White, A., and S. Heiner, "Default
                Security Contexts for Bundle Protocol Security (BPSec)",
                RFC 9173, DOI 10.17487/RFC9173, January 2022,
                <https://www.rfc-editor.org/info/rfc9173>.

     [RFC9529]  Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
                and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
                COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
                <https://www.rfc-editor.org/info/rfc9529>.

  Appendix A.  Example Sequencing

     This section contains a minimal example of two nodes initializing a
     primary SA and two secondary SAs with overlapping activities using
     pipelined messaging.  The EDHOC messages in the IA activity are taken
     from the example in Section 2 of [RFC9529] to avoid duplicating EDHOC
     example logic here.  This example does not include any PDU losses so
     no retransmission is needed.



  Sipos                    Expires 6 December 2025               [Page 71]


  Internet-Draft                   BP SAFE                       June 2025


                        PDU #1    #2    #3    #4    #5
                             |     |     |     |     |
                         (IA 0 --- 1 --- 2 --- 3)    |
                             | (CI 0 --- 1 --- 2)    |
                             |     | (SC 0 --- 1 --- 2)

                              =----- time ----->

               Figure 19: Activities within PDUs in this example

  A.1.  SAFE PDU #1

     The encoded PDU #1 (initiator-to-responder) is the following byte
     string:

     01f6f50006582031f82c7b5b9cbbf0f194d913cc12ef1532d328ef32632a4881a1c0
     701e237f042d

     The contents of that PDU are following CBOR sequence:

     1, / version /
     null, / partial-iv /
     true, / rx-sai /
     / message_1: /
     0, / method /
     6, / suites /
     h'31f82c7b5b9cbbf0f194d913cc12ef1532d328ef32632a48
       81a1c0701e237f04', / G_X /
     -14 / C_I /

  A.2.  SAFE PDU #2

     The encoded PDU #2 (responder-to-initiator) is following byte string:

     01f62d5880dc88d2d51da5ed67fc4616356bc8ca74ef9ebe8b387e623a360ba480b9
     b29d1c9e2115f057ff0687a41a21a1d7fc4553061357fe93dbef391c83e18a27b29c
     e24e44a45916fdebe9c5a505abdec132750551154966a67eed27236c093e2774814f
     11c5affadf8c0cd96e31fef7deda3398136d3e79419efd86efe646e1606b77

     That PDU has the following decoded header, eliding the ciphertext
     message.

     1, / version /
     null, / partial-iv /
     -14 / rx-sai from C_I /
     / message_2: h'dc88...6b77' /





  Sipos                    Expires 6 December 2025               [Page 72]


  Internet-Draft                   BP SAFE                       June 2025


     Derived from the shared secrets, the PLAINTEXT_2 contents are the
     following:

     4118A11822822E4879F2A41B510C1F9B58407934E54041AE5ACB7C68DE7ED477D947
     E4214E84659D99FCD49C4B25033DD92AF50DE0570BC27B72039CEB2F4A4F8F05082F
     F9739A823C25634FE42BB306F296364F010001A30119040002820102038103

     That plaintext has the following decoded items.

     h'18', / C_R /
     {34: [-15, h'79F2A41B510C1F9B']}, / ID_CRED_R with following sig. /
     h'A9CAAE6BB615B3C50D774AFA0B6297AA3CCDBED1A03A34614DEE8A62216F685DC9
       ED1C8DE7291E2C571E1E9DAD39B350869CC7B2658514EB7881E8B03D5C9D89',
     -23, / EAD label with following value /
     h'010001A30119040002820102038103'

     The embedded EAD_2 contains the following SAFE message:

     1, / act. index /
     0, / act. step /
     1, / act. type: CI /
     {
         1: 1024, / CAS: max 1024 /
         2: [1, 2], / ESS: dtn and ipn schemes /
         3: [3] / BCS: COSE Context /
     }

  A.3.  SAFE PDU #3

     The encoded PDU #3 is following byte string:

     01f6411858c1e418256972ed10356c2cadc3e72dd86c16e830590972a7fa238c92b3
     0c7cb6a030397061de4327b02b5aae7c0e1c6de2d67bd7627b33b8cb8e9bb8303aca
     53143aacd8713413becc1a3ad2ad7ac3bee1b56cb576637738787106a415c41ab3c4
     b70fe87782994bb93d25c2a7565255948267637511364b2236ae8ddbbfb4321246fc
     38ba317216893f9afe59b85a4301e871944d8e3afb7de0278bf2cf7c161ce6fe2ff6
     b2e6d8f5666d5ae4c555f07ee534293f4dc85d282bdd35e2676b126eee

     That PDU has the following decoded header, eliding the ciphertext
     message.

     1, / version /
     null, / partial-iv /
     h'18' / rx-sai from C_I /
     / message_3: h'e418...6eee' /

     Derived from the shared secrets, the PLAINTEXT_3 contents are the
     following:



  Sipos                    Expires 6 December 2025               [Page 73]


  Internet-Draft                   BP SAFE                       June 2025


     A11822822E48C24AB2FD7643C79F5840A6F33C8F1FED68F30F83261652D193DC1B29
     A5B40A53AA6D695466F8E473B74548914C293F8EB127C71813993338E6573F90A60A
     BB6F3484FE4172056B645A0A36584D010002A80146235A91D189EA035056B44D9A0F
     87538A24CA8EBE49D4FD51040305A10101090106F607F602582031F82C7B5B9CBBF0
     F194D913CC12EF1532D328EF32632A4881A1C0701E237F04364F010101A301190400
     02820102038103

     That plaintext has the following decoded items.

     {34: [-15, h'C24AB2FD7643C79F']}, / ID_CRED_I with following sig. /
     h'A6F33C8F1FED68F30F83261652D193DC1B29A5B40A53AA6D695466F8E473B74548
       914C293F8EB127C71813993338E6573F90A60ABB6F3484FE4172056B645A0A',
     -23, / EAD label with following value /
     h'010002A80146235A91D189EA035056B44D9A0F87538A24CA8EBE49D4FD51040305
       A10101090106F607F602582031F82C7B5B9CBBF0F194D913CC12EF1532D328EF32
       632A4881A1C0701E237F04',
     -23, / EAD label with following value /
     h'010101A30119040002820102038103'

     The embedded EAD_3 contains the following SAFE messages:

     1, / act. index /
     0, / act. step /
     2, / act. type: SC /
     {
         1: h'235A91D189EA', / local SAI bytes /
         3: h'56B44D9A0F87538A24CA8EBE49D4FD51', / ARN bytes /
         4: 3, / CTX: COSE (3) /
         5: { / KUS: /
           1: 1 / alg: A128GCM (1) /
         },
         9: 1, / SMS: end-to-end (1) /
         6: null, / TSI: still TBD /
         7: null, / TSR: still TBD /
         2: h'31F82C7B5B9CBBF0F194D913CC12EF1532D328EF32632A4881A1C0701E2
              37F04' / AKE bytes /
     }

     1, / act. index /
     1, / act. step /
     1, / act. type: CI /
     {
         1: 1024, / CAS: max 1024 /
         2: [1, 2], / ESS: dtn and ipn schemes /
         3: [3] / BCS: COSE Context /
     }





  Sipos                    Expires 6 December 2025               [Page 74]


  Internet-Draft                   BP SAFE                       June 2025


  A.4.  SAFE PDU #4

     The encoded PDU #4 is following byte string:

     01F62D586492459A97A617FE0176E1040FB1E98A640FBDF104E4839EB576F32EF07C
     F283B9C8FF4AC2B5B3DC72F15A5CAEC383A366A8310D97E369E1696D4D43BC9BAA99
     E63E750D29344A95D9C703B21B7AE796F36F82FDF8798F5428AD8057C2D197B7F6DE
     7ADEB6

     That PDU has the following decoded header, eliding the ciphertext
     message.

     1, / version /
     null, / partial-iv /
     -14 / rx-sai from C_I /
     / message_3: h'9245...DEB6' /

     Derived from the shared secrets, the PLAINTEXT_4 contents are the
     following:

     3642010236584d010102a80146a8c046494ebd035043184c4d9f379d2eb35fd2f2f1
     1ae27b040305a10101090106f607f6025820dc88d2d51da5ed67fc4616356bc8ca74
     ef9ebe8b387e623a360ba480b9b29d1c

     That plaintext has the following decoded items.

     -23, / EAD label with following value /
     h'0102',
     -23, / EAD label with following value /
     h'010102A80146A8C046494EBD035043184C4D9F379D2EB35FD2F2F11AE27B040305
       A10101090106F607F6025820DC88D2D51DA5ED67FC4616356BC8CA74EF9EBE8B38
       7E623A360BA480B9B29D1C'

     The embedded EAD_4 contains the following SAFE messages:

     1, / act. index /
     2 / act. step /














  Sipos                    Expires 6 December 2025               [Page 75]


  Internet-Draft                   BP SAFE                       June 2025


     1, / act. index /
     1, / act. step /
     2, / act. type: SC /
     {
         1: h'A8C046494EBD', / local SAI bytes /
         3: h'43184C4D9F379D2EB35FD2F2F11AE27B', / ARN bytes /
         4: 3, / CTX: COSE (3) /
         5: { / KUS: /
             1: 1 / alg: A128GCM (1) /
         },
         9: 1, / SMS: end-to-end (1) /
         6: null, / TSI: still TBD /
         7: null, / TSR: still TBD /
         2: h'DC88D2D51DA5ED67FC4616356BC8CA74EF9EBE8B387E623A360BA480B9B
              29D1C' / AKE bytes /
     }

  A.5.  SAFE PDU #5

     The encoded PDU #5 is following byte string:

     01410141185306684BF319BBE5B2237EF71606DB2714E0F992

     That PDU has the following decoded header, eliding the ciphertext
     message.

     1, / version /
     h'01', / partial-iv /
     h'18' / rx-sai from C_R /
     / message_3: h'0668...F992' /

     Derived from the shared secrets, the PLAINTEXT contents are the
     following:

     420102

     That plaintext has the following decoded items.

     h'0102'

     The embedded byte strings contain the following SAFE messages:

     1, / act. index /
     2 / act. step /







  Sipos                    Expires 6 December 2025               [Page 76]


  Internet-Draft                   BP SAFE                       June 2025


  Acknowledgments

     Thanks go to Leonardo Babun and Cherita Corbett of JHU/APL for pre-
     draft review and editing of this document.

  Author's Address

     Brian Sipos
     The Johns Hopkins University Applied Physics Laboratory
     11100 Johns Hopkins Rd.
     Laurel, MD 20723
     United States of America
     Email: brian.sipos+ietf@gmail.com






































  Sipos                    Expires 6 December 2025               [Page 77]


