# drafts

name: draft-mishra-oauth-agent-grants
rev: 00
title: Delegated Agent Authorization Protocol (DAAP)
time: 2026-02-27T09:36:25Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T09:36:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:03.420543+00: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.

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: ["Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:05.127413+00: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.

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]


name: draft-jiang-seat-dynamic-attestation
rev: 00
title: Dynamic Attestation for AI Agent Communication
time: 2025-11-13T08:45:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-17T08:45:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127432+00:00
abstract:
This document describes a use case for conveying remote attestation
   information in association with Transport Layer Security (TLS)
   sessions in the context of AI agent communication.  It focuses on
   long-lived secure channel sessions where an AI agent runtime posture,
   covering the platform Trusted Computing Base (TCB), agent manifest
   (models, tools and policies) and committed runtime context, can
   change frequently and unpredictably.  The document highlights
   requirements for dynamic attestation so that relying parties can base
   authorization decisions on the current runtime posture of the
   communicating agent.

full_text:
SEAT                                                            Y. Jiang
Internet-Draft                                                          
Intended status: Informational                                   D. Wang
Expires: 17 May 2026                                    13 November 2025


             Dynamic Attestation for AI Agent Communication
                draft-jiang-seat-dynamic-attestation-00

Abstract

   This document describes a use case for conveying remote attestation
   information in association with Transport Layer Security (TLS)
   sessions in the context of AI agent communication.  It focuses on
   long-lived secure channel sessions where an AI agent runtime posture,
   covering the platform Trusted Computing Base (TCB), agent manifest
   (models, tools and policies) and committed runtime context, can
   change frequently and unpredictably.  The document highlights
   requirements for dynamic attestation so that relying parties can base
   authorization decisions on the current runtime posture of the
   communicating agent.

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 17 May 2026.

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



Jiang & Wang               Expires 17 May 2026                  [Page 1]

Internet-Draft        Dynamic Attestation for SEAT         November 2025


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Dynamic Attestation for AI Agent Communication  . . . . . . .   3
     3.1.  AI Agent Runtime Attestation  . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Many deployed systems involve relatively static workloads, where
   software and configuration change primarily at onboarding or planned
   maintenance events.  In contrast, AI agents may alter effective
   behavior by updating their models, tools, and policies on timescales
   that are not necessarily aligned with TLS session establishment or
   traditional maintenance cycles.  Such updates may occur while long-
   lived TLS sessions remain open, or between sessions that are resumed
   or quickly re-established, raising security and privacy concerns
   about authorizing sensitive actions based on stale assumptions.

   Remote attestation (RA), as described in the Remote Attestation
   Procedures (RATS) architecture [RFC9334], allows a relying party to
   obtain information about the software and hardware state of a remote
   endpoint and to assess whether that state satisfies local policy.
   When combined with a secure channel protocol such as TLS 1.3
   [RFC8446], attestation information can be bound to a specific,
   authenticated session so that authorization decisions reflect the
   peer's current runtime posture (e.g., platform TCB plus an agent
   manifest covering model, tools and policy), rather than only the
   state at connection establishment.

   This document describes a use case for dynamic attestation in AI
   agent communication scenarios and outlines requirements for obtaining
   fresh, channel-bound attestation information without unnecessarily
   disrupting existing connections, allowing relying parties to base
   authorization on agent state at the time of use.





Jiang & Wang               Expires 17 May 2026                  [Page 2]

Internet-Draft        Dynamic Attestation for SEAT         November 2025


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   8174 [RFC8174] when, and only when, they appear in all capitals, as
   shown here.

   This document uses the terminology defined in the RATS architecture
   [RFC9334] and in TLS 1.3 [RFC8446], including "Attestation", "Relying
   Party", "Evidence" and "Attestation Results".

   Trusted Computing Base (TCB) of a device, is used to refer to
   security-relevant components: hardware, firmware, software, and their
   respective configurations.

   Runtime posture denotes the set of attestation-relevant claims about
   the communicating endpoint at the time of use, sufficient for a
   relying party to appraise policy.  Its exact composition is
   deployment- specific and may include claims about the platform,
   execution environment, configuration, or context.

3.  Dynamic Attestation for AI Agent Communication

   Goal: Support remote attestation for AI agent communication over
   secure channel sessions where the software and configuration on at
   least one endpoint can change on timescales that are not aligned with
   connection establishment or traditional maintenance cycles (for
   example, while long-lived sessions remain open or between sessions
   that are resumed), while the endpoint continues to exchange traffic
   with multiple network peers.

3.1.  AI Agent Runtime Attestation

   Use case: AI Agent Runtime Attestation.  An AI agent service
   communicates with other network nodes over TLS 1.3, invoking tools
   that can access sensitive data or change network state.  The agent's
   model, tools, and policies may be updated dynamically according to
   operator policy, and these updates are not guaranteed to align with
   TLS session boundaries or a fixed maintenance schedule.  Peers
   therefore need assurance that, at the time of a high-impact
   operation, the agent runs on an acceptable platform and uses an
   approved combination of model, code, and policy.








Jiang & Wang               Expires 17 May 2026                  [Page 3]

Internet-Draft        Dynamic Attestation for SEAT         November 2025


   *  Requirement 1 (fresh, channel-bound attestation): Before executing
      a high-impact operation over an existing secure channel, a peer
      MUST be able to obtain fresh attestation evidences that are
      cryptographically bound to that session and that reflect both the
      platform and the current agent-level state relevant to
      authorization, as determined by local policy.

   *  Requirement 2 (dynamic attestation): The mechanism used to obtain
      such attestation evidences SHOULD support lightweight, dynamic
      attestation without necessarily requiring a full new TLS
      handshake, so that changes to the runtime posture become visible
      to relying parties when required by local policy.

4.  Security Considerations

   Any mechanism that supports dynamic attestation for AI agent
   communication should ensure that attestation evidences are strongly
   bound to the TLS session for which they are intended, so that they
   cannot be replayed or relayed to another session or endpoint.

   Because the agent software stack can change rapidly, attestation
   evidences should be sufficiently fresh for the relying party's
   policy.  Implementations should provide a way to limit the validity
   period of evidences for a given session and to trigger attestation
   when that period expires or when relevant changes are detected.

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://datatracker.ietf.org/doc/html/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", August 2018,
              <https://datatracker.ietf.org/doc/html/rfc8446>.

   [RFC9334]  Birkholz, H., Fossati, T., Hardjono, T., and N. Smith,
              "Remote Attestation Procedures Architecture", January
              2023, <https://datatracker.ietf.org/doc/html/rfc9334>.

6.2.  Informative References




Jiang & Wang               Expires 17 May 2026                  [Page 4]

Internet-Draft        Dynamic Attestation for SEAT         November 2025


   [RFC9261]  Sullivan, N. and C. A. Wood, "Exported Authenticators in
              TLS and DTLS", July 2022,
              <https://datatracker.ietf.org/doc/html/rfc9261>.

Authors' Addresses

   Yuning Jiang
   Singapore
   Email: jiangyuning2@h-partners.com


   Donghui Wang
   China
   Email: wangdonghui124@huawei.com





































Jiang & Wang               Expires 17 May 2026                  [Page 5]


name: draft-gaikwad-woa
rev: 00
title: The Web of Agents (WoA)
time: 2025-11-30T01:42:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-03T01:42:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127435+00:00
abstract:
This document defines the Web of Agents (WoA), a minimal JSON based
   description format and invocation convention that allows HTTP hosts
   to advertise AI agents and for clients to invoke those agents in a
   uniform way.  A WoA document is typically served from a well known
   location on an HTTP origin and uses JSON Schema to describe agent
   inputs and outputs.  WoA does not define a discovery protocol itself
   but is designed to be used as a host level primitive by higher level
   discovery systems.

full_text:
Independent Submission                                        M. Gaikwad
Internet-Draft                                           1 December 2025
Intended status: Experimental                                           
Expires: 4 June 2026


                        The Web of Agents (WoA)
                          draft-gaikwad-woa-00

Abstract

   This document defines the Web of Agents (WoA), a minimal JSON based
   description format and invocation convention that allows HTTP hosts
   to advertise AI agents and for clients to invoke those agents in a
   uniform way.  A WoA document is typically served from a well known
   location on an HTTP origin and uses JSON Schema to describe agent
   inputs and outputs.  WoA does not define a discovery protocol itself
   but is designed to be used as a host level primitive by higher level
   discovery systems.

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 4 June 2026.

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.




Gaikwad                    Expires 4 June 2026                  [Page 1]

Internet-Draft                     WoA                     December 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  WoA Document Schema . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Agent Objects . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  JSON Schema Usage for Inputs and Outputs  . . . . . . . .   6
     4.3.  Transport Configurations  . . . . . . . . . . . . . . . .   6
       4.3.1.  REST Transport  . . . . . . . . . . . . . . . . . . .   7
       4.3.2.  MCP Transport . . . . . . . . . . . . . . . . . . . .   7
       4.3.3.  Private Transports  . . . . . . . . . . . . . . . . .   8
   5.  Invocation  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Invocation Envelope . . . . . . . . . . . . . . . . . . .   8
     5.2.  REST Transport Invocation . . . . . . . . . . . . . . . .   8
     5.3.  MCP Transport Invocation  . . . . . . . . . . . . . . . .   9
   6.  Authorization . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Caching . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.1.  Transport Security  . . . . . . . . . . . . . . . . . . .  10
     8.2.  Server Side Request Forgery and Origin Validation . . . .  10
     8.3.  Indirect Prompt Injection . . . . . . . . . . . . . . . .  11
     8.4.  Agent Output Trust  . . . . . . . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Well Known URI Registration . . . . . . . . . . . . . . .  11
     9.2.  Media Type Registration . . . . . . . . . . . . . . . . .  11
     9.3.  WoA Transport Registry  . . . . . . . . . . . . . . . . .  12
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   11. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Appendix A: Example Use with SOUTH (Non-Normative)  . . . . . . .  14
   Appendix B: Complete Example WoA Flow (Non-Normative) . . . . . .  16
     Example WoA Document  . . . . . . . . . . . . . . . . . . . . .  16
     Client Fetches WoA Document . . . . . . . . . . . . . . . . . .  17
     Client Invokes the Agent  . . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   AI agents are increasingly exposed as network reachable services,
   such as text based large language model interfaces, task specific
   tools, and composite workflows that call other services.  Today these
   agents are typically documented using ad hoc JSON documents or
   provider specific formats.  This makes it difficult for generic
   clients to discover which agents exist on a given origin and to
   invoke them in a predictable way.

   The Web of Agents (WoA) defines:



Gaikwad                    Expires 4 June 2026                  [Page 2]

Internet-Draft                     WoA                     December 2025


   *  a JSON based document format, usually served from a well known
      path on an origin, that lists agents and their properties

   *  a JSON Schema based description of agent inputs and outputs

   *  a small set of transport configuration objects that define how a
      client constructs an invocation request

   *  a simple invocation envelope used by some transports

   WoA is intentionally small in scope.  It does not attempt to define a
   global discovery system or a capability vocabulary.  It is designed
   to complement such systems by providing a host level primitive that
   discovery mechanisms can fetch, cache, and index.  For example, a
   cross platform discovery system such as [CUI-AGENT-DISCOVERY] could
   use WoA documents as one of its inputs when building a search index.

   This document is targeted at the Independent Submission Stream with
   category "exp".  The intent is to provide a concrete and
   implementable format that can be experimented with by client and host
   implementers.

2.  Conventions and 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.

   This document uses the JSON data model defined in [RFC8259] and HTTP
   terminology from [RFC9110].

2.1.  Terms

   WoA document  A JSON document served by an HTTP origin that describes
      one or more agents and their transport configurations according to
      this specification.

   Agent  A logical AI powered capability exposed by a host.  An agent
      has an identifier, a human readable name and description, a JSON
      Schema based input and output description, and one or more
      transport options that describe how to invoke it.

   Host  An HTTP origin that serves a WoA document and optionally
      implements one or more transports for agents described in that
      document.




Gaikwad                    Expires 4 June 2026                  [Page 3]

Internet-Draft                     WoA                     December 2025


   WoA Client  A component that retrieves the WoA document and invokes
      agents.  A WoA client may be a user facing application, an
      orchestration engine, or another independent agent, enabling agent
      to agent (A2A) interactions.

   Transport  A named mechanism that defines how a client constructs and
      sends an invocation request.  This document defines the "rest" and
      "mcp" transports.  Additional transports may be registered in the
      WoA Transport Registry.

3.  Architecture

   A typical deployment has an HTTP origin that serves a WoA document at
   a well known path, and one or more transports that accept invocation
   requests.

   +-----------+         GET /.well-known/woa.json        +-----------+
   |           | ---------------------------------------> |           |
   |   Client  |                                          |    Host   |
   |           | <--------------------------------------- |           |
   +-----------+         200 application/woa+json         +-----------+
         |
         |  Select agent and transport
         v
   +-----------+       HTTP POST (REST transport)         +-----------+
   |           | ---------------------------------------> |           |
   |   Client  |                                          |    Host   |
   |           | <--------------------------------------- |           |
   +-----------+             JSON response                +-----------+

                   Figure 1: High Level WoA Architecture

   A client fetches the WoA document from a host, selects an agent,
   chooses a transport supported by both client and host, constructs an
   invocation request according to the transport rules, and processes
   the response.  Higher level discovery systems may crawl or index WoA
   documents but are out of scope for this specification.

4.  WoA Document Schema

   A WoA document is a single JSON object with the following top level
   fields:

   *  woa_version: A string identifying the WoA document version.  For
      this specification the value MUST be the string "1".

   *  agents: An array of agent objects as defined in Section 4.1.




Gaikwad                    Expires 4 June 2026                  [Page 4]

Internet-Draft                     WoA                     December 2025


   *  transports: An object whose keys are transport names and whose
      values are transport configuration objects as defined in
      Section 4.3.

4.1.  Agent Objects

   Each element of the agents array is an object with the following
   fields:

   *  id (string, REQUIRED): A token that uniquely identifies the agent
      within the WoA document.  The value MUST match the following ABNF
      (using [RFC5234]):

   agent-id = 1*( ALPHA / DIGIT / "-" / "_" )

   *  name (string, REQUIRED): A short, human readable name for the
      agent.

   *  description (string, REQUIRED): A human readable description of
      what the agent does.  Clients MUST treat this field as untrusted
      input for security reasons (see Section 8).

   *  version (string, OPTIONAL): A version identifier for the agent
      implementation, such as "1.0.0".

   *  capabilities (array of strings, OPTIONAL): A list of capability
      identifiers.  This specification does not define a controlled
      vocabulary.  Implementations MAY use URIs (for example,
      "https://example.com/capability/summarization") or URN like
      identifiers as long as they are stable.

   *  inputs (object, REQUIRED): A JSON Schema document that describes
      the expected request body when invoking the agent.  See
      Section 4.2.

   *  outputs (object, REQUIRED): A JSON Schema document that describes
      the successful response body produced by the agent.

   *  transports (array of strings, REQUIRED): Names of transport
      configurations (keys in the top level transports object) that can
      be used to invoke this agent.

   *  operations (array of objects, OPTIONAL): A list of operation
      descriptors for agents that support multiple logical operations
      via a single transport endpoint.  If operations is not present,
      the agent is considered to have a single unnamed operation.

   Each operation object in the operations array has:



Gaikwad                    Expires 4 June 2026                  [Page 5]

Internet-Draft                     WoA                     December 2025


   *  name (string, REQUIRED): A token naming the operation.

   *  description (string, REQUIRED): Human readable description of the
      operation.

   *  inputs (object, OPTIONAL): JSON Schema overriding the agent level
      inputs for this operation.

   *  outputs (object, OPTIONAL): JSON Schema overriding the agent level
      outputs for this operation.

   Clients MUST NOT assume that two agents with the same id on different
   origins have the same behavior or schema.

4.2.  JSON Schema Usage for Inputs and Outputs

   The inputs, outputs, and any operation level inputs or outputs fields
   MUST be valid JSON Schema documents compliant with the JSON Schema
   2020-12 core and validation specifications [JSON-SCHEMA-CORE]
   [JSON-SCHEMA-VAL].

   At minimum, implementations MUST support JSON Schema documents whose
   root is an object with:

   *  a type of "object"

   *  a properties object describing named properties

   *  an optional required array naming required properties

   More advanced JSON Schema features such as oneOf, allOf, and format
   MAY be used by hosts and SHOULD be ignored by clients that do not
   understand them, as long as the client can still construct a
   conforming request.

   Hosts SHOULD provide concise and accurate JSON Schema documents to
   enable static validation and tooling.  Clients MAY validate request
   bodies locally against the inputs schema before sending them and MAY
   validate successful responses against the outputs schema.

4.3.  Transport Configurations

   The top level transports object maps transport names to configuration
   objects.  Transport names are strings.  This document defines the
   rest and mcp transports.  Additional transports MAY be defined and
   registered in the WoA Transport Registry (see Section 9.3).





Gaikwad                    Expires 4 June 2026                  [Page 6]

Internet-Draft                     WoA                     December 2025


4.3.1.  REST Transport

   A rest transport configuration object MUST contain:

   *  base (string, REQUIRED): An absolute HTTPS URL that identifies the
      base of the REST API.  The URL scheme MUST be "https" and the
      server SHOULD support TLS 1.3 [RFC8446].

   *  invoke_path (string, REQUIRED): An absolute path beginning with
      "/" that, when combined with base, yields the invocation URL
      template.  The path MAY contain a query component.  Within the
      path, the case sensitive substring "{agent_id}" MAY appear as a
      placeholder.

   To construct the invocation URL, the client concatenates the base URL
   and the invoke_path value.  If the invoke_path contains the case
   sensitive substring "{agent_id}", the client MUST replace it with the
   target agent's id value.

   Clients invoking an agent via the REST transport MUST use HTTP POST
   and MUST send a request body encoded as JSON with media type
   application/json.  The request body for the REST transport is defined
   in Section 5.  Hosts using the REST transport MUST respond with JSON
   and SHOULD use the application/problem+json media type for errors as
   specified in [RFC9457].

4.3.2.  MCP Transport

   A mcp transport configuration object describes how an agent is
   exposed via a Model Context Protocol (MCP) server [MCP].  The
   configuration object MUST contain:

   *  server (string, REQUIRED): An identifier or URL for the MCP server
      endpoint.  The exact format is defined by the MCP specification.

   *  tool_namespace (string, REQUIRED): A string that identifies the
      logical namespace of tools on the MCP server.

   *  tool_field (string, REQUIRED): The name of the field in the
      invocation envelope that contains the tool name for this MCP
      server.

   When using the MCP transport, the client translates the WoA
   invocation envelope into the appropriate MCP tool invocation as
   defined by the MCP specification [MCP].  For example, if tool_field
   is "agent", the client MAY pass the value of the envelope's agent
   field as the tool name.




Gaikwad                    Expires 4 June 2026                  [Page 7]

Internet-Draft                     WoA                     December 2025


4.3.3.  Private Transports

   Hosts MAY define private transport names for experimental use.
   Private transport names MUST use a reverse DNS prefix, such as
   "com.example.mytransport", to avoid collisions with registered
   transports.  Private transports MUST NOT be registered in the WoA
   Transport Registry.

5.  Invocation

   This section describes the invocation envelope and how it is used
   with the REST and MCP transports.  Other transports MAY define their
   own invocation rules.

5.1.  Invocation Envelope

   When a transport uses a JSON request body that contains metadata
   about the invocation in addition to the agent specific input object,
   this document refers to that JSON object as the "invocation
   envelope".

   For the REST transport defined in this document, the invocation
   envelope is an object with the following fields:

   *  agent (string, REQUIRED): The agent identifier as listed in the
      WoA document.

   *  operation (string, OPTIONAL): The operation name, if the agent
      defines an operations array.  If omitted for an agent that defines
      operations, the name "default" is RECOMMENDED as the implied
      operation.

   *  input (object, REQUIRED): A JSON object that MUST conform to the
      JSON Schema specified in the selected operation's inputs schema,
      or to the agent level inputs if there is no per operation
      override.

   Transports MAY add additional fields to the invocation envelope as
   long as they do not conflict with the fields defined above.

5.2.  REST Transport Invocation

   When using the REST transport, the client constructs the invocation
   URL as described in Section 4.3.1 and sends an HTTP POST request with
   media type application/json and a request body containing the
   invocation envelope.





Gaikwad                    Expires 4 June 2026                  [Page 8]

Internet-Draft                     WoA                     December 2025


   The agent field in the envelope MUST match the intended agent's id.
   If the REST invocation URL template includes an "{agent_id}"
   placeholder, the host can infer the agent from the URL.  In that
   case:

   *  If the host derives an agent identifier from the URL and the agent
      field is absent in the envelope, the host MAY use the identifier
      from the URL.

   *  If the host derives an agent identifier from the URL and the
      envelope contains an agent field with a different value, the host
      MUST reject the request with HTTP status 400 (Bad Request).  The
      host SHOULD return a application/problem+json body explaining the
      mismatch.

   On success, the host MUST return a 2xx status code and a JSON
   response body that conforms to the JSON Schema specified in the
   selected operation's outputs schema, or the agent level outputs
   schema if there is no per operation override.

   On error, the host SHOULD return a 4xx or 5xx status code and a
   response body using the problem details format defined in [RFC9457]
   with media type application/problem+json.  Problem type URIs and
   error code taxonomies are deployment specific.

5.3.  MCP Transport Invocation

   When using the MCP transport, the client translates the invocation
   envelope into the appropriate MCP tool invocation.  The exact mapping
   is defined by the MCP specification [MCP] and is not repeated here.
   As a typical pattern, the agent or operation fields of the envelope
   may map to tool names and the input object may map to MCP tool
   arguments.

   WoA does not define the wire protocol for MCP and does not impose
   additional security requirements beyond those defined by the MCP
   specification.  The security considerations in Section 8 still apply
   to the host that publishes the WoA document.

6.  Authorization

   WoA deliberately separates the question of "which agent exists and
   how can it be invoked" from "who is allowed to invoke this agent".
   The WoA document format does not contain access tokens and does not
   mandate a particular authorization protocol.  Hosts MAY use OAuth 2.0
   [RFC6749], mutual TLS, or other mechanisms to protect invocation
   endpoints.




Gaikwad                    Expires 4 June 2026                  [Page 9]

Internet-Draft                     WoA                     December 2025


   A host MAY include additional metadata in the WoA document to help
   clients understand the authorization expectations for an agent.  For
   example, a deployment using the SOUTH stochastic authorization
   protocol [I-D.gaikwad-south-authorization] might include an authz
   object with pointers to policy endpoints.  Such metadata is
   deployment specific and out of scope for the core WoA specification.

7.  Caching

   WoA documents are likely to be fetched frequently by clients and
   discovery systems.  Hosts SHOULD include HTTP caching headers, such
   as ETag, Last-Modified, and appropriate Cache-Control directives, on
   responses that carry a WoA document to reduce unnecessary network
   traffic.  Clients SHOULD honor these headers when polling for
   updates.

8.  Security Considerations

   WoA is a descriptive format and does not execute code by itself, but
   it is used in contexts where agents may execute untrusted input or
   perform sensitive actions.  Both hosts and clients need to consider
   the following security aspects.

8.1.  Transport Security

   Hosts that serve WoA documents and implement REST transports MUST use
   HTTPS.  The underlying TLS version SHOULD be TLS 1.3 [RFC8446].
   Clients MUST validate server certificates according to normal HTTPS
   rules.  Plain HTTP MUST NOT be used for WoA documents or REST
   invocations on the open Internet.

8.2.  Server Side Request Forgery and Origin Validation

   A malicious WoA document could advertise transport URLs that point to
   internal or otherwise sensitive endpoints.  Automated clients that
   unconditionally invoke agents based on WoA documents risk being used
   as a vector for server side request forgery.

   Clients SHOULD validate that transport URLs provided in a WoA
   document resolve to allowed domains or IP address ranges before
   invoking agents.  In particular, clients SHOULD NOT automatically
   send invocation requests to URLs that resolve to private or link
   local address ranges, such as those defined in [RFC1918], unless
   explicitly configured to do so by an administrator.  Clients SHOULD
   also be cautious of HTTP redirects that change the authority
   component of the URL and SHOULD apply the same validation to the
   redirect target.




Gaikwad                    Expires 4 June 2026                 [Page 10]

Internet-Draft                     WoA                     December 2025


8.3.  Indirect Prompt Injection

   The name and description fields of an agent are free form strings
   controlled by the host.  Clients that use a large language model to
   reason about or select agents based on these fields MUST treat them
   as untrusted input.  A malicious host could embed text that attempts
   to influence the client side model in ways that bypass user intent, a
   pattern sometimes referred to as indirect prompt injection.

   Implementers SHOULD design any agent selection logic that uses LLMs
   with appropriate input isolation, such as explicit system level
   instructions that describe which fields are trusted and which are
   untrusted, and with guardrails that restrict the actions that can be
   taken based on WoA content.

8.4.  Agent Output Trust

   WoA itself does not provide integrity or authenticity guarantees for
   agent outputs.  Clients SHOULD treat agent responses as untrusted
   data and apply appropriate validation, sandboxing, and authorization
   checks before using them to take actions such as executing code,
   issuing network requests, or changing external state.

9.  IANA Considerations

9.1.  Well Known URI Registration

   This document requests registration of a new well known URI suffix in
   the "Well Known URIs" registry as defined in [RFC8615].

   The registration template is:

   URI suffix: woa.json
   Change controller: IETF
   Specification document: This document
   Status: permanent
   Related information: none

9.2.  Media Type Registration

   This document requests registration of the application/woa+json media
   type in the "Media Types" registry according to [RFC6838].

   The registration template is:







Gaikwad                    Expires 4 June 2026                 [Page 11]

Internet-Draft                     WoA                     December 2025


   Type name: application
   Subtype name: woa+json
   Required parameters: none
   Optional parameters: none
   Encoding considerations: binary
     WoA documents are encoded as UTF-8 JSON text.
   Security considerations: See Section 7 of this document.
   Interoperability considerations: none
   Published specification: This document.
   Applications that use this media type:
     WoA hosts and clients that exchange WoA documents.
   Fragment identifier considerations: none
   Additional information: none
   Person & email address to contact:
     Madhava Gaikwad <gaikwad.madhav@gmail.com>
   Intended usage: COMMON
   Restrictions on usage: none
   Author: Madhava Gaikwad <gaikwad.madhav@gmail.com>
   Change controller: IETF

9.3.  WoA Transport Registry

   This document requests the creation of a new registry titled "WoA
   Transport Registry".  The registry records transport names used in
   the top level transports object of WoA documents.

   Each entry in the registry has the following fields:

   *  Transport name: a short string identifying the transport.

   *  Reference: a stable specification that defines the transport.

   Registration policy for the WoA Transport Registry is "Specification
   Required" as defined in [RFC8126].

   This document registers the following initial entries:

   Transport name: rest
   Reference: This document

   Transport name: mcp
   Reference: Model Context Protocol specification [MCP]

10.  Normative References







Gaikwad                    Expires 4 June 2026                 [Page 12]

Internet-Draft                     WoA                     December 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>.

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

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC9110]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
              Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June
              2022, <https://www.rfc-editor.org/info/rfc9110>.

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

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [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://www.rfc-editor.org/info/rfc6838>.

   [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
              for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
              <https://www.rfc-editor.org/info/rfc9457>.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

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



Gaikwad                    Expires 4 June 2026                 [Page 13]

Internet-Draft                     WoA                     December 2025


   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [JSON-SCHEMA-CORE]
              Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
              Schema: A Media Type for Describing JSON Documents",
              December 2020,
              <https://json-schema.org/draft/2020-12/json-schema-core>.

   [JSON-SCHEMA-VAL]
              Wright, A., Andrews, H., and B. Hutton, "JSON Schema
              Validation: A Vocabulary for Structural Validation of
              JSON", December 2020, <https://json-schema.org/draft/2020-
              12/json-schema-validation>.

   [I-D.gaikwad-south-authorization]
              Gaikwad, M., "SOUTH: Stochastic Authorization for Agent
              and Service Requests", Work in Progress, Internet-Draft,
              draft-gaikwad-south-authorization, October 2025,
              <https://datatracker.ietf.org/doc/draft-gaikwad-south-
              authorization/>.

11.  Informative References

   [CUI-AGENT-DISCOVERY]
              Cui, Y., Chao, Y., and C. Du, "HTTP-Based AI Agent
              Discovery and Invocation Protocol", Work in Progress,
              Internet-Draft, draft-cui-ai-agent-discovery-invocation,
              October 2025, <https://datatracker.ietf.org/doc/draft-cui-
              ai-agent-discovery-invocation/>.

   [MCP]      Anthropic, "Model Context Protocol Specification",
              November 2024, <https://modelcontextprotocol.io>.

Appendix A: Example Use with SOUTH (Non-Normative)

   This appendix sketches how a deployment might combine WoA with the
   SOUTH stochastic authorization protocol
   [I-D.gaikwad-south-authorization].  It is non-normative and does not
   modify the core WoA format.

   A host could add an authz object at the top level of the WoA document
   or within an agent object that points to a SOUTH policy endpoint.
   For example:





Gaikwad                    Expires 4 June 2026                 [Page 14]

Internet-Draft                     WoA                     December 2025


   {
     "woa_version": "1",
     "agents": [
       {
         "id": "summarizer",
         "name": "Document Summarizer",
         "description": "Summarizes English text.",
         "version": "1.0.0",
         "capabilities": [
           "https://example.com/capability/summarization"
         ],
         "inputs": { "...": "JSON Schema elided" },
         "outputs": { "...": "JSON Schema elided" },
         "transports": ["rest"],
         "authz": {
           "scheme": "south",
           "policy_uri":
             "https://authz.example.com/south/policies/summarizer",
           "token_header": "Authorization"
         }
       }
     ],
     "transports": {
       "rest": {
         "base": "https://api.example.com",
         "invoke_path": "/agents/{agent_id}/invoke"
       }
     }
   }

   A client that understands SOUTH could first obtain a token from the
   SOUTH authorization server according to
   [I-D.gaikwad-south-authorization] and then include it as a SOUTH
   token in the HTTP request:

   POST /agents/summarizer/invoke HTTP/1.1
   Host: api.example.com
   Content-Type: application/json
   Authorization: SOUTH eyJhbGciOi...

   {
     "agent": "summarizer",
     "operation": "default",
     "input": {
       "text": "Long document text here..."
     }
   }




Gaikwad                    Expires 4 June 2026                 [Page 15]

Internet-Draft                     WoA                     December 2025


   The details of how SOUTH evaluates policies and issues tokens are
   defined in [I-D.gaikwad-south-authorization] and are not repeated
   here.

Appendix B: Complete Example WoA Flow (Non-Normative)

   This appendix provides a complete example showing a WoA document, a
   client fetching it, invoking an agent via the REST transport, and
   receiving a successful response.

Example WoA Document

   Consider a host at https://api.example.com that serves the following
   WoA document at https://api.example.com/.well-known/woa.json using
   the application/woa+json media type.

   {
     "woa_version": "1",
     "agents": [
       {
         "id": "summarizer",
         "name": "Document Summarizer",
         "description": "Summarizes English text.",
         "version": "1.0.0",
         "capabilities": [
           "https://example.com/capability/summarization"
         ],
         "inputs": {
           "$schema": "https://json-schema.org/draft/2020-12/schema",
           "type": "object",
           "properties": {
             "text": {
               "type": "string",
               "description": "Input document text in English."
             },
             "max_words": {
               "type": "integer",
               "minimum": 10,
               "maximum": 500,
               "description": "Maximum number of words in the summary."
             }
           },
           "required": ["text"]
         },
         "outputs": {
           "$schema": "https://json-schema.org/draft/2020-12/schema",
           "type": "object",
           "properties": {



Gaikwad                    Expires 4 June 2026                 [Page 16]

Internet-Draft                     WoA                     December 2025


             "summary": {
               "type": "string",
               "description": "The generated summary."
             }
           },
           "required": ["summary"]
         },
         "transports": ["rest"],
         "operations": [
           {
             "name": "default",
             "description": "Default summarization operation."
           }
         ]
       }
     ],
     "transports": {
       "rest": {
         "base": "https://api.example.com",
         "invoke_path": "/agents/{agent_id}/invoke"
       }
     }
   }

Client Fetches WoA Document

   A client fetches the WoA document:

   GET /.well-known/woa.json HTTP/1.1
   Host: api.example.com
   Accept: application/woa+json, application/json

   The host responds:

   HTTP/1.1 200 OK
   Content-Type: application/woa+json
   ETag: "abc123"
   Cache-Control: max-age=300

   { ... JSON from previous section ... }

   The client parses the JSON, locates the agent with id "summarizer",
   and notes that it supports the rest transport.








Gaikwad                    Expires 4 June 2026                 [Page 17]

Internet-Draft                     WoA                     December 2025


Client Invokes the Agent

   The client constructs the invocation URL by concatenating the base
   and invoke_path values and substituting "{agent_id}" with
   "summarizer":

   https://api.example.com/agents/summarizer/invoke

   The client then builds an invocation envelope that conforms to the
   agent's inputs schema:

   {
     "agent": "summarizer",
     "operation": "default",
     "input": {
       "text": "The IETF is an open community of designers.",
       "max_words": 40
     }
   }

   The client sends the HTTP request:

   POST /agents/summarizer/invoke HTTP/1.1
   Host: api.example.com
   Content-Type: application/json
   Accept: application/json

   {
     "agent": "summarizer",
     "operation": "default",
     "input": {
       "text": "The IETF is an open community of designers.",
       "max_words": 40
     }
   }

   The host validates the request against the JSON Schema in inputs,
   performs the summarization, and returns a response that matches the
   outputs schema:

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "summary": "The IETF is a community focused on Internet evolution."
   }





Gaikwad                    Expires 4 June 2026                 [Page 18]

Internet-Draft                     WoA                     December 2025


   The client MAY validate the response body against the outputs schema
   and then present the summary to the user or feed it into subsequent
   processing.

Author's Address

   Madhava Gaikwad
   Email: gaikwad.madhav@gmail.com











































Gaikwad                    Expires 4 June 2026                 [Page 19]


name: draft-ietf-lisp-nexagon
rev: 57
title: Geo-Intelligence Network Based On H3 and LISP
time: 2025-09-23T12:45:25Z
group_uri: /api/v1/group/group/1751/
expires: 2026-03-27T12:45:25Z
shepherd: /api/v1/person/email/ggx@gigix.net/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127439+00:00
abstract:
Lisp-Nexagon is a geospatial intelligence network protocol designed
to support physical-world applications such as transportation, public
safety, and logistics. It combines the Locator/ID Separation Protocol
(LISP) with the H3 spatial indexing system to enable distributed
agents to report, aggregate, and disseminate geospatial state
information.

full_text:
LISP Working Group                                           S. Barkai
Internet-Draft                                               Oterra.ai
Intended status: Informational                       B. Fernandez-Ruiz
Expires: March 24, 2026                                    Nexar Inc.
                                                              R. Tamir
                                                              Ariga.io
                                                    A. Rodriguez-Natal
                                                              F. Maino
                                                         Cisco Systems
                                                  A. Cabellos-Aparicio
                                                 J. Paillisse-Vilanova
                                  Universitat Politecnica de Catalunya
                                                          D. Farinacci
                                                           lispers.net
                           September 24, 2025


             Geo-Intelligence Network Based On H3 and LISP
                      draft-ietf-lisp-nexagon-57.txt


Abstract

Lisp-Nexagon is a geospatial intelligence network protocol designed 
to support physical-world applications such as transportation, public
safety, and logistics. It combines the Locator/ID Separation Protocol
(LISP) with the H3 spatial indexing system to enable distributed 
agents to report, aggregate, and disseminate geospatial state 
information.






Barkai, et al.          Expires March 24, 2026             [Page 1]

Internet-Draft                     LISP              September 2025

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 October 1,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 Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   5
 3.  Deployment Assumptions  . . . . . . . . . . . . . . . . . . .   7
 4.  Clients-Agents Networking . . . . . . . . . . . . . . . . . .   8
 5.  Mobility Unicast and Multicast  . . . . . . . . . . . . . . .   9
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
 7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
 8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
 9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
10.  Normative References  . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses   . . . . . . . . . . . . . . . . . . . . . . .  19

Barkai, et al.          Expires March 24, 2026             [Page 2]

Internet-Draft                     LISP              September 2025

1.  Introduction

Lisp-Nexagon is a geospatial intelligence network protocol designed 
to support physical-world applications such as transportation, public
safety, and logistics. It combines the Locator/ID Separation Protocol
(LISP) with the [H3] spatial indexing system to enable distributed 
agents to report, aggregate, and disseminate geospatial state 
information.

The system models geospatial data flow and control after the 
management planes found in digital infrastructure to facilitate
autonomous systems support in physical environments. Geospatial 
intelligence is organized by H3 tiles at varying resolutions. High-
resolution (small-area) tiles are used to represent specific 
environmental and infrastructural conditions such as road status,
vegetation coverage, fire activity, weather, and physical
obstructions. Data for these tiles is produced by interoperating
sources and collected by geo-aggregation agents.

Each aggregation agent is assigned a low-resolution (large-area) H3
tile that defines its jurisdiction. This jurisdiction is associated
with a LISP Endpoint Identifier (EID), which acts as the routing and
addressing point for intelligence updates. Agents receive input from
data sources within their jurisdiction and provide processed
information or notifications to clients authorized to query or 
subscribe to state data.

Lisp-Nexagon provides a framework for structured, addressable, and 
jurisdiction-based geospatial coordination using existing LISP 
mechanisms and H3 spatial semantics.

Barkai, et al.          Expires March 24, 2026            [Page 3]

Internet-Draft                     LISP             September 2025


The network requires a formal provisioning step for sources, 
clients, and agents. For sources and destinations, this step 
involves an authentication, authorization, and accounting (AAA) 
procedure through which endpoints request and renew EIDs and LISP
tunnel-routers (XTR) to interact through.
                                 ___
                               /     \
                      EID >>    States  >> EID
                      Upload   \ ___ /     Channels
                       /\     Functions()      \/

                        Figure 1:H3-LISP Agents


   Off-Peak EID 
  Condensed Allocation
   _  _    _  _
  / \/ \  / \/ \   n+1
  \_/\_/  \_/\_/  ----         Peak allocation for same EID
  / \/ \  / \/ \  ----       Spread on more compute locations
  \_/\_/  \_/\_/  ----       _  _    _  _    _  _    _  _    n+1
  / \/ \  / \/ \  ----      / \/ \  / \/ \  / \/ \  / \/ \  ----
  \_/\_/  \_/\_/  ----      \_/\_/  \_/\_/  \_/\_/  \_/\_/  ----
  / \/ \  / \/ \  ----      / \/ \  / \/ \  / \/ \  / \/ \  ----
  \_/\_/  \_/\_/  ----      \_/\_/  \_/\_/  \_/\_/  \_/\_/  ----

   Site   Site               Site    Site    Site    Site  

         Figure 2: Dynamic allocation per activity



Barkai, et al.          Expires March 24, 2026           [Page 4]

Internet-Draft                     LISP            September 2025


2. Definition of Terms

  Based on [RFC9300][RFC9301]

  H3AgentEID: H3AgentEID is an EID-addressable Geolocation agent,
    also known as a nexagon. It serves as a designated destination for
    Geolocation aggregation and an (S,G) source of multicast themed
    channels. It has a LISP data-plane stack to encapsulate
    packets via ServerXTR.

  ServerXTR: ServerXTR is a data-plane only LISP protocol stack
    implementation that is co-located with the H3AgentEID process. It
    encapsulates and decapsulates packets to and from EdgeRTRs.

  MobilityClient: MobilityClient is an application that may be a part
    of a driving system or mobility application, It has a LISP data-
    plane stack to encapsulate packets via ClientXTR.

  MobilityClientEID: MobilityClientEID is the IPv6 EID used by 
    Mobility Clients. The destination of such packets are H3AgentEIDs.
    The EID is assigned as part of the MobilityClient network AAA.

  ClientXTR: ClientXTR is a data-plane only LISP protocol stack
    implementation co-located with the Mobility Client application. 
    It encapsulates and decapsulates packets to and from EdgeRTRs.

  EdgeRTR: The EdgeRTR network is responsible for connecting Mobility 
    Clients to Agents and managing MobilityClientEIDs multicast 
    registrations [RFC8378]. The network achieves this by using 
    encapsulation to aggregate Mobility Clients and Geolocation 
    Agents, making it easier to access the mobility network from 
    hosting providers and mobile providers.

The RTRs within the EdgeRTR network re-encapsulate packets from 
ClientXTRs, ServerXTRs, and remote RTRs. During packet decapsulation, 
EdgeRTRs glean H3 agent EIDs and MobilityClientEIDs and store them 
along with route locations (RLOCs) in map-caches. These mappings are
then registered to the LISP mapping system [RFC9301] and are 
provisioned when Geolocation Agents are assigned to EdgeRTRs.
It's key to note that EdgeRTRs do not register MobilityClientEIDs. 
Enterprises can provide their own EdgeRTRs to protect the geo-privacy. 




Barkai, et al.          Expires March 24, 2026          [Page 5]

Internet-Draft                     LISP           September 2025
                               
                          ___                                  ___
   H3AgentEIDs     ___  /     \           H3AgentEIDs   ___  /     \
            ___  /     | h3.rB |                 ___  /     | h3.rB |
          /     | h3.rB \ ___ /                /     | h3.rB \ ___ /
         | h3.rB \ ___ /  sXTR                | h3.rB \ ___ /  sXTR
          \ ___ /  sXTR   ||                   \ ___ /  sXTR    ||
            sXTR   ||     ||                    sXTR     ||     ||
             ||    ||     ||                      ||     ||     ||
             ||    ||     ||                      ||     ||     ||
                        EdgeRTR                EdgeRTR 
                           (                      )
                          (    Underlay Cloud      )
                           (                      )
                         EdgeRTR               EdgeRTR 
                         ||                    ||
                         ||                    ||
            MobilityClientA::cXTR   cXTR::MobilityClientB  
                |          ___    ___    ___     |              
               App       /     \/     \/     \ Source
                          h3.rS  h3.rS  h3.rS    
                         \ ___ /\ ___ / \ __ /
     
     
                       Figure 3: H3-LISP Network

  - MobilityClientA source detections used by MobilityClientB app
  - Sources share information only through the Geolocation agents
  - ClientXTR (cXTR):encapsulates packets over access to EdgeRTR
  - ServerXTR (sXTR):encapsulates packets over metro area to EdgeRTR
  - Notifications: from Geolocation agents replicated by EdgeRTRs


Barkai, et al.          Expires March 24, 2026          [Page 6]

Internet-Draft                     LISP           September 2025

3.  Deployment Assumptions
 
The authorization of Mobility Clients to the mobility network is 
renewed while driving. The AAA procedure described below can be used
as an example for obtaining EIDs and EdgeRTRs, and for enabling the
use of the network. Diameter [RFC6733] based AAA can be used:  
   1) obtain the address of the mobility-network AAA using DNS
   2) obtain MobilityClientEIDs and EdgeRTRs from AAA procedure
   3) renewed periodically from AAA while using the network

     MobilityClient DomainNameServer    AAA Server   MobilityEdgeRTR
     |                    |                   |                    |
     | lookup AAA Server  |                   |                    |
     |------------------->|                   |                    |
     |<-------------------|                   |                    |
     |   AAA  Server IP   |                   |                    |
     |                    |                   |                    |
     |  Client identifier and credentials     |                    |
     |--------------------------------------->|                    |
     |                    |                   |Provision Client EID|
     |                    |                   |------------------->|
     |                    |                   |<-------------------|
     |                    |                   | Ack Provisioned EID|
     |  Send ClientEID,EdgeRTR RLOC           |                    |
     |<---------------------------------------|                    |
     .                                                             .
     .       Use The H3-LISP Geolocation Mobility Network          .
     .                                                             .
     |<----------------------------------------------------------->|
     .    Renew AAA ClientEID and EdgeRT provisioning              .   

        Figure 4: Example AAA procedure for mobility clients

  Detections are enumerated in 16 fields x 16 enumerations. Nibbles
  named using hexadecimal index according to the position where most
  significant nibble has index 0. Enumerations defined in section 8.

    0       1       2       3       4       5       6       7
    +-------+-------+-------+-------+-------+-------+-------+-------+
    |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
    |012301230123012301230123 Index  01230123012301230123012301230123
    +---------------------------------------------------------------+
            Figure 5: Nibble based detection enumeration

Barkai, et al.          Expires March 24, 2026          [Page 7]

Internet-Draft                     LISP           September 2025


4. Clients-Agents Networking

 The mobility network functions as a standard LISP overlay that
 delivers unicast and multicast packets across data plane XTRs, which
 are used in the stack of each mobility client and server. ClientXTRs
 and ServerXTRs are associated with EdgeRTRs, which allows
 MobilityClients to "show up" at any location within the mobility
 network, regardless of the network provider or network address
 translation domain. This structure also enables any H3 agent EID to
 be instantiated, delegated, or failed over to any compute location.
 In this specification, we assume a semi-random association between
 ClientXTRs and EdgeRTRs assigned by the AAA procedure, with a pool of
 EdgeRTRs, which can be dynamically allocated, distributing the load
 of MobilityClients within a given metro area. We also assume that
 EdgeRTRs are topologically equivalent and use LISP to encapsulate
 traffic to and from other EdgeRTRs. It is possible for there to be
 more than one ClientEID in the same process using the same ClientXTR.
 The implementation of such multiplexing is not specified.

          H3AgentEID == ServerXTR        ServerXTR == H3AgentEID
         (Encryption Decryption)         (Encryption Decryption)
                                  ^     ^
                             EdgeRTR X EdgeRTR
                                  v     v
            (Encryption Decryption)     (Encryption Decryption)
      MobilityClient <> ClientXTR        ClientXTR <> MobilityClient

  Figure 6: LISP network connecting MobilityClients and H3AgentEIDs

  Encode HID to EID:
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI = 16387         |     Rsvd1     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |               |            Length = 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             HID (high-order)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             HID (low-order)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 7: Encoding HIDs in H3AgentEIDs

Barkai, et al.          Expires March 24, 2026          [Page 8]

Internet-Draft                     LISP           September 2025

5. Mobility Unicast and Multicast

 The day in a life of unicast road-segment mapping upload:

  1. A client detects condition of interest using AI camera
  2. The client uses its GPS to establish its h3.rS location
  3. It then estimates the h3.rS location of the detection
  4. Detection h3.rS center is used to calculate h3.rB => H3ServerEID
  5. Client sends (encrypted) location-detection via its ClientXTR

    Outer Header src/dest: ClientXTR RLOC, EdgeRTR RLOC
    Inner Header src/dest: ClientEID, H3AgentEID

  6. EdgeRTR gleans and caches ClientEID and ClientXTR RLOC
  7. EdgeRTR resolves RLOC of remote EdgeRTR, and re-encapsulates:

    Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC
    Inner Header src/dest: ClientEID, H3AgentEID

  8. Remote EdgeRTR lookups H3ServerEID ServerXTR RLOC, 
     re-encapsulates:

    Outer Header src/dest: EdgeRTR RLOC, ServerXTR RLOC
    Inner Header src/dest: ClientEID, H3AgentEID

  9. ServerXTR delivers ClientEID message to H3AgentEID

 The detection message headers consist of the following fields:

  - Outer headers size = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56
  - Inner headers size = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52
  - 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload size


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|  Type         |gzip |        Reserved         | Pair Count = X |NXGN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

                    Figure 8: Nexagon header format

 Nexagon Header allows for key-value (kv) tuples or value-key,key
 ...(vkkk) using the same formats of key and value outlined bellow:



Barkai, et al.          Expires March 24, 2026          [Page 9]

Internet-Draft                     LISP           September 2025

 Nexagon Header Type 0:reserved (*)
 Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs
 Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 h3.rS IDs
 Type 3-255: unassigned
 Nexagon Header GZIP field: 0x000 no compression, or(**) GZIP version.
 Nexagon Header Reserved bits
  Nexagon Header key and value count (in any format kv or vkkk)

(*)  Reserved fields are specified as being set to 0 on transmission,
       ignored when received.
(**) GZIP refers to entire kv or vkkk payload and major GZIP version,
       packets with unsupported GZIP version are dropped
































Barkai, et al.          Expires March 24, 2026         [Page 10]

Internet-Draft                     LISP           September 2025



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|Version| Traffic Class |           Flow Label                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         Payload Length        |  Next Header  |   Hop Limit   |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                                                               +  |
|                                                               |  |
+                    Source MobilityClientEID                   +  |
|                                                               | IPv6
+                                                               +  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                                                               +  |
|                                                               |  |
+                       Dest H3AgentEID                         +  |
|                                                               |  |
+                                                               +  |
|                                                               | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Source Port = xxxx      |       Dest Port = xxxx        | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
|           UDP Length          |        UDP Checksum           | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|  Type         |gzip |        Reserved         | Pair Count =  | NXGN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit State                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 9: Uploaded detections packet format



Barkai, et al.          Expires March 24, 2026         [Page 11]

Internet-Draft                     LISP           September 2025


 Each H3Agent is also an IP Multicast Source used to update
 subscribers on the state of the h3.rS tiles in the h3.rB area.
 We use [RFC8378] signal-free multicast to implement overlay channels.
 Mobility-networks have many channels with thousands subscribers each.
 MobilityClients driving through/subscribing to an h3.rB area issue
 group address report based on any mechanism supported by [RFC8378].
 Example report formats are specified in [RFC4604]. It is advised that
 clients establish a ring of objects on their areas of interest.
 Report messages are encapsulated between ClientXTRs and EdgeRTRs.

 The day in a life of multicast notification update:

 1. H3AgentEID determines change or timing requiring an update

 2. H3AgentEID sends (S,G) update message via its ServerXTR

     Outer Header src/dest: ServerXTR RLOC, EdgeRTR RLOC
     Inner Header (S,G): H3ServerEID, EID chosen for theme

 3. EdgeRTR resolves subscribed remote EdgeRTRs, replicates

     Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC
     Inner Header (S,G): H3ServerEID, EID chosen for theme

 4. EdgeRTRs lookups ClientEIDs ClientXTRs RLOCs, replicates

     Outer Header src/dest: EdgeRTR RLOC, ClientXTR RLOC
     Inner Header (S,G): H3ServerEID, EID chosen for theme

 5. ClientXTR delivers multicast channel update message to clientEID













Barkai, et al.          Expires March 24, 2026         [Page 12]

Internet-Draft                     LISP           September 2025




Multicast update packets are of the following structure:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|Version| Traffic Class |           Flow Label                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         Payload Length        |  Next Header  |   Hop Limit   |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                                                               +  |
|                                                               |  |
+                      Source H3AgentEID                   +  |
|                                                               | IPv6
+                                                               +  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                                                               +  |
|                                                               |  |
+                          Group Address                        +  |
|                                                               |  |
+                                                               +  |
|                                                               | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Source Port = xxxx      |       Dest Port = xxxx        | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
|           UDP Length          |        UDP Checksum           | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|                                                               |NXGN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
~                            Nexagons Payload                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 10: multicast update packet header






Barkai, et al.          Expires March 24, 2026         [Page 13]

Internet-Draft                     LISP           September 2025




 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|  Type =   1   |gzip |        Reserved         | Pair Count = X|NXGN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit State                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit State                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11: multicast update payload, key-value, key-value..


















Barkai, et al.          Expires March 24, 2026        [Page 14]

Internet-Draft                     LISP          September 2025


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
|  Type =   2   |gzip |     Reserved            |H3R15 Count = X|NXGN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
|                                                               |
+                       64bit State                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       64bit h3.rS ID                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 12: multicast update payload, value, key, key.. 




















Barkai, et al.          Expires March 24, 2026        [Page 15]

Internet-Draft                     LISP          September 2025



6.  Security Considerations

 The LISP mobility-network is inherently secure and private.
 All information is conveyed to clients using provisioned Geolocation
 agents. MobilityClients receive information only via geospatial
 channels originating at provisioned agents, replicated by EdgeRTRs.
 All traffic is carried over encrypted encapsulation.

7.  Privacy Considerations

 In the mobility network, MobilityClients obtain temporary clientEIDs
 and RLOCs of EdgeRTRs through an AAA process in order to access the
 network for a certain period. The interface between MobilityClients
 and EdgeRTRs is the most sensitive from a privacy perspective, as the
 EdgeRTR can determine the client RLOC and the h3.rB area that the
 client is engaged with based on header information, even though the
 traffic on this interface is tunneled and the detection content is
 encrypted between ClientXTR and EdgeRTR. Enterprises such as vehicle
 OEMs or carriers can use their own EdgeRTRs (BYO_RTRs), which are 
 pre-provisioned to use the mapping system and are approved by other
 EdgeRTRs. Beyond the client to EdgeRTR hop, the mapping system does
 not hold MobilityClientEID information and remote EdgeRTRs are only
 aware of clients' temporary EIDs. H3AgentEIDs decrypt and parse
 actual h3.rS detections, taking into account MobilityClientEID
 credentials encoded in the client EID and assigned by AAA to avoid
 poorly made or localized detections.

 In summary the privacy risk mitigations are:
 (1) tapping: all communications are through tunnels therefore
   may be encrypted using IP-Sec or other supported point to point
   underlay standards.
 (2) spoofing: it is very hard to guess a MobilityClientEID valid for
   a short period of time. Clients and H3Agents EIDs are provisioned
   in EdgeRTRs, Clients using the AAA procedure, H3Agents via dev-ops.
 (3) credibility: the interface crowd-sources and does not assume to
   trust single detections. Credit history track MobilityClient
   aggregate scores from all agents are delivered to AAA subsystem 
 (4) geo-privacy: Only EdgeRTRs are aware of both clients' RLOC and
   geo-location, only AAA is aware of client IDs credentials and 
   credit but not geo-location. Ongoing client credit adjustments span
   all H3Agents administratively to AAA without specific geo-source.

Barkai, et al.          Expires March 24, 2026        [Page 16]

Internet-Draft                     LISP          September 2025

8.  Acknowledgments

 We would like to kindly thank Joel Halperin for helping structure the
 AAA section and Geo-Privacy provisions, Luigi Lannone for promoting
 such LISP based Compute Aware Networking use-cases, helping structure
 the IANA section, and shepherding this draft to completion. We would
 like to thank George Ericson from Dell, Lei Zhong from Toyota, Mikael
 Klein from Ericsson, Leifeng Ruan from Intel, Ririn Andarini from NTT,
 for helping with Geolocation and Dataflow Virtualization terminology
 and key-issues during joint work at the AECC. We would like to thank
 Professor Trevor Darrel and Professor Fisher Yu of BDD for reviewing
 IANA enumerations for detections-consolidations feasible by visionAI
 and Edge Computing. We would like to thank Isaac Brodsky, Nick
 Rabinowitz, David Ellis, and AJ Friend of the H3 steering committee
 for reviewing the use of the H3 grid in the lisp-nexagon network.





























Barkai, et al.          Expires March 24, 2026        [Page 17]

Internet-Draft                     LISP          September 2025

9.  IANA Considerations
In accordance with BCP 26 [RFC8126].IANA is asked to create a registry
named NEXAGON with the following sub registries.
+----------+------------------+----------+---------------------------+
+----------+------------------+----------+---------------------------+
| Type     | nexagon-type     | 0-7      | Type of key-value encoding|
| gzip     | nexagon-gzip     | 8-10     | gzip major version used   |
| PairCount| nexagon-paircount| 24-31    | key-value pair count      |
+----------+------------------+----------+---------------------------+


Barkai, et al.          Expires March 24, 2026        [Page 18]

Internet-Draft                     LISP          September 2025


10.  Normative References


 [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
     Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)",
     RFC 9300, DOI 10.17487/RFC9300,
     October 2022, <https://www.rfc-editor.org/info/rfc9300>.

 [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed.,
     "Locator/ID Separation Protocol (LISP) Control Plane",
      RFC 9301, DOI 10.17487/RFC9301,
     October 2022, <https://www.rfc-editor.org/info/rfc9301>.

 [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
     Group Management Protocol Version 3 (IGMPv3) and Multicast
     Listener Discovery Protocol Version 2 (MLDv2) for Source-
     Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
     December 2006, <https://www.rfc-editor.org/info/rfc4604>.

 [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
     Ed., "Diameter Base Protocol", RFC 6733,
     DOI 10.17487/RFC6733, October 2012,
     <http://www.rfc-editor.org/info/rfc6733>.

 [RFC8126]  Cotton, M., Leiba, B., Narten, T., "Guidelines for
    Writing an IANA Considerations Section in RFCs", RFC8126,
    DOI 10.17487/RFC8126, Novembere 2017,
    <https://www.rfc-editor.org/info/rfc8126>.

 [RFC8378]  Farinacci, D., Moreno, V., "Signal-Free Locator/ID
    Separation Protocol (LISP) Multicast", RFC8378,
    DOI 10.17487/RFC8378, May 2018,
    <https://www.rfc-editor.org/info/rfc8378>.

 [H3] Uber Technologies Inc. [n.d.]. H3: Ubers Hexagonal
     Hierarchical Spatial Index, May 2021,
     <https://eng.uber.com/h3>.


Barkai, et al.          Expires March 24, 2026        [Page 19]

Internet-Draft                     LISP          September 2025


  Authors' Addresses

   Sharon Barkai
   Oterra
   CA
   USA

   Email: sbarkai@gmail.com


   Bruno Fernandez-Ruiz
   Nexar
   London
   UK

   Email: b@getnexar.com


   Rotem Tamir
   Ariga
   Israel

   Email: r@ariga.io

   Alberto Rodriguez-Natal
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: natal@cisco.com

   Fabio Maino
   Cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: fmaino@cisco.com





Barkai, et al.          Expires March 24, 2026        [Page 20]

Internet-Draft                     LISP          September 2025



   Albert Cabellos-Aparicio
   Universitat Politecnica de Catalunya
   Barcelona
   Spain

   Email: acabello@ac.upc.edu

   Jordi Paillisse-Vilanova
   Universitat Politecnica de Catalunya
   Barcelona
   Spain

   Email: jordip@ac.upc.edu

   Dino Farinacci
   lispers.net
   San Jose, CA
   USA

   Email: farinacci@gmail.com






















Barkai, et al.          Expires March 24, 2026          [Page 21]


name: draft-cosmos-protocol-specification
rev: 00
title: The Cosmos Protocol Specification (Trust-Native Semantic Protocol)
time: 2026-01-02T07:13:44Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-06T07:13:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:05.127443+00:00
abstract:
The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
   based identity and communication system intended for deployments that
   prefer not to rely on external consensus or blockchain
   infrastructure.  Cosmos supports trust-native communication and
   decentralized identity management through cryptographically signed
   badges that operate without mandatory external trust systems.  The
   protocol also supports passwordless authentication flows using badge-
   based credentials and biometric authenticators, reducing reliance on
   traditional password mechanisms.

   The Cosmos Protocol introduces several foundational innovations that
   together form an integrated identity-native communication substrate.
   These include: (1) Badge-Based Identity -- cryptographically signed,
   capability-bearing identifiers designed to operate without requiring
   blockchain or distributed ledger infrastructure, while allowing
   deployments to integrate such systems if desired; (2) Trust Scoring
   -- reputation-anchored trust models (domain-bound for DNS networks,
   star-bound for Cosmos-native networks) that enable cross-star
   capability granting and trust-based authorization without requiring
   new badges; (3) Lumen Encryption -- uses post-quantum candidate
   cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
   encryption designed to support forward secrecy; (4) Echo Grammar --
   semantic message structures that provide intent clarity, UI hints,
   and agent compatibility; (5) Capsule System -- universal, encrypted
   containers for communication and storage; (6) Slipstream Transport
   (TNTP) -- a trust-native transport protocol with badge-based
   sessions, intent-aware routing, and the ability to operate without
   blockchain or external consensus dependencies; (7) Ramp and SDFF
   Serialization -- deterministic text and binary formats that provide
   canonical structure for all Cosmos data; (8) Profile System --
   portable, domain-scoped user profiles with badge-based access
   control; and (9) Productivity Protocols -- standardized scheduling,
   contacts, and calendaring protocols (Comet, Nebula, Nova) that
   provide a badge-native model that can serve as an alternative to
   multiple legacy standards.

   Cosmos badges are Ramp (Slope Data Format, SDF) documents with
   optional DID compatibility, allowing integration with existing
   decentralized identity systems while preserving the protocol's self-
   contained architecture within Cosmos deployments.  The badge system
   addresses key limitations in current identity approaches, including
   the lack of enterprise-grade lifecycle management, star-bound trust
   establishment, and the ability to operate independently of external
   infrastructure in constrained or disconnected environments.

   The protocol provides a viable alternative to complex identity stacks
   while maintaining interoperability with existing standards, making it
   suitable for both greenfield deployments and integration with
   existing systems.

full_text:
Network Working Group                                       A. Hernandez
Internet-Draft                                        Varlil Corporation
Intended status: Standards Track                          1 January 2026
Expires: 5 July 2026


   The Cosmos Protocol Specification (Trust-Native Semantic Protocol)
                 draft-cosmos-protocol-specification-00

Abstract

   The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
   based identity and communication system intended for deployments that
   prefer not to rely on external consensus or blockchain
   infrastructure.  Cosmos supports trust-native communication and
   decentralized identity management through cryptographically signed
   badges that operate without mandatory external trust systems.  The
   protocol also supports passwordless authentication flows using badge-
   based credentials and biometric authenticators, reducing reliance on
   traditional password mechanisms.

   The Cosmos Protocol introduces several foundational innovations that
   together form an integrated identity-native communication substrate.
   These include: (1) Badge-Based Identity -- cryptographically signed,
   capability-bearing identifiers designed to operate without requiring
   blockchain or distributed ledger infrastructure, while allowing
   deployments to integrate such systems if desired; (2) Trust Scoring
   -- reputation-anchored trust models (domain-bound for DNS networks,
   star-bound for Cosmos-native networks) that enable cross-star
   capability granting and trust-based authorization without requiring
   new badges; (3) Lumen Encryption -- uses post-quantum candidate
   cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
   encryption designed to support forward secrecy; (4) Echo Grammar --
   semantic message structures that provide intent clarity, UI hints,
   and agent compatibility; (5) Capsule System -- universal, encrypted
   containers for communication and storage; (6) Slipstream Transport
   (TNTP) -- a trust-native transport protocol with badge-based
   sessions, intent-aware routing, and the ability to operate without
   blockchain or external consensus dependencies; (7) Ramp and SDFF
   Serialization -- deterministic text and binary formats that provide
   canonical structure for all Cosmos data; (8) Profile System --
   portable, domain-scoped user profiles with badge-based access
   control; and (9) Productivity Protocols -- standardized scheduling,
   contacts, and calendaring protocols (Comet, Nebula, Nova) that
   provide a badge-native model that can serve as an alternative to
   multiple legacy standards.





Hernandez                  Expires 5 July 2026                  [Page 1]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   Cosmos badges are Ramp (Slope Data Format, SDF) documents with
   optional DID compatibility, allowing integration with existing
   decentralized identity systems while preserving the protocol's self-
   contained architecture within Cosmos deployments.  The badge system
   addresses key limitations in current identity approaches, including
   the lack of enterprise-grade lifecycle management, star-bound trust
   establishment, and the ability to operate independently of external
   infrastructure in constrained or disconnected environments.

   The protocol provides a viable alternative to complex identity stacks
   while maintaining interoperability with existing standards, making it
   suitable for both greenfield deployments and integration with
   existing systems.

Note

   This document is in draft status and represents a proposed standard
   for the Cosmos Protocol specification.

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 5 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Hernandez                  Expires 5 July 2026                  [Page 2]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   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.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Solution Overview . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Why Not Existing Solutions? . . . . . . . . . . . . . . .   7
       2.3.1.  Why Not Decentralized Identifiers (DIDs)? . . . . . .   7
       2.3.2.  Why Not LDAP or Active Directory? . . . . . . . . . .   8
   3.  Scope and Applicability . . . . . . . . . . . . . . . . . . .   9
   4.  Requirements Language . . . . . . . . . . . . . . . . . . . .  10
   5.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Core Principles . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Architecture Overview . . . . . . . . . . . . . . . . . .  13
     6.3.  Component Relationships . . . . . . . . . . . . . . . . .  15
     6.4.  Cosmos as Network Stack Evolution . . . . . . . . . . . .  15
       6.4.1.  TCP/IP Stack Comparison . . . . . . . . . . . . . . .  16
   7.  Badge System  . . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.  Policy Substrate (Governance Substrate) . . . . . . . . . . .  18
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     13.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  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/.




Hernandez                  Expires 5 July 2026                  [Page 3]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


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

2.  Introduction

   This document specifies the Cosmos Protocol, a trust-native, badge-
   based identity and communication system designed for enterprise
   deployment without requiring blockchain or distributed ledger
   infrastructure.  The protocol provides a viable alternative to
   existing decentralized identity solutions by combining identity
   management, trust scoring, encryption, and communication in a
   unified, self-contained system within Cosmos deployments.

   This document does not obsolete or update any existing RFCs.  It
   defines a new protocol specification intended for use in enterprise
   identity and communication systems, decentralized applications, and
   environments that can operate without external consensus or
   blockchain infrastructure.

2.1.  Problem Statement

   Current decentralized identity and communication systems face
   fundamental limitations that prevent widespread adoption and
   practical deployment:

   *Infrastructure Dependencies*: Most decentralized identity solutions
   require complex infrastructure dependencies including blockchain
   networks, distributed ledgers, or specialized consensus mechanisms.
   These dependencies create barriers to deployment, especially in
   constrained environments, enterprise settings, or scenarios requiring
   rapid deployment.

   *Trust Quantification Challenges*: Existing systems lack effective
   mechanisms for quantifying trustworthiness between entities.  Without
   reliable trust metrics, users cannot make informed decisions about
   communication partners, leading to either excessive caution or
   inappropriate trust.

   *Enterprise Integration Gaps*: Current solutions often focus on
   individual identity management but fail to address enterprise
   requirements such as lifecycle management, organizational
   hierarchies, domain-based policies, and integration with existing
   infrastructure.






Hernandez                  Expires 5 July 2026                  [Page 4]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *Communication Fragmentation*: Identity and communication systems are
   typically separate, requiring complex integration work and creating
   security gaps between authentication and messaging.

   *Walled Garden Communication*: Modern communication platforms create
   walled gardens where users on different platforms cannot communicate
   effectively.  This forces users to rely on email systems for cross-
   platform communication, even when other chat and messaging solutions
   may be preferred.  Users must maintain multiple accounts across
   different platforms, fragmenting their communication and social
   graph.  Cross-platform interoperability is limited or non-existent,
   preventing users from choosing preferred communication tools while
   maintaining universal connectivity.

   *Profile Data Fragmentation and Lock-in*: User profiles are
   fragmented across multiple platforms, each with its own data silo.
   Users must recreate their profiles on each platform, losing their
   social graph and content when switching providers.  Profile data is
   locked into individual platforms with no portability, preventing
   users from migrating their profiles, content, and relationships.
   Users lack control over their profile data and privacy settings
   across platforms, leading to data silos and vendor lock-in.

   *Scalability Limitations*: Many decentralized systems struggle with
   scalability, either requiring significant computational resources or
   failing to handle enterprise-scale deployments effectively.

   *Password-Based Authentication Weaknesses*: Traditional password-
   based authentication systems suffer from fundamental security
   weaknesses including password reuse, weak passwords, password theft,
   phishing attacks, and the burden of password management.  Users are
   forced to create, remember, and manage passwords across multiple
   services, leading to security vulnerabilities and poor user
   experience.  Password-based systems also lack built-in identity
   verification and trust establishment mechanisms, requiring external
   trust systems.

2.2.  Solution Overview

   The Cosmos Protocol addresses these challenges through a
   comprehensive badge-based identity and communication system that
   supports the following capabilities:









Hernandez                  Expires 5 July 2026                  [Page 5]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *Infrastructure Independence*: Cosmos can operate without blockchain,
   distributed ledgers, or external consensus mechanisms.  The protocol
   is self-contained within Cosmos deployments and can be deployed in
   any environment, including constrained environments and enterprise
   data centers, without external consensus or blockchain
   infrastructure.

   *Star-bound Trust Scoring*: A trust algorithm designed to reduce
   manipulation risks that quantifies trustworthiness using star
   reputation, network effects, and behavioral patterns, enabling
   informed trust decisions without centralized authorities.

   *Enterprise-ready Identity Management*: Lifecycle management for
   badge issuance, renewal, revocation, and organizational hierarchies,
   designed for enterprise deployment scenarios.

   *Productivity Protocols*: Integrated scheduling, contacts, and
   calendar protocols (Comet, Nebula, Nova) that interoperate with the
   badge-based identity system, reducing security gaps between
   authentication and communication.

   *Cross-Provider Interoperability*: Interlink enables cross-provider
   interoperability for participating platforms.  Users can communicate
   seamlessly across different providers while each provider maintains
   their unique features and user experience.  This enables users to use
   preferred chat and messaging solutions for cross-platform
   communication while maintaining connectivity across participating
   platforms.  Users maintain a single identity and social graph that
   works across participating providers.

   *Profile System*: The Cosmos Profile System is designed to support
   portability across participating providers, subject to provider
   implementation and policy.  Cosmos reduces fragmentation by defining
   a consistent profile format with domain-scoped data spaces.  Users
   maintain a single canonical profile that functions across
   participating providers, reducing duplication and data silos.  Domain
   spaces allow each service to store its own data within the user's
   profile, while users retain full control over privacy settings and
   migration.  Users may migrate their profiles, content, and social
   graph between participating providers without data loss, subject to
   provider support.  Profiles are private by default and require
   explicit user action to make public, ensuring user-controlled
   visibility.

   *Scalability*: The architecture is intended to support deployments
   ranging from small installations to large multi-service environments,
   with design considerations for maintaining performance and security
   across varying scales.



Hernandez                  Expires 5 July 2026                  [Page 6]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *Passwordless Authentication*: Cosmos authentication flows are
   designed to minimize password usage by supporting badge-based
   credentials and FIDO2/Passkey-compliant biometric authenticators.
   Badge-based authentication reduces reliance on passwords and
   mitigates common password-related vulnerabilities such as password
   reuse, weak passwords, password theft, and phishing attacks.  Badge-
   based authentication also provides built-in identity verification and
   trust establishment within Cosmos deployments without requiring
   external trust systems.

2.3.  Why Not Existing Solutions?

2.3.1.  Why Not Decentralized Identifiers (DIDs)?

   DIDs [W3C-DID] provide a flexible decentralized identity model.
   Cosmos focuses on a different deployment profile by emphasizing self-
   contained operation and integrated trust scoring.  The following
   differences highlight Cosmos's approach:

   *Infrastructure Complexity*: DIDs require complex resolver
   infrastructure, method-specific implementations, and often depend on
   blockchain or distributed ledger technology.  This creates deployment
   barriers and operational complexity that Cosmos avoids through its
   self-contained design within Cosmos deployments.

   *Trust Quantification Gap*: DIDs provide cryptographic verification
   but lack built-in trust scoring mechanisms.  Cosmos includes star-
   bound trust scoring that supports informed decisions about
   communication partners without relying on external trust systems.

   *Enterprise Lifecycle Management*: DIDs focus on individual identity
   but do not provide enterprise features such as organizational
   hierarchies, star-based policies, or integrated lifecycle management,
   which Cosmos is designed to support.

   *Communication Integration*: DIDs are primarily identity-focused and
   require separate integration with communication systems.  Cosmos
   provides unified identity and communication protocols, reducing
   integration complexity and security gaps between identity and
   communication systems.

   *Deployment Flexibility*: DIDs often require specific infrastructure
   choices (blockchain, resolver networks) that limit deployment
   options.  Cosmos can be deployed in any environment without
   infrastructure dependencies.






Hernandez                  Expires 5 July 2026                  [Page 7]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *Badge-DID Compatibility*: Cosmos badges are Ramp (Slope Data Format,
   SDF) [RFC-XXXX-Ramp] documents with optional DID [W3C-DID]
   compatibility, allowing integration with existing decentralized
   identity systems while preserving the protocol's self-contained
   architecture within Cosmos deployments.  This enables Cosmos
   deployments to interoperate with DID ecosystems without depending on
   external DID infrastructure.

   The Cosmos approach provides an integrated, enterprise-oriented
   solution that addresses practical deployment needs while maintaining
   interoperability with existing decentralized identity standards.

2.3.2.  Why Not LDAP or Active Directory?

   LDAP [RFC4511] and Active Directory provide mature directory
   services.  Cosmos targets scenarios that require integrated trust
   scoring, badge-based authentication, and unified communication
   semantics.  The following differences highlight Cosmos's approach:

   *Password-Based Authentication*: All LDAP implementations (including
   Active Directory, OpenLDAP, 389 Directory Server, Apache Directory
   Server, FreeIPA, eDirectory, and other LDAP-based directory services)
   rely on password-based authentication, which is vulnerable to
   password reuse, weak passwords, password theft, and phishing attacks.
   Cosmos uses badge-based authentication with FIDO2/Passkey-compliant
   biometric authentication, eliminating the need for passwords within
   standard Cosmos authentication flows and providing cryptographic
   proof of identity.

   *Centralized Architecture*: LDAP and Active Directory are centralized
   systems with single points of failure, domain controller
   dependencies, and global catalog bottlenecks.  Cosmos supports
   distributed, edge-based deployment models that reduce single-point-
   of-failure risks, enabling global distribution and automatic scaling.

   *Trust Establishment Gap*: LDAP and Active Directory lack effective
   mechanisms for establishing and quantifying trust between entities.
   Cosmos includes star-bound trust scoring that enables informed
   decisions about communication partners without requiring external
   trust systems.

   *Communication Integration*: LDAP and Active Directory are primarily
   identity/directory-focused and require separate integration with
   communication systems.  Cosmos provides unified identity and
   communication protocols, reducing integration complexity and security
   gaps between authentication and messaging systems.





Hernandez                  Expires 5 July 2026                  [Page 8]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *Directory Scope Limitation*: LDAP is purely a directory query
   protocol for hierarchical data structures.  Cosmos is an integrated
   identity and communication protocol that includes directory-like
   query capabilities (Manifest) as one component of a broader system
   that integrates identity, trust, encryption, messaging, and
   productivity protocols into a unified, badge-native system.

   *Key Advantages*: Cosmos provides passwordless authentication, trust-
   based access control, integrated communication, distributed
   architecture, cryptographic verification, cross-star federation,
   intended post-quantum resistance, platform-agnostic enforcement, and
   real-time policy updates.  Cosmos implementations can integrate with
   existing LDAP/Active Directory infrastructure through adapter layers,
   enabling gradual migration.

3.  Scope and Applicability

   This specification defines the full Cosmos Protocol, including:

   *  Badge-based identity system with DID compatibility

   *  Domain-bound trust scoring algorithm

   *  Lumen encryption system [RFC-XXXX-Lumen] with intended post-
      quantum resistance

   *  Echo grammar [RFC-XXXX-Echo] for semantic messaging

   *  Capsule system [RFC-XXXX-Capsules] for encrypted communication and
      storage

   *  Slipstream Transport Protocol (TNTP) [RFC-XXXX-Slipstream]

   *  Ramp (Slope Data Format, SDF) [RFC-XXXX-Ramp] and SDFF (Self-
      Describing Field Format) [RFC-XXXX-SDFF] for data serialization

   *  Profile system [RFC-XXXX-Profile]

   *  Productivity suite protocols (Comet [RFC-XXXX-Comet], Nebula
      [RFC-XXXX-Nebula], Nova [RFC-XXXX-Nova])

   The protocol is applicable to:

   *  Enterprise identity and communication systems

   *  Decentralized applications requiring trust-native communication





Hernandez                  Expires 5 July 2026                  [Page 9]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *  Constrained environments that can operate without external
      consensus or blockchain infrastructure

   *  Systems requiring deployments ranging from small installations to
      large multi-service environments

   *  Environments requiring gradual migration from legacy systems

   *  Complete network replacement scenarios (future work, requires
      separate transport protocol specification)

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

5.  Terminology

   This document defines the following key terms:

   *Protocol Name vs. Brand Name*:

   The relationship between "TNSP" (Trust-Native Semantic Protocol) and
   "Cosmos" follows the same pattern as IEEE 802.11 and WiFi, or IEEE
   802.15.1 and Bluetooth:

   *  *TNSP (Trust-Native Semantic Protocol)*: The technical protocol
      specification name used in RFCs, technical documentation, and
      protocol implementations.  TNSP is the formal network-layer
      protocol in the Cosmos stack, providing an identity-native
      alternative to IP.

   *  *Cosmos*: The brand/marketing name used in user-facing
      documentation, product names, and marketing materials.  Cosmos is
      the user-friendly name for the complete protocol ecosystem.

   *  *Relationship*: TNSP is the technical protocol specification (like
      IEEE 802.11), and Cosmos is the brand name (like WiFi).  When
      referring to the technical protocol specification, use "TNSP" or
      "Trust-Native Semantic Protocol".  When referring to the brand,
      ecosystem, or user-facing aspects, use "Cosmos".

   *  *Usage Guidelines*:





Hernandez                  Expires 5 July 2026                 [Page 10]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


      -  Use "TNSP" in technical contexts: RFCs, protocol
         specifications, code comments, technical documentation, network
         layer discussions

      -  Use "Cosmos" in brand/marketing contexts: user documentation,
         product names, marketing materials, ecosystem discussions

      -  This document uses "Cosmos Protocol" in the title and abstract
         for brand recognition, but refers to "TNSP" when discussing the
         technical network layer protocol specification

   *  *Badge*: A cryptographically signed identifier that serves as
      identity, capability, and trust container in the Cosmos Protocol.
      Badges are self-contained and do not require external
      infrastructure for validation.

   *  *Manifest*: The core authority service in the Cosmos ecosystem
      that consolidates certificate authority, authentication service,
      and token/authorization service functions into a single unified
      service.

   *  *Star*: A Cosmos-native entity identified by a domain name (e.g.,
      "example.com") that serves as the trust anchor and authority
      boundary in the Cosmos Protocol.  Stars are Cosmos-implemented
      entities with badge-based identity, trust scoring, and Cosmos-
      native protocols.  The term "star" emphasizes the authority and
      trust anchor role: stars have gravity (authority), and all things
      around stars naturally gravitate toward them.

   *  *Domain*: The domain name that a star uses as its primary
      identifier (e.g., "example.com").  A star is identified by its
      domain name, which follows familiar TCP/IP domain naming
      conventions.

   *  *Accretion*: A bilateral trust relationship between stars where
      both sides must agree.  Accretion is a coordinated event, not
      automatic, and can be reversed.  With enough accretions, a star
      becomes a constellation (super node).

   *  *Constellation*: A star that has achieved super node status
      through sufficient accretion relationships.  When a star has
      enough accretions, it becomes a constellation with high gravity
      (trust), making it a preferred path in routing decisions.  Routing
      algorithms consider constellation relationships when selecting
      optimal paths, but routing itself is performed by service layer
      instances.





Hernandez                  Expires 5 July 2026                 [Page 11]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *  *Trust Score*: A computed metric that quantifies the
      trustworthiness of a star based on star reputation, network
      effects, and behavioral patterns.  The Cosmos Protocol defines two
      trust-scoring modes: domain-bound trust scoring, which derives
      signals from DNS-native sources (e.g., DNS records, TLS history,
      email reputation) when operating over DNS-addressed networks; and
      star-bound trust scoring, which uses Cosmos-native signals such as
      accretions, badge stability, and Manifest behavior when operating
      within Cosmos-native addressing and federation.  The trust-scoring
      model is extensible: any star MAY implement custom trust-scoring
      algorithms for its own use cases, and trust scores MAY be applied
      beyond network routing to authorization decisions, service
      selection, and other trust-based operations, but MUST NOT be
      treated as absolute indicators of identity legitimacy.

   *  *Lumen Encryption*: The badge-based encryption system used in the
      Cosmos Protocol that uses post-quantum candidate cryptographic
      primitives (see [RFC-XXXX-Lumen]) and is designed to support
      forward secrecy.

   *  *Echo Grammar*: The semantic message structure system in the
      Cosmos Protocol that provides UI hints and agent compatibility for
      structured communication.

   *  *Capsule*: A general-purpose encrypted container in the Cosmos
      Protocol that provides secure communication and storage
      capabilities with badge-based access control.

   *  *Interlink*: Optional social networking protocol that enables
      cross-provider interoperability for participating platforms.
      Interlink formalizes how existing Cosmos components work together
      for social networking, defining standard Echo Grammar structures
      for posts, comments, and social interactions.

   *  *Corona*: The star's outward identity surface and distributed
      presence layer.  Corona provides a minimal, canonical interface to
      the star without exposing the Manifest directly.  Corona instances
      sit between Wormhole (routing) and Manifest (authority), allowing
      stars to appear in multiple locations while remaining anchored to
      a single sovereign Manifest.  Corona exposes the star's basic
      metadata, trust hints, and canonical service endpoints.










Hernandez                  Expires 5 July 2026                 [Page 12]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


6.  Protocol Overview

   *Implementation Note*: Protocol versioning and evolution rules,
   including deprecation lifecycle, version compatibility, and version
   negotiation procedures, are defined in
   [RFC-XXXX-Protocol-Versioning].  This document provides only a high-
   level overview of the Cosmos Protocol primitives.

6.1.  Core Principles

   The Cosmos Protocol is built on five fundamental principles:

   *Infrastructure Independence*: The protocol operates without
   requiring blockchain, distributed ledgers, or external consensus
   mechanisms, enabling deployment in any environment without external
   consensus or blockchain infrastructure.

   *Star-bound Trust*: Trust is established and managed at the star
   (domain) level through accretion relationships, providing natural
   organizational boundaries and policy enforcement.

   *Badge-centric Identity*: All identity, capability, and trust
   information is contained within cryptographically signed badges that
   are self-contained and verifiable.

   *Federated Communication*: Identity and communication systems are
   integrated, enabling cross-provider interoperability for
   participating platforms while maintaining security and reducing
   integration complexity.

   *Enterprise Readiness*: The protocol is designed for enterprise-scale
   deployment with comprehensive lifecycle management and organizational
   support.

6.2.  Architecture Overview

   The Cosmos Protocol consists of several integrated components:

   *  *Badge System*: Cryptographically signed identifiers serving as
      self-contained identity, capability, and trust containers
      [RFC-XXXX-Badge]

   *  *Trust Scoring System*: Manipulation-resistant algorithm for
      quantifying trustworthiness [RFC-XXXX-Trust-Scoring]

   *  *Lumen Encryption*: Badge-based encryption using post-quantum
      candidate primitives [RFC-XXXX-Lumen]




Hernandez                  Expires 5 July 2026                 [Page 13]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   *  *Echo Grammar*: Semantic message structures with UI hints
      [RFC-XXXX-Echo]

   *  *Capsule System*: General-purpose encrypted communication and
      storage containers [RFC-XXXX-Capsules]

   *  *Transport Layer*: Slipstream Transport Protocol (TNTP)
      [RFC-XXXX-Slipstream] with badge-based sessions

   *  *Corona*: The star's outward identity surface and distributed
      presence layer [RFC-XXXX-Corona], providing a minimal, canonical
      interface to the star without exposing Manifest directly

   *  *Profile System*: Universal profiles with domain spaces and
      privacy controls [RFC-XXXX-Profile]

   *  *Comet (Scheduling Protocol)*: Unified scheduling protocol that
      combines iTIP [RFC5546] and iMIP [RFC6047] with badge-based
      identity and trust scoring [RFC-XXXX-Comet]

   *  *Nebula (Contact Protocol)*: Unified contact management protocol
      that combines vCard [RFC6350] and CardDAV [RFC6352] with badge-
      based identity and trust scoring [RFC-XXXX-Nebula]

   *  *Nova (Calendar Protocol)*: Unified calendar protocol that
      combines iCalendar [RFC5545], CalDAV [RFC4791], iTIP [RFC5546],
      and iMIP [RFC6047] with badge-based identity and trust scoring
      [RFC-XXXX-Nova]

   *Implementation Scope Note*: While the protocol defines all
   components, different entities implement different parts based on
   their role:

   *  *Manifest Operators*: Implement badge system, trust scoring, and
      badge lifecycle management

   *  *Profile Providers*: Implement profile system and (optionally)
      Interlink

   *  *Service Providers*: Implement services using badges, profiles,
      and messaging as needed

   *  Entities can combine roles (e.g., a manifest operator can also
      operate as a profile provider)







Hernandez                  Expires 5 July 2026                 [Page 14]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


6.3.  Component Relationships

   All components work together to provide an integrated identity and
   communication system:

   *  Badges provide identity and authentication for all other
      components

   *  Trust scoring informs decisions across all communication and
      access control

   *  Lumen encryption secures all communication and storage

   *  Echo grammar structures all messages for semantic processing

   *  Capsules package all data for secure transmission and storage

   *  Transport layer provides secure networking consistent with Cosmos
      transport requirements

   *  Corona provides the star's identity surface and distributed
      presence, sitting between routing (Wormhole) and authority
      (Manifest) to protect Manifest and enable distributed presence

   *  Profiles manage user information and privacy

   *  Manifest-based resolution enables star discovery and capability
      verification

   *  Comet (Scheduling Protocol) enables badge-based scheduling with
      trust-scored permissions, designed for enterprise-scale
      deployments

   *  Nebula (Contact Protocol) enables badge-based contact management
      with trust-scored relationships and cross-star interoperability

   *  Nova (Calendar Protocol) enables badge-based calendar management
      with trust-scored access control, designed for enterprise-scale
      deployments

6.4.  Cosmos as Network Stack Evolution

   The Cosmos Protocol provides trust-native, identity-aware networking
   that can operate over existing TCP/IP infrastructure or without IP
   infrastructure (see Deployment Phases).  Cosmos can operate in
   environments where TCP/IP infrastructure is available and can also
   operate without IP infrastructure for scenarios that can operate
   without external consensus or blockchain infrastructure (see Phase 4:



Hernandez                  Expires 5 July 2026                 [Page 15]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   Independent Operation).

   These components operate as functional alternatives within Cosmos-
   native deployments; they do not require or mandate replacement of
   existing Internet protocols.

6.4.1.  TCP/IP Stack Comparison

   Cosmos provides alternative protocols that correspond to layers of
   the TCP/IP network stack:

   *Layer 1-2 (Physical/Data Link):* Cosmos retains existing physical
   and data link layers (Ethernet, WiFi, Fiber, MAC addressing).  These
   layers remain unchanged as they provide fundamental hardware
   communication.

   *Layer 3 (Network):* Cosmos provides the Trust-Native Semantic
   Protocol (TNSP) as an alternative to IP.  Capsules serve as the
   fundamental unit of TNSP, analogous to IP packets at the network
   layer.  They operate at the application/identity layer with built-in
   trust, identity, and semantics.  In Phase 4 deployments, Badge IDs
   provide network-layer addressing as an alternative to IP addresses,
   and intent-based routing (defined in TNSP and service discovery
   protocols) provides an alternative to IP routing.

   *Layer 4 (Transport):* Cosmos provides Slipstream (Trust-Native
   Transport Protocol, TNTP) [RFC-XXXX-Slipstream] as an alternative to
   TCP/UDP.  Slipstream provides badge-based sessions, trust-aware flow
   control, and the ability to operate without external consensus or
   blockchain infrastructure.

   *Layer 5+ (Application):* Cosmos provides Manifest federation as an
   identity-native alternative to DNS within Cosmos-native deployments
   (see Deployment Phases).  DNS is still used for bootstrap Manifest
   discovery in early deployment phases.  BEAP (Badge-Enabled API
   Protocol) [RFC-XXXX-BEAP] with Echo Grammar provides an application
   protocol model for identity-addressed operations, badge-based
   authentication, and intent-aware routing, serving the role that HTTP/
   HTTPS plays in traditional web architectures.  Echo Grammar provides
   structured, semantic message formats in place of HTTP's unstructured
   payloads.  Badge IDs serve as identity anchors analogous to domain
   names, but with cryptographic trust semantics.

   *Implementation Note*: The complete Slipstream (Trust-Native
   Transport Protocol, TNTP) specification is defined in
   [RFC-XXXX-Slipstream].  Slipstream is the recommended transport
   protocol for Cosmos deployments and can operate both independently of
   IP (Layer 2 mode) and over IP networks (via UDP/TCP encapsulation).



Hernandez                  Expires 5 July 2026                 [Page 16]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   Slipstream does not require blockchain or external consensus
   dependencies, but may require Manifest for badge validation in Cosmos
   deployments (see [RFC-XXXX-Slipstream] for standalone operation
   details).

6.4.1.1.  Deployment Phases

   Cosmos can be deployed in phases, from operation over TCP/IP
   infrastructure to independent operation:

   *Phase 1 (TCP/IP Infrastructure):* Cosmos runs on TCP/IP
   infrastructure.  Slipstream (TNTP) is the recommended transport
   protocol and can operate over IP networks via UDP/TCP encapsulation.
   DNS is used for bootstrap Manifest discovery.  This enables immediate
   deployment without requiring infrastructure changes.

   *Phase 2 (Application Layer Alternatives):* Manifest federation
   provides an identity-native alternative to DNS resolution within the
   Cosmos substrate.  BEAP (Badge-Enabled API Protocol) [RFC-XXXX-BEAP]
   with Echo Grammar provides an application protocol model for
   identity-addressed operations and structured messaging, serving the
   role that HTTP/HTTPS plays in traditional web architectures.
   Capsules provide a structured, semantic alternative to HTTP content
   formats.  Slipstream (TNTP) operates over existing IP networks via
   UDP/TCP encapsulation, and Cosmos continues to use IP for the network
   layer during this phase.

   *Phase 3 (Transport Layer Alternatives):* Slipstream (Trust-Native
   Transport Protocol, TNTP) [RFC-XXXX-Slipstream] provides an
   alternative to TCP/UDP, providing badge-based sessions.  Cosmos
   continues to use IP for network layer.

   *Phase 4 (Independent Operation):* TNSP provides an alternative to IP
   at the network layer.  In Phase 4 deployments, Badge IDs provide an
   alternative to IP addresses (see [RFC-XXXX-Badge] for Badge ID
   structure and routing properties), and intent-based routing (defined
   in TNSP and service discovery protocols) provides an alternative to
   IP routing.  Slipstream (Trust-Native Transport Protocol, TNTP)
   operates directly over Layer 2 (Ethernet frames) or via TNSP
   capsules.  This enables deployment without external consensus or
   blockchain infrastructure, including environments where IP
   infrastructure is not available or desired.  Phase 4 deployments
   still require Manifest for badge validation and trust establishment
   (see [RFC-XXXX-Manifest]).







Hernandez                  Expires 5 July 2026                 [Page 17]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


7.  Badge System

   Cosmos implementations MUST use the Badge System as specified in
   [RFC-XXXX-Badge] for all identity, capability, and trust management
   operations.  Badges are cryptographically signed Ramp (Slope Data
   Format, SDF) [RFC-XXXX-Ramp] documents that serve as identity,
   capability, and trust containers without requiring blockchain or
   external infrastructure.

   *Implementation Note*: The complete Badge System specification,
   including detailed badge structure, badge types, lifecycle
   management, DID compatibility, group badges, and security
   considerations, is defined in [RFC-XXXX-Badge].  This document
   specifies only the requirement to use badges and the integration
   points with the Cosmos Protocol.

8.  Manifest

   Each star participates in the Cosmos Protocol through its Manifest
   service, which acts as the star's authority for badge issuance,
   validation, and policy distribution.  Deployment models, availability
   strategies, and operational requirements for Manifest are defined in
   [RFC-XXXX-Manifest].

   *Note*: Detailed specifications for cross-domain registry hosting,
   including hosting relationships, federated service model, termination
   requirements, and high availability requirements, are defined in
   [RFC-XXXX-Manifest].  This document provides only a high-level
   overview of Manifest's role in the Cosmos Protocol.

9.  Policy Substrate (Governance Substrate)

   The Policy Substrate is a network-wide governance layer that defines
   and enforces policies across all Cosmos components.  Unlike
   traditional policy systems that are component-specific, the Policy
   Substrate provides a unified governance model for Cosmos deployments
   where implemented (see [RFC-XXXX-Manifest] for Policy Substrate
   requirements and deployment models), covering access control,
   compliance, security, data management, and system configuration.

   *Implementation Note*: Detailed Policy Substrate specifications,
   including policy categories, network-wide enforcement mechanisms,
   compliance policies, security policies, data management policies, and
   Access Control Grammar, are defined in [RFC-XXXX-Manifest] (see
   Section 9).  This document provides only a high-level overview of the
   Policy Substrate's role in the Cosmos Protocol.





Hernandez                  Expires 5 July 2026                 [Page 18]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


10.  Security Considerations

   The Cosmos Protocol's security properties derive from cryptographic
   badge signatures, post-quantum encryption (Lumen; see
   [RFC-XXXX-Lumen]), domain-bound trust scoring, and the ability to
   operate without blockchain or external consensus dependencies.
   Cosmos provides confidentiality through post-quantum candidate
   primitives (see [RFC-XXXX-Lumen] for algorithm details and security
   considerations), integrity through cryptographic signatures,
   authentication through badge-based verification, authorization
   through badge capabilities and trust scores, and non-repudiation
   through cryptographically signed operations that include timestamp
   fields defined in the Badge specification (see [RFC-XXXX-Badge] for
   signature structure and validation requirements), subject to the
   security properties of the underlying algorithms.

   Key security considerations include: identity spoofing prevention
   through cryptographic verification, trust manipulation resistance
   through algorithms designed to reduce manipulation risks,
   communication interception protection through post-quantum candidate
   primitives (see [RFC-XXXX-Lumen]), and cross-domain security through
   domain-bound policies and cryptographic isolation.

   *Implementation Note*: Detailed security considerations, including
   threat models, attack resistance analysis, privacy protection
   mechanisms, single-point-of-failure analysis, and implementation
   security requirements, are defined in component RFCs.  See
   [RFC-XXXX-Badge] for badge security, [RFC-XXXX-Manifest] for Manifest
   security requirements and SPOF mitigation, [RFC-XXXX-Lumen] for
   encryption security, and [RFC-XXXX-Slipstream] for transport
   security.  This document provides only a high-level overview of the
   Cosmos Protocol's security properties.

11.  IANA Considerations

   This document defines the Cosmos Protocol specification and uses
   existing DNS record types (TXT, SRV, CNAME).  The protocol defines
   transport-agnostic requirements and internal data structures and
   algorithms that do not require IANA registration.  This document
   defines no new IANA registries.  Transport protocols such as
   Slipstream define their own IANA considerations in separate
   documents.

   Badge types, trust levels, capabilities, and other protocol-internal
   elements are defined within this specification and do not require
   separate IANA registries.  Service discovery uses existing SRV record
   types.  Domain authority declaration uses existing TXT record types.




Hernandez                  Expires 5 July 2026                 [Page 19]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   A separate specification document defines the COSMOS DNS record type,
   which will require IANA registration.  That specification contains
   the necessary IANA considerations for the new DNS record type.

   This document has no IANA actions.

12.  Acknowledgments

   The authors would like to thank the contributors to the Cosmos
   Protocol specification and the broader decentralized identity
   community for their insights and feedback.

13.  References

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

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

13.2.  Informative References

   [RFC-XXXX-Badge]
              Hernandez, A., "The Cosmos Badge System", Work in
              Progress, Internet-Draft, draft-cosmos-badge-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-badge-
              00>.

   [RFC-XXXX-BEAP]
              Hernandez, A., "Badge-Enabled API Protocol (BEAP):
              Identity-Addressed, Intent-Aware API Standard", Work in
              Progress, Internet-Draft, draft-cosmos-beap-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-beap-
              00>.

   [RFC-XXXX-Capsules]
              Hernandez, A., "The Cosmos Capsule Protocol", Work in
              Progress, Internet-Draft, draft-cosmos-capsules-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-
              capsules-00>.






Hernandez                  Expires 5 July 2026                 [Page 20]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   [RFC-XXXX-Comet]
              Hernandez, A., "The Cosmos Comet Scheduling Protocol",
              Work in Progress, Internet-Draft, draft-cosmos-comet-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-comet-
              00>.

   [RFC-XXXX-Corona]
              Hernandez, A., "The Cosmos Corona Protocol", Work in
              Progress, Internet-Draft, draft-cosmos-corona-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-
              corona-00>.

   [RFC-XXXX-Echo]
              Hernandez, A., "The Cosmos Echo Grammar Protocol", Work in
              Progress, Internet-Draft, draft-cosmos-echo-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-echo-
              00>.

   [RFC-XXXX-Lumen]
              Hernandez, A., "The Cosmos Lumen Encryption Protocol",
              Work in Progress, Internet-Draft, draft-cosmos-lumen-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-lumen-
              00>.

   [RFC-XXXX-Manifest]
              Hernandez, A., "The Cosmos Manifest (Badge Registry)
              Protocol", Work in Progress, Internet-Draft, draft-cosmos-
              manifest-00, <https://datatracker.ietf.org/doc/html/draft-
              cosmos-manifest-00>.

   [RFC-XXXX-Nebula]
              Hernandez, A., "The Cosmos Nebula Contact Protocol", Work
              in Progress, Internet-Draft, draft-cosmos-nebula-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-
              nebula-00>.

   [RFC-XXXX-Nova]
              Hernandez, A., "The Cosmos Nova Calendar Protocol", Work
              in Progress, Internet-Draft, draft-cosmos-nova-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-nova-
              00>.

   [RFC-XXXX-Profile]
              Hernandez, A., "The Cosmos Profile Protocol and
              Interlink", Work in Progress, Internet-Draft, draft-
              cosmos-profile-00, <https://datatracker.ietf.org/doc/html/
              draft-cosmos-profile-00>.




Hernandez                  Expires 5 July 2026                 [Page 21]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   [RFC-XXXX-Protocol-Versioning]
              Hernandez, A., "Cosmos Protocol Versioning and Evolution",
              Work in Progress, Internet-Draft, draft-cosmos-protocol-
              versioning-00, <https://datatracker.ietf.org/doc/html/
              draft-cosmos-protocol-versioning-00>.

   [RFC-XXXX-Ramp]
              Hernandez, A., "Ramp: Slope Data Format (SDF)", Work in
              Progress, Internet-Draft, draft-ramp-00,
              <https://datatracker.ietf.org/doc/html/draft-ramp-00>.

   [RFC-XXXX-SDFF]
              Hernandez, A., "SDFF: Self-Describing Field Format", Work
              in Progress, Internet-Draft, draft-cosmos-sdff-00,
              <https://datatracker.ietf.org/doc/html/draft-cosmos-sdff-
              00>.

   [RFC-XXXX-Slipstream]
              Hernandez, A., "The Cosmos Slipstream Transport Protocol
              (TNTP)", Work in Progress, Internet-Draft, draft-cosmos-
              slipstream-00, <https://datatracker.ietf.org/doc/html/
              draft-cosmos-slipstream-00>.

   [RFC-XXXX-Trust-Scoring]
              Hernandez, A., "The Cosmos Trust Scoring Protocol", Work
              in Progress, Internet-Draft, draft-cosmos-trust-scoring-
              00, <https://datatracker.ietf.org/doc/html/draft-cosmos-
              trust-scoring-00>.

   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511,
              June 2006, <https://www.rfc-editor.org/info/rfc4511>.

   [RFC4791]  Daboo, C. and L. Desruisseaux, "Calendaring Extensions to
              WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March
              2007, <https://www.rfc-editor.org/info/rfc4791>.

   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
              Core Object Specification (iCalendar)", RFC 5545,
              DOI 10.17487/RFC5545, September 2009,
              <https://www.rfc-editor.org/info/rfc5545>.

   [RFC5546]  Daboo, C., "iCalendar Transport-Independent
              Interoperability Protocol (iTIP)", RFC 5546,
              DOI 10.17487/RFC5546, December 2009,
              <https://www.rfc-editor.org/info/rfc5546>.





Hernandez                  Expires 5 July 2026                 [Page 22]

Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


   [RFC6047]  Daboo, C., "iCalendar Message-Based Interoperability
              Protocol (iMIP)", RFC 6047, DOI 10.17487/RFC6047, December
              2010, <https://www.rfc-editor.org/info/rfc6047>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,
              <https://www.rfc-editor.org/info/rfc6350>.

   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to WebDAV",
              RFC 6352, DOI 10.17487/RFC6352, August 2011,
              <https://www.rfc-editor.org/info/rfc6352>.

   [W3C-DID]  Sporny, M., Longley, D., and M. Sabadello, "Decentralized
              Identifiers (DIDs) v1.0", July 2022,
              <https://www.w3.org/TR/did-core/>.

Author's Address

   Antoine Hernandez
   Varlil Corporation
   Email: ahernan1@varlil.com






























Hernandez                  Expires 5 July 2026                 [Page 23]


name: draft-kale-agntcy-federated-privacy
rev: 00
title: Privacy-Preserving Federated Learning Architecture for Multi-Tenant AI Agent Systems
time: 2026-01-08T03:28:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-12T03:28:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:05.127454+00:00
abstract:
This document specifies a reference architecture for privacy-
   preserving federated learning in multi-tenant AI agent deployments.
   It addresses the challenge of enabling collaborative model training
   across organizational boundaries while maintaining formal privacy
   guarantees and tenant data isolation.  The architecture combines
   federated averaging, differential privacy mechanisms, and secure
   aggregation to enable cross-tenant knowledge transfer without
   exposing sensitive behavioral data.

full_text:
Network Working Group                                           N. Kale
Internet-Draft                                             Cisco Systems
Intended status: Informational                             January 2026
Expires: July 2026


      Privacy-Preserving Federated Learning Architecture for
              Multi-Tenant AI Agent Systems

                 draft-kale-agntcy-federated-privacy-00

Abstract

   This document specifies a reference architecture for privacy-
   preserving federated learning in multi-tenant AI agent deployments.
   It addresses the challenge of enabling collaborative model training
   across organizational boundaries while maintaining formal privacy
   guarantees and tenant data isolation.  The architecture combines
   federated averaging, differential privacy mechanisms, and secure
   aggregation to enable cross-tenant knowledge transfer without
   exposing sensitive behavioral data.

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 July 7, 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.

Kale                          Informational                     [Page 1]

Internet-Draft        Federated Learning for Agents         January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Relationship to AI Agent Protocol Work  . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     4.1.  System Components . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Data Flow . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Federated Learning Protocol . . . . . . . . . . . . . . . . .   6
     5.1.  Initialization  . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Local Training Phase  . . . . . . . . . . . . . . . . . .   7
     5.3.  Aggregation Phase . . . . . . . . . . . . . . . . . . . .   7
     5.4.  Weighting Strategies  . . . . . . . . . . . . . . . . . .   8
   6.  Privacy Mechanisms  . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Differential Privacy Definition . . . . . . . . . . . . .   8
     6.2.  Gaussian Mechanism  . . . . . . . . . . . . . . . . . . .   8
     6.3.  Privacy Budget Allocation . . . . . . . . . . . . . . . .   9
     6.4.  Gradient Clipping . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  Attacks Not Addressed . . . . . . . . . . . . . . . . . .  10
     7.3.  Extensions for Stronger Security  . . . . . . . . . . . .  10
     7.4.  Compliance Considerations . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Example Configuration  . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   AI agent systems increasingly operate in multi-tenant enterprise
   environments where behavioral data from user interactions could
   improve system performance through machine learning.  However,
   centralizing such data across organizational boundaries conflicts
   with privacy regulations (GDPR, HIPAA, CCPA), contractual data
   isolation requirements, and enterprise security policies.

   This document specifies a federated learning architecture that
   enables collaborative model training while ensuring:

   o  Tenant data isolation: Raw behavioral data never leaves tenant
      boundaries

   o  Formal privacy guarantees: Differential privacy bounds
      information leakage

Kale                          Informational                     [Page 2]

Internet-Draft        Federated Learning for Agents         January 2026


   o  Regulatory compliance: Architecture supports GDPR, HIPAA, and
      CCPA requirements

   o  Scalable deployment: Protocol supports large numbers of tenants
      with heterogeneous data distributions

   The architecture applies broadly to any multi-tenant machine
   learning deployment requiring privacy preservation, with particular
   relevance to AI agent systems operating across organizational
   boundaries.  This work builds on foundational research in federated
   learning [McMahan17] and differential privacy [Dwork14] [Abadi16],
   as well as recent advances addressing open problems in the field
   [Kairouz21] [Wang23].

1.1.  Relationship to AI Agent Protocol Work

   This document complements ongoing work on AI agent protocols at the
   IETF, including frameworks for agent communication [Rosenberg25]
   and secure messaging for agentic AI [SLIM25].  The privacy-
   preserving aggregation mechanisms specified here address federated
   learning requirements that arise when AI agents operate across
   organizational boundaries and must learn from distributed behavioral
   data without centralizing sensitive information.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Aggregation Server:  A central coordinator that receives model
      updates from tenants and computes aggregated models.

   Differential Privacy (DP):  A mathematical framework providing
      formal bounds on information leakage from statistical queries.

   Federated Learning (FL):  A machine learning approach where model
      training occurs on decentralized data without centralizing the
      data itself.

   Local Model:  A model trained on a single tenant's data.

   Global Model:  An aggregated model computed from multiple local
      model updates.

   Privacy Budget:  Parameters (epsilon, delta) that quantify the
      privacy guarantee provided by differential privacy mechanisms.

Kale                          Informational                     [Page 3]

Internet-Draft        Federated Learning for Agents         January 2026


   Tenant:  An organizational entity with isolated data and computing
      resources within a multi-tenant deployment.

3.  Problem Statement

   Consider an AI agent system deployed across N organizational
   tenants.  Each tenant generates behavioral data from user
   interactions with the agent.  The system operator wishes to:

   1.  Train personalization models that adapt to user behavior

   2.  Leverage patterns across tenants to improve model quality

   3.  Maintain strict tenant data isolation

   4.  Comply with privacy regulations

   Traditional centralized machine learning requires aggregating data
   from all tenants, violating requirements 3 and 4.  Purely local
   training (each tenant trains independently) satisfies isolation but
   sacrifices the benefits of cross-tenant learning (requirement 2).

   This document specifies an architecture that satisfies all four
   requirements through federated learning with differential privacy.

4.  Architecture Overview

4.1.  System Components

   The architecture comprises the following components, illustrated in
   Figure 1:

   o  Local Data stores residing within each tenant boundary

   o  Local Model training infrastructure at each tenant

   o  Differential Privacy (DP) noise injection modules

   o  A central Aggregation Server for computing global model updates













Kale                          Informational                     [Page 4]

Internet-Draft        Federated Learning for Agents         January 2026


   +------------------+   +------------------+   +------------------+
   |    Tenant A      |   |    Tenant B      |   |    Tenant C      |
   |  +------------+  |   |  +------------+  |   |  +------------+  |
   |  | Local Data |  |   |  | Local Data |  |   |  | Local Data |  |
   |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
   |        |         |   |        |         |   |        |         |
   |  +-----v------+  |   |  +-----v------+  |   |  +-----v------+  |
   |  |Local Model |  |   |  |Local Model |  |   |  |Local Model |  |
   |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
   |        |         |   |        |         |   |        |         |
   |  +-----v------+  |   |  +-----v------+  |   |  +-----v------+  |
   |  |  DP Noise  |  |   |  |  DP Noise  |  |   |  |  DP Noise  |  |
   |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
   +--------+---------+   +--------+---------+   +--------+---------+
            |                      |                      |
            +----------------------+----------------------+
                                   |
                        +----------v-----------+
                        |  Aggregation Server  |
                        |  (Computes Global    |
                        |   Model Updates)     |
                        +----------+-----------+
                                   |
            +----------------------+----------------------+
            |                      |                      |
   +--------v---------+   +--------v---------+   +--------v---------+
   |    Tenant A      |   |    Tenant B      |   |    Tenant C      |
   |  Receives Global |   |  Receives Global |   |  Receives Global |
   |  Model Update    |   |  Model Update    |   |  Model Update    |
   +------------------+   +------------------+   +------------------+

                    Figure 1: Federated Architecture


















Kale                          Informational                     [Page 5]

Internet-Draft        Federated Learning for Agents         January 2026


4.2.  Data Flow

   1.  Each tenant trains a local model on tenant-specific data

   2.  Model updates (not raw data) are computed

   3.  Differential privacy noise is added to updates

   4.  Noisy updates are transmitted to aggregation server

   5.  Server computes weighted average of updates

   6.  Global model is distributed back to tenants

   7.  Process repeats for specified number of rounds

4.3.  Trust Model

   The architecture assumes:

   o  Aggregation server is honest-but-curious: It follows the
      protocol correctly but may attempt to infer information from
      received updates

   o  Tenants are honest: They train models correctly and do not
      attempt to poison the global model

   o  Communication channels are secure: TLS protects updates in
      transit

   Section 7 discusses extensions for stronger threat models.

5.  Federated Learning Protocol

   This section specifies the federated learning protocol in detail.
   The protocol follows the FedAvg algorithm structure with
   modifications for differential privacy.















Kale                          Informational                     [Page 6]

Internet-Draft        Federated Learning for Agents         January 2026


5.1.  Initialization

   The aggregation server MUST:

   1.  Generate initial global model parameters theta_0

   2.  Distribute theta_0 to all participating tenants

   3.  Specify privacy budget (epsilon, delta) for the training session

   4.  Specify number of training rounds T

5.2.  Local Training Phase

   For each round t, each tenant i MUST:

   1.  Receive current global model theta_t from aggregation server

   2.  Train local model on tenant data for E local epochs:
       theta_i = LocalTrain(theta_t, D_i, E)

   3.  Compute model update: delta_i = theta_i - theta_t

   4.  Clip update to bound sensitivity:
       delta_i_clipped = Clip(delta_i, C) where C is the clipping bound

   5.  Add Gaussian noise for differential privacy:
       delta_i_dp = delta_i_clipped + N(0, sigma^2 * I)

   6.  Transmit delta_i_dp to aggregation server

5.3.  Aggregation Phase

   The aggregation server MUST:

   1.  Receive noisy updates {delta_1_dp, ..., delta_n_dp} from tenants

   2.  Compute weighted average:
       delta_global = sum(w_i * delta_i_dp) where sum(w_i) = 1

   3.  Update global model: theta_{t+1} = theta_t + delta_global

   4.  Distribute theta_{t+1} to all tenants








Kale                          Informational                     [Page 7]

Internet-Draft        Federated Learning for Agents         January 2026


5.4.  Weighting Strategies

   Tenant weights w_i MAY be computed based on:

   o  Population size: Larger tenants contribute proportionally more

   o  Data quality: Tenants with lower-variance updates receive higher
      weight

   o  Equal weighting: w_i = 1/n for all tenants

   The specific weighting strategy SHOULD be documented in the
   deployment configuration.

6.  Privacy Mechanisms

6.1.  Differential Privacy Definition

   A mechanism M satisfies (epsilon, delta)-differential privacy if
   for all datasets D and D' differing in one record, and all output
   sets S:

      Pr[M(D) in S] <= e^epsilon * Pr[M(D') in S] + delta

6.2.  Gaussian Mechanism

   The Gaussian mechanism achieves (epsilon, delta)-DP by adding noise:

      sigma >= C * sqrt(2 * ln(1.25/delta)) / epsilon

   where C is the L2 sensitivity bound (clipping threshold).


















Kale                          Informational                     [Page 8]

Internet-Draft        Federated Learning for Agents         January 2026


6.3.  Privacy Budget Allocation

   For T training rounds with subsampling rate q, the total privacy
   budget follows composition theorems.  Implementations SHOULD use
   advanced composition or Renyi differential privacy accounting for
   tighter bounds.

   Recommended privacy parameters for enterprise deployments:

      epsilon: 1.0 to 10.0 (depending on data sensitivity)
      delta: 1/n where n is the minimum tenant population size
      C (clipping bound): Determined empirically based on gradient
      norms

6.4.  Gradient Clipping

   Before noise addition, model updates MUST be clipped:

      delta_clipped = delta * min(1, C / ||delta||_2)

   This bounds the sensitivity of individual data points, enabling
   precise privacy accounting.

7.  Security Considerations

7.1.  Threat Model

   This architecture protects against:

   o  Honest-but-curious aggregation server attempting to infer tenant
      data from model updates

   o  External attackers observing aggregated models

   o  Membership inference attacks against the global model
















Kale                          Informational                     [Page 9]

Internet-Draft        Federated Learning for Agents         January 2026


7.2.  Attacks Not Addressed

   The basic architecture does NOT protect against:

   o  Malicious tenants submitting poisoned updates

   o  Collusion between aggregation server and tenants

   o  Model inversion attacks against the final trained model

7.3.  Extensions for Stronger Security

7.3.1.  Secure Aggregation

   To protect against curious aggregation servers, implementations MAY
   use secure aggregation protocols where the server learns only the
   sum of updates, not individual tenant contributions.  See
   [Bonawitz17] for protocol details.

7.3.2.  Byzantine Fault Tolerance

   To protect against malicious tenants, implementations MAY use
   Byzantine-resilient aggregation methods such as coordinate-wise
   median or trimmed mean.

7.4.  Compliance Considerations

   Implementations targeting GDPR compliance SHOULD:

   o  Document privacy budget selection rationale

   o  Maintain audit logs of aggregation operations

   o  Implement data subject access request procedures

   o  Specify data retention policies for model checkpoints
















Kale                          Informational                    [Page 10]

Internet-Draft        Federated Learning for Agents         January 2026


8.  IANA Considerations

   This document has no IANA actions.

9.  References

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

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

9.2.  Informative References

   [Abadi16]  Abadi, M., Chu, A., Goodfellow, I., McMahan, H.B.,
              Mironov, I., Talwar, K., and L. Zhang, "Deep Learning
              with Differential Privacy", Proceedings of the 2016 ACM
              SIGSAC Conference on Computer and Communications
              Security, 2016.

   [Bonawitz17]
              Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A.,
              McMahan, H.B., Patel, S., Ramage, D., Segal, A., and K.
              Seth, "Practical Secure Aggregation for Privacy-
              Preserving Machine Learning", Proceedings of the 2017
              ACM SIGSAC Conference on Computer and Communications
              Security, 2017.

   [Dwork14]  Dwork, C. and A. Roth, "The Algorithmic Foundations of
              Differential Privacy", Foundations and Trends in
              Theoretical Computer Science, Vol. 9, No. 3-4, 2014.

   [Kairouz21]
              Kairouz, P., McMahan, H.B., Avent, B., et al., "Advances
              and Open Problems in Federated Learning", Foundations
              and Trends in Machine Learning, Vol. 14, No. 1-2, 2021.

   [McMahan17]
              McMahan, H.B., Moore, E., Ramage, D., Hampson, S., and
              B. Aguera y Arcas, "Communication-Efficient Learning of
              Deep Networks from Decentralized Data", Proceedings of
              AISTATS, 2017.

Kale                          Informational                    [Page 11]

Internet-Draft        Federated Learning for Agents         January 2026


   [Rosenberg25]
              Rosenberg, J. and C. Jennings, "Framework, Use Cases and
              Requirements for AI Agent Protocols", Work in Progress,
              Internet-Draft, draft-rosenberg-aiproto-framework-00,
              October 2025.

   [SLIM25]   Muscariello, L., Papalini, M., Sardara, S., and S.
              Betts, "Secure Low-Latency Interactive Messaging
              (SLIM)", Work in Progress, Internet-Draft,
              draft-mpsb-agntcy-slim-00, October 2025.

   [Wang23]   Wang, J., Charles, Z., Xu, Z., Joshi, G., McMahan, H.B.,
              et al., "A Field Guide to Federated Optimization",
              arXiv:2107.06917, 2023.

Appendix A.  Example Configuration

   Example deployment configuration for enterprise AI agent system:

   {
     "federated_learning": {
       "rounds": 100,
       "local_epochs": 5,
       "learning_rate": 0.01,
       "privacy": {
         "epsilon": 3.0,
         "delta": 1e-6,
         "clipping_bound": 1.0,
         "noise_multiplier": 1.1
       },
       "aggregation": {
         "method": "fedavg",
         "weighting": "population_proportional",
         "min_tenants_per_round": 10
       }
     }
   }














Kale                          Informational                    [Page 12]

Internet-Draft        Federated Learning for Agents         January 2026


Author's Address

   Nik Kale
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, CA 95134
   United States of America

   Email: nikkal@cisco.com










































Kale                          Informational                    [Page 13]


name: draft-li-dmsc-inf-architecture
rev: 05
title: Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
time: 2026-02-05T02:44:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-09T02:44:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:05.127457+00:00
abstract:
This document presents an architectural framework for dynamic multi-
   agent collaboration from an infrastructure perspective.  It outlines
   the network requirements introduced by large-scale agents
   collaboration, and proposes a systematic approach to enabling Dynamic
   Multi-agent Secured Collaboration (DMSC) through infrastructure
   capabilities.  The architecture focuses on how network control and
   forwarding functions can actively participate in agent collaboration.

full_text:
DMSC Working Group                                                 X. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 9 August 2026                                   5 February 2026


 Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
                   draft-li-dmsc-inf-architecture-05

Abstract

   This document presents an architectural framework for dynamic multi-
   agent collaboration from an infrastructure perspective.  It outlines
   the network requirements introduced by large-scale agents
   collaboration, and proposes a systematic approach to enabling Dynamic
   Multi-agent Secured Collaboration (DMSC) through infrastructure
   capabilities.  The architecture focuses on how network control and
   forwarding functions can actively participate in agent collaboration.

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

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Li & Wang                 Expires 9 August 2026                 [Page 1]

Internet-Draft              DMSC Architecture              February 2026


   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 . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Network Requirements  . . . . . . . . . . . . . . . . . . . .   4
   5.  DMSC Architecture Overview  . . . . . . . . . . . . . . . . .   4
     5.1.  DMSC Infrastructure Architecture  . . . . . . . . . . . .   5
   6.  Infrastructure Functions Enabling Active Network
           Participation . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Agent Identification and Capability Directory . . . . . .   8
     6.2.  Infrastructure-Level Agent Discovery  . . . . . . . . . .   8
     6.3.  Semantic Routing  . . . . . . . . . . . . . . . . . . . .   8
     6.4.  Secure Collaboration Capability and Policy  . . . . . . .   9
     6.5.  Operational Visibility  . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Intelligent agents have evolved rapidly in recent years, driven by
   advances in artificial intelligence models, computing platforms, and
   network connectivity.  Early forms of agents were typically embedded
   within isolated systems and designed to perform narrowly defined
   tasks under predefined conditions.  Their interactions with external
   entities were limited and often mediated by tightly coupled
   application logic [IoA].












Li & Wang                 Expires 9 August 2026                 [Page 2]

Internet-Draft              DMSC Architecture              February 2026


   With the increasing availability of large-scale AI models, edge
   computing resources, and programmable network infrastructures, agents
   are becoming more autonomous, adaptive, and capable of operating
   across distributed environments.  Modern agents can perceive changes
   in their environment, make decisions based on local or shared
   information, and interact with other agents and tools in order to
   achieve complex objectives.  These interactions are no longer
   confined to static configurations or single administrative domains,
   but increasingly span devices, networks, and application platforms.

   As agents continue to proliferate, they are forming large-scale
   collaborative systems in which multiple agents dynamically discover
   each other, exchange information, and coordinate actions.  Such
   systems exhibit highly dynamic behavior, including frequent changes
   in agent population, roles, and interaction patterns.  The resulting
   agent ecosystems resemble an open, interconnected environment rather
   than a collection of isolated applications.

   The evolution toward large-scale, dynamic agent ecosystems introduces
   new challenges for the underlying network infrastructure.  While
   agents are capable of sophisticated reasoning and decision-making,
   their ability to collaborate effectively depends on the availability
   of common, scalable, and interoperable networking support.

   This document focuses on the architectural aspects of enabling
   dynamic multi-agent collaboration from a network and infrastructure
   perspective.  It examines how network control and forwarding
   functions can be extended to recognize agents as first-class entities
   and provide generic support for agent identification, discovery,
   semantic routing, and coordination.  The architecture is intended to
   support a wide range of agent types, including on-device agents,
   network-resident agents, and third-party agents, without imposing
   assumptions about their internal implementation.

   The scope of this document is limited to architectural concepts and
   functional building blocks.  It does not define specific protocols,
   data models, or security mechanisms, nor does it prescribe particular
   deployment scenarios or application workflows.  Instead, it provides
   a foundational framework upon which more detailed specifications,
   including protocol designs and security architectures, can be
   developed in subsequent documents.

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




Li & Wang                 Expires 9 August 2026                 [Page 3]

Internet-Draft              DMSC Architecture              February 2026


3.  Terminology

   The following terms are defined in this draft:

   *  DMSC: Dynamic Multi-agent Secured Collaboration.  The framework
      and infrastructure enabling secure and efficient collaboration
      among dynamic agents.

   *  Agent: An autonomous software entity capable of perception,
      planning, decision-making, and execution.

   *  SemR: Semantic Routing.  The process of routing an Agent request
      based on the meaning or intent of the request, rather than solely
      on IP address.

4.  Network Requirements

   The proliferation of intelligent agents fundamentally reshapes
   interaction patterns and control dynamics in future networks.  Agent
   interactions are typically short-lived, context-dependent, and driven
   by task semantics rather than static endpoints.  Moreover, agents may
   dynamically join or leave collaborative groups, migrate across
   administrative domains, or change roles over time.  These
   characteristics introduce new requirements for network
   infrastructures, including agent-level identity management,
   capability-aware communication, scalable registration and discovery,
   cross-domain collaboration support, and adaptive routing, as also
   reflected in [draft-yu-ai-agent-use-cases-in-6g].[usecase]

   Collectively, these requirements indicate that future networks must
   go beyond passive connectivity and actively support dynamic multi-
   agent collaboration.  The core idea of Dynamic Multi-agent Secured
   Collaboration (DMSC) is to elevate key collaboration-related
   functions into the network infrastructure.  Instead of embedding all
   coordination logic within applications or agent frameworks, DMSC
   leverages infrastructure-level capabilities exposed through control-
   plane and forwarding-plane functions.  This approach enables the
   network to recognize agents as first-class entities, maintain high-
   level collaboration context, and make informed decisions on
   discovery, routing, and coordination support in a scalable and
   interoperable manner.

5.  DMSC Architecture Overview








Li & Wang                 Expires 9 August 2026                 [Page 4]

Internet-Draft              DMSC Architecture              February 2026


5.1.  DMSC Infrastructure Architecture

   Figure 1 illustrates the overall architecture for dynamic multi-agent
   collaboration from an infrastructure-centric perspective.  The
   architecture positions the network infrastructure as an active
   participant in agent collaboration, while preserving the autonomy and
   task-level reasoning of individual agents.  In this architecture, the
   network does not execute agent logic or interpret task semantics.
   Instead, it provides generic support functions that enable agents to
   collaborate more efficiently and reliably.  Agents remain autonomous,
   while the network supplies shared infrastructure capabilities.

   From an infrastructure perspective, the architecture is organized
   into three logical layers:

   *  Management Plane: governs authentication, capability taxonomy,
      observability and policy aspects.

   *  Control Plane: Manages agent registration, discovery, invocation,
      lifecycle, and capability information maintenance and so on.

   *  Forwarding Plane: Supports semantic routing for agent
      interactions.




























Li & Wang                 Expires 9 August 2026                 [Page 5]

Internet-Draft              DMSC Architecture              February 2026


   +------------------------------------------------------------------------------------+
   |                         Management & Orchestration Plane                           |
   |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
   |  |  Agent       |   |Capability Taxonomy|   | Observability & |  |Policy Manager|  |
   |  |Authentication|   |(Agent,Capability) |   | Analytics       |  | (Rules...)   |  |
   |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
   +------------------------------------------------------------------------------------+
                                       |        ^
                                       v        |
+-------------------------------------------------------------------------------------------+
|                                  Network Infrastructure                                   |
| +---------------------------------------------------------------------------------------+ |
| |         Node 1                              Node 2                     Node 3 ...     | |
| | +-------------------------+    +-------------------------+     +--------------------+ | |
| | |      Control Plane      |    |      Control Plane      |     | Control Plane      | | |
| | |-------------------------|    |-------------------------|     |--------------------| | |
| | | - Agent Registration    |<-->| - Agent Registration    |<--> | ...                | | |
| | | - Agent Invocation      |    | - Agent Invocation      |     |                    | | |
| | | - Agent Discovery       |    | - Agent Discovery       |     |                    | | |
| | | - Capability Directory  |    | - Capability Directory  |     |                    | | |
| | +-------------------------+    +-------------------------+     +--------------------+ | |
| |            | Control & Policy               | Control                   | Control     | |
| |            v                                v & Policy                  v & Policy    | |
| | +------------------------+     +-------------------------+      +-------------------+ | |
| | | Forwarding Plane       |     |      Forwarding Plane   |      | Forwarding Plane  | | |
| | |------------------------+     +-------------------------+      +-------------------+ | |
| | | - Semantic  Routing    |     |    ...                  |      |  ...              | | |
| | | - ...                  |     |                         |      |                   | | |
| | +------------------------+     +-------------------------+      +-------------------+ | |
| +---------------------------------------------------------------------------------------+ |
+------------------^  ------------------------^ ------------------------------^ ------------+
                   |Registration              |  Registration                 |Registration
                   |                          |                               |
         +--------------------+     +--------------------+         +--------------------+
         |        Agent A     |     |        Agent B     |         |        Agent C     |
         |--------------------|     |--------------------|         |--------------------|
         | - Capabilities     |     | - Capabilities     |         | - Capabilities     |   ...
         | - Local Reasoning  |     | - Local Reasoning  |         | - Local Reasoning  |
         +--------------------+     +--------------------+         +--------------------+
   Figure 1 The infrastructure architecture of dynamic multi-agent collaboration

   On top of this architecture, agents engage in collaborative
   activities driven by task intents, shared goals, and capability
   information.  Agents are responsible for local reasoning, decision-
   making, and execution of task-specific logic.  The network does not
   interpret agent semantics or execute agent logic; instead, it
   provides common infrastructure capabilities that support efficient
   and scalable collaboration among agents.  Above the network



Li & Wang                 Expires 9 August 2026                 [Page 6]

Internet-Draft              DMSC Architecture              February 2026


   infrastructure, a Management and Orchestration Plane provides non-
   real-time management functions, including agent authentication, agent
   capability taxonomy management, policy management, observability and
   analytics.  This plane supplies policy, trust, and state-related
   inputs to the network infrastructure.

   The network infrastructure itself is composed of multiple network
   nodes, each implementing a common set of logical functions, and the
   nodes support hierarchical deployment.  Within each node, the Control
   Plane provides agent-aware control functions, including agent
   identity management, capability directory maintenance, registration,
   and discovery control.  These functions enable the network to
   recognize agents as first-class entities and maintain a consistent
   view of agent-related information across the infrastructure.  By
   decoupling agent identity from physical location through capability
   identifiers, the control plane supports dynamic agent lifecycle
   events such as mobility, instantiation, and termination.

   The Forwarding Plane supports semantic routing by forwarding requests
   based on capability identifiers—such as /capability/ocr—rather than
   static IP addresses.  When multiple instances of a capability are
   available, the forwarding plane may select a target based on real-
   time health and availability information—such as liveness or
   load—provided by the control plane.  In the event of failure, it can
   perform fast failover to an alternative instance within the same
   capability group, ensuring continuity of service.

   When an agent joins the network, it authenticates and obtains trusted
   authorization through network controller; only verified agents may
   register their capabilities—such as “supports high-precision OCR” or
   “performs GDPR-compliant de-identification”—which are stored locally
   to form a capability directory.  When another agent issues a
   capability-based discovery request (e.g., “find an OCR agent”), the
   local node either responds directly or securely synchronizes
   capability information with other nodes—including across domains or
   clouds—to locate eligible candidates.  Once a target is identified,
   the request is forwarded via semantic routing (e.g., using
   /capability/ocr) to the appropriate instance.

   Overall, this architecture establishes a clear division of
   responsibilities: agents focus on intelligent behavior and task
   execution, while the network infrastructure provides capability-based
   control, semantic forwarding, and secure coordination mechanisms.
   This separation enables dynamic multi-agent collaboration to scale
   across heterogeneous environments—on-premises, at the edge, or in the
   cloud—while allowing agents and the network to evolve independently.





Li & Wang                 Expires 9 August 2026                 [Page 7]

Internet-Draft              DMSC Architecture              February 2026


6.  Infrastructure Functions Enabling Active Network Participation

6.1.  Agent Identification and Capability Directory

   In large-scale dynamic multi-agent environments, agents cannot be
   effectively supported using traditional host- or service-based
   identifiers alone.  Agents may be instantiated dynamically, migrate
   across network locations, or operate concurrently on the same
   physical node.  As a result, the network requires a mechanism to
   identify agents as logical entities that are decoupled from network
   topology.

   The proposed architecture introduces network-visible agent
   identifiers that represent agents independently of their physical
   location or hosting environment.  These identifiers enable the
   network to consistently recognize agents across control and
   forwarding functions, even as underlying network bindings change.
   Beyond basic identification, the architecture supports forming an
   agent capability directory on nodes.

6.2.  Infrastructure-Level Agent Discovery

   Agent discovery is a fundamental prerequisite for collaboration, yet
   traditional discovery mechanisms are typically designed for
   relatively static services or tightly scoped environments.  In
   contrast, multi-agent collaboration requires discovery mechanisms
   that can operate across heterogeneous platforms, adapt to dynamic
   agent populations, and respect administrative boundaries.

   In DMSC architecture, agent discovery is provided as an
   infrastructure-level function, rather than being entirely implemented
   within agent frameworks.  The network supports discovery queries
   based on agent identifiers, advertised capabilities.  This allows
   agents to locate suitable collaborators without requiring global
   knowledge or centralized coordination.

6.3.  Semantic Routing

   Traditional routing mechanisms forward packets based on destination
   addresses without awareness of application intent.  In dynamic multi-
   agent collaboration, however, interactions are driven by *what* is
   needed—such as a specific capability—rather than *where* a fixed
   endpoint resides.  The DMSC architecture addresses this by
   introducing semantic routing: requests are expressed in terms of
   agent capabilities (e.g., "/capability/ocr").






Li & Wang                 Expires 9 August 2026                 [Page 8]

Internet-Draft              DMSC Architecture              February 2026


   Semantic routing enables flexible agent invocation without hard-coded
   endpoints.  A request for a given capability can be routed to any
   authorized and available instance that has declared that capability.
   If the selected instance becomes unavailable, the network may fail
   over to another instance within the same capability group, provided
   such redundancy exists.

6.4.  Secure Collaboration Capability and Policy

   Effective collaboration among dynamic agents requires consistent
   handling of capabilities and policies, especially when interactions
   span multiple domains or network segments.  The DMSC architecture
   supports secure synchronization of capability declarations and policy
   constraints at the infrastructure level.

   Capability information associated with an agent—such as its declared
   functions (e.g., OCR, payment validation) and security attributes
   (e.g., GDPR compliance, authentication requirements)—can be
   registered with the control plane and synchronized across domains.
   Where appropriate, these capability descriptions may be bound to
   policy rules that govern access and interaction.  Security-related
   attributes, such as authorization scope or domain-specific
   constraints, can be attached to capability entries to ensure that
   interactions remain compliant with local regulations and trust
   boundaries.  In cross-domain scenarios, policy abstraction mechanisms
   support controlled translation or normalization to enable
   interoperability while respecting local governance.

6.5.  Operational Visibility

   As multi-agent systems scale, gaining visibility into collaboration-
   level behavior becomes essential for effective operation and
   troubleshooting.  Traditional network observability focuses on flows
   and endpoints, offering limited insight into agent interactions and
   coordination dynamics.  The DMSC architecture introduces operational
   visibility at the collaboration level by enabling controlled
   observation of key interaction events.

   Observable entities may include:

   *  Agent registration and abstract capability advertisements.

   *  Capability-based discovery activities and outcomes.

   *  Semantic routing decisions and high-level invocation outcomes.

   *  Association with network resources and applied policy controls.




Li & Wang                 Expires 9 August 2026                 [Page 9]

Internet-Draft              DMSC Architecture              February 2026


   This visibility is not intended to expose agent internals or infer
   application logic, but to provide sufficient information for
   monitoring, auditing, root cause analysis, and performance
   optimization.  The collected telemetry can be used by management and
   orchestration systems to support long-term optimization—such as
   identifying underutilized capabilities or detecting policy
   violations.  It may also inform policy refinement and infrastructure
   planning, but does not drive real-time control-plane decisions or
   forwarding-plane behavior.  To address privacy and security concerns,
   exposure of observable data is controlled through policy mechanisms,
   ensuring that only authorized parties can access relevant
   information.

7.  Security Considerations

   This architecture introduces several security considerations,
   including risks related to agent identity spoofing, capability
   misrepresentation, semantic routing manipulation, cross-domain trust
   inconsistencies, and information leakage through enhanced
   observability.  Detailed security mechanisms are outside the scope of
   this document.

8.  IANA Considerations

   TBD

9.  Acknowledgement

   TBD

10.  Normative References

   [IoA]      L, J., "Internet of Agents – Definition, Architecture and
              Applications.
              https://aip.openatom.tech/explore/journalism/
              detail/501037383572131840", October 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>.

   [usecase]  Y, M., "AI Agent Use Cases and Requirements in 6G Network.
              draft-yu-ai-agent-use-cases-in-6g.
              <https://datatracker.ietf.org/doc/html/draft-yu-dmsc-ai-
              agent-use-cases-in-6g>", July 2025.





Li & Wang                 Expires 9 August 2026                [Page 10]

Internet-Draft              DMSC Architecture              February 2026


Authors' Addresses

   Xueting Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lixt2@foxmail.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn

































Li & Wang                 Expires 9 August 2026                [Page 11]


