# drafts

name: draft-ainp-protocol
rev: 00
title: AI-Native Network Protocol (AINP) for Semantic Agent Communication
time: 2025-11-24T20:30:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-28T20:30:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:06.864819+00:00
abstract:
This document specifies the AI-Native Network Protocol (AINP) version
   0.1, a semantic communication protocol designed for intent exchange
   between AI agents.  AINP replaces location-based routing with
   semantic routing, byte-stream delivery with intent delivery, and
   simple handshakes with multi-round negotiation.  AINP enables agents
   to discover each other by capability rather than network location,
   negotiate terms autonomously, and exchange structured intents with
   cryptographic security.

full_text:
Independent Submission                                 E. P. Nagulapalli
Internet-Draft                                             Servesys Labs
Intended status: Standards Track                        24 November 2025
Expires: 28 May 2026


   AI-Native Network Protocol (AINP) for Semantic Agent Communication
                         draft-ainp-protocol-00

Abstract

   This document specifies the AI-Native Network Protocol (AINP) version
   0.1, a semantic communication protocol designed for intent exchange
   between AI agents.  AINP replaces location-based routing with
   semantic routing, byte-stream delivery with intent delivery, and
   simple handshakes with multi-round negotiation.  AINP enables agents
   to discover each other by capability rather than network location,
   negotiate terms autonomously, and exchange structured intents with
   cryptographic security.

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

Copyright Notice

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










Nagulapalli                Expires 28 May 2026                  [Page 1]

Internet-Draft                AINP Protocol                November 2025


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Definitions . . . . . . . . . . . . . . . . . . . . .   4
   2.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   3.  Wire Format . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Message Envelope  . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Envelope Fields . . . . . . . . . . . . . . . . . . .   5
     3.3.  Message Types . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Quality of Service Parameters . . . . . . . . . . . . . .   5
     3.5.  Capability Query  . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Signature Format  . . . . . . . . . . . . . . . . . . . .   6
   4.  Semantic Addresses  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Decentralized Identifiers (DIDs)  . . . . . . . . . . . .   6
     4.2.  Semantic Address Structure  . . . . . . . . . . . . . . .   7
   5.  Intent Schemas  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  REQUEST_MEETING Intent  . . . . . . . . . . . . . . . . .   7
     5.2.  APPROVAL_REQUEST Intent . . . . . . . . . . . . . . . . .   7
     5.3.  SUBMIT_INFO Intent  . . . . . . . . . . . . . . . . . . .   8
     5.4.  INVOICE Intent  . . . . . . . . . . . . . . . . . . . . .   8
     5.5.  FREEFORM_NOTE Intent  . . . . . . . . . . . . . . . . . .   8
     5.6.  REQUEST_SERVICE Intent  . . . . . . . . . . . . . . . . .   9
   6.  Negotiation Protocol  . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Negotiation Flow  . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Negotiation Message Structure . . . . . . . . . . . . . .   9
     6.3.  Negotiation Convergence . . . . . . . . . . . . . . . . .   9
     6.4.  Timeout Behavior  . . . . . . . . . . . . . . . . . . . .  10
     6.5.  Multi-Party Negotiation . . . . . . . . . . . . . . . . .  10
   7.  Protocol Handshake Sequence . . . . . . . . . . . . . . . . .  10
     7.1.  Five-Step Handshake . . . . . . . . . . . . . . . . . . .  10
     7.2.  ADVERTISE Phase . . . . . . . . . . . . . . . . . . . . .  10
     7.3.  DISCOVER Phase  . . . . . . . . . . . . . . . . . . . . .  11
     7.4.  ERROR Phase . . . . . . . . . . . . . . . . . . . . . . .  11
     7.5.  Offline Intent Queueing . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
     8.2.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .  12



Nagulapalli                Expires 28 May 2026                  [Page 2]

Internet-Draft                AINP Protocol                November 2025


     8.3.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  12
     8.4.  Replay Protection . . . . . . . . . . . . . . . . . . . .  12
     8.5.  DoS Protection  . . . . . . . . . . . . . . . . . . . . .  13
     8.6.  Replay Protection and Delivery Semantics  . . . . . . . .  13
     8.7.  Capability Attestations . . . . . . . . . . . . . . . . .  13
     8.8.  Timeouts  . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.9.  Outlier Detection . . . . . . . . . . . . . . . . . . . .  13
     8.10. Discovery Scalability . . . . . . . . . . . . . . . . . .  13
     8.11. Lite Mode for Resource-Constrained Agents . . . . . . . .  14
   9.  CBOR Encoding (Optional)  . . . . . . . . . . . . . . . . . .  15
   10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Custom Intent Types  . . . . . . . . . . . . . . . . . .  15
     10.2.  Custom Negotiation Terms . . . . . . . . . . . . . . . .  15
     10.3.  Versioning . . . . . . . . . . . . . . . . . . . . . . .  15
     10.4.  Lite Profile (Trusted Networks)  . . . . . . . . . . . .  15
   11. Success Metrics . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Route Success Rate . . . . . . . . . . . . . . . . . . .  16
     11.2.  Latency (p95)  . . . . . . . . . . . . . . . . . . . . .  16
     11.3.  Negotiation Completion Rate  . . . . . . . . . . . . . .  16
     11.4.  False Route Rate . . . . . . . . . . . . . . . . . . . .  16
     11.5.  Abuse Resilience . . . . . . . . . . . . . . . . . . . .  16
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     13.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Traditional network protocols (TCP/IP, HTTP, SMTP) were designed for
   reliable byte stream delivery between machines.  AINP represents a
   paradigm shift: it is designed for semantic intent delivery between
   AI agents, with built-in understanding, negotiation, and adaptation.

   AINP Phase 0.1 provides: - Wire format specification (JSON-LD + CBOR)
   - Message envelope structure with cryptographic signatures - Intent
   schemas for common agent interactions - Semantic address format with
   Decentralized Identifiers (DIDs) - Negotiation protocol for multi-
   agent consensus - Discovery and routing mechanisms

1.1.  Terminology

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






Nagulapalli                Expires 28 May 2026                  [Page 3]

Internet-Draft                AINP Protocol                November 2025


1.1.1.  Definitions

   *Agent*: An autonomous software entity capable of semantic
   understanding and intent exchange

   *Intent*: A semantic representation of an agent's goal, including
   embeddings and structured semantics

   *Semantic Address*: An identity-based address using DIDs and
   capability descriptors

   *Negotiation*: Multi-round protocol for establishing consensus on
   resources, terms, and capabilities

   *Capability*: A semantic description of what an agent can do,
   including natural language and embeddings

   *Trust Vector*: Multi-dimensional reputation score tracking
   reliability, honesty, competence, and timeliness

2.  Architecture Overview

   AINP consists of four layers:

   +-----------------------------+ | Intent Layer | Semantic exchange
   (intents) +-----------------------------+ | Negotiation Layer |
   Multi-agent consensus +-----------------------------+ | Routing
   Layer | Semantic routing +-----------------------------+ | Substrate
   Layer | Physical transport (TCP/IP, etc.)
   +-----------------------------+

   Phase 0.1 runs as an overlay network on TCP/IP with WebSocket or
   HTTP/3 transport.

3.  Wire Format

3.1.  Encoding

   AINP messages MUST support both: - *JSON-LD*: Human-readable, linked
   data format with @context for semantic interoperability - *CBOR*:
   Binary encoding ([RFC8949]) for efficient transmission

   Implementations SHOULD negotiate encoding during handshake.  JSON-LD
   is the default for Phase 0.1.







Nagulapalli                Expires 28 May 2026                  [Page 4]

Internet-Draft                AINP Protocol                November 2025


3.2.  Message Envelope

   All AINP messages MUST be wrapped in an envelope structure:

   json { "version": "0.1.0", "msg_type": "INTENT", "id": "550e8400-
   e29b-41d4-a716-446655440000", "timestamp": 1728259400000, "ttl":
   30000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
   "to_did": "did:key:z6Mk...", "schema":
   "https://ainp.dev/schemas/intents/request-meeting/v1", "qos": {
   "urgency": 0.7, "importance": 0.8, "novelty": 0.1, "ethicalWeight":
   0.5, "bid": 5 }, "payload": { ... }, "sig": "base64signature..." }

3.2.1.  Envelope Fields

   *  version (string, REQUIRED): Protocol version, MUST be "0.1.0"
   *  msg_type (string, REQUIRED): Message type (see Section 3.3)
   *  id (string, REQUIRED): UUID v4 for message identification
   *  timestamp (number, REQUIRED): Unix epoch milliseconds
   *  ttl (number, REQUIRED): Time-to-live in milliseconds
   *  trace_id (string, REQUIRED): Distributed tracing UUID for thread
      tracking
   *  from_did (string, REQUIRED): Sender DID ([W3C.DID])
   *  to_did (string, OPTIONAL): Recipient DID (for direct addressing)
   *  to_query (object, OPTIONAL): Semantic query (alternative to
      to_did, see Section 3.5)
   *  schema (string, REQUIRED): JSON-LD context URI
   *  qos (object, REQUIRED): Quality of Service parameters (see
      Section 3.4)
   *  payload (object, OPTIONAL): Application payload (intent,
      negotiation, etc.)
   *  sig (string, REQUIRED): Ed25519 signature in base64 encoding

3.3.  Message Types

   AINP defines the following message types:

   *  ADVERTISE: Publish capabilities to discovery index
   *  DISCOVER: Query for agents by capability
   *  DISCOVER_RESULT: Discovery results
   *  NEGOTIATE: Multi-round negotiation
   *  INTENT: Send intent payload
   *  RESULT: Response with optional proof
   *  ERROR: Error response

3.4.  Quality of Service Parameters

   QoS parameters enable priority-based routing and resource allocation:




Nagulapalli                Expires 28 May 2026                  [Page 5]

Internet-Draft                AINP Protocol                November 2025


   json { "urgency": 0.7, // 0-1, time sensitivity "importance": 0.8, //
   0-1, impact magnitude "novelty": 0.1, // 0-1, information gain
   "ethicalWeight": 0.5, // 0-1, moral importance "bid": 5 // Token
   amount or credits (non-negative) }

   *Priority Calculation*: Implementations SHOULD calculate message
   priority as:

   priority = (urgency * w_urgency) + (importance * w_importance) +
   (novelty * w_novelty) + (ethicalWeight * w_ethical) adjusted_priority
   = priority + 0.5 * tanh(bid / bid_scale)

   Where bid_scale is node-configurable (RECOMMENDED default: 10
   credits).

   *Default Weights*: - w_urgency = 0.3 - w_importance = 0.3 - w_novelty
   = 0.2 - w_ethical = 0.2

3.5.  Capability Query

   For semantic discovery, agents use capability queries:

   json { "description": "Find agents who can schedule meetings",
   "embedding": "base64-encoded Float32Array[1536]", "tags":
   ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000,
   "max_cost": 10 }

3.6.  Signature Format

   Messages MUST be signed using Ed25519 ([Ed25519]) with detached
   signatures in base64 encoding.

   *Signing Process*: 1.  Serialize envelope fields (excluding sig) to
   canonical JSON ([RFC8785]) 2.  Compute SHA-256 hash of canonical JSON
   3.  Sign hash with Ed25519 private key 4.  Encode signature as base64
   5.  Add sig field to envelope

   *Verification Process*: 1.  Extract sig field 2.  Remove sig from
   envelope 3.  Serialize remaining fields to canonical JSON ([RFC8785])
   4.  Compute SHA-256 hash 5.  Verify signature using Ed25519 public
   key from from_did

4.  Semantic Addresses

4.1.  Decentralized Identifiers (DIDs)

   Agents MUST have a DID conforming to [W3C.DID].




Nagulapalli                Expires 28 May 2026                  [Page 6]

Internet-Draft                AINP Protocol                November 2025


   *Supported DID Methods* (Phase 0.1): - did:key: - Self-certified
   cryptographic keys - did:web: - Web-based identifiers

4.2.  Semantic Address Structure

   json { "did": "did:key:z6Mk...", "capabilities": [ { "description":
   "Schedule meetings with calendar integration", "embedding": { "b64":
   "base64-encoded float32 array", "dim": 1536, "dtype": "f32", "model":
   "openai:text-embedding-3-small" }, "tags": ["scheduling",
   "calendar"], "version": "1.0.0", "evidence":
   "https://credentials.example.com/vc/scheduling" } ], "trust": {
   "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85,
   "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977,
   "last_updated": 1728259200000 }, "credentials":
   ["https://credentials.example.com/vc/scheduling"] }

5.  Intent Schemas

   AINP defines six core intent types for Phase 0.1.  All intents MUST
   include: - JSON-LD @context for semantic interoperability - Embedding
   (Embedding object; base64 Float32Array inside b64) - Budget
   constraints - Semantic payload

5.1.  REQUEST_MEETING Intent

   *Schema URI*: https://ainp.dev/schemas/intents/request-meeting/v1

   json { "@context": "https://ainp.dev/contexts/meeting/v1", "@type":
   "RequestMeeting", "version": "1.0.0", "embedding": { "b64":
   "base64-encoded Float32Array", "dim": 1536, "dtype": "f32", "model":
   "openai:text-embedding-3-small" }, "semantics": { "participants":
   ["did:key:..."], "duration_minutes": 30, "preferred_times":
   ["2025-10-07T14:00:00Z"], "location": "virtual", "constraints": {
   "timezone": "America/Los_Angeles", "max_latency_ms": 5000,
   "min_notice_hours": 24 } }, "budget": { "max_credits": 10,
   "max_rounds": 5, "timeout_ms": 30000 } }

5.2.  APPROVAL_REQUEST Intent

   *Schema URI*: https://ainp.dev/schemas/intents/approval-request/v1











Nagulapalli                Expires 28 May 2026                  [Page 7]

Internet-Draft                AINP Protocol                November 2025


   json { "@context": "https://ainp.dev/contexts/approval/v1", "@type":
   "ApprovalRequest", "version": "1.0.0", "embedding": { "b64": "...",
   "dim": 1536, "dtype": "f32" }, "semantics": { "request_type":
   "purchase", "description": "Purchase office supplies", "amount": 500,
   "currency": "USD", "justification": "Quarterly restock", "deadline":
   "2025-10-10T00:00:00Z", "approvers": ["did:key:..."], "threshold": 1,
   "constraints": { "requires_attestation": true, "max_latency_ms": 5000
   } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms":
   30000 } }

5.3.  SUBMIT_INFO Intent

   *Schema URI*: https://ainp.dev/schemas/intents/submit-info/v1

   json { "@context": "https://ainp.dev/contexts/submit-info/v1",
   "@type": "SubmitInfo", "version": "1.0.0", "embedding": { "b64":
   "...", "dim": 1536, "dtype": "f32" }, "semantics": { "data_type":
   "form", "payload": { "field1": "value1" }, "schema_ref":
   "https://example.com/schema.json", "privacy_level": "encrypted",
   "retention_policy": { "duration_days": 90, "delete_after": true },
   "constraints": { "requires_acknowledgment": true, "max_latency_ms":
   5000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
   "timeout_ms": 15000 } }

5.4.  INVOICE Intent

   *Schema URI*: https://ainp.dev/schemas/intents/invoice/v1

   json { "@context": "https://ainp.dev/contexts/invoice/v1", "@type":
   "Invoice", "version": "1.0.0", "embedding": { "b64": "...", "dim":
   1536, "dtype": "f32" }, "semantics": { "invoice_id": "INV-2025-001",
   "from": "did:key:...", "to": "did:key:...", "amount": "1000.00",
   "currency": "USD", "line_items": [ { "description": "Service fee",
   "quantity": 1, "unit_price": "1000.00", "total": "1000.00" } ],
   "due_date": "2025-11-01T00:00:00Z", "payment_methods": ["crypto",
   "wire"], "constraints": { "requires_escrow": true, "max_latency_ms":
   10000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
   "timeout_ms": 30000 } }

5.5.  FREEFORM_NOTE Intent

   *Schema URI*: https://ainp.dev/schemas/intents/freeform-note/v1

   json { "@context": "https://ainp.dev/contexts/freeform/v1", "@type":
   "FreeformNote", "version": "1.0.0", "embedding": { "b64": "...",
   "dim": 1536, "dtype": "f32" }, "semantics": { "subject": "Meeting
   notes", "body": "Discussion summary...", "format": "markdown",
   "attachments": [ { "url": "https://example.com/doc.pdf", "mime_type":



Nagulapalli                Expires 28 May 2026                  [Page 8]

Internet-Draft                AINP Protocol                November 2025


   "application/pdf", "size_bytes": 102400, "hash": "sha256:abc123..." }
   ], "thread_id": "thread-123", "in_reply_to": "msg-456",
   "constraints": { "max_latency_ms": 5000 } }, "budget": {
   "max_credits": 1, "max_rounds": 1, "timeout_ms": 10000 } }

5.6.  REQUEST_SERVICE Intent

   *Schema URI*: https://ainp.dev/schemas/intents/request-service/v1

   json { "@context": "https://ainp.dev/contexts/service/v1", "@type":
   "RequestService", "version": "1.0.0", "embedding": { "b64": "...",
   "dim": 1536, "dtype": "f32" }, "semantics": { "service_type":
   "plumbing.leak.fix", "geo": { "lat": 37.7749, "lon": -122.4194,
   "radiusKm": 10, "zip": "94102" }, "time_window": { "earliest":
   "2025-10-08T09:00:00Z", "latest": "2025-10-08T17:00:00Z" },
   "constraints": { "eco": true, "access_notes": "Ring doorbell",
   "evidence_required": ["photo_before_after"] }, "details": {
   "urgency": "high", "description": "Kitchen sink leak" } }, "budget":
   { "max_credits": 20, "max_total": 200, "escrow_required": true,
   "max_rounds": 10, "timeout_ms": 60000 } }

6.  Negotiation Protocol

6.1.  Negotiation Flow

   Negotiation MUST follow this state machine:

   START -> OFFER -> COUNTER <-> COUNTER -> ACCEPT | | ABORT TIMEOUT | |
   REJECT REJECT

6.2.  Negotiation Message Structure

   json { "negotiation_id": "uuid", "round": 1, "phase": "OFFER",
   "proposal": { "price": 100, "latency_ms": 500, "confidence": 0.9,
   "privacy": "encrypted", "terms": {} }, "constraints": { "max_rounds":
   10, "timeout_per_round_ms": 5000, "convergence_threshold": 0.9 } }

   *Negotiation Phases*: - OFFER: Initial offer - COUNTER: Counter-offer
   - ACCEPT: Accept proposal - REJECT: Reject and end - ABORT: Abort
   negotiation - TIMEOUT: Timeout occurred

6.3.  Negotiation Convergence

   Implementations MAY auto-accept proposals when convergence threshold
   is met:

   ``` convergence_score = 1 - (abs(offer.price - counter.price) /
   max(offer.price, counter.price))



Nagulapalli                Expires 28 May 2026                  [Page 9]

Internet-Draft                AINP Protocol                November 2025


   if convergence_score >= convergence_threshold: auto_accept() ```

6.4.  Timeout Behavior

   *  *Per-round timeout*: If no response within timeout_per_round_ms,
      sender MAY send TIMEOUT message
   *  *Overall timeout*: If negotiation exceeds max_rounds *
      timeout_per_round_ms, MUST terminate with TIMEOUT

6.5.  Multi-Party Negotiation

   For intents involving multiple agents (e.g., scheduling a meeting
   with 5 participants, multi-signature approvals), negotiation MUST
   support group consensus mechanisms.

   *Group Proposal Structure*: json { "negotiation_id": "multi-abc123",
   "phase": "OFFER", "proposal": { "participants": ["did:key:agent-a",
   "did:key:agent-b", "did:key:agent-c"], "voting_mechanism":
   "majority", "convergence_threshold": 0.75, "terms": {
   "preferred_times": ["2025-10-07T14:00:00Z", "2025-10-07T15:00:00Z"],
   "duration_minutes": 30 } } }

   *Voting Mechanisms*: 1. *Unanimous*: All agents must ACCEPT (default
   for high-stakes) 2. *Majority*: More than 50% must ACCEPT 3.
   *Weighted*: Votes weighted by trust scores

   *Multi-Party Flow*: 1.  Fan-out: Send NEGOTIATE(OFFER) to all
   participants 2.  Collection: Each agent responds with individual
   proposal 3.  Aggregation: Broker aggregates and computes consensus
   score 4.  Convergence Check: Compare score to threshold 5.  Auto-
   accept if converged, else synthesize counter-proposal and repeat 6.
   Termination: ABORT after max_rounds or timeout if no consensus

7.  Protocol Handshake Sequence

7.1.  Five-Step Handshake

   1.  *ADVERTISE*: Agent publishes capabilities to discovery index
   2.  *DISCOVER*: Agent queries for matching capabilities
   3.  *NEGOTIATE*: Agents negotiate terms (OFFER → COUNTER → ACCEPT)
   4.  *INTENT*: Agent sends intent after successful negotiation
   5.  *RESULT*: Recipient responds with result

7.2.  ADVERTISE Phase

   Agent publishes capabilities to discovery index:





Nagulapalli                Expires 28 May 2026                 [Page 10]

Internet-Draft                AINP Protocol                November 2025


   json { "version": "0.1.0", "msg_type": "ADVERTISE", "id": "550e8400-
   e29b-41d4-a716-446655440000", "timestamp": 1728259200000, "ttl":
   86400000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
   "schema": "https://ainp.dev/schemas/advertise/v1", "qos": {
   "urgency": 0.1, "importance": 0.5, "novelty": 0.3, "ethicalWeight":
   0.5, "bid": 0 }, "sig": "base64signature...", "payload": {
   "capabilities": [ { "description": "Schedule meetings with calendar
   integration", "embedding": { "b64": "...", "dim": 1536, "dtype":
   "f32" }, "tags": ["scheduling", "calendar"], "version": "1.0.0",
   "evidence": "https://credentials.example.com/vc/scheduling" } ],
   "trust": { "score": 0.85, "dimensions": { "reliability": 0.9,
   "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 },
   "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials":
   ["https://credentials.example.com/vc/scheduling"] } }

7.3.  DISCOVER Phase

   Agent queries for capabilities:

   json { "version": "0.1.0", "msg_type": "DISCOVER", "id": "660e8400-
   e29b-41d4-a716-446655440001", "timestamp": 1728259300000, "ttl":
   10000, "trace_id": "trace-def456", "from_did": "did:key:z6Mk...",
   "to_query": { "description": "Find agents who can schedule meetings",
   "embedding": "base64...", "tags": ["scheduling", "calendar"],
   "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }, "schema":
   "https://ainp.dev/schemas/discover/v1", "qos": { "urgency": 0.5,
   "importance": 0.7, "novelty": 0.2, "ethicalWeight": 0.5, "bid": 1 },
   "sig": "base64signature..." }

   Discovery index responds with DISCOVER_RESULT containing matching
   agents with similarity scores, trust ratings, and estimated latency.

7.4.  ERROR Phase

   On error, agent MUST respond with ERROR message:

   json { "msg_type": "ERROR", "error_code": "TIMEOUT", "error_message":
   "Negotiation timed out", "intent_id": "770e8400-e29b-
   41d4-a716-446655440002", "retry_after_ms": 5000 }

   *Standard Error Codes*: - INVALID_SIGNATURE - UNAUTHORIZED -
   UNSUPPORTED_SCHEMA - TIMEOUT - RATE_LIMIT_EXCEEDED -
   INSUFFICIENT_CREDITS - NEGOTIATION_FAILED - ESCROW_REQUIRED -
   EVIDENCE_INSUFFICIENT - DUPLICATE_INTENT - AGENT_OFFLINE -
   INTERNAL_ERROR






Nagulapalli                Expires 28 May 2026                 [Page 11]

Internet-Draft                AINP Protocol                November 2025


7.5.  Offline Intent Queueing

   When recipient agent is offline or unreachable, broker MAY queue
   intents for later delivery instead of immediately failing.

   *Queue Behavior*: - TTL enforcement: Intent expires after ttl
   milliseconds from original timestamp - Broker SHOULD send ERROR to
   sender immediately: error_code: "AGENT_OFFLINE" - ERROR response
   SHOULD include retry_after_ms field - Broker MUST NOT queue intents
   indefinitely (maximum queue time = ttl)

   *Queue Delivery Protocol*: 1.  Agent Offline Detection: Broker
   detects agent offline 2.  Queue Intent: Insert into queue with
   expires_at = timestamp + ttl 3.  Send ERROR: Notify sender with
   AGENT_OFFLINE and retry_after_ms 4.  Agent Reconnect: When agent
   comes online, broker delivers queued intents in priority order 5.
   Delivery Ordering: Process queue as FIFO within each priority level
   6.  Retry Logic: If delivery fails, increment retry_count and retry
   after exponential backoff 7.  Expiration Cleanup: Periodically purge
   expired intents

8.  Security Considerations

8.1.  Authentication

   *  All messages MUST be signed with Ed25519
   *  Signatures MUST be verifiable using public key from from_did
   *  Unsigned messages MUST be rejected

8.2.  Identity

   *  Agents MUST have a valid [W3C.DID]
   *  DIDs MUST be resolvable to DID documents containing public keys

8.3.  Rate Limiting

   Implementations MUST enforce rate limits: - Default: 100 intents per
   minute per agent - Burst: Up to 200 intents in 10-second window -
   Discovery queries: 10 per minute per agent

8.4.  Replay Protection

   Recipients MUST reject duplicate messages with the same (from_did,
   id) seen within ttl + 60000ms.







Nagulapalli                Expires 28 May 2026                 [Page 12]

Internet-Draft                AINP Protocol                November 2025


8.5.  DoS Protection

   Implementations MUST: - Validate message signatures before processing
   - Enforce TTL (drop expired messages) - Limit negotiation rounds (max
   10) - Reject messages exceeding 1MB payload size - Require
   attachments by reference (URLs) rather than inlining large binaries

8.6.  Replay Protection and Delivery Semantics

   *  Recipients MUST reject duplicate messages with the same (from_did,
      id) seen within ttl + 60000ms
   *  Implementations MUST allow a clock skew of +/-60000ms when
      validating timestamp
   *  At-least-once delivery is RECOMMENDED; senders MUST use UUID v4
      ids and recipients MUST make intent handling idempotent with
      respect to id

8.7.  Capability Attestations

   *  Agents advertising capabilities SHOULD provide Verifiable
      Credentials (VCs)
   *  VCs MUST conform to [W3C.VC]
   *  Discovery indices MAY reject advertisements without VCs

8.8.  Timeouts

   *  *Intent delivery*: 60 seconds default TTL
   *  *Negotiation per round*: 5 seconds default
   *  *Overall negotiation*: 30 seconds default
   *  *Discovery query*: 10 seconds default

8.9.  Outlier Detection

   Discovery indices SHOULD flag agents with: - Trust score < 0.3 -
   Capability embeddings >3 standard deviations from cluster mean
   (potential false advertising) - Success rate < 50% over last 100
   intents

8.10.  Discovery Scalability

   *Phase 0.1 Architecture*: Centralized discovery index using
   PostgreSQL with pgvector extension for semantic search.

   *Vector Indexing*: Discovery indices SHOULD use Approximate Nearest
   Neighbor (ANN) indexing for efficient semantic search at scale.






Nagulapalli                Expires 28 May 2026                 [Page 13]

Internet-Draft                AINP Protocol                November 2025


   *Recommended Algorithm*: HNSW (Hierarchical Navigable Small World) -
   *Structure*: Multi-layer graph with hierarchical routing -
   *Parameters*: m = 16, ef_construction = 64, ef_search = 40 -
   *Distance Metric*: Cosine similarity - *Performance*: ~10ms search
   latency for 1M agents, ~99% recall

   *Scaling Strategies*: 1. *Vertical Scaling*: Increase HNSW
   parameters, use NVMe SSDs, scale PostgreSQL memory 2. *Horizontal
   Scaling*: Read replicas, connection pooling (PgBouncer), Redis
   caching 3. *Partitioning*: Capability sharding, tag-based routing,
   geographic partitioning 4. *Query Optimization*: Pre-filtering, batch
   queries, approximate search

   *Performance Benchmarks* (Phase 0.1 targets):

   +=============+============+============+===============+===========+
   | Agent Count | Index Size | Build      | Query Latency | Recall@10 |
   |             |            | Time       | (p95)         |           |
   +=============+============+============+===============+===========+
   | 1K          | 2 MB       | 5s         | 2ms           | 99.5%     |
   +-------------+------------+------------+---------------+-----------+
   | 10K         | 20 MB      | 45s        | 5ms           | 99.2%     |
   +-------------+------------+------------+---------------+-----------+
   | 100K        | 200 MB     | 8 min      | 12ms          | 98.8%     |
   +-------------+------------+------------+---------------+-----------+
   | 1M          | 2 GB       | 90         | 25ms          | 98.0%     |
   |             |            | min        |               |           |
   +-------------+------------+------------+---------------+-----------+

                                  Table 1

8.11.  Lite Mode for Resource-Constrained Agents

   For lightweight agents (e.g., IoT devices, mobile, embedded systems),
   implementations MAY use a minimal envelope to reduce payload size and
   processing overhead.

   *Required Fields*: version, msg_type, id, timestamp, from_did,
   to_did, sig

   *Optional Fields* (MAY be omitted): - ttl (default: 60000ms) -
   trace_id (no distributed tracing) - to_query (explicit addressing
   only) - capabilities_ref (no VC attestations) - attestations (trust
   by DID only) - qos (default: all 0.5, bid 0)







Nagulapalli                Expires 28 May 2026                 [Page 14]

Internet-Draft                AINP Protocol                November 2025


   *Lite Mode Constraints*: - Lite mode SHOULD NOT be used for high-
   stakes intents - Agents using lite mode MUST still provide valid
   Ed25519 signatures - Discovery indices MAY reject lite mode
   advertisements - Brokers MAY apply lower trust scores to lite mode
   agents by default

9.  CBOR Encoding (Optional)

   For efficiency, implementations MAY use CBOR ([RFC8949]) encoding:

   *Key Map (v0.1)*: - 1: version - 2: msg_type - 3: id - 4: timestamp -
   5: ttl - 6: trace_id - 7: from_did - 8: to_did - 9: to_query - 10:
   schema - 11: qos - 12: capabilities_ref - 13: attestations - 14:
   payload - 15: sig

   CBOR encoding SHOULD be negotiated during ADVERTISE or DISCOVER
   phase.

10.  Extensibility

10.1.  Custom Intent Types

   Agents MAY define custom intent types beyond the core set.  Custom
   intents MUST: - Include @context with unique URI - Include version
   field - Include embedding field - Include budget constraints -
   Register schema URI in public registry (future)

10.2.  Custom Negotiation Terms

   Proposal.terms field allows extensible negotiation parameters.
   Common extensions: - privacy_guarantees: ZK proof requirements -
   sla_guarantees: Service level agreements - data_retention: Data
   retention policies

10.3.  Versioning

   AINP uses semantic versioning.  Breaking changes MUST increment major
   version.  Phase 0.1 is backwards-compatible within 0.x series.

10.4.  Lite Profile (Trusted Networks)

   In trusted or closed-network deployments, the following
   simplifications are PERMITTED: - Omit capabilities_ref and
   attestations if peers are pre-authorized - Prefer JSON-LD for small
   payloads; negotiate CBOR for payloads > 4KB - Allow to_query-only
   routing within a single administrative domain





Nagulapalli                Expires 28 May 2026                 [Page 15]

Internet-Draft                AINP Protocol                November 2025


   Nodes MUST still sign messages, enforce TTLs, and implement replay
   protection.

11.  Success Metrics

11.1.  Route Success Rate

   route_success_rate = (intents_delivered_correctly /
   total_intents_sent) × 100%

   *Target (Phase 0.1)*: >=95%

11.2.  Latency (p95)

   95th percentile time from INTENT sent to RESULT received.

   *Target (Phase 0.1)*: <=2000ms

11.3.  Negotiation Completion Rate

   negotiation_completion_rate = (negotiations_accepted /
   total_negotiations) * 100

   *Target (Phase 0.1)*: >=80%

11.4.  False Route Rate

   false_route_rate = (intents_misrouted / total_intents_sent) * 100

   *Target (Phase 0.1)*: <=5%

11.5.  Abuse Resilience

   Detection rate of: - DoS attacks (>1000 requests/min from single
   agent) - Sybil attacks (multiple DIDs from same source) - False
   capability advertising (capability mismatch >0.5 cosine distance)

   *Target (Phase 0.1)*: >=90% detection rate

12.  IANA Considerations

   This document has no IANA actions.

13.  References

13.1.  Normative References





Nagulapalli                Expires 28 May 2026                 [Page 16]

Internet-Draft                AINP Protocol                November 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/rfc/rfc2119>.

   [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/rfc/rfc8949>.

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

   [W3C.VC]   W3C, "Verifiable Credentials Data Model v1.1", 3 March
              2022, <https://www.w3.org/TR/vc-data-model/>.

13.2.  Informative References

   [Ed25519]  Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B.
              Yang, "High-speed high-security signatures", 26 September
              2011, <https://ed25519.cr.yp.to/>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

Author's Address

   Eswara Prasad Nagulapalli
   Servesys Labs
   Email: contact@servsys.com



















Nagulapalli                Expires 28 May 2026                 [Page 17]


name: draft-gaikwad-south-authorization
rev: 00
title: SOUTH: Stochastic Authorization for Agent and Service Requests
time: 2025-11-28T10:20:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-01T10:20:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864826+00:00
abstract:
SOUTH defines an authorization protocol for evaluating requests
   issued by users, services, or autonomous agents.  SOUTH allows a
   server to return a deterministic decision or an allow decision that
   is issued with a probability determined by local policy.  This
   enables servers to incorporate uncertainty, contextual information,
   and load conditions into authorization decisions.

   SOUTH is transport independent and can be composed with existing
   authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
   or DPoP.  This document describes the request and response objects,
   decision semantics, and an HTTP binding for interoperable deployment.

full_text:
Network Working Group                                         M. Gaikwad
Internet-Draft                                    Independent Researcher
Intended status: Experimental                           28 November 2025
Expires: 1 June 2026


     SOUTH: Stochastic Authorization for Agent and Service Requests
                  draft-gaikwad-south-authorization-00

Abstract

   SOUTH defines an authorization protocol for evaluating requests
   issued by users, services, or autonomous agents.  SOUTH allows a
   server to return a deterministic decision or an allow decision that
   is issued with a probability determined by local policy.  This
   enables servers to incorporate uncertainty, contextual information,
   and load conditions into authorization decisions.

   SOUTH is transport independent and can be composed with existing
   authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
   or DPoP.  This document describes the request and response objects,
   decision semantics, and an HTTP binding for interoperable deployment.

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

Copyright Notice

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







Gaikwad                    Expires 1 June 2026                  [Page 1]

Internet-Draft                    SOUTH                    November 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Design Goals and Non-Goals  . . . . . . . . . . . . . . . . .   6
     4.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Interaction Model . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Deployment Patterns . . . . . . . . . . . . . . . . . . .   9
   6.  Decision Semantics  . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.2.  Deterministic Allow and Deny  . . . . . . . . . . . . . .  11
     6.3.  Stochastic Allow  . . . . . . . . . . . . . . . . . . . .  11
     6.4.  Retry and Defer . . . . . . . . . . . . . . . . . . . . .  12
     6.5.  Error Semantics . . . . . . . . . . . . . . . . . . . . .  12
     6.6.  Idempotence and Side Effects  . . . . . . . . . . . . . .  13
   7.  Request Object  . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Fields  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Subject . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Action  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Object  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.5.  Context and Signals . . . . . . . . . . . . . . . . . . .  15
     7.6.  Complete Request Example  . . . . . . . . . . . . . . . .  16
   8.  Response Object . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Fields  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  Allow Responses . . . . . . . . . . . . . . . . . . . . .  19
     8.3.  Deny Responses  . . . . . . . . . . . . . . . . . . . . .  19
     8.4.  Retry and Defer Responses . . . . . . . . . . . . . . . .  20
     8.5.  Error Responses . . . . . . . . . . . . . . . . . . . . .  20
     8.6.  Correlation and Logging . . . . . . . . . . . . . . . . .  21
   9.  Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . .  21
     9.1.  Transport Independent Model . . . . . . . . . . . . . . .  21
     9.2.  HTTP Binding  . . . . . . . . . . . . . . . . . . . . . .  22
     9.3.  HTTP Status Codes . . . . . . . . . . . . . . . . . . . .  23
     9.4.  Timeouts and Retries  . . . . . . . . . . . . . . . . . .  23
     9.5.  Idempotence and Caching . . . . . . . . . . . . . . . . .  24
   10. Operational Modes . . . . . . . . . . . . . . . . . . . . . .  24
     10.1.  Agent and Tool Authorization . . . . . . . . . . . . . .  24
     10.2.  Service to Service and Mesh Gateways . . . . . . . . . .  25



Gaikwad                    Expires 1 June 2026                  [Page 2]

Internet-Draft                    SOUTH                    November 2025


     10.3.  Mail Transfer Agents . . . . . . . . . . . . . . . . . .  25
     10.4.  SDN Controllers and NFV Service Chaining . . . . . . . .  26
     10.5.  Kubernetes Admission and Scheduling  . . . . . . . . . .  26
     10.6.  Library and Local Mode . . . . . . . . . . . . . . . . .  27
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  27
     11.1.  Authentication and Integrity . . . . . . . . . . . . . .  27
     11.2.  Fail Open and Fail Closed Behavior . . . . . . . . . . .  28
     11.3.  Stochastic Decisions and Probing . . . . . . . . . . . .  28
     11.4.  Logging and Policy Leakage . . . . . . . . . . . . . . .  29
     11.5.  Dependency and Bypass Risks  . . . . . . . . . . . . . .  29
     11.6.  Denial of Service  . . . . . . . . . . . . . . . . . . .  30
     11.7.  Caching and Replay . . . . . . . . . . . . . . . . . . .  30
     11.8.  Agent Specific Considerations  . . . . . . . . . . . . .  31
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  31
     12.1.  Data Types in SOUTH Messages . . . . . . . . . . . . . .  31
     12.2.  Data Minimization  . . . . . . . . . . . . . . . . . . .  32
     12.3.  Retention and Access Control for Logs  . . . . . . . . .  32
     12.4.  Agent Context and Prompt Data  . . . . . . . . . . . . .  33
     12.5.  Metadata and Inference Risks . . . . . . . . . . . . . .  33
     12.6.  Cross Border Transfers and Third Parties . . . . . . . .  33
     12.7.  User Rights and Transparency . . . . . . . . . . . . . .  34
     12.8.  Extensions and Profiles  . . . . . . . . . . . . . . . .  34
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
     13.1.  application/south+json Media Type  . . . . . . . . . . .  35
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  36
   15. Informative References  . . . . . . . . . . . . . . . . . . .  36
   Appendix A.  Example Flows  . . . . . . . . . . . . . . . . . . .  37
     A.1.  Agent Tool Invocation . . . . . . . . . . . . . . . . . .  37
     A.2.  Service Mesh Gateway  . . . . . . . . . . . . . . . . . .  39
     A.3.  Mail Transfer Agent . . . . . . . . . . . . . . . . . . .  40
   Appendix B.  Signing Profiles . . . . . . . . . . . . . . . . . .  41
     B.1.  Mutual TLS Profile  . . . . . . . . . . . . . . . . . . .  41
     B.2.  OAuth 2.0 and DPoP Profile  . . . . . . . . . . . . . . .  41
     B.3.  Signed Request Bodies . . . . . . . . . . . . . . . . . .  42
     B.4.  Agent and User Binding  . . . . . . . . . . . . . . . . .  42
   Appendix C.  Rate and Load Aware Policies . . . . . . . . . . . .  42
     C.1.  Rate and Load Signals . . . . . . . . . . . . . . . . . .  43
     C.2.  Decisions for Throttling and Shedding . . . . . . . . . .  43
     C.3.  Agent Specific Rate Policies  . . . . . . . . . . . . . .  43
     C.4.  Fairness and Multi Tenant Settings  . . . . . . . . . . .  44
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  44










Gaikwad                    Expires 1 June 2026                  [Page 3]

Internet-Draft                    SOUTH                    November 2025


1.  Introduction

   Systems that act on behalf of users or other services must decide
   whether a requested operation is permitted.  Traditional
   authorization mechanisms rely on deterministic evaluation of
   attributes, roles, or policy rules.  These mechanisms are effective
   in constrained environments, but they do not represent uncertainty,
   context variation, or adaptive behavior that arise in modern agent
   driven systems.

   SOUTH defines a small authorization protocol that allows a server to
   return either a deterministic decision or a probabilistic allow
   decision.  A server evaluates a structured request, computes a
   preference score, and maps this score to a decision.  SOUTH also
   supports retry and defer outcomes that allow a server to signal
   transient conditions, such as load or missing context.  SOUTH does
   not replace authentication or identity.  Instead, it complements
   existing identity systems by defining a consistent authorization
   interface.

   The name SOUTH is derived from "Stochastic Auth."  It reflects the
   protocol's ability to express authorization decisions that may
   include probabilistic behavior, allowing servers to map preference
   scores or contextual signals to non-deterministic outcomes when
   required by policy.

   The protocol is transport independent.  It can be used with HTTP,
   message queues, or local control interfaces.  It can also be paired
   with authentication and integrity mechanisms such as OAuth based
   flows, OpenID Connect, mutual TLS, or DPoP proof of possession.
   SOUTH does not define how preference scores are computed.  It defines
   the request and response structures and the semantics of decisions
   returned by a server.

   SOUTH can be used by user agents, machine learning agents, service
   meshes, schedulers, MTAs, SDN controllers, and similar components
   that require an explicit authorization decision for a proposed
   action.  This document describes terminology, message formats,
   decision semantics, transport bindings, and operational
   considerations for interoperable use.

2.  Terminology

   The terms defined in this section are used throughout this document.
   These definitions are specific to the SOUTH protocol.






Gaikwad                    Expires 1 June 2026                  [Page 4]

Internet-Draft                    SOUTH                    November 2025


   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] and [RFC8174] when, and only when, they appear in all
   capitals.

   Client  The entity that sends a SOUTH request.  A client may be a
      user agent, an automated agent, a service, a scheduler, or any
      component that requires an authorization decision for a proposed
      operation.

   Server  The entity that evaluates a SOUTH request and returns a
      decision.  A server applies local policy to determine whether a
      request should be allowed, denied, retried, or deferred.

   Request  A structured object that describes the operation the client
      wishes to perform.  A request includes an action, a target, and
      optional context that assists the server in making a decision.

   Decision  The outcome returned by a SOUTH server.  Decisions include
      allow, deny, retry, defer, and error.  SOUTH does not assign
      meaning to application level outcomes beyond these states.

   Preference Score  A numerical value in the interval [0, 1] that
      reflects how compatible a request is with server policy.  SOUTH
      does not specify how the score is computed.  The server maps the
      score to a decision.

   Stochastic Allow  A mode where the server returns an allow decision
      with a probability derived from the preference score.  The exact
      mapping is defined by server policy.

   Context Attachment  Additional information supplied by the client or
      collected by the server that provides signals relevant to the
      decision.  Examples include rate information, environmental data,
      recent behavior, or device posture.  Context attachment formats
      are implementation dependent.

   Integrity Binding  A method used to ensure that the request has not
      been modified and that the sender can prove possession of a key.
      SOUTH is transport independent and can be paired with mechanisms
      such as mutual TLS or DPoP.









Gaikwad                    Expires 1 June 2026                  [Page 5]

Internet-Draft                    SOUTH                    November 2025


3.  Motivation

   Authorization mechanisms used in current systems are largely
   deterministic.  A request is evaluated against a set of rules or
   attributes, and the server returns an allow or deny outcome.  These
   mechanisms work well when policies are simple and when the
   environment is stable.  Many modern deployments no longer meet these
   conditions.

   Agent driven systems, service meshes, serverless frameworks, and
   automated workflows issue requests whose safety depends on transient
   information such as current load, recent behavior, signal quality, or
   incomplete state.  A deterministic policy cannot represent these
   conditions without either becoming overly restrictive or overly
   permissive.  Systems often fall back on large sets of static rules
   that do not scale and are difficult to maintain.

   SOUTH introduces a small protocol that allows a server to encode
   preference and uncertainty directly.  A server evaluates a structured
   request, computes a score, and maps this score to a decision.  The
   server may return a deterministic allow or deny decision or may
   choose a probabilistic allow when the score falls in an uncertain
   range.  SOUTH also supports explicit retry and defer outcomes so that
   clients can distinguish between a stable deny and a temporary
   condition.

   This approach provides two benefits.  First, it allows a server to
   represent policies that depend on contextual or uncertain information
   without expanding the policy surface.  Second, it gives clients clear
   signals about whether a denial is final or whether a request may
   succeed after obtaining more context or waiting for transient
   conditions to change.

   SOUTH is intended for systems that require lightweight authorization
   decisions between components that operate at high frequency or under
   shifting operational context.  This aligns with zero trust principles
   [NIST-ZT].  It can be used by user agents, machine learning agents,
   schedulers, MTAs, SDN controllers, and other components that need
   explicit authorization semantics for proposed operations.

4.  Design Goals and Non-Goals

   This section states the main design goals for SOUTH and clarifies
   which problems are outside the scope of this document.







Gaikwad                    Expires 1 June 2026                  [Page 6]

Internet-Draft                    SOUTH                    November 2025


4.1.  Design Goals

   SOUTH is designed with the following goals.


   *  *Simple decision interface.* SOUTH provides a small set of
      decision outcomes such as allow, deny, retry, and defer.  The
      protocol does not try to encode full policy logic on the wire.
      Policy remains on the server.

   *  *Stochastic authorization.* SOUTH allows a server to map internal
      preference scores to probabilistic allow decisions.  This supports
      policies that depend on uncertain signals or that aim to reduce
      predictability for probing clients.

   *  *Transport independence.* SOUTH defines request and response
      objects that are not tied to one specific transport.  An HTTP
      binding is described in this document, but other bindings can be
      defined by deployment specific profiles.

   *  *Compatibility with existing identity.* SOUTH is intended to work
      alongside existing authentication and identity systems, such as
      OAuth based flows, OpenID Connect, mutual TLS, and DPoP.  It does
      not define its own identity model.

   *  *Low integration cost.* SOUTH can be called by existing components
      as an external decision service.  A client can construct a request
      object, send it to a SOUTH server, and apply the returned decision
      without changes to its internal policy representation.

   *  *Clear denial semantics.* SOUTH distinguishes between a stable
      deny, a temporary condition, and a request that should be retried
      or stepped up.  This allows clients to react appropriately to
      authorization outcomes.

4.2.  Non-Goals

   SOUTH does not attempt to solve the following problems.


   *  *Authentication and identity.* SOUTH does not define how clients
      or servers authenticate.  It assumes that deployments use existing
      mechanisms such as mutual TLS, OAuth, OpenID Connect, or similar
      protocols.







Gaikwad                    Expires 1 June 2026                  [Page 7]

Internet-Draft                    SOUTH                    November 2025


   *  *Policy language definition.* SOUTH does not define a policy
      language or a rule syntax.  It defines only the interface for
      exchanging decisions.  Policy representation and evaluation are
      local choices.

   *  *Data plane enforcement.* SOUTH does not specify how decisions are
      enforced in data planes, such as packet forwarding hardware or
      message brokers.  Enforcement mechanisms are outside the scope of
      this document.

   *  *Global consistency.* SOUTH does not attempt to provide globally
      consistent authorization views across multiple servers.  Any
      replication or coordination of policy state is the responsibility
      of the deployment.

   *  *End to end security proofs.* SOUTH is a building block.  It does
      not provide a complete security framework for all authorization
      use cases and does not claim end to end security guarantees by
      itself.

5.  Architecture

   SOUTH is designed as a decision service that can be called by
   different types of clients.  The protocol defines a logical client
   role, a server role, and supporting components such as policy stores
   and identity providers.  SOUTH does not constrain how these roles are
   deployed or how they are mapped to physical systems.

5.1.  Roles

   The SOUTH architecture includes the following logical roles.


   Client  The client constructs a SOUTH request, sends it to a server,
      and applies the returned decision.  Clients may be user agents,
      automated agents, application services, schedulers, mail transfer
      agents, or network controllers.

   Server  The server receives SOUTH requests, evaluates them against
      local policy and context, and returns decisions.  A server may be
      implemented as a standalone service, as a component within a
      larger system, or as a library linked into an application.

   Policy Store  A policy store holds configuration and rules that the
      server uses to evaluate requests.  The format and location of the
      policy store are not specified by SOUTH.  A policy store may be a
      configuration file, a database, or an external policy engine.




Gaikwad                    Expires 1 June 2026                  [Page 8]

Internet-Draft                    SOUTH                    November 2025


   Identity Provider  An identity provider issues credentials or tokens
      that clients use to authenticate to the server.  SOUTH does not
      define identity provider behavior but assumes that servers can
      validate client identities using existing mechanisms.

5.2.  Interaction Model

   The basic interaction pattern in SOUTH consists of a single request
   followed by a single response.


   1.  The client constructs a request object that describes the
       proposed operation.  The request includes information about the
       acting subject, the action to be performed, the target object,
       and optional context.

   2.  The client sends the request to the server using a chosen
       transport.  An HTTP binding using JSON is described in this
       document.  Other bindings may be defined in separate documents.

   3.  The server evaluates the request according to local policy.  The
       server may consult its policy store, fetch additional context, or
       apply internal scoring models.

   4.  The server returns a response that contains a decision and
       optional metadata.  The decision indicates whether the operation
       is allowed, denied, should be retried, or should be deferred.
       The response may include a probability or score for diagnostic or
       logging purposes.

   5.  The client applies the decision.  For example, a client may
       proceed with the operation, block it, queue it for later retry,
       or prompt for additional verification, depending on local
       behavior.

   SOUTH does not specify how many requests a client may send or how
   servers handle concurrent requests.  These aspects are deployment
   choices.  Implementations are expected to apply standard practices
   for rate limiting, timeouts, and failure handling.

5.3.  Deployment Patterns

   SOUTH can be deployed in several patterns.  This document does not
   mandate any specific topology, but the following patterns are
   expected to be common.






Gaikwad                    Expires 1 June 2026                  [Page 9]

Internet-Draft                    SOUTH                    November 2025


   *  *Central decision service.* A dedicated SOUTH server receives
      requests from many clients and applies shared policy.  This is
      suitable for environments that want a single authorization view
      across multiple systems.

   *  *Sidecar or local proxy.* A SOUTH server runs next to an
      application component and serves only that component.  This avoids
      network hops but keeps policy evaluation separate from application
      logic.

   *  *Library integration.* SOUTH evaluation is implemented as a
      library linked into a client or gateway.  The wire protocol may
      still be used for audit, testing, or cross language integration,
      but is not required for every decision.

   *  *Controller integration.* A control plane component, such as a
      service mesh controller, scheduler, or SDN controller, calls SOUTH
      during its own decision flow.  The controller then programs local
      enforcement points based on the SOUTH decision.

   In all patterns, SOUTH is intended to run in the control plane or
   management plane.  Enforcement in data planes, such as packet
   forwarding paths or storage engines, is outside the scope of the
   protocol.  Implementations are expected to map SOUTH decisions to
   local enforcement mechanisms.

6.  Decision Semantics

   SOUTH defines a small set of decision outcomes that a server can
   return to a client.  These outcomes are intended to be stable across
   deployments so that clients can react consistently, even when policy
   and scoring logic differ between servers.

6.1.  Overview

   A SOUTH server evaluates a request and returns exactly one primary
   decision.  The decision describes how the client should treat the
   requested operation.  The server may include additional metadata,
   such as a numerical score or a probability value, but the primary
   decision is authoritative.

   This document groups decisions into four categories:


   *  Allow decisions, where the server authorizes the request.

   *  Deny decisions, where the server does not authorize the request.




Gaikwad                    Expires 1 June 2026                 [Page 10]

Internet-Draft                    SOUTH                    November 2025


   *  Retry and defer decisions, where the server indicates that the
      request might succeed later.

   *  Error outcomes, where the server cannot evaluate the request.

6.2.  Deterministic Allow and Deny

   In the deterministic mode, the server returns an explicit allow or
   deny decision.  Clients that do not use stochastic behavior can treat
   SOUTH as a standard binary authorization protocol.


   allow  The server authorizes the requested operation.  The client is
      expected to proceed, subject to any local enforcement or
      application constraints.  An allow decision indicates that the
      server does not require additional checks for this request.

   deny  The server does not authorize the requested operation.  The
      client must not perform the operation.  A deny decision indicates
      that the server regards the request as incompatible with current
      policy and that the decision is stable with respect to the
      information available.

   A server that does not implement stochastic behavior or retry
   semantics can restrict itself to allow and deny decisions.

6.3.  Stochastic Allow

   SOUTH supports a stochastic mode where the server produces an allow
   decision based on a probability derived from its internal preference
   score.  In this mode, the server evaluates the request, computes a
   score in the interval [0, 1], and maps this score to a probability of
   authorization.

   The exact mapping from score to probability is a matter of local
   policy.  A simple example is a threshold rule where scores above a
   high threshold always allow, scores below a low threshold always
   deny, and scores in between allow with a probability that increases
   with the score.

   When a server uses stochastic behavior, the primary decision seen by
   the client is still allow or deny.  SOUTH does not define a separate
   decision token for stochastic allow.  Instead, the server may include
   an optional field that reports the probability or score that was used
   to produce the decision.






Gaikwad                    Expires 1 June 2026                 [Page 11]

Internet-Draft                    SOUTH                    November 2025


   From the client perspective, a stochastic allow is processed in the
   same way as a deterministic allow.  The distinction is a server side
   choice that affects how often allow decisions are produced near the
   decision boundary.

6.4.  Retry and Defer

   Some authorization outcomes are temporary.  A server may be
   overloaded, may be missing required context, or may need the client
   to perform an additional step before a decision can be made.  SOUTH
   models these situations through retry and defer outcomes.


   retry  The server cannot authorize the request at this time, but the
      client may retry after a delay.  The response may include a hint
      such as a suggested retry interval.  Clients must treat retry as a
      deny for the current attempt.

   defer  The server requests that the client defer the operation and
      possibly perform an additional step, such as step up verification
      or context collection.  The exact meaning of defer is deployment
      specific.  Clients must not perform the requested operation until
      a later allow decision is obtained.

   Retry and defer decisions allow clients to distinguish between a
   stable policy deny and a temporary condition.  This distinction is
   important in systems where repeated failures may signal
   misconfiguration, attack, or changes in policy.

6.5.  Error Semantics

   A server may be unable to evaluate a request.  Causes include
   malformed input, lack of required authentication, internal faults, or
   backend unavailability.  In such cases, SOUTH distinguishes between
   an authorization decision and a protocol or processing error.

   When a server returns an error, the response indicates that no
   authorization decision has been made.  The client must apply its own
   failure policy.  For example, a client may choose to fail closed and
   block the operation, or fail open in development environments where
   availability is more important.

   Implementations should distinguish clearly between deny and error.  A
   deny decision is a valid authorization outcome.  An error indicates
   that the server did not complete the evaluation.






Gaikwad                    Expires 1 June 2026                 [Page 12]

Internet-Draft                    SOUTH                    November 2025


6.6.  Idempotence and Side Effects

   SOUTH evaluates authorization decisions only.  It does not perform
   the requested operation and does not define any side effects beyond
   logging and internal accounting.  Two identical requests sent to the
   same server under the same conditions may produce the same decision
   or, in stochastic mode, may produce different outcomes with known
   probabilities.

   Clients should treat SOUTH calls as idempotent with respect to system
   state.  Any non idempotent behavior, such as consuming one time
   credentials, is a property of the surrounding system, not of SOUTH
   itself.

7.  Request Object

   A SOUTH request is a structured object that describes the operation
   the client wishes to perform.  The request object is transport
   independent.  This document uses JSON examples for clarity, but other
   encodings are possible.

7.1.  Fields

   A request object contains the fields listed below.  Fields marked as
   required MUST be present.  Fields marked as optional MAY be omitted.


   request_id (optional)  An opaque identifier chosen by the client.
      When present, the server SHOULD copy this value into the response.
      The identifier helps clients correlate responses with requests.

   subject (required)  An object that describes the actor on whose
      behalf the request is made.  The subject object MUST contain at
      least an id field and MAY contain a type field and an attributes
      object.

   action (required)  An object that describes the operation the client
      wishes to perform.  The action object MUST contain a type field
      and MAY contain additional fields such as name and parameters.

   object (required)  An object that describes the target of the
      operation.  The object MUST contain at least an id or type field
      and MAY contain an attributes object.

   context (optional)  An object that carries additional information
      about the environment, such as network location, device posture,
      rates, or time.  The structure of the context object is deployment
      specific.



Gaikwad                    Expires 1 June 2026                 [Page 13]

Internet-Draft                    SOUTH                    November 2025


   signals (optional)  An object that holds pre computed scores or hints
      from other modules, such as anomaly detectors or rate limiters.
      SOUTH does not define specific signal names.

   extensions (optional)  An object reserved for deployment specific
      fields that are not covered by the core model.  Extensions MUST
      NOT change the meaning of the core fields.

7.2.  Subject

   The subject object describes who or what is acting.  A minimal
   subject object contains only an identifier.  Richer deployments may
   include type and attributes.  The following JSON examples are
   illustrative.

   {
     "subject": {
       "id": "user-1234"
     }
   }

                       Figure 1: Basic subject object

   {
     "subject": {
       "id": "service-api-gateway",
       "type": "service",
       "attributes": {
         "tenant": "tenant-42",
         "roles": ["gateway", "frontend"],
         "auth_method": "mtls"
       }
     }
   }

                     Figure 2: Extended subject object

7.3.  Action

   The action object describes the requested operation.  The type field
   identifies the general category.  The name and parameters fields
   allow further refinement.









Gaikwad                    Expires 1 June 2026                 [Page 14]

Internet-Draft                    SOUTH                    November 2025


   {
     "action": {
       "type": "tool.invoke",
       "name": "database_query",
       "parameters": {
         "query": "SELECT * FROM customers WHERE id = ?"
       }
     }
   }

                      Figure 3: Example action objects

   Deployment profiles SHOULD define allowed action types and their
   expected parameters.  SOUTH itself does not interpret action
   semantics.

7.4.  Object

   The object describes the target resource.  The identification scheme
   is deployment specific.  The object MAY be a logical resource such as
   a table, an API endpoint, a queue, a file, a node, or a service.

   {
     "object": {
       "id": "customers-table",
       "type": "database.table",
       "attributes": {
         "sensitivity": "high",
         "owner": "finance-team"
       }
     }
   }

                      Figure 4: Example object objects

7.5.  Context and Signals

   The context and signals fields allow a client to supply additional
   information that may be relevant for policy evaluation.  The
   structure of these fields is not fixed by SOUTH.  Deployments may
   define profiles that describe common attributes.










Gaikwad                    Expires 1 June 2026                 [Page 15]

Internet-Draft                    SOUTH                    November 2025


   {
     "context": {
       "ip": "198.51.100.23",
       "location": "region-1",
       "time": "2025-11-27T10:34:12Z",
       "user_agent": "example-client/1.0"
     },
     "signals": {
       "anomaly_score": 0.41,
       "recent_failures": 2
     }
   }

                   Figure 5: Example context and signals

   Servers MAY ignore unknown context or signal fields.  Clients SHOULD
   NOT rely on any specific field being honored unless the deployment
   defines a shared profile.

7.6.  Complete Request Example

   The following example shows a complete SOUTH request object in JSON
   form.  Line breaks and spacing are for readability.




























Gaikwad                    Expires 1 June 2026                 [Page 16]

Internet-Draft                    SOUTH                    November 2025


   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "subject": {
       "id": "user-1234",
       "type": "user",
       "attributes": {
         "tenant": "tenant-42",
         "roles": ["reader"]
       }
     },
     "action": {
       "type": "tool.invoke",
       "name": "database_query",
       "parameters": {
         "query": "SELECT * FROM customers WHERE id = ?"
       }
     },
     "object": {
       "id": "customers-table",
       "type": "database.table",
       "attributes": {
         "sensitivity": "high"
       }
     },
     "context": {
       "ip": "198.51.100.23",
       "location": "region-1",
       "time": "2025-11-27T10:34:12Z"
     },
     "signals": {
       "anomaly_score": 0.41
     },
     "extensions": {
       "trace_id": "abc123"
     }
   }

                  Figure 6: Complete SOUTH request example

8.  Response Object

   A SOUTH response is a structured object that carries the server
   decision and optional metadata.  The response object is transport
   independent.  This document uses JSON examples for clarity, but other
   encodings are possible.






Gaikwad                    Expires 1 June 2026                 [Page 17]

Internet-Draft                    SOUTH                    November 2025


8.1.  Fields

   A response object contains the fields listed below.  Fields marked as
   required MUST be present.  Fields marked as optional MAY be omitted.


   request_id (optional)  An opaque identifier copied from the request.
      When present, this value MUST match the request_id in the
      corresponding request.  It allows the client to correlate
      responses with requests.

   decision (required)  A string that indicates the primary outcome of
      the evaluation.  Valid values are "allow", "deny", "retry",
      "defer", and "error".

   score (optional)  A numerical value in the interval [0, 1] that
      represents the internal preference score used by the server.  This
      field is intended for diagnostics and logging.  Clients MUST NOT
      rely on a specific interpretation of this value unless agreed in a
      deployment profile.

   probability (optional)  A numerical value in the interval [0, 1] that
      represents the probability used when the server applies stochastic
      behavior to produce an allow decision.  This field MAY be present
      even when the decision is deny, to indicate the probability
      threshold that was not met.

   reason (optional)  A short, human readable string that describes the
      decision at a coarse level, such as "policy", "rate_limit", or
      "missing_context".  The reason is not intended to expose internal
      policy details.

   details (optional)  An object that carries structured diagnostic
      information.  The format of the details object is deployment
      specific.

   retry_after (optional)  A hint that indicates when the client MAY
      retry the request.  This field is meaningful when the decision is
      "retry" or "defer".  The value MAY be a number of seconds or a
      timestamp string, depending on the deployment profile.

   error_code (optional)  A machine readable string that indicates the
      type of error when the decision is "error".  Example values
      include "invalid_request", "unauthenticated", and "server_error".

   extensions (optional)  An object reserved for deployment specific
      fields that are not covered by the core model.  Extensions MUST
      NOT change the meaning of the decision field.



Gaikwad                    Expires 1 June 2026                 [Page 18]

Internet-Draft                    SOUTH                    November 2025


8.2.  Allow Responses

   When the server authorizes the operation, it returns a response with
   decision set to "allow".  The server MAY include score and
   probability fields to expose internal evaluation metrics.

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "allow",
     "reason": "policy",
     "score": 0.98
   }

                   Figure 7: Deterministic allow response

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "allow",
     "reason": "boundary_region",
     "score": 0.62,
     "probability": 0.55
   }

                    Figure 8: Stochastic allow response

   From the client perspective, a stochastic allow is treated in the
   same way as a deterministic allow.  The probability field is optional
   metadata that may be logged or used for audit.

8.3.  Deny Responses

   When the server does not authorize the operation, and the decision is
   considered stable with respect to current policy and context, it
   returns decision "deny".

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "deny",
     "reason": "policy",
     "score": 0.12
   }

                          Figure 9: Deny response

   Clients MUST NOT perform the requested operation after a deny
   decision.  The server MAY still include score and probability fields
   for diagnostic purposes, but these values do not change the meaning
   of the deny outcome.



Gaikwad                    Expires 1 June 2026                 [Page 19]

Internet-Draft                    SOUTH                    November 2025


8.4.  Retry and Defer Responses

   When the server cannot authorize the request at this time, but the
   outcome may change later, it can return a decision of "retry" or
   "defer".

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "retry",
     "reason": "load",
     "retry_after": 30
   }

                    Figure 10: Retry response with hint

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "defer",
     "reason": "missing_context",
     "details": {
       "required_factor": "stronger_auth"
     }
   }

                Figure 11: Defer response with step up hint

   Clients MUST treat retry and defer as not authorized for the current
   attempt.  The client MAY retry later or perform the indicated step,
   depending on local logic and deployment guidance.

8.5.  Error Responses

   When the server cannot process the request, it returns a decision of
   "error".  In this case no authorization decision has been made.  The
   client MUST apply its own failure handling policy.

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "error",
     "error_code": "invalid_request",
     "reason": "malformed_subject"
   }

                         Figure 12: Error response







Gaikwad                    Expires 1 June 2026                 [Page 20]

Internet-Draft                    SOUTH                    November 2025


   Deployments SHOULD document how clients are expected to behave on
   error responses.  For example, some environments may require fail
   closed behavior, while others may accept fail open in development or
   testing stages.

8.6.  Correlation and Logging

   Implementations SHOULD log request and response pairs for audit,
   debugging, and incident analysis.  The request_id field enables
   simple correlation.  Deployments may also use external correlation
   identifiers conveyed in the extensions field.

   SOUTH does not define log formats or retention policies.  Operators
   are responsible for applying local security and privacy requirements
   to any stored decision data.

9.  Wire Protocol

   SOUTH defines a logical exchange between a client and a server: the
   client sends a request object and receives a response object.  The
   protocol is transport independent.  This document specifies a
   concrete HTTP binding that uses JSON as the serialization format.

9.1.  Transport Independent Model

   In the abstract model, a client constructs a request object as
   described in Section 7, sends it to a server, and receives a response
   object as described in Section Section 8.  The binding between these
   objects and any underlying transport is left to deployment profiles.

   The following properties are expected of any SOUTH transport binding.


   *  The binding MUST preserve the request object and response object
      without modification, except for encoding.

   *  The binding MUST provide a way to carry authentication and
      integrity information for the client and server.

   *  The binding SHOULD support request correlation, for example by
      propagating the request_id.

   *  The binding SHOULD allow clients to distinguish between
      authorization decisions and transport or protocol errors.







Gaikwad                    Expires 1 June 2026                 [Page 21]

Internet-Draft                    SOUTH                    November 2025


9.2.  HTTP Binding

   This section specifies an HTTP binding for SOUTH following HTTP
   semantics [RFC9110].  Other bindings may be defined in separate
   documents.  The HTTP binding uses JSON encoding for request and
   response bodies.

   Clients send SOUTH requests as HTTP POST messages to a server
   controlled endpoint.  The choice of path is a deployment concern.  A
   common pattern is a path such as /south/decision.

   A typical HTTP request has the following form.

   POST /south/decision HTTP/1.1
   Host: auth.example.com
   Content-Type: application/json
   Accept: application/json
   Authorization: Bearer eyJhbGciOi...

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "subject": {
       "id": "user-1234",
       "type": "user"
     },
     "action": {
       "type": "tool.invoke",
       "name": "database_query"
     },
     "object": {
       "id": "customers-table",
       "type": "database.table"
     }
   }

                      Figure 13: Example HTTP request

   The server responds with a JSON encoded SOUTH response object.

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

   {
     "request_id": "550e8400-e29b-41d4-a716-446655440000",
     "decision": "allow",
     "reason": "policy",
     "score": 0.94
   }



Gaikwad                    Expires 1 June 2026                 [Page 22]

Internet-Draft                    SOUTH                    November 2025


                      Figure 14: Example HTTP response

   Clients and servers MAY use HTTP authentication mechanisms or carry
   credentials in headers, such as OAuth bearer tokens or DPoP proofs.
   SOUTH does not define any specific authentication scheme.

9.3.  HTTP Status Codes

   In the HTTP binding, the HTTP status code and the SOUTH decision
   field carry different information.  The HTTP status code reflects the
   result of transport and parsing.  The decision field reflects the
   authorization outcome.

   Servers using the HTTP binding SHOULD follow these guidelines.


   200 OK  The request was successfully processed and a SOUTH response
      object is present in the body.  The decision field indicates the
      authorization outcome, such as allow, deny, retry, defer, or
      error.

   400 Bad Request  The HTTP message could not be parsed or the body
      could not be decoded as a SOUTH request object.  In this case, the
      server MAY return an error response body, but clients cannot rely
      on its presence.

   401 Unauthorized / 403 Forbidden  The client failed authentication or
      is not permitted to call the SOUTH endpoint.  The server MAY omit
      a SOUTH response object in this case.

   500 Internal Server Error and 5xx  The server encountered an internal
      error.  A SOUTH response object MAY be returned, but clients MUST
      treat the condition as a transport or processing failure, not as
      an explicit authorization decision.

   When the server returns 200 OK, clients SHOULD expect a valid SOUTH
   response object and MUST interpret the decision field as
   authoritative.  When the server returns non 2xx status codes, clients
   MUST apply local failure handling policies.

9.4.  Timeouts and Retries

   Timeouts and connection failures are transport level events, not
   SOUTH decisions.  When a client does not receive a response within
   its configured timeout, the client MUST treat the attempt as if no
   decision was obtained.





Gaikwad                    Expires 1 June 2026                 [Page 23]

Internet-Draft                    SOUTH                    November 2025


   Clients MAY retry the SOUTH request, subject to local rate and
   backoff policies.  Retry behavior on transport failure is separate
   from retry behavior signaled by a SOUTH decision with value "retry".
   A server generated retry decision is explicit in the response body
   and may include a retry_after hint.

   Deployments SHOULD document how clients distinguish between these
   cases and how many retries are permitted before treating the failure
   as persistent.

9.5.  Idempotence and Caching

   SOUTH requests are intended to be idempotent with respect to server
   policy state.  Sending the same request multiple times SHOULD NOT by
   itself change the policy decision, although stochastic behavior may
   cause different outcomes near the decision boundary.

   Clients and intermediaries MAY cache SOUTH responses when allowed by
   deployment policy.  Caching policies are out of scope for this
   document.  Any caching mechanism MUST ensure that sensitive data in
   responses is handled according to local security and privacy
   requirements.

10.  Operational Modes

   SOUTH is intended as a small decision protocol that can be reused
   across different environments.  This section describes several
   operational modes.  These examples are illustrative and do not
   constrain implementations.

10.1.  Agent and Tool Authorization

   In agent based deployments, a language model or agent runtime
   orchestrates tool calls, API invocations, or system level actions on
   behalf of a user.  Before executing a tool call, the agent runtime
   can call a SOUTH server to obtain an explicit authorization decision
   for the proposed action.

   A typical flow is:


   1.  The agent plans to call a tool or service, such as a database,
       filesystem, or external API.

   2.  The agent runtime constructs a SOUTH request that encodes the
       user identity as the subject, the tool invocation as the action,
       and the target resource as the object.  The context may include
       agent identifiers, chain identifiers, and environment details.



Gaikwad                    Expires 1 June 2026                 [Page 24]

Internet-Draft                    SOUTH                    November 2025


   3.  The SOUTH server evaluates the request using local policy, recent
       behavior, and any connected signals, and returns a decision.

   4.  The agent runtime executes the tool call only if the decision is
       allow.  For deny, retry, or defer, the runtime may adjust the
       plan, ask for user confirmation, or fail the step according to
       local rules.

   This mode separates alignment of model outputs from alignment of
   actions executed in the environment.  The agent may generate many
   candidate plans, but only those approved by SOUTH are executed.

10.2.  Service to Service and Mesh Gateways

   In microservice and service mesh environments [SERVICE-MESH],
   services call each other over RPC or HTTP.  Gateways and sidecars
   often enforce authorization policies for incoming and outgoing calls.
   SOUTH can be used as an external decision service in this setting.

   A sidecar or gateway can:


   1.  Extract subject information from mutual TLS, tokens, or local
       identities.

   2.  Map the requested method and path to an action and object.

   3.  Construct a SOUTH request with optional context such as zone,
       workload identity, or rate information.

   4.  Call the SOUTH server and apply the returned decision to allow or
       block the upstream call.

   This mode centralizes authorization policy while keeping enforcement
   at gateways and sidecars.

10.3.  Mail Transfer Agents

   Mail transfer agents (MTAs) often need to decide whether to accept,
   relay, or reject a message based on sender identity, recipient,
   content classification, and reputation signals.  SOUTH can be used as
   an authorization step between MTAs.

   In one deployment model:







Gaikwad                    Expires 1 June 2026                 [Page 25]

Internet-Draft                    SOUTH                    November 2025


   1.  When an incoming SMTP transaction reaches a receiving MTA, the
       MTA builds a SOUTH request capturing envelope sender, envelope
       recipient, client IP, authentication status, and local reputation
       scores as signals.

   2.  The MTA calls a SOUTH server and receives a decision such as
       allow, deny, or defer.

   3.  The MTA maps allow to message acceptance, deny to rejection, and
       defer to temporary failure codes such as 4xx.

   This mode lets operators encode complex spam and abuse policies
   outside the MTA core logic while keeping SMTP behavior standard.

10.4.  SDN Controllers and NFV Service Chaining

   Software defined networking (SDN) controllers and network function
   virtualization (NFV) platforms often compute flow rules and service
   chains in a control plane, then program enforcement points such as
   switches or virtual functions.  SOUTH can be used as an external
   decision function for these control plane actions.

   A controller can:


   1.  Construct a SOUTH request where the subject is the control
       application or tenant, the action is a flow or service chain
       installation, and the object is the target path or chain.

   2.  Include context such as current load, link health, and security
       posture.

   3.  Call the SOUTH server to decide whether the proposed flow or
       chain is allowed.

   4.  Install the flow rules only when the decision is allow.  For
       deny, retry, or defer, the controller may choose alternate paths
       or delay provisioning.

   In this mode, SOUTH does not operate on individual packets.  It
   governs control plane actions that change forwarding behavior.

10.5.  Kubernetes Admission and Scheduling

   In Kubernetes and similar orchestrators, controllers admit and
   schedule workloads based on policies and cluster state.  SOUTH can be
   used as an external decision point in admission [K8S-ADMISSION]
   webhooks or scheduler [K8S-SCHEDULER] extensions.



Gaikwad                    Expires 1 June 2026                 [Page 26]

Internet-Draft                    SOUTH                    November 2025


   Possible patterns include:


   *  An admission webhook builds a SOUTH request for each incoming
      object, such as a Pod or Job, with the subject as the user or
      service account, the action as create or update, and the object as
      the resource.  A deny decision maps to a failed admission.

   *  A scheduler plugin calls SOUTH before binding a Pod to a node,
      using context such as node labels, taints, and current load as
      part of the request.  A deny or defer decision can cause the
      scheduler to consider different nodes or queue the Pod.

   This mode allows operators to centralize certain policies that govern
   placement and resource access, while leaving Kubernetes semantics
   intact.

10.6.  Library and Local Mode

   While SOUTH is defined as a wire protocol, some deployments may embed
   the decision logic as a library within an application or gateway.  In
   these cases, the application constructs the same request and response
   objects but calls a local function instead of sending messages over
   the network.

   Library mode can be useful for low latency paths or for environments
   that later plan to move to a remote SOUTH server.  The wire format
   defined in this document still provides value by giving a stable
   schema for testing, logging, and future interoperability.

11.  Security Considerations

   SOUTH is an authorization decision protocol.  It does not replace
   transport security, authentication, or application specific checks.
   Incorrect deployment or interpretation can weaken system security.
   This section highlights key considerations.

11.1.  Authentication and Integrity

   SOUTH assumes that both client and server identities are established
   by the surrounding transport and authentication mechanisms.  The
   protocol does not define its own authentication scheme.

   Deployments SHOULD:


   *  Use a secure transport such as TLS to protect SOUTH requests and
      responses from eavesdropping and tampering.



Gaikwad                    Expires 1 June 2026                 [Page 27]

Internet-Draft                    SOUTH                    November 2025


   *  Authenticate clients and servers using appropriate mechanisms,
      such as mutual TLS, bearer tokens, or DPoP proofs, depending on
      the environment.

   *  Bind subject information in the request to authenticated
      identities, so that a client cannot claim a different subject than
      the one established at the transport layer.

   If authentication or integrity is not enforced, an attacker may
   inject SOUTH requests, spoof subjects, or alter response decisions in
   transit.

11.2.  Fail Open and Fail Closed Behavior

   SOUTH separates authorization decisions from transport and processing
   errors.  Clients must decide how to behave when no valid SOUTH
   response is available.

   In security sensitive environments, clients SHOULD fail closed when:


   *  No response is received within a timeout.

   *  The HTTP status code is not 2xx.

   *  The response body cannot be parsed as a SOUTH response object.

   Failing open in these situations can allow unauthorized actions when
   the SOUTH server is unavailable or under attack.  Any decision to
   fail open SHOULD be limited to controlled contexts such as
   development or explicit emergency recovery procedures.

11.3.  Stochastic Decisions and Probing

   SOUTH allows stochastic behavior near the decision boundary.  While
   this can reduce predictability, it also introduces considerations for
   probing and analysis by an attacker.

   An adversary who can send many similar requests and observe allow or
   deny outcomes may estimate the underlying score function or
   probability mapping.  This can reveal where decision boundaries lie
   and may help the attacker craft more effective requests.

   Deployments SHOULD:


   *  Rate limit requests that reach the SOUTH server, especially near
      sensitive resources.



Gaikwad                    Expires 1 June 2026                 [Page 28]

Internet-Draft                    SOUTH                    November 2025


   *  Monitor for repeated probing patterns and adjust policy or block
      abusive clients.

   *  Consider limiting the precision of exported scores and
      probabilities, or omitting them entirely in high risk
      environments.

11.4.  Logging and Policy Leakage

   SOUTH requests and responses can contain sensitive information,
   including subject identifiers, resource names, and diagnostic
   reasons.  Logs that capture this data may reveal internal structure,
   policy rules, or usage patterns to unauthorized parties.

   Operators SHOULD:


   *  Apply access control and retention policies to SOUTH logs.

   *  Avoid exposing detailed decision reasons or raw request objects to
      low privilege users or external systems.

   *  Consider redacting or aggregating fields that might reveal
      sensitive policy details or user behavior.

   In agent deployments, prompts and tool parameters may appear in
   action or object fields.  These can be sensitive and require the same
   care as application logs that contain prompts or user inputs.

11.5.  Dependency and Bypass Risks

   SOUTH is only effective when its decisions are enforced.  If some
   code paths or tools bypass SOUTH, then policy enforcement becomes
   incomplete.

   Deployments SHOULD:


   *  Identify which actions and tools must be guarded by SOUTH and
      ensure that all corresponding paths call the SOUTH server or
      library consistently.

   *  Ensure that enforcement points, such as gateways, sidecars, or
      agent runtimes, cannot be bypassed by direct access to back end
      systems.

   *  Protect configuration that defines which actions require SOUTH
      decisions, to prevent downgrades.



Gaikwad                    Expires 1 June 2026                 [Page 29]

Internet-Draft                    SOUTH                    November 2025


   If attackers can reach underlying resources without going through
   SOUTH controlled enforcement points, the protocol provides no
   protection for those paths.

11.6.  Denial of Service

   SOUTH servers can become a central dependency.  If a SOUTH server is
   unavailable or overloaded, clients may be unable to obtain decisions
   and may block or fail open, depending on configuration.

   An attacker may try to exhaust SOUTH server capacity by sending a
   large number of requests.  To mitigate this risk, deployments SHOULD:


   *  Apply rate limiting and admission controls to SOUTH endpoints.

   *  Use resource isolation and scaling mechanisms appropriate for
      critical infrastructure components.

   *  Define clear client behavior when SOUTH is unavailable, with a
      bias toward fail closed in sensitive environments.

11.7.  Caching and Replay

   Caching SOUTH responses can reduce load and latency, but it
   introduces risks if cached decisions are reused beyond their valid
   context.

   Deployments that use caching SHOULD:


   *  Scope caches to specific subjects, objects, and actions, so that
      decisions are not applied across unrelated contexts.

   *  Use appropriate lifetimes for cached entries, especially when
      policy or context can change quickly.

   *  Protect any cache keys or stored responses against tampering and
      unauthorized access.

   Attackers who can replay old responses in place of fresh decisions
   may bypass updated policies.  Binding cached entries to request
   attributes and transport layer security is recommended.








Gaikwad                    Expires 1 June 2026                 [Page 30]

Internet-Draft                    SOUTH                    November 2025


11.8.  Agent Specific Considerations

   When SOUTH is used in agent frameworks, an agent runtime may generate
   many candidate actions in response to a single user prompt.  SOUTH
   decisions influence which of these actions are executed in the
   environment.

   Operators SHOULD:


   *  Ensure that all environment changing actions, such as writes,
      deployments, and external calls, are covered by SOUTH or
      equivalent controls.

   *  Treat user prompts and agent generated plans as untrusted inputs
      and rely on SOUTH decisions to filter dangerous actions.

   *  Consider additional rate and scope constraints for agents that can
      generate many tool calls in a short time.

   SOUTH does not guarantee that an agent will choose the best or safest
   plan.  It only decides whether a particular requested action is
   within policy.  Other safety layers remain necessary.

12.  Privacy Considerations

   SOUTH requests and responses can contain personal data and other
   sensitive information.  This section outlines privacy related
   considerations.  It does not replace local legal or regulatory
   obligations.

12.1.  Data Types in SOUTH Messages

   A SOUTH request may carry subject identifiers, tenant identifiers,
   resource identifiers, locations, timestamps, device attributes,
   anomaly scores, and other contextual signals.  In agent deployments,
   action and object fields may also contain parts of prompts, tool
   parameters, or derived user data.

   A SOUTH response may contain reasons, error codes, and other
   diagnostics that reveal aspects of policy or user behavior.

   Operators SHOULD treat SOUTH messages and logs as sensitive data.
   They can reveal:


   *  Which users access which resources, at what times, and from which
      locations.



Gaikwad                    Expires 1 June 2026                 [Page 31]

Internet-Draft                    SOUTH                    November 2025


   *  The structure of internal resources such as tables, endpoints, or
      tools.

   *  Behavioral patterns, including anomaly scores and recent failures.

12.2.  Data Minimization

   SOUTH defines a flexible schema for requests.  Deployments SHOULD
   apply data minimization principles when populating fields.

   In particular, clients SHOULD:


   *  Avoid sending full prompts or large payloads in the action or
      object fields when a compact identifier would suffice.

   *  Restrict subject attributes to those needed for policy evaluation,
      rather than copying entire user records.

   *  Limit context and signal fields to information that has clear
      value for the decision.

   Servers SHOULD discourage deployments that place unnecessary personal
   data into SOUTH messages and SHOULD document which fields are
   essential for common policies.

12.3.  Retention and Access Control for Logs

   SOUTH implementations often log requests and responses for debugging,
   incident analysis, and compliance.  Such logs can form a detailed
   record of user and agent behavior.

   Operators SHOULD:


   *  Apply access controls to logs so that only authorized personnel
      and systems can view them.

   *  Define and enforce retention periods that are consistent with
      local policy and regulation.

   *  Consider pseudonymization or anonymization of identifiers when
      full fidelity is not needed.

   *  Avoid exporting raw SOUTH logs to third parties unless appropriate
      agreements and safeguards are in place.





Gaikwad                    Expires 1 June 2026                 [Page 32]

Internet-Draft                    SOUTH                    November 2025


12.4.  Agent Context and Prompt Data

   When SOUTH is used with agents, the boundary between policy data and
   user content can be blurred.  Tools may carry pieces of prompts,
   documents, or messages in their parameters.  If these are copied into
   SOUTH requests, the authorization layer may receive more user data
   than necessary.

   To reduce risk, agent runtimes SHOULD:


   *  Represent tools and resources using stable identifiers where
      possible, rather than embedding full content.

   *  Keep free form user text out of SOUTH messages unless the policy
      explicitly depends on it.

   *  Treat any prompt fragments or document snippets that do enter
      SOUTH requests as sensitive and protect them in storage and
      transit.

   Policy authors SHOULD design rules that depend on coarse attributes
   or classifications rather than raw user content when possible.

12.5.  Metadata and Inference Risks

   Even when raw content is not present, metadata can support inference
   about users and organizations.  For example, a sequence of SOUTH
   requests may reveal:


   *  Work schedules and time zones of specific users.

   *  Which internal projects or datasets are active.

   *  Which resources are considered sensitive or high value.

   Operators SHOULD consider these inference risks when deciding where
   SOUTH messages and logs are stored and who can access them.  In some
   cases, aggregating or sampling logs may be preferable to storing full
   detail.

12.6.  Cross Border Transfers and Third Parties

   In some deployments, SOUTH servers may run in different regions or
   under different administrative domains than the calling services.
   This can create cross border data flows.




Gaikwad                    Expires 1 June 2026                 [Page 33]

Internet-Draft                    SOUTH                    November 2025


   Operators SHOULD:


   *  Verify that sending SOUTH requests to remote regions or third
      party providers is compatible with local data protection rules.

   *  Limit which fields are sent across boundaries, and prefer
      identifiers over raw content when possible.

   *  Ensure that contracts or agreements with third parties cover the
      handling of SOUTH messages and logs.

12.7.  User Rights and Transparency

   In some jurisdictions, users have rights to access, correct, or
   delete personal data.  SOUTH by itself does not define any mechanisms
   to support these rights.

   Deployments that use SOUTH in systems with user facing obligations
   SHOULD:


   *  Treat SOUTH logs and configuration as part of the overall data
      inventory.

   *  Ensure that user facing documentation describes how authorization
      and decision logs are used.

   *  Provide procedures to locate and handle personal data that appears
      in SOUTH messages when required by law or policy.

12.8.  Extensions and Profiles

   The extensions field in SOUTH requests and responses allows
   deployments to add custom data.  Unconstrained use of extensions can
   introduce privacy risks.

   Profiles that define extensions SHOULD:


   *  Document the purpose and data types of each extension clearly.

   *  Avoid placing raw user content into extensions when derived
      attributes would suffice.

   *  Apply the same security and privacy controls to extension fields
      as to core fields.




Gaikwad                    Expires 1 June 2026                 [Page 34]

Internet-Draft                    SOUTH                    November 2025


   Operators SHOULD periodically review extensions and remove those that
   are no longer necessary.

13.  IANA Considerations

   This document registers a new media type for SOUTH request and
   response objects encoded in JSON.  The registration follows the
   guidelines in [RFC6838].

13.1.  application/south+json Media Type

   The following media type registration is for the JSON encoding of
   SOUTH messages.

   Type name:  application

   Subtype name:  south+json

   Required parameters:  None

   Optional parameters:  None

   Encoding considerations:  Must be encoded as UTF-8.  See [RFC8259].

   Security considerations:  See the Security Considerations section of
      this document.

   Interoperability considerations:  None known.

   Published specification:  This document.

   Applications that use this media type:  SOUTH-aware clients and
      servers, agent frameworks, service meshes, authorization
      middleboxes, and schedulers requiring structured authorization
      decisions.

   Additional information:  None.

   Person & email address to contact for further information:  Madhava
      Gaikwad <gaikwad.madhav@gmail.com>

   Intended usage:  Common

   Restrictions on usage:  None

   Author:  See Author section of this document.

   Change controller:  IESG <iesg@ietf.org>, or as designated by future



Gaikwad                    Expires 1 June 2026                 [Page 35]

Internet-Draft                    SOUTH                    November 2025


      standardization work.

14.  Normative References

   [RFC6838]  Freed, N., "Media Type Specifications and Registration
              Procedures", January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

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

   [RFC9110]  "HTTP Semantics", RFC 9110,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC8446]  "The Transport Layer Security (TLS) Protocol Version 1.3",
              RFC 8446, <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC6749]  "The OAuth 2.0 Authorization Framework", RFC 6749,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC9449]  "Demonstrating Proof-of-Possession at the Application
              Layer (DPoP)", RFC 9449,
              <https://www.rfc-editor.org/rfc/rfc9449>.

15.  Informative References

   [NIST-ZT]  "Zero Trust Architecture", NIST Special
              Publication 800-207,
              <https://csrc.nist.gov/publications/detail/sp/800-207/
              final>.

   [K8S-ADMISSION]
              "Kubernetes Admission Controllers", Kubernetes
              Documentation Admission Controllers,
              <https://kubernetes.io/docs/reference/access-authn-authz/
              admission-controllers/>.

   [K8S-SCHEDULER]
              "Kubernetes Scheduler", Kubernetes
              Documentation Scheduler,
              <https://kubernetes.io/docs/concepts/scheduling-eviction/
              kube-scheduler/>.

   [SERVICE-MESH]
              "Istio Service Mesh Documentation", Istio
              Documentation Overview, <https://istio.io/latest/docs/>.




Gaikwad                    Expires 1 June 2026                 [Page 36]

Internet-Draft                    SOUTH                    November 2025


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

Appendix A.  Example Flows

   This appendix provides example SOUTH message sequences for several
   deployment scenarios.  These examples are illustrative.  They do not
   constrain implementations.

A.1.  Agent Tool Invocation

   In this flow a language model based agent wishes to call a database
   tool on behalf of a user.  The agent runtime consults SOUTH before
   making the tool call.

   Step 1: the user submits a prompt to the agent.  The agent decides
   that it needs to read a customer record and plans a tool invocation
   such as database_query.

   Step 2: the agent runtime constructs a SOUTH request.  The subject is
   the user, the action is the tool invocation, the object is the target
   table, and the context includes agent related information.
























Gaikwad                    Expires 1 June 2026                 [Page 37]

Internet-Draft                    SOUTH                    November 2025


   {
     "request_id": "req-001",
     "subject": {
       "id": "user-1234",
       "type": "user",
       "attributes": {
         "tenant": "tenant-42",
         "roles": ["reader"]
       }
     },
     "action": {
       "type": "tool.invoke",
       "name": "database_query",
       "parameters": {
         "operation": "select",
         "resource": "customers-table"
       }
     },
     "object": {
       "id": "customers-table",
       "type": "database.table"
     },
     "context": {
       "agent_id": "agent-runtime-1",
       "chain_id": "plan-abc",
       "ip": "198.51.100.23"
     }
   }

               Figure 15: Agent tool invocation SOUTH request

   Step 3: the SOUTH server evaluates the request and returns a response
   that allows the action.

   {
     "request_id": "req-001",
     "decision": "allow",
     "reason": "policy",
     "score": 0.92
   }

              Figure 16: Agent tool invocation SOUTH response

   Step 4: the agent runtime proceeds with the database tool call.  If
   the decision had been deny or retry, the runtime would select a
   different plan or ask the user for guidance.





Gaikwad                    Expires 1 June 2026                 [Page 38]

Internet-Draft                    SOUTH                    November 2025


A.2.  Service Mesh Gateway

   In this flow a service mesh sidecar consults SOUTH before forwarding
   an HTTP call from service A to service B.

   Step 1: service A sends an HTTP request to service B.  The request
   passes through a sidecar proxy.

   Step 2: the sidecar constructs a SOUTH request.  The subject is the
   identity of service A, the action encodes the HTTP method, and the
   object identifies the upstream service and path.

   {
     "request_id": "mesh-123",
     "subject": {
       "id": "service-A",
       "type": "service",
       "attributes": {
         "namespace": "payments"
       }
     },
     "action": {
       "type": "http.call",
       "name": "GET",
       "parameters": {
         "path": "/v1/charges"
       }
     },
     "object": {
       "id": "service-B",
       "type": "service",
       "attributes": {
         "namespace": "billing"
       }
     },
     "context": {
       "ip": "10.0.0.5",
       "zone": "zone-1"
     }
   }

                   Figure 17: Service mesh SOUTH request

   Step 3: the SOUTH server returns a deny decision.  The sidecar
   returns an HTTP error to service A and does not forward the request
   to service B.





Gaikwad                    Expires 1 June 2026                 [Page 39]

Internet-Draft                    SOUTH                    November 2025


   {
     "request_id": "mesh-123",
     "decision": "deny",
     "reason": "policy",
     "score": 0.08
   }

                   Figure 18: Service mesh SOUTH response

A.3.  Mail Transfer Agent

   In this flow an incoming SMTP connection triggers a SOUTH check
   before message acceptance.

   Step 1: a sending MTA connects to a receiving MTA and issues an SMTP
   transaction with MAIL FROM and RCPT TO commands.

   Step 2: before accepting the message body, the receiving MTA
   constructs a SOUTH request.  The subject reflects the sending host
   and authenticated identity, the object is the recipient, and the
   signals include local reputation scores.

   {
     "request_id": "mta-42",
     "subject": {
       "id": "smtp-client-1",
       "type": "mta",
       "attributes": {
         "ip": "203.0.113.5",
         "helo": "mail.example.org"
       }
     },
     "action": {
       "type": "smtp.accept",
       "name": "deliver"
     },
     "object": {
       "id": "user@example.net",
       "type": "mailbox"
     },
     "signals": {
       "reputation_score": 0.21,
       "spf_pass": false
     }
   }

                        Figure 19: MTA SOUTH request




Gaikwad                    Expires 1 June 2026                 [Page 40]

Internet-Draft                    SOUTH                    November 2025


   Step 3: the SOUTH server returns a defer decision.  The MTA responds
   with a temporary failure code and may try again later or drop the
   connection according to local policy.

Appendix B.  Signing Profiles

   SOUTH does not define its own authentication or signing format.  This
   appendix sketches profiles that combine SOUTH with existing
   mechanisms.  These descriptions are informative.

B.1.  Mutual TLS Profile

   In the mutual TLS profile, client and server authentication rely on
   TLS [RFC8446].  The client presents a certificate and the server maps
   the certificate to a client identity.  The SOUTH request includes a
   subject that is derived from this identity.

   Properties:


   *  Integrity and confidentiality are provided by the TLS session.

   *  The subject in the SOUTH request is bound to the certificate
      presented on the connection.

   *  No additional signatures are required in the body.

   This profile is suitable inside data centers or service mesh
   environments where mutual TLS is already deployed.

B.2.  OAuth 2.0 and DPoP Profile

   In this profile, the client authenticates to the SOUTH server using
   OAuth 2.0 bearer tokens [RFC6749] and may use DPoP [RFC9449] for
   proof of possession.

   A typical flow is:


   1.  The client obtains an access token from an authorization server,
       with a subject identifier and optional scopes.

   2.  The client sends SOUTH requests over HTTPS, including the token
       in an Authorization header and optional DPoP proof.

   3.  The SOUTH server validates the token and proof, then uses the
       subject and scopes as part of policy evaluation.




Gaikwad                    Expires 1 June 2026                 [Page 41]

Internet-Draft                    SOUTH                    November 2025


   The SOUTH subject should reflect the identity in the access token.
   Additional attributes may be derived from token claims.

B.3.  Signed Request Bodies

   Some deployments may require explicit integrity protection for the
   SOUTH request body, separate from the transport.  One option is to
   use a JSON based signature format that covers the serialized request
   object.

   A simple pattern is:


   1.  Serialize the SOUTH request object as JSON.

   2.  Compute a signature over the JSON representation using a key
       associated with the client.

   3.  Attach the signature and key identifier in the extensions field
       or a separate header that is understood by the SOUTH server.

   The server verifies the signature before evaluating policy.  The
   exact signature format, key management, and canonical serialization
   rules are deployment specific and out of scope for this document.

B.4.  Agent and User Binding

   In agent scenarios, a SOUTH request may represent a combined decision
   for a user and an agent runtime.  One deployment model uses two
   layers of proof.


   *  The outer transport authenticates the agent runtime itself, for
      example through mutual TLS or a client credential token.

   *  The inner subject reflects the user identity, which is carried in
      a user token or session credential.

   The SOUTH server can validate both identities and apply policy that
   depends on the combination.  For example, some tools may only be
   allowed when a specific agent acts on behalf of a given user group.

Appendix C.  Rate and Load Aware Policies

   SOUTH is compatible with rate and load sensitive decision logic.
   This appendix outlines patterns for encoding such policies in the
   request and response objects.




Gaikwad                    Expires 1 June 2026                 [Page 42]

Internet-Draft                    SOUTH                    November 2025


C.1.  Rate and Load Signals

   Rate and load information can appear in the context and signals
   fields of the SOUTH request.  The following fields are common
   examples.


   *  Per subject request rate over a recent window.

   *  Per resource or per tenant request rate.

   *  Current load on a target service or cluster.

   *  Anomaly or burst scores from external detectors.

   The exact schema for these fields is deployment specific.  A profile
   can define standard names such as subject_rate or service_load.

C.2.  Decisions for Throttling and Shedding

   Rate and load aware policies can use SOUTH decisions to control
   throttling and shedding.

   Typical patterns include:


   *  allow when rates and load are below thresholds.

   *  deny when a request clearly exceeds policy or is part of an
      abusive pattern.

   *  retry when the policy suggests that the operation may succeed
      later, for example under transient load.

   *  defer when the system prefers queued or delayed execution rather
      than immediate failure.

   The reason field and optional retry_after extension can give further
   guidance to clients.  For example, a rate limited decision may
   suggest a backoff period.

C.3.  Agent Specific Rate Policies

   Agents can generate many actions in a short time.  SOUTH can help
   enforce limits that prevent unbounded tool use or external calls.

   Examples include:




Gaikwad                    Expires 1 June 2026                 [Page 43]

Internet-Draft                    SOUTH                    November 2025


   *  Per user and per agent caps on tool calls per minute.

   *  Budgets for external API calls or high cost operations.

   *  Step up requirements when an agent exceeds typical behavior, such
      as additional user confirmation.

   These policies are expressed as functions of the rate related signals
   in the SOUTH request.  The SOUTH response then guides how the agent
   runtime adapts its plan.

C.4.  Fairness and Multi Tenant Settings

   In multi tenant environments, rate and load policies affect fairness.
   SOUTH can help implement per tenant and per group quotas that prevent
   a single tenant from consuming a disproportionate share of capacity.

   A SOUTH server can:


   1.  Track usage counters per tenant or group.

   2.  Include current quota status in the decision logic.

   3.  Return deny or defer decisions when quotas are exceeded.

   The protocol itself does not enforce quotas, but it provides a
   structured place to apply quota aware decisions and to signal these
   decisions back to clients.

Author's Address

   Madhava Gaikwad
   Independent Researcher
   Email: gaikwad.madhav@gmail.com
















Gaikwad                    Expires 1 June 2026                 [Page 44]


name: draft-gaikwad-aps-profile
rev: 00
title: Agent Persistent State Profile
time: 2025-11-30T01:55:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-03T01:55:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864828+00:00
abstract:
Autonomous agents increasingly maintain durable persistent state
   containing user preferences, embedding vectors, safety logs,
   intermediate reasoning steps, and audit traces.  Today, agent
   frameworks treat storage as a generic file system, while storage
   administrators treat agents as stateless virtual machines.  This
   "layer mismatch" leads to fragility, poor performance, and privacy
   risks.

   The Agent Persistent State (APS) Profile defines an experimental,
   vendor-neutral storage service class for durable agent state.  APS
   emphasizes *compliance*: ensuring that memory associated with a
   specific user or agent identity can be retained, audited, and
   cryptographically erased.  APS also addresses high-frequency small I/
   O, vector index workloads, crash consistency, and Kubernetes/CSI
   [CSI] integration.

   APS introduces a Usage Class ("AgentPersistentState"), a versioned
   PersistentStateLineOfService schema, guidance for container
   orchestration systems, non-normative bindings for Swordfish
   [Swordfish] and Redfish [Redfish], and considerations for multi-
   tenancy.  APS is intended as an Experimental RFC to gather
   implementation feedback prior to any standards-track work.

full_text:
Network Working Group                                         M. Gaikwad
Internet-Draft                                           1 December 2025
Intended status: Experimental                                           
Expires: 4 June 2026


                     Agent Persistent State Profile
                      draft-gaikwad-aps-profile-00

Abstract

   Autonomous agents increasingly maintain durable persistent state
   containing user preferences, embedding vectors, safety logs,
   intermediate reasoning steps, and audit traces.  Today, agent
   frameworks treat storage as a generic file system, while storage
   administrators treat agents as stateless virtual machines.  This
   "layer mismatch" leads to fragility, poor performance, and privacy
   risks.

   The Agent Persistent State (APS) Profile defines an experimental,
   vendor-neutral storage service class for durable agent state.  APS
   emphasizes *compliance*: ensuring that memory associated with a
   specific user or agent identity can be retained, audited, and
   cryptographically erased.  APS also addresses high-frequency small I/
   O, vector index workloads, crash consistency, and Kubernetes/CSI
   [CSI] integration.

   APS introduces a Usage Class ("AgentPersistentState"), a versioned
   PersistentStateLineOfService schema, guidance for container
   orchestration systems, non-normative bindings for Swordfish
   [Swordfish] and Redfish [Redfish], and considerations for multi-
   tenancy.  APS is intended as an Experimental RFC to gather
   implementation feedback prior to any standards-track work.

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



Gaikwad                    Expires 4 June 2026                  [Page 1]

Internet-Draft       Agent Persistent State Profile        December 2025


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Landscape of Agent Frameworks and Persistent State Needs  . .   4
   4.  APS Data Model  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  PersistentStateLineOfService Schema . . . . . . . . . . . . .   5
     5.1.  IOProfile Behavior (Non-Normative)  . . . . . . . . . . .   7
     5.2.  DurabilityClass Guidance (Non-Normative)  . . . . . . . .   8
   6.  Crash Consistency Requirements  . . . . . . . . . . . . . . .   9
   7.  Privacy, Replication, and Erasure . . . . . . . . . . . . . .   9
     7.1.  Non-Normative Implementation Patterns . . . . . . . . . .  11
   8.  Multi-Tenancy and Volume Scalability  . . . . . . . . . . . .  12
   9.  Block and File Applicability  . . . . . . . . . . . . . . . .  12
   10. Identity and Control Plane Role . . . . . . . . . . . . . . .  12
   11. Kubernetes and CSI Mapping  . . . . . . . . . . . . . . . . .  12
   12. Bindings and Profile Discovery  . . . . . . . . . . . . . . .  13
   13. Versioning and Extensibility  . . . . . . . . . . . . . . . .  14
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
   16. Limitations and Future Work . . . . . . . . . . . . . . . . .  14
   17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     18.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Example APS Profiles (Non-Normative) . . . . . . . .  16
     A.1.  APS-Standard (Checkpoint-Oriented)  . . . . . . . . . . .  16
     A.2.  APS-Vector (Embedding-Heavy)  . . . . . . . . . . . . . .  18
     A.3.  APS-Light (BestEffort / ApplicationKey) . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22








Gaikwad                    Expires 4 June 2026                  [Page 2]

Internet-Draft       Agent Persistent State Profile        December 2025


1.  Introduction

   AI agents are entering a new operational phase.  Early systems
   focused on prompt engineering and model context.  Modern deployments
   involve several of autonomous agents with distinct identities and
   long-lived state.  Persistent state stores embeddings, preferences,
   memory, safety constraints, and reasoning artifacts that must remain
   durable and compliant across failures.

   Current practice reveals a structural mismatch: agent developers
   assume implicitly that "somewhere" there is a low-latency, compliant
   store; storage administrators assume short-lived, stateless
   applications.  This mismatch leads to data loss, privacy violations,
   tail-latency spikes, and unpredictable behavior.

   Reviewers have observed that this draft is premature but can be
   possibly timely: as deployments scale to thousands of agents, storage
   semantics will become critical infrastructure.  By the time APS
   reaches maturity, the need is expected to be urgent.

   The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this
   document are to be interpreted as described in [RFC2119] and
   [RFC8174] when, and only when, they appear in all capitals.

2.  Terminology

   Agent:  An autonomous software entity with a distinct identity and a
      multi-session lifecycle.  Agents maintain durable state across
      restarts or container rescheduling, motivating specialized
      persistent storage semantics.

   Persistent State:  Durable data associated with an agent identity,
      including embeddings, preferences, caches, audit logs, and vector
      indexes.

   APS:  Agent Persistent State Profile defined in this document.

   Usage Class:  A tag applied to storage resources indicating the
      expected workload.  This document defines AgentPersistentState.

   Line of Service (LoS):  A structured description of storage behavior.

   Forgetting Policy:  A policy that causes persistent state to be
      deleted or scrubbed according to age, event triggers, or external
      legal/compliance requests (for example, scheduled deletion of
      records older than a given retention period).





Gaikwad                    Expires 4 June 2026                  [Page 3]

Internet-Draft       Agent Persistent State Profile        December 2025


3.  Landscape of Agent Frameworks and Persistent State Needs

   Agent frameworks today implement persistence at the application
   layer, leading to fragility.  The following table summarizes common
   patterns as of 2025; it is illustrative and non-exhaustive.

   +===========+==================+===============+====================+
   |Framework  | Current          |Pain Point     | APS Benefit        |
   |           | Mechanism        |               |                    |
   +===========+==================+===============+====================+
   |LangChain  | Postgres/SQLite/ |Locking, tail  | SmallRandom        |
   |(LangGraph)| Redis            |latency from   | profile; advisory  |
   |           | checkpoints      |high-frequency | locking hints      |
   |           |                  |checkpointing  |                    |
   +-----------+------------------+---------------+--------------------+
   |AutoGPT/   | JSON files and   |Crash can      | CrashConsistency   |
   |BabyAGI    | local workspace  |corrupt state; | and journaling     |
   |           | directories      |agent          | recommendations    |
   |           |                  |"forgets"      |                    |
   |           |                  |everything     |                    |
   +-----------+------------------+---------------+--------------------+
   |LlamaIndex | Vector stores    |Noisy-neighbor | Vector-phase-aware |
   |           | (e.g., HNSW)     |throttling     | profiles; tail-    |
   |           | plus document    |during bulk    | latency awareness  |
   |           | stores           |index I/O      |                    |
   +-----------+------------------+---------------+--------------------+
   |CrewAI     | Local SQLite or  |Multi-agent    | ReplicationScope   |
   |           | similar shared   |persistence    | for AZ/region      |
   |           | state            |fragile across | resilience         |
   |           |                  |failures       |                    |
   +-----------+------------------+---------------+--------------------+

                                  Table 1

   The structural problems across frameworks validate the need for APS:
   requirements for durability, performance, and compliance must move
   downward into the infrastructure layer in a standard form.

4.  APS Data Model

   APS defines a new Usage Class:

   UsageClass: "AgentPersistentState"








Gaikwad                    Expires 4 June 2026                  [Page 4]

Internet-Draft       Agent Persistent State Profile        December 2025


   APS applies to storage abstractions that present block or filesystem
   semantics to agents and their orchestrators, including volumes
   provisioned via Kubernetes PersistentVolumes or surfaces exposed
   through SNIA/DMTF management schemas.  Applying APS directly to pure
   object stores or HTTP-based APIs is outside the scope of the
   normative requirements in this document.

5.  PersistentStateLineOfService Schema

   The PersistentStateLineOfService structure describes a single APS
   profile.  Fields marked OPTIONAL are advisory and MAY be omitted.  A
   subset of fields constitutes the core APS compliance baseline and
   MUST be present and honored for any profile that claims APS
   compliance.

   PersistentStateLineOfService {

     ApsVersion: string           # e.g., "1.0"

     Id: string
     Name: string
     Purpose: "AgentPersistentState"

     IOProfile: enum {
         SmallRandom,
         MixedRandom,
         MetadataHeavy,
         VectorIndex
     }

     # Optional refinement for vector workloads:
     VectorPhase: enum {
         Ingest,
         Query,
         Mixed
     } OPTIONAL

     CapacityRangeGiB {
       MinGiB: integer
       MaxGiB: integer
       RecommendedStepGiB: integer
     }

     Performance {
       MinIOPS: integer
       MaxLatencyMsP95: number
       MaxLatencyMsP99: number




Gaikwad                    Expires 4 June 2026                  [Page 5]

Internet-Draft       Agent Persistent State Profile        December 2025


       RecommendedIOSizeKiB: integer
           # Embeddings and vectors may use 16-64KiB I/O sizes
     }

     Durability {
       DurabilityClass: enum { Standard, High, VeryHigh }
       ReplicationScope: enum { LocalAZ, MultiAZ, MultiRegion }
     }

     CrashConsistency {
       RequiresWriteOrdering: boolean
     }

     Retention {
       RetentionDays: integer
       ForgettingPolicySupported: boolean
     }

     Privacy {
       ContainsUserFacingDataExpected: boolean

       MinDeletionSemantics: enum {
         BestEffort,
         CryptographicErase,
         MediaScrub
       }

       ErasureScope: enum {
         Volume,          # Whole LUN / filesystem
         FilesystemTree,  # Directory / inode subtree
         ObjectPrefix,    # Prefix subset for object-backed systems
         ApplicationKey   # Crypto handled above storage
       }

       MaxEraseLatencyHours: integer
     }

     ConcurrencyHints {        # OPTIONAL, advisory only
       AdvisoryLockingSupported: boolean
     }
   }

   The core APS compliance baseline consists of the following fields,
   which *MUST* be present and reflect behavior meaningful to the
   abstraction being exposed:

   *  IOProfile




Gaikwad                    Expires 4 June 2026                  [Page 6]

Internet-Draft       Agent Persistent State Profile        December 2025


   *  CapacityRangeGiB (all members)

   *  Performance.MinIOPS

   *  Performance.MaxLatencyMsP95

   *  Durability.DurabilityClass

   *  Durability.ReplicationScope

   *  CrashConsistency.RequiresWriteOrdering

   *  Retention.RetentionDays

   *  Retention.ForgettingPolicySupported

   *  Privacy.MinDeletionSemantics

   *  Privacy.ErasureScope

   *  Privacy.MaxEraseLatencyHours

   Providers *MUST NOT* advertise an APS-compliant profile that omits or
   ignores these core fields.  Additional fields MAY be omitted if they
   are not meaningful for the abstraction (for example, advisory locking
   hints on raw block volumes).

   In environments that provision storage in terms of throughput (for
   example, MiB/s) rather than IOPS, implementers MAY derive an
   effective MinIOPS from documented throughput and average I/O size.
   One reasonable approach is:

   MinIOPS ≈ (ThroughputMiBps * 1024) / RecommendedIOSizeKiB

   APS does not constrain how this effective value is calculated, but
   providers SHOULD document the relationship between throughput and
   MinIOPS.

5.1.  IOProfile Behavior (Non-Normative)

   IOProfile values describe expected workload envelopes.  This section
   is non-normative guidance for implementers and consumers.  APS
   profiles are provisioned at volume-creation time, while agent
   workloads may evolve dynamically.  Consumers SHOULD treat IOProfile
   as a coarse signal for provisioning decisions, not a real-time
   optimization mechanism.





Gaikwad                    Expires 4 June 2026                  [Page 7]

Internet-Draft       Agent Persistent State Profile        December 2025


   Some IOProfile values (for example, VectorIndex) include an OPTIONAL
   VectorPhase field.  VectorPhase refines expected workload behavior
   but does not override the baseline characteristics of the underlying
   IOProfile.

   SmallRandom:  Dominated by 4-16 KiB random reads and writes, typical
      for agent checkpointing, key-value state blocks, preference
      updates, and log fragments.  Storage SHOULD provision enough low-
      latency IOPS to avoid tail-latency amplification during frequent
      agent state flushes.

   MetadataHeavy:  Characterized by high rates of metadata changes
      (directory operations, inode updates, journal commits).  Suitable
      for agents producing many small files or maintaining structured
      reasoning traces.  Storage SHOULD support efficient metadata
      journaling and crash-consistent mounts.

   MixedRandom:  A balanced workload combining small random I/O with
      occasional larger sequential batches.  Appropriate when agents
      interleave checkpointing, replay logs, and batched vector updates.

   VectorIndex:  Represents workloads dominated by embedding ingestion,
      vector construction, nearest-neighbor search, or index compaction.
      Providers SHOULD document which vector phase(s) their
      configuration optimizes.  The OPTIONAL VectorPhase enum has the
      following meanings:

      *  Ingest — optimized for high-throughput sequential or semi-
         sequential writes during bulk embedding generation, HNSW edge
         linking, or batch import.

      *  Query — optimized for low-latency random reads and small-range
         fetches typical of approximate nearest neighbor search
         workloads such as DiskANN-style index queries.

      *  Mixed — balanced for deployments where ingest, query, and
         compaction phases interleave or shift over time.  Providers
         SHOULD state which tradeoffs are made (write-friendly vs. read-
         friendly).

      Because vector workloads are phase-shifting, consumers SHOULD NOT
      assume that a single VectorPhase value can optimize all stages of
      the index lifecycle.

5.2.  DurabilityClass Guidance (Non-Normative)

   DurabilityClass values are intentionally abstract.  As non-normative
   guidance, providers might interpret them as:



Gaikwad                    Expires 4 June 2026                  [Page 8]

Internet-Draft       Agent Persistent State Profile        December 2025


   *  Standard: durability comparable to typical single-region cloud
      block volumes.

   *  High: durability comparable to replicated volumes or erasure-coded
      storage (for example, multiple independent copies within a region
      or across zones).

   *  VeryHigh: durability approaching or exceeding widely replicated
      object storage classes.

   Exact "nines" targets are out of scope and MAY vary by provider.

6.  Crash Consistency Requirements

   All APS-compliant resources *MUST* provide metadata consistency after
   power loss or crash.  For the purposes of this document, metadata
   consistency means that the filesystem or block namespace remains
   mountable without manual repair tools and that directory and inode
   structures do not exhibit silent corruption that would cause loss of
   reachability for existing files.

   The RequiresWriteOrdering flag indicates that applications rely on
   storage honoring write ordering or barrier semantics (for example,
   flush/fence operations) to maintain write-ahead logging or similar
   invariants.  When true, providers *MUST* document the ordering
   guarantees and the mechanisms available to applications.

   Implementations supporting high-frequency agent checkpointing SHOULD
   document whether O_DIRECT, O_SYNC, or equivalent durability hints are
   honored by the underlying storage stack.

   Applications are expected to rely on standard filesystem atomic
   operations (such as POSIX rename) for batched updates.  APS does not
   define or negotiate additional transactional semantics.

7.  Privacy, Replication, and Erasure

   The MinDeletionSemantics, ErasureScope, and MaxEraseLatencyHours
   fields describe the minimum deletion and erasure behavior for data
   stored under the profile.  When combined with ReplicationScope,
   providers *MUST* interpret these fields as applying to all replicas
   of the primary data in scope.

   The MaxEraseLatencyHours field *MUST* be a strictly positive integer.
   A value of zero is reserved and MUST NOT be used.  Deployments that
   effectively provide synchronous erasure MAY represent this with a
   small non-zero value and SHOULD document the expected behavior.




Gaikwad                    Expires 4 June 2026                  [Page 9]

Internet-Draft       Agent Persistent State Profile        December 2025


   For example, if MinDeletionSemantics is set to CryptographicErase and
   ReplicationScope is MultiRegion, then cryptographic erasure of all
   regions *MUST* complete within MaxEraseLatencyHours, unless the
   provisioning request explicitly accepts weaker behavior.

   APS describes behavior for primary data under the profile.
   Snapshots, backups, and other disaster recovery mechanisms MAY retain
   older copies of data beyond MaxEraseLatencyHours.  End-to-end
   compliance for such copies is outside the scope of this document and
   MUST be addressed by higher-level data lifecycle policies.

   The ErasureScope field indicates the granularity at which
   cryptographic or destructive erase is expected to act:

   *  Volume: erasure is performed at the level of a whole volume, LUN,
      or filesystem.  Destroying the associated key or media affects all
      data hosted on that volume.

   *  FilesystemTree: erasure is performed at the level of a directory
      or inode subtree.  For example, implementations MAY use per-
      directory filesystem encryption mechanisms (such as Linux fscrypt)
      where destroying the key renders only that subtree unreadable.

   *  ObjectPrefix: erasure is scoped to a subset of objects under a
      prefix or bucket namespace.  This is primarily informative for
      object-backed systems that expose filesystem views or may be the
      basis of future APS profiles for object-native agent state.
      Profiles that target purely block or filesystem abstractions MUST
      NOT use ObjectPrefix.

   *  ApplicationKey: cryptographic erase is implemented above the
      storage layer.  The storage system provides generic persistence,
      and an application, sidecar, or agent runtime manages keys and
      performs crypto-shredding by destroying them.

   When MinDeletionSemantics is set to CryptographicErase and
   ErasureScope is Volume, FilesystemTree, or ObjectPrefix, the storage
   or filesystem layer is responsible for ensuring that destruction of
   the relevant cryptographic material renders the targeted scope
   unreadable without affecting adjacent scopes beyond what is
   documented.

   When MinDeletionSemantics is CryptographicErase and ErasureScope is
   ApplicationKey, the storage layer is not aware of per-agent keys.  In
   this case, APS simply records that cryptographic erase is expected to
   be achieved via application- or sidecar-managed key lifecycles.
   Operators MUST NOT interpret such a profile as evidence of storage-
   controller-level key separation.



Gaikwad                    Expires 4 June 2026                 [Page 10]

Internet-Draft       Agent Persistent State Profile        December 2025


   Storage backing APS MAY be multi-tenant.  Providers *SHOULD* document
   whether cryptographic erase is implemented via volume-level keys,
   per-tenant keys, filesystem-level keys, or other mechanisms, and what
   the effective erase granularity is.

   There is intentionally no single mandatory minimum for
   MinDeletionSemantics.  A provider that cannot implement
   CryptographicErase MAY still advertise an APS profile using
   BestEffort semantics, but such profiles are generally unsuitable for
   compliance-critical deployments and SHOULD be clearly documented as
   such.

7.1.  Non-Normative Implementation Patterns

   The following patterns illustrate how different implementations might
   realize finer-grained erasure scopes in practice:

   FilesystemTree via fscrypt:  A CSI driver or agent runtime mounts a
      shared volume and creates per-agent directories (for example,
      /data/agent-a, /data/agent-b).  Each directory is protected with a
      distinct filesystem encryption key (such as a Linux fscrypt
      policy).  To erase a specific agent's data, the orchestrator
      destroys that directory's key in a KMS.  The APS profile would set
      ErasureScope=FilesystemTree and
      MinDeletionSemantics=CryptographicErase.

   Sub-volume Constructs (vVols, Qtrees):  Enterprise arrays that
      support lightweight logical containers inside a physical pool can
      assign unique keys to those constructs.  An APS profile might then
      represent each logical container as having ErasureScope=Volume
      from the perspective of the host filesystem, while the array
      internally multiplexes many such logical volumes.

   ApplicationKey Sidecar:  When the underlying storage provides only
      coarse-grained encryption, an application or sidecar may intercept
      I/O, encrypt data with per-agent keys, and write to a shared
      volume.  Destroying the per-agent key achieves cryptographic erase
      for that agent's data.  An APS profile for such a deployment would
      use ErasureScope=ApplicationKey.

   These patterns are examples only.  APS does not mandate a particular
   implementation, but seeks to make the erasure scope explicit so
   operators and frameworks understand where compliance responsibilities
   sit.







Gaikwad                    Expires 4 June 2026                 [Page 11]

Internet-Draft       Agent Persistent State Profile        December 2025


8.  Multi-Tenancy and Volume Scalability

   APS does *not* require a 1:1 mapping between agents and volumes.
   Volume-per-agent designs risk exhausting controller limits at scale.
   Instead, APS is intended to describe the behavior of shared storage
   classes that MAY host many agents.

   Implementations are encouraged to separate cryptographic and policy
   granularity from volume granularity.  For example, a single APS
   volume may host multiple agents while still satisfying erasure and
   isolation requirements at a filesystem-tree or application-key level,
   as indicated by ErasureScope.

9.  Block and File Applicability

   APS is intended for storage abstractions that present block or
   filesystem semantics to agents.  Some fields are primarily relevant
   to block devices (for example, RecommendedIOSizeKiB), and others are
   primarily relevant to filesystems (for example,
   AdvisoryLockingSupported).

   Providers *MAY* omit non-core fields that are not meaningful for the
   abstraction they expose.  Core fields listed in Section Section 5
   MUST be honored.

10.  Identity and Control Plane Role

   APS discusses persistent state in terms of "agent identity", but does
   not require storage protocols (for example, NVMe, iSCSI, NFS) to
   carry per-agent identifiers on individual I/O operations.  In most
   deployments, storage controllers see host or initiator identifiers,
   not agent IDs.

   Identity mapping and scoping are therefore the responsibility of the
   control plane and agent platform (for example, an orchestrator that
   binds particular agents or pods to specific volumes, filesystems, or
   filesystem subtrees).  APS describes the properties of those storage
   constructs; it does not define new protocol headers or on-the-wire
   identity fields.

11.  Kubernetes and CSI Mapping

   Kubernetes and CSI are expected to be primary consumers of APS.  This
   section provides guidance for CSI driver integrations.  It is
   informative for the CSI specification itself.






Gaikwad                    Expires 4 June 2026                 [Page 12]

Internet-Draft       Agent Persistent State Profile        December 2025


   A CSI driver that claims to be "APS-aware" *MUST* support a
   documented mechanism to pass APS hints from higher-level
   configuration (for example, StorageClass parameters) to backend
   profiles.  One possible mapping is:

   *  parameters["aps.storage.k8s.io/ioProfile"] → IOProfile

   *  parameters["aps.storage.k8s.io/privacy.minDeletion"] →
      MinDeletionSemantics

   *  parameters["aps.storage.k8s.io/privacy.erasureScope"] →
      ErasureScope

   *  parameters["aps.storage.k8s.io/privacy.maxEraseHours"] →
      MaxEraseLatencyHours

   *  parameters["aps.storage.k8s.io/durability.replicationScope"] →
      ReplicationScope

   The recommended "aps.storage.k8s.io/" prefix reduces the likelihood
   of collisions with vendor-defined parameters.  Alternative key names
   MAY be used if they are clearly documented by the CSI driver and its
   consumers.

12.  Bindings and Profile Discovery

   APS MAY be expressed in existing schemas as follows:

   Swordfish:  Implementations expressing APS profiles in Swordfish
      SHOULD use ClassOfService with UsageClass="AgentPersistentState",
      and attach a vendor-defined or standardized
      PersistentStateLineOfService extension carrying APS fields.
      Discovery of available APS profiles then follows Swordfish
      mechanisms for enumerating lines of service.

   Redfish:  Implementations exposing APS via Redfish SHOULD use OEM
      extensions on StorageService and Volume resources to represent
      PersistentStateLineOfService fields, together with
      UsageClass="AgentPersistentState" where applicable.  Discovery
      would use Redfish resource enumeration.

   CSI:  APS hints MAY be conveyed through StorageClass parameters by
      convention, as described in Section Section 11.  A higher-level
      control plane (for example, a storage operator) is expected to map
      available backend profiles to supported StorageClasses.






Gaikwad                    Expires 4 June 2026                 [Page 13]

Internet-Draft       Agent Persistent State Profile        December 2025


   The details of profile discovery are intentionally left to existing
   management and orchestration mechanisms; APS focuses on the shape and
   semantics of individual profiles.

   Future work MAY explore bindings for object-native stores, for
   example, using object prefixes and S3 Select-like mechanisms to host
   agent state directly in object storage, based on the ObjectPrefix
   erasure scope.

13.  Versioning and Extensibility

   The ApsVersion field in PersistentStateLineOfService identifies the
   APS version the profile conforms to (for example, "1.0").

   Future versions of APS *MAY* add new OPTIONAL fields.  Profiles that
   set ApsVersion to "1.x" MUST remain backward compatible for all
   fields defined in version 1.0, and consumers *MUST* ignore unknown
   fields rather than treating them as errors.

14.  Security Considerations

   APS-compliant resources are expected to host sensitive agent state,
   including user-identifiable data and behavior-derived embeddings.
   Implementations *SHOULD* support encryption at rest, strong identity
   scoping in the control plane, and cryptographic erasure according to
   policy.

15.  Privacy Considerations

   Enterprises may need to demonstrate that agent memory for a specific
   user was deleted in accordance with regulation (for example, GDPR).
   APS provides explicit deletion semantics, an erasure scope, and a
   latency bound to support such compliance, but implementation details
   and audits remain the responsibility of the operator and any higher-
   level governance systems.

16.  Limitations and Future Work

   This document does not define a conformance test suite or reference
   implementation.  Future work MAY include tests for APS-aware CSI
   drivers, managed vector databases, and storage arrays.

   APS does not provide guidance on how agents should degrade gracefully
   when APS-compliant storage is unavailable.  Agent frameworks are
   responsible for fallback behavior (for example, operating in a
   stateless mode).





Gaikwad                    Expires 4 June 2026                 [Page 14]

Internet-Draft       Agent Persistent State Profile        December 2025


   APS does not model cost trade-offs explicitly.  Operators are
   expected to balance erase latency, replication scope, erasure scope,
   and storage-class cost.

   APS does not attempt to model differential privacy, federated
   learning, or higher-level alignment techniques.  Those may rely on
   APS semantics but are outside the scope of this profile.

   A normative JSON Schema for PersistentStateLineOfService is intended
   for a future revision to enable automated validation and tooling.

17.  IANA Considerations

   This document requests that IANA create an "APS UsageClass and
   Profile Registry" containing the following initial values:

   UsageClass:
      *  AgentPersistentState

   IOProfile:
      *  SmallRandom

      *  MixedRandom

      *  MetadataHeavy

      *  VectorIndex

   ErasureScope:
      *  Volume

      *  FilesystemTree

      *  ObjectPrefix

      *  ApplicationKey

   No additional IANA actions are required by this document.

18.  References

18.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.





Gaikwad                    Expires 4 June 2026                 [Page 15]

Internet-Draft       Agent Persistent State Profile        December 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

18.2.  Informative References

   [Swordfish]
              SNIA, "Swordfish Storage Management Specification", 2024.

   [Redfish]  DMTF, "Redfish Scalable Platforms Management API", 2024.

   [CSI]      Kubernetes Community, "Container Storage Interface (CSI)",
              2024.

Appendix A.  Example APS Profiles (Non-Normative)

   This appendix provides three example PersistentStateLineOfService
   instances.  These are illustrative and non-normative.  They are
   intended to show how capacity, performance, durability, and privacy
   settings can be combined for common agent scenarios.

A.1.  APS-Standard (Checkpoint-Oriented)

   APS-Standard is intended for general agent checkpointing and short-
   to medium-term memory.  It favors small random I/O, moderate
   capacity, and relatively tight tail latency so that frequent state
   saves do not break conversational responsiveness.  The 8 KiB
   recommended I/O size and 3000 IOPS target are representative of a
   busy checkpointing workload where many agents periodically flush
   small state blobs or logs.





















Gaikwad                    Expires 4 June 2026                 [Page 16]

Internet-Draft       Agent Persistent State Profile        December 2025


   PersistentStateLineOfService {
     ApsVersion: "1.0"
     Id: "aps-standard-1"
     Name: "APS-Standard-Checkpoint"
     Purpose: "AgentPersistentState"

     IOProfile: SmallRandom

     CapacityRangeGiB {
       MinGiB: 5
       MaxGiB: 100
       RecommendedStepGiB: 5
     }

     Performance {
       MinIOPS: 3000
       MaxLatencyMsP95: 20
       MaxLatencyMsP99: 50
       RecommendedIOSizeKiB: 8
     }

     Durability {
       DurabilityClass: High
       ReplicationScope: MultiAZ
     }

     CrashConsistency {
       RequiresWriteOrdering: true
     }

     Retention {
       RetentionDays: 30
       ForgettingPolicySupported: true
     }

     Privacy {
       ContainsUserFacingDataExpected: true
       MinDeletionSemantics: CryptographicErase
       ErasureScope: Volume
       MaxEraseLatencyHours: 24
     }

     ConcurrencyHints {
       AdvisoryLockingSupported: true
     }
   }





Gaikwad                    Expires 4 June 2026                 [Page 17]

Internet-Draft       Agent Persistent State Profile        December 2025


A.2.  APS-Vector (Embedding-Heavy)

   APS-Vector is intended for embedding-heavy and index-heavy agent
   workloads.  It assumes larger capacity, higher IOPS, and a
   RecommendedIOSizeKiB of 32 KiB to reflect typical vector segment
   sizes during scan-oriented operations.  It disables advisory locking
   hints because many vector index implementations use append-only or
   copy-on-write designs and do not rely on traditional filesystem
   locking semantics for concurrency control.  The VectorPhase field is
   set to indicate that this profile is tuned primarily for read-heavy
   query traffic.








































Gaikwad                    Expires 4 June 2026                 [Page 18]

Internet-Draft       Agent Persistent State Profile        December 2025


   PersistentStateLineOfService {
     ApsVersion: "1.0"
     Id: "aps-vector-1"
     Name: "APS-Vector-Index"
     Purpose: "AgentPersistentState"

     IOProfile: VectorIndex
     VectorPhase: Query

     CapacityRangeGiB {
       MinGiB: 50
       MaxGiB: 2000
       RecommendedStepGiB: 50
     }

     Performance {
       MinIOPS: 8000
       MaxLatencyMsP95: 25
       MaxLatencyMsP99: 80
       RecommendedIOSizeKiB: 32
     }

     Durability {
       DurabilityClass: VeryHigh
       ReplicationScope: MultiRegion
     }

     CrashConsistency {
       RequiresWriteOrdering: true
     }

     Retention {
       RetentionDays: 90
       ForgettingPolicySupported: true
     }

     Privacy {
       ContainsUserFacingDataExpected: true
       MinDeletionSemantics: CryptographicErase
       ErasureScope: FilesystemTree
       MaxEraseLatencyHours: 48
     }

     ConcurrencyHints {
       AdvisoryLockingSupported: false
     }
   }




Gaikwad                    Expires 4 June 2026                 [Page 19]

Internet-Draft       Agent Persistent State Profile        December 2025


A.3.  APS-Light (BestEffort / ApplicationKey)

   APS-Light illustrates deployments that rely on application-managed
   keys or do not require strict retention or erase guarantees.
   Suitable for experimentation, low-risk workloads, or sidecar-based
   encryption designs where the storage layer itself does not enforce
   cryptographic erase.












































Gaikwad                    Expires 4 June 2026                 [Page 20]

Internet-Draft       Agent Persistent State Profile        December 2025


   PersistentStateLineOfService {
     ApsVersion: "1.0"
     Id: "aps-light-1"
     Name: "APS-Light-Experiment"
     Purpose: "AgentPersistentState"

     IOProfile: MixedRandom

     CapacityRangeGiB {
       MinGiB: 1
       MaxGiB: 200
       RecommendedStepGiB: 1
     }

     Performance {
       MinIOPS: 500
       MaxLatencyMsP95: 40
       MaxLatencyMsP99: 120
       RecommendedIOSizeKiB: 4
     }

     Durability {
       DurabilityClass: Standard
       ReplicationScope: LocalAZ
     }

     CrashConsistency {
       RequiresWriteOrdering: false
     }

     Retention {
       RetentionDays: 7
       ForgettingPolicySupported: false
     }

     Privacy {
       ContainsUserFacingDataExpected: false
       MinDeletionSemantics: BestEffort
       ErasureScope: ApplicationKey
       MaxEraseLatencyHours: 24
     }

     ConcurrencyHints {
       AdvisoryLockingSupported: false
     }
   }





Gaikwad                    Expires 4 June 2026                 [Page 21]

Internet-Draft       Agent Persistent State Profile        December 2025


Author's Address

   Madhava Gaikwad
   Email: gaikwad.madhav@gmail.com















































Gaikwad                    Expires 4 June 2026                 [Page 22]


name: draft-williams-http-bearer-extension
rev: 00
title: HTTP Bearer Auth Method Extensions
time: 2025-12-03T19:18:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-06T19:18:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864830+00:00
abstract:
This document specifies an improved HTTP 401 and 407 flow for Bearer
   authentication where user-agents (or client applications) can
   automatically fetch requested tokens from a Security Token Service
   (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
   included.

   This improved 401/407 Bearer flow, when used, elides the need for
   Proof Key for Code Exchange (PKCE) and does not impose on application
   Universal Resource Identifier (URI) query parameter design.  As well
   this extension allows for user-agent caching of tokens.

full_text:
HTTP                                                         N. Williams
Internet-Draft                                           3 December 2025
Intended status: Standards Track                                        
Expires: 6 June 2026


                   HTTP Bearer Auth Method Extensions
                draft-williams-http-bearer-extension-00

Abstract

   This document specifies an improved HTTP 401 and 407 flow for Bearer
   authentication where user-agents (or client applications) can
   automatically fetch requested tokens from a Security Token Service
   (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
   included.

   This improved 401/407 Bearer flow, when used, elides the need for
   Proof Key for Code Exchange (PKCE) and does not impose on application
   Universal Resource Identifier (URI) query parameter design.  As well
   this extension allows for user-agent caching of tokens.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-williams-http-bearer-
   extension/.

   Discussion of this document takes place on the NETWORK Working Group
   mailing list (mailto:ietf-http-wg@w3.org), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/nicowilliams/http-bearer-ext.

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





Williams                   Expires 6 June 2026                  [Page 1]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   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 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.  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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Automation of Bearer  . . . . . . . . . . . . . . . .   3
       1.1.2.  Making OAuth, OIDC, and SAML not Camp on URI
               Design  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.3.  Reducing Load on Token Issuers by Facilitating Token
               Caching . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.4.  Enabling the Use of Bearer for Proxy Auth . . . . . .   4
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
   2.  Extended 401 WWW-Authenticate: Bearer Flow  . . . . . . . . .   5
     2.1.  Example flow  . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Server Response Type Selection  . . . . . . . . . . . . .   8
     2.3.  User-Agent Use  . . . . . . . . . . . . . . . . . . . . .   9
     2.4.  Client Application Use  . . . . . . . . . . . . . . . . .   9
     2.5.  Mapping realm to issuer . . . . . . . . . . . . . . . . .   9
     2.6.  Token Caching . . . . . . . . . . . . . . . . . . . . . .  10
   3.  Extended Redirect Flow  . . . . . . . . . . . . . . . . . . .  10
   4.  Negotiation of 401 vs Redirect Flows  . . . . . . . . . . . .  11
   5.  Local Policy  . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  New fields  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  New auth-params . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Wider Applicability: Negotiate Auth w/o GSS or Kerberos
           Implementations!  . . . . . . . . . . . . . . . . . . . .  12
   9.  Single Sign-On  . . . . . . . . . . . . . . . . . . . . . . .  13
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13



Williams                   Expires 6 June 2026                  [Page 2]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     10.1.  HTTP Field Registrations . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   HTTP [HTTP] has a number of authentication methods available,
   including Bearer [BEARER] that uses OAuth 2.0 [OAUTH2], which is the
   subject of this document.  Some HTTP authentication methods, like
   Negotiate [NEGOTIATE], allow the user-agent to automatically respond
   to a 401 or 407 status response when possible by creating a token
   locally using the GSS-API [GSSAPI], typically using Kerberos
   [KERBEROS].  However, the Bearer method effectively requires that the
   client application respond to the 401/407 authentication request
   rather than the HTTP user-agent, and it provides little metadata that
   either can use to figure out how to obtain a Bearer token.  Today an
   OAuth application just has to know how to obtain the Bearer token,
   and has to be configured appropriately, and this greatly limits the
   applicability of the 401/407 flows.

   Note that we will mostly refer to 401 flows here, but everything that
   applies to 401 flows also applies to 407 flows.

   Here we specify extension auth-params to the 401 WWW-Authenticate:
   Bearer HTTP response so that either the client application or the
   user-agent can figure out how to obtain the requested token after
   applying local policy.

   As well we provide a way to improve the OIDC redirect flow to make
   use of this extension where possible, and this provides a migration
   path to a world where URI q-param camping and PKCE [PKCE] and code-
   to-token conversions are no-longer needed just to use OAuth 2.x.

   The extended Bearer 401 flow presented here is a glorified redirect
   that avoids the need for camping on the application's URI q-params.

1.1.  Motivation

1.1.1.  Automation of Bearer

   In general it would be better for user-agents to know how to execute
   HTTP auth methods, and generally they do, except for Bearer, where
   they often only know when the application has provided the user-agent
   with a token ahead of it being needed.



Williams                   Expires 6 June 2026                  [Page 3]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   Some user-agents, such as for example (at the time of this writing)
   curl, do not support redirect flows quite well enough.  This causes
   users to work around these limitations by, for example, scripting
   around these user-agents' limitations.

   In order to make such user-agents automatically fetch tokens we want
   improve the 401 Bearer flow so that the user-agent can learn where
   and how to acquire a token.  This necessitates OPTIONAL local policy,
   but only because some such user-agents do not enable redirect
   following by default, whereas browser-type user-agents chase
   redirects by default.

1.1.2.  Making OAuth, OIDC, and SAML not Camp on URI Design

   Besides automatic Bearer token fetching in tools such as curl there
   is also the desire to not impose on application URI design.

1.1.3.  Reducing Load on Token Issuers by Facilitating Token Caching

   By making auth requests a first-class operation (by using 401 where
   possible instead of a redirect) and the user-agent responsible for
   executing auth request we make it possible for the user-agent to
   cache tokens during their remaining lifetime.  This allows for a
   significant reduction in issuer load in some cases.

   The token cache can be in-memory or stored in local storage (e.g., a
   local filesystem) for sharing among the user's non-browser
   applications, further reducing issuer load.

1.1.4.  Enabling the Use of Bearer for Proxy Auth

   Currently Bearer cannot be used for proxy auth (407) in browsers as
   browsers do not know how to fetch the required token.

   For many users this means being stuck with the New Technology LAN
   Manager (NTLM) mechanism via Negotiate [NEGOTIATE], or Kerberos
   [KERBEROS] via Negotiate, or SCRAM [SCRAM].  But NTLM is weak and
   dangerous, Kerberos is often seen as legacy that one should be able
   to avoid, and SCRAM requires passwords and thus is not a single-sign-
   on solution.

   Maintaining infrastructure for many auth methods is a burden on
   operators.  Operators would like to reduce that burden.  And many
   operators want to be able to use OAuth as the primary or only auth
   method.  But there is a long tail of work to do to make OAuth a
   replacement for Kerberos.  Proxy auth is part of that long tail, thus
   by eliminating that part of the long tail we make the tail shorter.




Williams                   Expires 6 June 2026                  [Page 4]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


1.2.  Notational Conventions

   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.

2.  Extended 401 WWW-Authenticate: Bearer Flow

   Currently the following auth-params are supported in a 401 response
   with WWW-Authenticate=Bearer:

   *  realm

   *  scope

   *  error

   *  error_description

   *  error_uri

   We add the following additional, OPTIONAL auth-params:

   *  issuer with a URI as a value

   *  server_token_type with a token type Universal Resource Name (URN)
      as a value

   *  server_token with a token to be forwarded to the issuer by the
      user-agent or client application

   *  state with a "state" value -- this corresponds to the OIDC state
      q-param in a redirect to the OpenID provider

   The issuer parameter allows the user-agent or client application to
   discover the URI of a Security Token Service (STS) to visit to get a
   token.  Though of course a user-agent or client application could map
   a realm auth-param value to an STS URI, or even the realm could
   consist of an issuer URI, however by having an auth-param intended to
   carry an issuer URI we avoid ambiguities about the meaning of
   "realm".








Williams                   Expires 6 June 2026                  [Page 5]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   The server_token auth-param allows the server to pass a cryptographic
   token to the issuer via the user-agent's or client application's
   subsequent request to the issuer.  The user-agent or client
   application will set a new requested header Token-Request-Pref to the
   value in the 401 response's server_token auth-param.

   Essentially this functions like a redirect response, but with a 401
   status code and with the Server-Token and Server-Token-Type carrying
   the token and token type from the server_token and server_token_type
   auth-params respectively, if present.

   The user-agent and/or client application MUST apply local policy,
   where any is set, as to whether to execute a token request against
   the requrested issuer.

   When making the token request to the issuer the user-agent or client
   application MUST also set the following fields:

   *  Referer, as if the 401 response had been a redirect

   *  a new Token-Request header to indicate that the request is in
      response to an extended Bearer token request by the server

   *  Token-Request-Token, set to the token from the server_token auth-
      param, if present

   When making the token request to the issuer the user-agent or client
   application SHOULD also set the following fields:

   *  Token-Request-Auth-Params, with all auth-params other than the
      issuer and server_token parameters.

   When the STS supports this feature then a successful response MUST be
   a 200 status code response if successful rather than a 3xx redirect
   response, with a field Location field set to the value of the Token-
   Request-URI field (if present) from the request to the STS and with
   the issued token in the response body.

   The value forms of these headers are specified below (Section 6).

2.1.  Example flow

   Request to https://some.origin.example/some/resource:

   GET /some/resource HTTP/1.1
   Host: some.origin.example





Williams                   Expires 6 June 2026                  [Page 6]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   Here the user-agent or client MAY use a new field, Token-Request-
   Pref, to indicate a preference for 401 or 3xx flows.  Not specifying
   a preference allows the server to honor that preference instead of
   having to guess it from fingerprinting the user-agent.

   The server may not support this feature, in which case it will either
   use an unextended 401 WWW-Authenticate: bearer or a 3xx OIDC redirect
   flow.  Here we show the server responding with an extended 401 WWW-
   Authenticate: Bearer:

   HTTP/1.1 401 Authentication required
   WWW-Authenticate: Negotiate
   WWW-Authenticate: Bearer issuer=https://iam.foo.example/v1/token
           scope=read:some/resource
           server_token=Bearer:<some-JWT>

   Token request to STS:

   POST /v1/token
   Host: iam.foo.example
   Token-Request-Auth-Params: scope=read:some/resource
   Token-Request-Token: Bearer:<some-JWT>
   Token-Request-URI: https://some.origin.example/some/resource

   grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
   audience=some.origin.example&
   scope=read:some/resource&
   ...

   The token request to the STS may elicit a 401 response instructing
   the user-agent or client application to authenticate in some manner.
   For example, an STS might use Bearer with a "token granting token"
   that the user-agent just has to have a priori (how such a token-
   granting-token is acquired and refreshed is out of scope for this
   document), and/or it might use Negotiate, Basic, or other
   authentication methods.  The user-agent or client application might
   also be configured to know which authentication methods a given
   issuer might require and thus "pre-flight" an Authorization field in
   the token request to the STS.  We elide the 401 and retry here for
   brevity.

   It is also possible that an STS might issue a redirect or extended
   401 flow to another STS.  This too is elided here, but the user-agent
   MUST save the state from the first token request, process the second,
   return to the first STS, and retry the first request with the newly
   acquired credential.





Williams                   Expires 6 June 2026                  [Page 7]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   Thus after any authentication exchanges, a successful response from
   the STS if it supports this feature is a 200 Ok response with a
   Location field to remind the user-agent or client its state (but the
   user-agent or client MUST recall this metadata anyways):

   HTTP/1.1 200 Ok
   Location: https://some.origin.example/some/resource

   <token>

   XXX Well, perhaps we should dispense with the Location field here
   given that we require the user-agent/client to know that anyways.

   XXX It might be desirable to allow the STS to tell the user-agent to
   set some select fields in its return request to the origin, perhaps
   headers named Token-Response* or specifically Authorization.

   Otherwise if the STS does not support this feature but it would issue
   the token then it should issue a code and respond with a redirect as
   in an OIDC redirect flow:

   HTTP/1.1 302 Found
   Location: https://some.origin.example/some/resource?code=..&state=..

   The user-agent or client MUST remember the URI in case the STS
   responds with 200 Ok with the token as the response body and without
   a Location field.

   Armed with the requisite token (if it was issued), the user-agent/
   client SHOULD retry the original request with the Authorization field
   set to Bearer <token> with the token returned by the STS.

   Note that the extended Bearer 401 flow MUST NOT change the browser's
   window location when the user-agent is a browser.  Instead the user-
   agent MUST execute the STS request and then retry the original
   request (if the STS response is successful) in the same sort of way
   that it would perform any Kerberos KDC exchanges had the selected
   HTTP authentication method been Negotiate [NEGOTIATE], that is: the
   STS interaction MUST NOT be visible to any scripts on the web page
   that produced the 401 response.

2.2.  Server Response Type Selection

   When a server needs the client to authenticate or obtain a new access
   token (with different scopes), it can respond with a 3xx redirect or
   a 401.  The server needs to be able to decide which to use.





Williams                   Expires 6 June 2026                  [Page 8]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   When the client includes a Token-Request-Pref field in its request,
   the server that supports extended 401 flows SHOULD use the client's
   preference.

   Otherwise the server should use local configuration, possibly
   including user-agent fingerprinting (such as by user-agent substring
   matching), to pick a response type.  When the user-agent is
   interactive the server can return a 401 with a body with a script
   that will load a page that will trigger an OIDC redirect flow,
   possibly after a few seconds, or with a link that the user can click
   on.  Or the server can expose a way for the user to choose the flow
   to use, though this presumably will not usually be done except for
   debugging or demonstration purposes.

2.3.  User-Agent Use

   Ideally user-agents will implement the 401 flow, but typically they
   will not include the Token-Request-Pref field in their requests,
   either at all or unless configured to do so (possibly only for some
   sites).

   Reasons for not including the Token-Request-Pref field include:

   *  avoiding request bloat

   *  avoiding fingerprinting

   User-agents SHOULD be configurable, possibly using a list of sites
   and domainname stems for selecting when to include this header.

2.4.  Client Application Use

   Client applications can also implement the extended 401 flow as they
   would a regular unextended 401 flow.

   As with user-agents, when it is the client application that
   implements the extended 401 flow the application SHOULD have local
   policy and configuration.

2.5.  Mapping realm to issuer

   For the non-extended 401 case, user-agents and clients can be
   configured to map the realm auth-param to an issuer, and engage in
   the extended 401 flow anyways.







Williams                   Expires 6 June 2026                  [Page 9]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


2.6.  Token Caching

   Where a user-agent or client application implements this extended
   Bearer 401 flow it can and SHOULD also implement some sort of token
   cache to alleviate load on STSes and to improve availability.
   Proxies, however, should never cache token request responses, and the
   STS SHOULD set the Cache-Control field accordingly to include the the
   following directives:

   *  no-cache, unqualified

   *  max-age set to the number of seconds after which the token should
      not be used due to impending expiration

   *  s-maxage=0 so as to reinforce that shared caches must not cache
      this token

   If the Cache-Control is absent then the user-agent or client MAY
   infer:

   *  no-cache, unqualified

   *  max-age with any lifetime it can glean from the token if that
      metadata is unencrypted in the token

   Similarly, if Cache-Control but no-cache is absent then the user-
   agent or client MAY infer it, and if max-age is absent then the user-
   agent or client MAY infer it as well.

3.  Extended Redirect Flow

   The extended redirect flow has a normal 3xx response from the server
   but with the WWW-Authenticate field present, possibly including new
   auth-params.

   Note well that some user-agents terminate 3xx response processing as
   soon as they see the expected Location field, and thus may not see a
   WWW-Authenticate field if it comes after, and note that proxies are
   allowed to reorder fields (but not field values for multi-valued
   fields), therefore it is not possible for a server to reliably count
   on the WWW-Authenticate field being seen by the client.

   Still, when a client sees the WWW-Authenticate field then it SHOULD
   act as though the response was a 401 response engaging in an extended
   OAuth 401 flow.






Williams                   Expires 6 June 2026                 [Page 10]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


4.  Negotiation of 401 vs Redirect Flows

   A server may only support redirect flows, only 401 flows, or it may
   support negotiation as described here.  Ideally all servers will
   eventually support negotiation, and/or all user-agents will support
   the extended Bearer 401 flow.

   The Token-Request-Pref field has two values: 401 and redirect.  When
   present the server SHOULD use the expressed preference if it needs a
   new token.

   When this field is absent the server must choose a response type
   using configuration and user-agent fingerprinting.

5.  Local Policy

   Local policy is OPTIONAL.  When present, local policy expresses:

   *  whether to enable automatic token request handling when using the
      extended Bearer 401 flow

   *  allow lists for issuers and/or realms

   *  mappings of realms to issuers

   *  authentication methods to allow at each issuer, if any

   *  global and site-specific flow type preferences, and whether to
      express those flow type preferences via the Token-Request-Pref
      field

   *  for each allowed issuer optionally record its authentication
      method preferences so that the user-agent or client application
      may pre-flight an Authorization field in the token requests to
      that issuer

6.  New fields

   *  Token-Request-Pref is a structured field of kind Item with a value
      of "401" or "redirect"

   *  Token-Request is a structured field of kind Item with a value of
      "true" if present

   *  Token-Request-Token is a structured field of kind Item with a
      token as its value





Williams                   Expires 6 June 2026                 [Page 11]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   *  Token-Request-Auth-Params is a structured field of kind List with
      the 401 response's auth-params from the WWW-Authenticate: Bearer
      field

   *  Token-Request-URI is a field of kind Item containing the URI that
      requested the token

7.  New auth-params

   *  issuer

   *  server_token_type

   *  server_token

   *  state

   See section 2 (Section 2) for details.

8.  Wider Applicability: Negotiate Auth w/o GSS or Kerberos
    Implementations!

   This section is INFORMATIONAL.

   A similar extension design can be applied to the Negotiate HTTP auth
   method that would allow user-agents to support Negotiate without
   having a local implementation of the GSS-API [GSSAPI], Kerberos
   [KERBEROS], or other GSS mechanisms.  All that would be needed is an
   STS-like service that itself can issue Kerberos tickets or can
   impersonate users to a Kerberos Key Distribution Center (KDC) and
   thus obtain tickets on their behalf, then the STS can mint GSS-API
   tokens for the Kerberos mechanism [GSSKRB5].  The rest of the flow
   would be remarkably similar to the extended Bearer 401 flow.

   An implementation of such an Negotiate token issuer could have a
   certification authority credential to mint user certificates for use
   with PKINIT [PKINIT] to impersonate users to a Kerberos KDC.  Thus
   such a service would not need intimate access to the KDC's key
   database, and can be interoperate with any KDC implementation that
   supports PKINIT.  In all cases such a service would be as security-
   sensitive as a KDC, and would best be seen as part of the KDC, and
   for discovery purposes should probably be co-located with the KDC.

   As in the case of Bearer an issuer URI auth-param for Negotiate might
   be useful, though perhaps the user will have to have selected an
   issuer from a server-provided list of choices.  In the case of
   Kerberos, for example, the choice of token issuer will be dependent
   on the user's credentials' issuer, thus local configuration at the



Williams                   Expires 6 June 2026                 [Page 12]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   user-agent will be the best source of an issuer value for a Negotiate
   401 flow that resembles the extended Bearer 401 flow.  But even in
   the case of Kerberos if the user-agent can help the server include
   the correct issuer auth-param value then the flow can work in spite
   of the lack of local configuration.

9.  Single Sign-On

   This section is INFORMATIVE.

   When engaging in an OIDC or SAML redirect flow, or an extended
   401/407 flow as in this document, ultimately the user-agent, the
   client, and/or the user will have to authenticate the user to an
   issuer.  How that is done initially (e.g., with passwords, smartcards
   and PINs, etc.) is out of scope here, but for Single Sign-On (SSO)
   one will want to distinguish between "initial authentication" and
   non-initial authentication (i.e., _not_ passwords, smartcards, PINs,
   etc.), much like Kerberos [KERBEROS] does.  A user-agent could use
   cookies, or a "token-granting token" (similar to a Kerbero ticket-
   granting ticket, both sharing the same acronym of 'TGT') to
   repeatedly authenticate to an issuer for a limited time after which
   the user has to once again engage in "initial authentication".

10.  IANA Considerations

   As there is no registry of HTTP auth method auth-params, we do not
   register any of the new auth-params created here.  However, it might
   be desirable to create such a registry before this document's
   publication as an RFC.

   This document registers several new HTTP fields listed below.

10.1.  HTTP Field Registrations

   *  Field Name: Token-Request-Pref

      Status: permanent

      Structured Type: Item

      Reference: this document

   *  Field Name: Token-Request

      Status: permanent

      Structured Type: Item




Williams                   Expires 6 June 2026                 [Page 13]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


      Reference: this document

   *  Field Name: Token-Request-Token

      Status: permanent

      Structured Type: Item

      Reference: this document

   *  Field Name: Token-Request-Auth-Params

      Status: permanent

      Structured Type: Item

      Reference: this document

   *  Field Name: Token-Request-URI

      Status: permanent

      Structured Type: Item

      Reference: this document

11.  Security Considerations

   Existing user-agents that support redirect flows usually trust all
   redirects.  As a result we make local policy OPTIONAL for use in the
   automatic the extended Bearer 401 flow.  The specification of an
   "abstract schema" for local policy is an improvement.

   User-agents such as browsers MUST NOT allow scripts embedded or
   injected into web pages to access to the STS responses from extended
   Bearer 401 flow.  This is already the case, thus this requirement is
   not a new requirement and does not impose on other working groups or
   standards development organizations.

   Apart from the above this document does not add new security
   considerations beyond those of OAuth and OIDC, but it does remove the
   need for "codes" and PKCE [PKCE] by not abusing URI q-params to carry
   tokens or token-like "codes", instead carrying tokens only in the
   Authorization field and in the STS response body invisible to scripts
   on web pages.  As well by not abusing URI q-params no sensitive
   cryptographic material such as "codes" and tokens can end up in user-
   agent history nor in client- or server-side logs.




Williams                   Expires 6 June 2026                 [Page 14]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   Thus this extended Bearer 401 flow is strictly an improvement in
   security for OAuth.

   But note that when the server does not implement the extended Bearer
   401 flow then a fallback to a redirect flow may happen, thus user-
   agents and/or clients still need to implement PKCE [PKCE].

12.  References

12.1.  Normative References

   [BEARER]   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/info/rfc6750>.

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

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

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

12.2.  Informative References

   [GSSAPI]   Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743,
              DOI 10.17487/RFC2743, January 2000,
              <https://www.rfc-editor.org/info/rfc2743>.

   [GSSKRB5]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              DOI 10.17487/RFC4121, July 2005,
              <https://www.rfc-editor.org/info/rfc4121>.





Williams                   Expires 6 June 2026                 [Page 15]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


   [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <https://www.rfc-editor.org/info/rfc4120>.

   [NEGOTIATE]
              Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
              Kerberos and NTLM HTTP Authentication in Microsoft
              Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
              <https://www.rfc-editor.org/info/rfc4559>.

   [PKCE]     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/info/rfc7636>.

   [PKINIT]   Zhu, L. and B. Tung, "Public Key Cryptography for Initial
              Authentication in Kerberos (PKINIT)", RFC 4556,
              DOI 10.17487/RFC4556, June 2006,
              <https://www.rfc-editor.org/info/rfc4556>.

   [SCRAM]    Melnikov, A., "Salted Challenge Response HTTP
              Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
              March 2016, <https://www.rfc-editor.org/info/rfc7804>.

Appendix A.  Acknowledgements

Author's Address

   Nico Williams
   Austin
   United States
   Email: nico@cryptonector.com


















Williams                   Expires 6 June 2026                 [Page 16]


name: draft-schulze-ecap
rev: 00
title: The Ethical Crawler Agreement Protocol (ECAP)
time: 2025-12-10T10:41:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-13T10:41:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:06.864836+00:00
abstract:
This document specifies the Ethical Crawler Agreement Protocol (ECAP),
   an application-layer protocol for managing consent and ethical
   verification between web hosts and automated agents (crawlers, AI
   scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
   cryptographic signatures and a declarative policy handshake to ensure
   verifiable, consent-based access to web resources.

full_text:
Internet-Draft                                         A. Schulze-Hueneke
Intended status: Experimental                                   JamOne-DE
Expires: June 13, 2026                                  December 10, 2025


              The Ethical Crawler Agreement Protocol (ECAP)
                         draft-schulze-ecap-00

Abstract

   This document specifies the Ethical Crawler Agreement Protocol (ECAP),
   an application-layer protocol for managing consent and ethical
   verification between web hosts and automated agents (crawlers, AI
   scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
   cryptographic signatures and a declarative policy handshake to ensure
   verifiable, consent-based access to web resources.

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 June 13, 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.  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.  Terminology
   3.  Protocol Overview
   4.  The ECAP Handshake
   5.  Data Formats
       5.1.  HTTP Headers
       5.2.  Policy File
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
   Author's Address

1.  Introduction

   The proliferation of automated agents, particularly for AI training
   and data harvesting, has rendered traditional access control
   mechanisms like robots.txt insufficient.  ECAP proposes a new
   standard where access is negotiated via a cryptographic handshake,
   ensuring that agents explicitly declare their intent and hosts
   explicitly grant consent.

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.

   Agent:  The automated client initiating the request.
   Host:   The server hosting the resource.
   Intent: The declared purpose of the data access (e.g., "research").

3.  Protocol Overview

   ECAP operates over HTTP/1.1 or HTTP/2.  It introduces a set of
   headers and a well-known policy file located at
   "/.well-known/ecap-policy".

4.  The ECAP Handshake

   The handshake consists of the following steps:

   1.  The Agent requests "/.well-known/ecap-policy".
   2.  The Host returns the JSON policy containing allowed intents and
       a public key.
   3.  The Agent sends a signed request to the protected resource using
       ECAP headers.
   4.  The Host verifies the signature and intent against its policy.
   5.  The Host responds with "210 Accepted" or an appropriate error
       code (e.g., "403E Ethical Denied").

5.  Data Formats

5.1.  HTTP Headers

   This document defines the following HTTP headers:

   ECAP-Agent-ID:  A unique identifier for the crawler (e.g., email).
   ECAP-Intent:    The purpose of the crawl (e.g., "indexing").
   ECAP-Signature: Ed25519 signature of the request metadata.
   ECAP-Timestamp: ISO 8601 timestamp to prevent replay attacks.

5.2.  Policy File

   The policy file MUST be a JSON document containing version, allowed
   intents, and cryptographic material.

6.  Security Considerations

   Implementations MUST use secure signature algorithms (Ed25519 recommended).
   Hosts MUST validate timestamps to prevent replay attacks (max skew
   +/- 60 seconds).

7.  IANA Considerations

   This document requests the registration of the HTTP headers listed
   in Section 5.1 in the "Permanent Message Header Field Names" registry.

8.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017.

Author's Address

   Adnan Schulze-Hueneke
   JamOne-DE
   Schwuelper
   Germany

   Email: hallo@jamone.de
   URI:   https://ecap-protocol.com


name: draft-li-dmsc-mcps-agw
rev: 00
title: Multi-agent Collaboration Protocol Suite based on Agent Gateway
time: 2026-02-06T00:50:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-10T00:50:23Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864838+00:00
abstract:
This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as control-plane entities responsible for agent registration,
   authentication, capability management, semantic routing and other
   functions, while preserving direct peer-to-peer semantic interactions
   among agents.

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


    Multi-agent Collaboration Protocol Suite based on Agent Gateway
                       draft-li-dmsc-mcps-agw-00

Abstract

   This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as control-plane entities responsible for agent registration,
   authentication, capability management, semantic routing and other
   functions, while preserving direct peer-to-peer semantic interactions
   among agents.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 August 2026.

Copyright Notice

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










Li                        Expires 9 August 2026                 [Page 1]

Internet-Draft                  MCPS-AGW                   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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Multi-Agent Collaboration Protocol Suite Overview . . . . . .   3
     4.1.  Agent Registration and Authorization Process  . . . . . .   5
     4.2.  Capability Digest and Synchronization Process . . . . . .   5
     4.3.  Semantic Resolution and Routing Process . . . . . . . . .   6
     4.4.  Task-based Multi-Agent Invocation Process . . . . . . . .   6
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   As multi-agent systems become increasingly distributed across
   heterogeneous networks and administrative domains, efficient, secure,
   and semantically meaningful collaboration among agents becomes a
   critical challenge.  Traditional service-oriented or message-based
   interaction models are insufficient to capture agent-level
   capabilities, dynamic task decomposition, and semantic intent-driven
   communication.

   This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway (AGW).  The suite defines a set of coordinated
   protocols that enable agent registration, authentication, capability
   synchronization, semantic routing, task-based invocation, and peer-
   to-peer semantic interaction.  The architecture leverages Agent
   Gateways as first-class network entities that mediate control, policy
   enforcement, and orchestration, while allowing agents to directly
   exchange semantic information once authorized.

   The protocol suite is aligned with the architectural principles of
   control/forwarding plane separation, least-privilege authorization,
   and session-scoped semantic communication.




Li                        Expires 9 August 2026                 [Page 2]

Internet-Draft                  MCPS-AGW                   February 2026


2.  Conventions used in this document

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

3.  Terminology

   The following terms are defined in this draft:

   *  AGW: Agent Gateway.  A network-resident control and forwarding
      entity responsible for agent registration, local binding,
      capability management, semantic routing, and policy enforcement.

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

   *  Semantic Routing: The process of routing an Agent request based on
      the meaning or intent of the request, rather than solely on a pre-
      defined address or identifier.

   *  Central Auth: Central Authentication Service: A logically
      centralized authority that performs identity verification and
      authorization decisions for agents and gateways.

4.  Multi-Agent Collaboration Protocol Suite Overview

   The Multi-Agent Collaboration Protocol Suite based on Agent Gateway
   defines a set of coordinated protocols as shown in figure 1 that
   collectively enable secure agent onboarding, ,distributed capability
   visibility, semantic request resolution, peer-to-peer semantic
   interaction, and task-oriented multi-agent orchestration.  Rather
   than operating independently, these protocols are designed to be
   executed in a tightly coupled manner along the agent lifecycle and
   collaboration workflows.  The Agent Gateway (AGW) serves as the
   anchoring point for control-plane coordination, while semantic
   interactions are progressively delegated to agents once resolution
   and authorization are completed.

   The protocol suite consists of the following functional components::

   *  Agent Registration Protocol (ARP) and Agent Authentication and
      Authorization Protocol (AAAP), which jointly establish agent
      identity, trust, and operational scope.

   *  Capability Synchronization Protocol (CSP), which maintains
      distributed visibility of agent capability digest across gateways.




Li                        Expires 9 August 2026                 [Page 3]

Internet-Draft                  MCPS-AGW                   February 2026


   *  Semantic Resolution and Routing Protocol (SRRP), which enables
      semantic request discovery and routing across gateway domains.

   *  Task-based Invocation Protocol (TIP), which extends semantic
      routing to multi-agent task decomposition and orchestration.

   Each protocol operates at a specific phase of the collaboration
   lifecycle and may be invoked independently or in combination with
   others.  The following sections describe how these protocols are
   integrated into coherent operational flows.

 User        Agent A      AGW1          AGW3        Central Auth        AGW2        Agent B    Agent C
  |             |            |             |               |              |<--------------Register|
  |             |Register--->|             |               |              |<--Register|           |
  |             |            |--Auth Req------------------>|<---Auth Req--|           |           |     +-----------------------------+
  |             |            |<-----------------Auth Grant |--Auth Grant->|           |           |<----| Agent Registration process  |
  |             |<-Local Bind|             |               |              |           |           |     +-----------------------------+
  |             |            |             |               |              |--Local Bind (B,C)---->|
  |             |            |             |               |              |           |           |
  |             |            |             |               |              |           |           |     +-----------------------------+
  |             |            |<----------->|<-----Capa Digest and Sync -->|           |           |<----| Agent Gateway Interaction   |
  |             |            |             |               |              |           |           |     +-----------------------------+
  |             |            |             |               |              |           |           |
  |             |            |             |               |              |           |           |
  |             |            |             |               |              |           |           |
  | --Req-----> |-SemR Req-->|             |               |              |           |           |
  |             |            |             |               |              |           |           |
  |             |            |---SemR Req->|----------------------------->|           |           |
  |             |            |<------------|<------SemR Resp--------------|           |           |
  |             |<-SemR Resp |             |               |              |           |           |     +-----------------------------+
  |             |============================ Semantic Session========================|           |<----| Semantic Routing process    |
  |             |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|           |     +-----------------------------+
  |             |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<|           |
  |             |            |             |               |              |           |           |
  |             |            |             |               |              |           |           |
  |             |            |             |               |              |           |           |
  |--Task Req-->|               +-----------------------------+           |           |           |
  |             | ---------->   | Semantic Routing process    |---------->|           |           |
  |             |               + ----------------------------+           |           |           |     +-----------------------------+
  |             |--------------------------------------Invoke------------------------------------>|<----|Task-based Invocation process|
  |             |<--------------------------------------Executing---------------------------------|     +-----------------------------+
  |             |            |             |               |              |           |           |

                           Figure 1 The overall sequence diagram of MCPS-AGW







Li                        Expires 9 August 2026                 [Page 4]

Internet-Draft                  MCPS-AGW                   February 2026


4.1.  Agent Registration and Authorization Process

   An agent MUST register with its locally attached Agent Gateway before
   participating in any collaboration.  This process is governed jointly
   by ARP and AAAP and establishes the agent’s identity, trust status,
   and capability binding.  Upon receiving a registration request, the
   Agent Gateway performs preliminary validation of the agent’s identity
   attributes and initial capability description, and creates a
   provisional local binding.  The gateway then initiates an
   authentication and authorization request to the Central
   Authentication Service, conveying the agent identity, gateway
   identity, and requested operational scope.

   The Central Authentication Service evaluates the request and returns
   an authorization grant or denial.  Upon successful authorization, the
   Agent Gateway finalizes the registration by assigning the agent a
   globally unique Agent Identifier and Capability Identifier(s).  An
   agent MUST NOT be considered active, discoverable, or invocable until
   this process completes successfully.  This combined registration and
   authorization procedure ensures that all subsequent semantic routing
   and task invocation operate on authenticated identities and policy-
   approved capability scopes.

4.2.  Capability Digest and Synchronization Process

   Each Agent Gateway maintains detailed capability information only for
   its locally registered agents.  Gateways do not synchronize full
   agent capability states with each other.  Instead, to support inter-
   gateway semantic resolution, gateways exchange capability digests
   using the Capability Synchronization Protocol (CSP).  A capability
   digest is a locally generated, abstract summary of available
   capabilities, designed solely to indicate what kinds of capabilities
   exist behind a gateway, rather than how those capabilities are
   internally implemented or executed by agents.The structure and
   semantics of capability digests are intentionally decoupled from
   agent-internal capability representations, allowing gateways to
   evolve local capability models without impacting inter-gateway
   interoperability.

   CSP distributes these capability digests incrementally.  An initial
   exchange establishes basic inter-gateway visibility, while subsequent
   updates convey only digest changes, such as newly advertised
   capabilities, capability updates, or withdrawals.  Digest updates are
   versioned and acknowledged to support consistency and conflict
   resolution.  Through this digest-based mechanism, gateways maintain a
   scalable and privacy-preserving view of distributed agent
   capabilities without requiring centralized directories or full
   capability replication.



Li                        Expires 9 August 2026                 [Page 5]

Internet-Draft                  MCPS-AGW                   February 2026


4.3.  Semantic Resolution and Routing Process

   When a user issues a request to an agent (e.g., Agent A), the agent
   abstracts the request into a semantic request and submits it to its
   locally attached Agent Gateway (AGW1).  This interaction is governed
   by the Semantic Resolution and Routing Protocol (SRRP).  Upon
   receiving the semantic request, AGW1 performs semantic parsing and
   normalization and consults its local capability directory.  If no
   matching capability identifier is found, AGW1 forwards the semantic
   request to a peer or upstream gateway (e.g., AGW3), which repeats the
   same resolution procedure.  If the request remains unresolved, it is
   further forwarded to another gateway (e.g., AGW2).

   When a gateway identifies a matching capability in its local
   directory, it generates a semantic resolution response containing the
   resolved capability identifier and the corresponding target agent
   information.  This response is propagated hop-by-hop back to the
   originating gateway and ultimately delivered to Agent A.

   Following successful resolution, Agent A and the target agent (e.g.,
   Agent B) directly establish a semantic session.  During the lifetime
   of this session, semantic data is exchanged directly between agents
   in a peer-to-peer manner, while gateways remain responsible for
   resolution, authorization scope enforcement, and security policy
   application during session establishment.

4.4.  Task-based Multi-Agent Invocation Process

   Task-based collaboration extends semantic resolution to scenarios
   requiring multiple agents and coordinated execution, as defined by
   the Task-based Invocation Protocol (TIP).  When a user initiates a
   task request, the request is delivered to Agent A, which performs
   semantic understanding of the task and decomposes it into one or more
   sub-tasks along with the required capabilities.  If Agent A does not
   possess task decomposition capabilities, its attached Agent Gateway
   MAY act as a proxy to analyze and decompose the task on behalf of the
   agent.

   For each sub-task, Agent A submits a semantic request to its local
   gateway, triggering the same multi-hop semantic resolution process
   defined by SRRP.  Unlike pure point-to-point semantic communication,
   gateways additionally apply task-level constraints, policy
   considerations, and capability selection logic to identify suitable
   target agents.

   The resolved results are returned to Agent A, which then directly
   invokes the selected agents and establishes the necessary semantic
   sessions for execution.  Through this mechanism, multiple agents can



Li                        Expires 9 August 2026                 [Page 6]

Internet-Draft                  MCPS-AGW                   February 2026


   be dynamically selected and coordinated to collaboratively execute
   complex tasks, while maintaining consistent authorization and
   security enforcement through gateway-mediated control-plane
   functions.

5.  Conclusion

   By explicitly separating control-plane functions from semantic
   interaction flows, and leveraging gateways as control-plane
   coordination points, the proposed protocol suite enables scalable and
   secure multi-agent collaboration without compromising agent autonomy.

6.  IANA Considerations

   TBD

7.  Acknowledgement

   TBD

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

Author's Address

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















Li                        Expires 9 August 2026                 [Page 7]


name: draft-romanchuk-normative-admissibility
rev: 00
title: Normative Admissibility Framework for Agent Speech Acts
time: 2026-01-06T19:35:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T19:35:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864850+00:00
abstract:
This document defines a normative framework for evaluating the
   admissibility of speech acts produced by autonomous agents in goal-
   directed activity.  The framework establishes rules for determining
   whether an agent's statement is admissible based on its modality
   (assertive, conditional, refusal, descriptive) and its grounding
   state, independent of semantic truth.

   This framework enables deterministic, auditable evaluation of agent
   contributions without requiring truth verification or semantic
   interpretation.

full_text:
Network Working Group                                       O. Romanchuk
Internet-Draft                                               Independent
Intended status: Informational                            6 January 2026
Expires: 10 July 2026


        Normative Admissibility Framework for Agent Speech Acts
               draft-romanchuk-normative-admissibility-00

Abstract

   This document defines a normative framework for evaluating the
   admissibility of speech acts produced by autonomous agents in goal-
   directed activity.  The framework establishes rules for determining
   whether an agent's statement is admissible based on its modality
   (assertive, conditional, refusal, descriptive) and its grounding
   state, independent of semantic truth.

   This framework enables deterministic, auditable evaluation of agent
   contributions without requiring truth verification or semantic
   interpretation.

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

Copyright Notice

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








Romanchuk                 Expires 10 July 2026                  [Page 1]

Internet-Draft           Normative Admissibility            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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Model Overview  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Evaluation Flow . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .   5
   4.  Statement Model . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Statement Structure . . . . . . . . . . . . . . . . . . .   5
     4.2.  Statement Admissibility Conditions  . . . . . . . . . . .   6
   5.  Modality Classification . . . . . . . . . . . . . . . . . . .   6
     5.1.  Modality Types  . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Modality Determination  . . . . . . . . . . . . . . . . .   7
     5.3.  Formal Indicators . . . . . . . . . . . . . . . . . . . .   7
   6.  Grounding Model . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  GroundSet Structure . . . . . . . . . . . . . . . . . . .   8
     6.2.  Ground Scope  . . . . . . . . . . . . . . . . . . . . . .   8
     6.3.  Strength Derivation . . . . . . . . . . . . . . . . . . .   8
     6.4.  Scope Strength Aggregation  . . . . . . . . . . . . . . .   9
     6.5.  License Derivation  . . . . . . . . . . . . . . . . . . .   9
   7.  Normative Axioms  . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Axiom A5: Prohibition of Ungrounded Assertive Claims  . .  10
     7.2.  Axiom A6: Admissibility of Refusal  . . . . . . . . . . .  10
     7.3.  Axiom A7: Conditional Admissibility . . . . . . . . . . .  11
     7.4.  Axiom A4: Grounding Requirement . . . . . . . . . . . . .  11
     7.5.  Axiom Evaluation Order  . . . . . . . . . . . . . . . . .  11
   8.  Evaluation Outcomes . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Status Values . . . . . . . . . . . . . . . . . . . . . .  11
     8.2.  Evaluation Result Structure . . . . . . . . . . . . . . .  12
   9.  Evaluation Algorithm  . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Algorithm . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.2.  Determinism Guarantee . . . . . . . . . . . . . . . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
     10.1.  Modality Detection Errors  . . . . . . . . . . . . . . .  13
     10.2.  Grounding Manipulation . . . . . . . . . . . . . . . . .  14
     10.3.  Self-Licensing Prevention  . . . . . . . . . . . . . . .  14
     10.4.  Limitations  . . . . . . . . . . . . . . . . . . . . . .  14



Romanchuk                 Expires 10 July 2026                  [Page 2]

Internet-Draft           Normative Admissibility            January 2026


   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   13. Appendix A: Rationale (Non-Normative) . . . . . . . . . . . .  15
     13.1.  Why Form-Based Evaluation  . . . . . . . . . . . . . . .  15
     13.2.  Why Modality Matters . . . . . . . . . . . . . . . . . .  15
     13.3.  Conservative Assumptions . . . . . . . . . . . . . . . .  15
     13.4.  Theoretical Foundation . . . . . . . . . . . . . . . . .  15
   14. Appendix B: Examples (Non-Normative)  . . . . . . . . . . . .  16
     14.1.  Assertive Claim with Strong Grounding  . . . . . . . . .  16
     14.2.  Assertive Claim with Weak Grounding  . . . . . . . . . .  16
     14.3.  Conditional Claim with Weak Grounding  . . . . . . . . .  16
     14.4.  Explicit Refusal . . . . . . . . . . . . . . . . . . . .  16
   15. Author's Address  . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

1.1.  Problem Statement

   Autonomous agents operating in goal-directed environments produce
   statements that require evaluation before being acted upon.
   Traditional evaluation approaches rely on semantic truth
   verification, which is either impossible (no oracle exists) or
   circular (using another model to judge model outputs).

   This document specifies an alternative approach: evaluating
   admissibility of agent speech acts based on their logical form
   (modality) and evidential basis (grounding), without requiring truth
   verification.

1.2.  Scope

   This framework:

   *  Defines admissibility conditions for agent-generated statements
   *  Specifies modality classification rules
   *  Establishes grounding requirements for each modality
   *  Provides deterministic evaluation axioms

   This framework does NOT:

   *  Verify semantic truth of statements
   *  Model agent reasoning or intent
   *  Provide domain-specific knowledge validation
   *  Replace human judgment in high-stakes decisions





Romanchuk                 Expires 10 July 2026                  [Page 3]

Internet-Draft           Normative Admissibility            January 2026


1.3.  Design Goals

   1.  *Determinism*: Same input produces same evaluation outcome
   2.  *Auditability*: Full trace from input to evaluation result
   3.  *Non-circularity*: No agent-generated content validates itself
   4.  *Modality-sensitivity*: Different statement forms have different
       requirements

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.

2.1.  Definitions

   *Statement*: A linguistic unit consisting of a subject (what is being
   discussed) and a predicate (what is claimed about the subject).

   *Modality*: The logical form of a statement that determines its
   manner of participation in normative evaluation.  One of: ASSERTIVE,
   CONDITIONAL, REFUSAL, DESCRIPTIVE.

   *Grounding*: The evidential basis for a statement, consisting of
   knowledge nodes with associated epistemic status.

   *Ground Scope*: Classification of grounding as FACTUAL (observable
   world state) or CONTEXTUAL (user goals, preferences, situational
   factors).

   *Strength*: Epistemic quality of grounding: STRONG (observed,
   confirmed) or WEAK (hypothesized, inferred).

   *License*: The set of modalities permitted for a statement given its
   grounding state.

   *Admissibility*: Property of a statement whose modality is within its
   permitted license.

   *Non-admissible*: Property of a statement whose modality exceeds its
   permitted license.

3.  Model Overview






Romanchuk                 Expires 10 July 2026                  [Page 4]

Internet-Draft           Normative Admissibility            January 2026


3.1.  Architecture

   The evaluation framework operates on three inputs:

   Inputs:
     ├─ Statement (S)          - Agent-generated linguistic output
     ├─ GroundSet (G)          - Available evidential basis
     └─ Context (C)            - Terms considered as given

   Output:
     └─ EvaluationResult       - Admissibility status with trace

3.2.  Evaluation Flow

Statement → Modality Classification → License Derivation → Axiom Check → Status
     │              │                       │                  │           │
     S        Modality(S)             License(G)          Axiom(M,L)    Status

3.3.  Separation of Concerns

   The framework explicitly separates:

    +===========+===============================+=====================+
    | Layer     | Responsibility                | NOT Responsible For |
    +===========+===============================+=====================+
    | Modality  | Statement form classification | Semantic            |
    |           |                               | interpretation      |
    +-----------+-------------------------------+---------------------+
    | Grounding | Evidential basis assessment   | Truth verification  |
    +-----------+-------------------------------+---------------------+
    | Axioms    | Admissibility rules           | Domain knowledge    |
    +-----------+-------------------------------+---------------------+

                                  Table 1

4.  Statement Model

4.1.  Statement Structure

   A Statement is a tuple:

   Statement := ⟨Subject, Predicate⟩

   Where: - Subject: Term denoting the object of the statement -
   Predicate: Term denoting property, relation, or state






Romanchuk                 Expires 10 July 2026                  [Page 5]

Internet-Draft           Normative Admissibility            January 2026


4.2.  Statement Admissibility Conditions

   A statement MUST satisfy all of the following to be well-formed:

   *Condition F1 (Formability)*:

   Subject ≠ ∅ ∧ Predicate ≠ ∅

   *Condition F2 (Contextual Independence)*:

   Meaning(Subject) and Meaning(Predicate) do not depend on Statement

   *Condition F3 (Non-Self-Reference)*:

   Statement does not refer to itself or its generation process

   Violation of any condition results in status ILL_FORMED.

5.  Modality Classification

5.1.  Modality Types

   Modality is a function over Statement:

   Modality : Statement → {ASSERTIVE, CONDITIONAL, REFUSAL, DESCRIPTIVE}

              +=============+==============================+
              | Modality    | Definition                   |
              +=============+==============================+
              | ASSERTIVE   | Categorical normative claim  |
              |             | without explicit conditions  |
              +-------------+------------------------------+
              | CONDITIONAL | Normative claim with         |
              |             | explicitly stated conditions |
              +-------------+------------------------------+
              | REFUSAL     | Explicit admission of        |
              |             | inability to determine       |
              +-------------+------------------------------+
              | DESCRIPTIVE | Factual observation without  |
              |             | normative claim              |
              +-------------+------------------------------+

                                 Table 2

   *Note on GOAL-CONDITIONAL*: Goal-conditional statements (e.g., "If
   your goal is X, do Y") are a syntactic subclass of CONDITIONAL
   modality with higher detection priority.  They are classified as
   CONDITIONAL for axiom application purposes.



Romanchuk                 Expires 10 July 2026                  [Page 6]

Internet-Draft           Normative Admissibility            January 2026


5.2.  Modality Determination

   Modality MUST be determined by presence of formal indicators (textual
   patterns) in the statement, NOT by semantic interpretation.

   *Head-Driven Detection*: Modality is determined by the CORE ASSERTION
   only (first paragraph or first sentence).  Supplementary clauses in
   the tail do not change modality classification.

   Example:

   "Prioritize X. [justification]. If you tell me Y..."
     → Core: "Prioritize X"
     → Modality: ASSERTIVE (not CONDITIONAL)

   *Detection Priority* (evaluated in order, MUST NOT be reordered):

1. REFUSAL           - if refusal indicators present
2. GOAL-CONDITIONAL  - if goal-conditional structure ("if your goal is...")
3. ASSERTIVE         - if recommendation indicators present in core
4. CONDITIONAL       - if condition indicators present in core
5. DESCRIPTIVE       - if purely factual indicators present
6. ASSERTIVE         - default (anti-evasion policy)

5.3.  Formal Indicators

   Formal indicators are textual patterns sufficient for classification.

           +==================+================================+
           | Modality         | Indicator Patterns (examples)  |
           +==================+================================+
           | REFUSAL          | "cannot determine", "need more |
           |                  | information", "insufficient"   |
           +------------------+--------------------------------+
           | GOAL-CONDITIONAL | "if your goal is", "if you     |
           |                  | want to", "assuming you care"  |
           +------------------+--------------------------------+
           | CONDITIONAL      | "if", "unless", "assuming",    |
           |                  | "depends on", "given that"     |
           +------------------+--------------------------------+
           | ASSERTIVE        | "should", "must", "recommend", |
           |                  | "is better", "prioritize"      |
           +------------------+--------------------------------+
           | DESCRIPTIVE      | "has status", "is blocked by", |
           |                  | "due date is", "blocks"        |
           +------------------+--------------------------------+

                                  Table 3



Romanchuk                 Expires 10 July 2026                  [Page 7]

Internet-Draft           Normative Admissibility            January 2026


   *Goal-Conditional Override*: Statements beginning with goal-
   conditional structure ("If your goal is X, do Y") MUST be classified
   as CONDITIONAL even if recommendation indicators are present.

   The default to ASSERTIVE is a POLICY CHOICE for safety-critical
   deployments.  Alternative policies (e.g., CONSERVATIVE_REFUSAL) may
   be appropriate for exploratory contexts.

6.  Grounding Model

6.1.  GroundSet Structure

   GroundSet := {KnowledgeNode}

   KnowledgeNode := ⟨content, scope, status, confidence⟩

   Where: - content: The propositional content - scope: FACTUAL or
   CONTEXTUAL - status: OBSERVED, CONFIRMED, HYPOTHESIZED, INFERRED -
   confidence: Numeric value [0.0, 1.0]

6.2.  Ground Scope

      +============+==========================+=====================+
      | Scope      | Definition               | Examples            |
      +============+==========================+=====================+
      | FACTUAL    | Observable world state   | API responses,      |
      |            |                          | database records    |
      +------------+--------------------------+---------------------+
      | CONTEXTUAL | User goals, preferences, | User intent,        |
      |            | situational factors      | business priorities |
      +------------+--------------------------+---------------------+

                                  Table 4

6.3.  Strength Derivation

   Strength is derived from content properties, NOT from transport
   channel.

   *CRITICAL PRINCIPLE: Content-Based Warrant*

   Tool call ≠ truth acquired.

   The act of invoking a tool or external system is a causal action.
   The epistemic status of a proposition is a property of the content
   returned and its evidential warrant, not of the transport mechanism
   by which it was obtained.




Romanchuk                 Expires 10 July 2026                  [Page 8]

Internet-Draft           Normative Admissibility            January 2026


   Accordingly, weakly warranted propositions MUST NOT be upgraded to
   STRONG solely by passing through tools, expert systems, or APIs
   without an explicit improvement in evidential status.

   Strength(node) :=
     STRONG  if status = CONFIRMED ∧ confidence ≥ threshold
     WEAK    otherwise

   The threshold value (e.g., 0.7) is illustrative.  Implementations MAY
   use different thresholds provided the STRONG/WEAK distinction remains
   deterministic and documented.

   For tool-derived observations (API responses, database records):

   status = OBSERVED or CONFIRMED
   confidence = 1.0
   → Strength = STRONG

   For cognitive context (user preferences, inferred goals):

   status = HYPOTHESIZED or CANDIDATE
   confidence < 0.7
   → Strength = WEAK

   This prevents illegitimate upgrading of weakly warranted
   propositions: such propositions cannot acquire STRONG status merely
   by passing through tool boundaries.

6.4.  Scope Strength Aggregation

   Within a scope, strongest evidence determines scope strength:

  ScopeStrength(scope, G) :=
    STRONG  if ∃ node ∈ G : node.scope = scope ∧ Strength(node) = STRONG
    WEAK    otherwise

6.5.  License Derivation

   License is derived from GroundSet composition:












Romanchuk                 Expires 10 July 2026                  [Page 9]

Internet-Draft           Normative Admissibility            January 2026


       +=============+=========+============+======================+
       | GroundSet   | FACTUAL | CONTEXTUAL | Permitted Modalities |
       | Composition |         |            |                      |
       +=============+=========+============+======================+
       | FACTUAL     | STRONG  | N/A        | ASSERTIVE,           |
       | only        |         |            | CONDITIONAL, REFUSAL |
       +-------------+---------+------------+----------------------+
       | FACTUAL     | WEAK    | N/A        | CONDITIONAL, REFUSAL |
       | only        |         |            |                      |
       +-------------+---------+------------+----------------------+
       | FACTUAL +   | STRONG  | STRONG     | ASSERTIVE,           |
       | CONTEXTUAL  |         |            | CONDITIONAL, REFUSAL |
       +-------------+---------+------------+----------------------+
       | FACTUAL +   | STRONG  | WEAK       | CONDITIONAL, REFUSAL |
       | CONTEXTUAL  |         |            |                      |
       +-------------+---------+------------+----------------------+
       | FACTUAL +   | WEAK    | any        | CONDITIONAL, REFUSAL |
       | CONTEXTUAL  |         |            |                      |
       +-------------+---------+------------+----------------------+
       | CONTEXTUAL  | N/A     | any        | REFUSAL              |
       | only        |         |            |                      |
       +-------------+---------+------------+----------------------+
       | Empty       | N/A     | N/A        | REFUSAL              |
       +-------------+---------+------------+----------------------+

                                  Table 5

7.  Normative Axioms

7.1.  Axiom A5: Prohibition of Ungrounded Assertive Claims

   Modality(S) = ASSERTIVE ∧ ASSERTIVE ∉ License(G)
     → Status(S) = VIOLATES_NORM

   Applicability: ASSERTIVE modality only.

   An assertive statement without sufficient grounding is non-
   admissible.

7.2.  Axiom A6: Admissibility of Refusal

   Modality(S) = REFUSAL → Status(S) = ACCEPTABLE

   Applicability: REFUSAL modality only.

   Explicit refusal to determine is always admissible.





Romanchuk                 Expires 10 July 2026                 [Page 10]

Internet-Draft           Normative Admissibility            January 2026


   *Scope Clarification*: This axiom establishes admissibility, not
   desirability.  Excessive or strategic refusal may be undesirable at
   the application layer but is out of scope for this framework.
   Application-layer policies MAY impose additional constraints on
   refusal frequency or patterns.

7.3.  Axiom A7: Conditional Admissibility

   Modality(S) = CONDITIONAL ∧ ConditionsDeclared(S)
     → Status(S) = CONDITIONALLY_ACCEPTABLE

   Applicability: CONDITIONAL modality only.

   Conditional claims are admissible when conditions are explicit.

7.4.  Axiom A4: Grounding Requirement

   Normative(S) ∧ GroundSet = ∅ → Status(S) = UNSUPPORTED

   Applicability: ASSERTIVE, CONDITIONAL modalities.

   Normative claims require non-empty grounding.

7.5.  Axiom Evaluation Order

   Axioms MUST be evaluated in the following order:

1. A6 (REFUSAL)     - if Modality = REFUSAL, return ACCEPTABLE
2. A5 (ASSERTIVE)   - if Modality = ASSERTIVE and unlicensed, return VIOLATES_NORM
3. A7 (CONDITIONAL) - if Modality = CONDITIONAL with conditions, return CONDITIONALLY_ACCEPTABLE
4. A4 (GROUNDING)   - if normative with empty ground, return UNSUPPORTED
5. Default          - return ACCEPTABLE

8.  Evaluation Outcomes

8.1.  Status Values

         +==========================+============================+
         | Status                   | Meaning                    |
         +==========================+============================+
         | ACCEPTABLE               | Statement is admissible    |
         +--------------------------+----------------------------+
         | CONDITIONALLY_ACCEPTABLE | Statement is admissible    |
         |                          | under stated conditions    |
         +--------------------------+----------------------------+
         | VIOLATES_NORM            | Statement modality exceeds |
         |                          | permitted license          |
         +--------------------------+----------------------------+



Romanchuk                 Expires 10 July 2026                 [Page 11]

Internet-Draft           Normative Admissibility            January 2026


         | UNSUPPORTED              | Normative statement lacks  |
         |                          | grounding                  |
         +--------------------------+----------------------------+
         | ILL_FORMED               | Statement fails structural |
         |                          | requirements               |
         +--------------------------+----------------------------+
         | UNDERDETERMINED          | Evaluation not possible    |
         |                          | with available information |
         +--------------------------+----------------------------+

                                  Table 6

   *Terminology Note*: The term VIOLATES_NORM denotes non-admissibility
   under the evaluation rules defined in this framework.  It does NOT
   imply ethical, legal, or security violation.  "Norm" refers to the
   activity participation rules (axioms A4-A7), not external normative
   standards.

8.2.  Evaluation Result Structure

   EvaluationResult := {
     statement: String,
     modality: Modality,
     license: Set[Modality],
     status: Status,
     applicable_axiom: AxiomId,
     grounding_trace: GroundSet
   }

9.  Evaluation Algorithm

9.1.  Algorithm



















Romanchuk                 Expires 10 July 2026                 [Page 12]

Internet-Draft           Normative Admissibility            January 2026


EVALUATE(statement, ground_set):
  1. VALIDATE structure (F1, F2, F3)
     IF violation THEN RETURN ILL_FORMED

  2. DETERMINE modality M := Modality(statement)
     IF modality cannot be determined THEN RETURN UNDERDETERMINED

  3. DERIVE license L := License(ground_set)
     IF grounding incomplete or ambiguous THEN RETURN UNDERDETERMINED

  4. APPLY axioms in order:
     IF M = REFUSAL THEN RETURN ACCEPTABLE (A6)
     IF M = ASSERTIVE AND ASSERTIVE ∉ L THEN RETURN VIOLATES_NORM (A5)
     IF M = CONDITIONAL AND conditions_declared THEN RETURN CONDITIONALLY_ACCEPTABLE (A7)
     IF M ∈ {ASSERTIVE, CONDITIONAL} AND ground_set = ∅ THEN RETURN UNSUPPORTED (A4)
     IF M = DESCRIPTIVE AND factual_grounding_present THEN RETURN ACCEPTABLE
     IF M = ASSERTIVE AND ASSERTIVE ∈ L THEN RETURN ACCEPTABLE

  5. RETURN UNDERDETERMINED

   *Note on UNDERDETERMINED*: This status indicates that the evaluator
   lacks sufficient information or jurisdiction to render a verdict.  It
   is a valid outcome representing honest acknowledgment of evaluation
   limits, not an error condition.  Triggering conditions are
   implementation-defined but MUST include cases where modality
   detection or grounding assessment cannot proceed deterministically.

9.2.  Determinism Guarantee

   Given identical inputs (statement, ground_set), the algorithm MUST
   produce identical outputs.  No probabilistic components are permitted
   in the evaluation path.

10.  Security Considerations

10.1.  Modality Detection Errors

   Incorrect modality classification may result in:

   *  *False ASSERTIVE*: Conditional statement classified as assertive
      may be incorrectly flagged as VIOLATES_NORM
   *  *False CONDITIONAL*: Assertive statement classified as conditional
      may evade A5 enforcement

   Implementations SHOULD log modality determination traces for audit.






Romanchuk                 Expires 10 July 2026                 [Page 13]

Internet-Draft           Normative Admissibility            January 2026


10.2.  Grounding Manipulation

   Adversarial agents may attempt to:

   *  Inject synthetic "strong" grounding to license assertive claims
   *  Omit contextual grounding to avoid scope checks

   Implementations MUST ensure grounding sources are authenticated and
   MUST NOT allow agent-generated content to serve as grounding for the
   same agent's claims.

10.3.  Self-Licensing Prevention

   This framework explicitly prevents self-licensing:

   *  Agent-generated hypotheses MUST NOT license agent assertions
   *  Tool outputs containing LLM-generated content MUST be typed as
      INFERRED, not OBSERVED

10.4.  Limitations

   This framework does NOT guarantee:

   *  Semantic correctness of admissible statements
   *  Absence of hallucination in statement content
   *  Domain-specific validity

   Admissibility is necessary but not sufficient for trustworthiness.

11.  IANA Considerations

   This document has no IANA actions.

12.  References

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

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

12.2.  Informative References

   [ZINOVIEV] Zinoviev, A.A., "Logical Physics", Reidel Publishing,
   Dordrecht, 1983.



Romanchuk                 Expires 10 July 2026                 [Page 14]

Internet-Draft           Normative Admissibility            January 2026


13.  Appendix A: Rationale (Non-Normative)

13.1.  Why Form-Based Evaluation

   Traditional AI evaluation approaches assume access to ground truth or
   employ LLM-as-judge patterns.  Both are problematic:

   *  Ground truth is often unavailable in real-world deployments
   *  LLM-as-judge introduces circularity and non-determinism

   This framework evaluates statement form (modality) against evidential
   basis (grounding), avoiding both issues.

13.2.  Why Modality Matters

   Different statement forms carry different epistemic commitments:

   *  Assertive claims commit the speaker to the truth of the claim
   *  Conditional claims commit only under stated conditions
   *  Refusals commit to inability to determine

   Evaluation must be sensitive to these differences.

13.3.  Conservative Assumptions

   The framework employs conservative assumptions:

   *  *Presence = Usage*: If contextual grounding is present, it is
      assumed to be used by the statement.  This prevents false
      assertive licenses for contextual claims.

   *  *Default = Assertive*: Ambiguous statements default to assertive
      classification.  This prevents evasion via vague language.

   These assumptions may over-restrict in some cases but ensure safety
   in adversarial conditions.

13.4.  Theoretical Foundation

   This framework is informed by Zinoviev's Logic of Science, which
   distinguishes:

   *  Logic as rules for operating with linguistic forms
   *  Logic as normative regulation of activity mediated by language

   Axioms A5–A7 implement norms of participation in activity, not laws
   of truth or inference.




Romanchuk                 Expires 10 July 2026                 [Page 15]

Internet-Draft           Normative Admissibility            January 2026


   Violation indicates a breach of admissibility conditions within an
   activity, not semantic falsehood.

14.  Appendix B: Examples (Non-Normative)

14.1.  Assertive Claim with Strong Grounding

   Statement: "Task X blocks Task Y"
   Modality: DESCRIPTIVE (purely factual)
   GroundSet:
     └─ API response (OBSERVED, FACTUAL, confidence=1.0)
   License: {ASSERTIVE, CONDITIONAL, REFUSAL}
   Status: ACCEPTABLE

14.2.  Assertive Claim with Weak Grounding

   Statement: "Task X should be prioritized"
   Modality: ASSERTIVE
   GroundSet:
     ├─ API response (OBSERVED, FACTUAL, confidence=1.0)
     └─ User intent (HYPOTHESIZED, CONTEXTUAL, confidence=0.5)
   License: {CONDITIONAL, REFUSAL}
   Status: VIOLATES_NORM (A5)

14.3.  Conditional Claim with Weak Grounding

Statement: "If revenue impact is critical, Task X should be prioritized"
Modality: CONDITIONAL
GroundSet:
  ├─ API response (OBSERVED, FACTUAL, confidence=1.0)
  └─ User intent (HYPOTHESIZED, CONTEXTUAL, confidence=0.5)
License: {CONDITIONAL, REFUSAL}
Status: CONDITIONALLY_ACCEPTABLE (A7)

14.4.  Explicit Refusal

 Statement: "Cannot determine priority without knowing business context"
 Modality: REFUSAL
 GroundSet: (any)
 License: (any)
 Status: ACCEPTABLE (A6)

15.  Author's Address

   Oleg Romanchuk Independent Researcher

   Email: [olromanchuk@gmail.com]




Romanchuk                 Expires 10 July 2026                 [Page 16]


name: draft-hackett-ures
rev: 00
title: Unified Rendering of Email Standard (URES)
time: 2026-01-12T14:19:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T14:19:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:06.864857+00:00
abstract:
This document specifies requirements for the uniform rendering of
   HTML email content across mail user agents (MUAs).  It addresses
   critical inconsistencies in how email clients interpret HTML and CSS,
   including dark mode adaptation, embedded asset handling, positioning
   constraints, and secure SVG rendering.  The specification aims to
   eliminate the current fragmentation in email rendering while
   maintaining backwards compatibility with existing MIME standards
   (RFCs 2045-2049) and the Internet Message Format (RFC 5322).

full_text:
Independent Submission                                        W. Hackett
Internet-Draft                                              January 2026
Intended status: Standards Track                                        
Expires: 16 July 2026


               Unified Rendering of Email Standard (URES)
                         draft-hackett-ures-00

Abstract

   This document specifies requirements for the uniform rendering of
   HTML email content across mail user agents (MUAs).  It addresses
   critical inconsistencies in how email clients interpret HTML and CSS,
   including dark mode adaptation, embedded asset handling, positioning
   constraints, and secure SVG rendering.  The specification aims to
   eliminate the current fragmentation in email rendering while
   maintaining backwards compatibility with existing MIME standards
   (RFCs 2045-2049) and the Internet Message Format (RFC 5322).

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.










Hackett                   Expires 16 July 2026                  [Page 1]

Internet-Draft                    URES                      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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Document Structure Requirements . . . . . . . . . . . . . . .   6
     3.1.  HTML Version  . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Required Document Structure . . . . . . . . . . . . . . .   6
     3.3.  Style Placement . . . . . . . . . . . . . . . . . . . . .   7
   4.  CSS Support Requirements  . . . . . . . . . . . . . . . . . .   8
     4.1.  MUST Support Properties . . . . . . . . . . . . . . . . .   8
       4.1.1.  Box Model Properties  . . . . . . . . . . . . . . . .   8
       4.1.2.  Typography Properties . . . . . . . . . . . . . . . .   8
       4.1.3.  Colour and Background Properties  . . . . . . . . . .   8
       4.1.4.  Layout Properties . . . . . . . . . . . . . . . . . .   8
       4.1.5.  CSS Selectors . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Positioning Constraints . . . . . . . . . . . . . . . . .   9
       4.2.1.  Permitted Values  . . . . . . . . . . . . . . . . . .   9
       4.2.2.  Prohibited Values in Web Clients  . . . . . . . . . .   9
     4.3.  z-index Handling  . . . . . . . . . . . . . . . . . . . .  10
       4.3.1.  Stacking Context Isolation  . . . . . . . . . . . . .  10
       4.3.2.  Maximum z-index . . . . . . . . . . . . . . . . . . .  10
     4.4.  Flexbox . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.5.  CSS Grid (SHOULD Support) . . . . . . . . . . . . . . . .  10
   5.  Dark Mode Adaptation  . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Colour Scheme Meta Tag  . . . . . . . . . . . . . . . . .  11
     5.2.  Media Query Support . . . . . . . . . . . . . . . . . . .  11
     5.3.  Colour Inversion Rules  . . . . . . . . . . . . . . . . .  12
       5.3.1.  Inversion Pairing . . . . . . . . . . . . . . . . . .  12
       5.3.2.  Contrast Preservation . . . . . . . . . . . . . . . .  12
   6.  Image and Asset Handling  . . . . . . . . . . . . . . . . . .  12
     6.1.  Inline Base64 Images  . . . . . . . . . . . . . . . . . .  12
       6.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.2.  Required Support  . . . . . . . . . . . . . . . . . .  12
       6.1.3.  Size Limits . . . . . . . . . . . . . . . . . . . . .  13
       6.1.4.  Rendering Behaviour . . . . . . . . . . . . . . . . .  13
     6.2.  CID (Content-ID) Images . . . . . . . . . . . . . . . . .  13



Hackett                   Expires 16 July 2026                  [Page 2]

Internet-Draft                    URES                      January 2026


       6.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  13
       6.2.2.  Required Behaviour  . . . . . . . . . . . . . . . . .  14
   7.  SVG Rendering . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Executive-Safe SVG Profile  . . . . . . . . . . . . . . .  14
     7.2.  Prohibited SVG Elements . . . . . . . . . . . . . . . . .  15
       7.2.1.  Script and Event Handlers . . . . . . . . . . . . . .  15
       7.2.2.  External References . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     8.1.  Script Execution  . . . . . . . . . . . . . . . . . . . .  15
       8.1.1.  Prohibited Elements . . . . . . . . . . . . . . . . .  15
       8.1.2.  Prohibited Attributes . . . . . . . . . . . . . . . .  16
       8.1.3.  JavaScript URLs . . . . . . . . . . . . . . . . . . .  16
     8.2.  Positioning Attack Prevention . . . . . . . . . . . . . .  16
       8.2.1.  Fixed Position Blocking . . . . . . . . . . . . . . .  16
       8.2.2.  z-index Sandboxing  . . . . . . . . . . . . . . . . .  16
     8.3.  Tracking Prevention . . . . . . . . . . . . . . . . . . .  16
       8.3.1.  Pixel Tracking  . . . . . . . . . . . . . . . . . . .  17
       8.3.2.  Inline Content as Alternative . . . . . . . . . . . .  17
   9.  Accessibility . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Semantic HTML . . . . . . . . . . . . . . . . . . . . . .  17
     9.2.  Alternative Text  . . . . . . . . . . . . . . . . . . . .  17
     9.3.  Colour Contrast . . . . . . . . . . . . . . . . . . . . .  18
   10. Conformance Levels  . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  URES Level 1 (Baseline)  . . . . . . . . . . . . . . . .  18
     10.2.  URES Level 2 (Enhanced)  . . . . . . . . . . . . . . . .  18
     10.3.  URES Level 3 (Full)  . . . . . . . . . . . . . . . . . .  19
   11. Adoption Considerations . . . . . . . . . . . . . . . . . . .  19
     11.1.  Open Source Reference Implementations  . . . . . . . . .  19
     11.2.  Precedent for Community-Driven Adoption  . . . . . . . .  20
     11.3.  Incremental Adoption Path  . . . . . . . . . . . . . . .  20
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     13.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  Known Client Inconsistencies . . . . . . . . . . . .  22
     A.1.  CSS Support Matrix (Selected Properties)  . . . . . . . .  23
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

1.1.  Background

   Email remains one of the most critical communication channels for
   both personal and business communications.  Despite decades of
   development, the rendering of HTML email content remains
   frustratingly inconsistent across mail user agents (MUAs).




Hackett                   Expires 16 July 2026                  [Page 3]

Internet-Draft                    URES                      January 2026


   The current standards landscape is fragmented:

   *  RFC 5322 [RFC5322] defines the Internet Message Format, specifying
      header fields and basic body structure.

   *  RFCs 2045-2049 [RFC2045] define MIME, enabling multi-part messages
      with various content types including text/html.

   *  The W3C maintains HTML and CSS specifications, but these are
      designed for web browsers, not email clients.

   *  No RFC or standard body governs how email clients SHOULD or MUST
      render HTML and CSS content.

   This gap has resulted in a situation where email developers must
   maintain extensive compatibility matrices, use archaic techniques
   such as table-based layouts, and accept that their carefully crafted
   emails will appear differently—or broken—across different clients.

1.2.  Problem Statement

   The following critical issues plague current email rendering:

   1.  *CSS Support Inconsistency:* Properties universally supported in
       browsers (flexbox, grid, CSS variables) have zero or partial
       support in major email clients.  Gmail strips style tags in non-
       AMP contexts.  Outlook uses Microsoft Word's rendering engine.

   2.  *Dark Mode Chaos:* Email clients implement dark mode adaptation
       differently.  Some invert all colours, some honour author
       preferences, some do nothing.  Text becomes illegible when
       foreground colours are inverted but backgrounds are not.

   3.  *Image Handling:* Base64 inline images are blocked by many
       clients citing size concerns.  CID attachments render
       inconsistently.  Remote images enable tracking and are blocked by
       default.

   4.  *SVG Non-Support:* Most email clients strip or fail to render SVG
       entirely, despite it being a W3C standard since 2001.  Executives
       receive emails with missing logos and charts.

   5.  *Positioning Attacks:* In web-based clients (Gmail, Outlook.com),
       malicious use of position:fixed or high z-index values could
       overlay phishing content atop the webmail UI.






Hackett                   Expires 16 July 2026                  [Page 4]

Internet-Draft                    URES                      January 2026


   6.  *Layout Primitives:* Modern CSS layout (flexbox, grid) is
       unsupported in Outlook desktop, forcing continued use of nested
       HTML tables—a technique deprecated in web development since 2010.

   7.  *Font Rendering:* @font-face and web fonts work in approximately
       40% of email clients, with no fallback standardisation.

   8.  *Media Queries:* Support for responsive design via @media queries
       is inconsistent, with Gmail notably stripping them entirely.

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

2.  Terminology

   Mail User Agent (MUA)  An application that accesses email on behalf
      of a user.  This includes desktop applications (Apple Mail,
      Outlook, Thunderbird), web-based clients (Gmail, Outlook.com,
      Yahoo Mail), and mobile applications (iOS Mail, Gmail app).

   Rendering Engine  The component of an MUA responsible for
      interpreting and displaying HTML/CSS content.  Some MUAs use web
      browser engines (WebKit, Blink), others use proprietary engines
      (Microsoft Word in Outlook desktop).

   Dark Mode  A display preference where the UI uses a dark background
      with light text.  Email clients may automatically adapt email
      content to match this preference.

   Colour Scheme  The light or dark preference indicated by the email
      author or inferred by the email client.

   Inline Image  An image embedded directly in the HTML using a data:
      URI with base64 encoding, or referenced via Content-ID (CID).

   Executive-Safe  Content that renders correctly in email clients
      commonly used by business executives, particularly Outlook
      desktop, Apple Mail, and Gmail.

   Stacking Context  A three-dimensional conceptualisation of HTML
      elements along an imaginary z-axis relative to the user.  Elements
      with z-index values form stacking contexts.




Hackett                   Expires 16 July 2026                  [Page 5]

Internet-Draft                    URES                      January 2026


   Content Isolation  The practice of preventing email content from
      affecting or overlaying the host application's user interface.

3.  Document Structure Requirements

3.1.  HTML Version

   Conforming MUAs MUST support HTML5 document structure as defined in
   [HTML5].  The following DOCTYPE declaration MUST be recognised:

   <!DOCTYPE html>

   MUAs MUST also accept and render documents using XHTML and HTML4
   doctypes for backwards compatibility.  However, email authors SHOULD
   use HTML5.

   MUAs MUST NOT require an XML declaration for HTML email content.

3.2.  Required Document Structure

   MUAs MUST correctly parse and render the following minimal document
   structure:





























Hackett                   Expires 16 July 2026                  [Page 6]

Internet-Draft                    URES                      January 2026


   <!DOCTYPE html>
   <html lang="en" xmlns="http://www.w3.org/1999/xhtml"
         xmlns:o="urn:schemas-microsoft-com:office:office">
   <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width,initial-scale=1">
     <meta name="color-scheme" content="light dark">
     <meta name="supported-color-schemes" content="light dark">
     <title>Email Subject</title>
     <!--[if mso]>
     <noscript>
       <xml>
         <o:OfficeDocumentSettings>
           <o:PixelsPerInch>96</o:PixelsPerInch>
         </o:OfficeDocumentSettings>
       </xml>
     </noscript>
     <![endif]-->
     <style>
       /* Author styles */
     </style>
   </head>
   <body>
     <!-- Content -->
   </body>
   </html>

   MUAs MUST preserve the html element's lang attribute and make it
   available to accessibility tools.

   MUAs MUST parse and apply the viewport meta tag for responsive
   rendering on mobile devices.

   MUAs supporting Microsoft Office conditional comments SHOULD
   interpret <!--[if mso]> blocks appropriately.

3.3.  Style Placement

   MUAs MUST support CSS styles in ALL of the following locations:

   1.  Inline styles via the style attribute on any HTML element

   2.  Embedded styles via style elements in the head

   3.  Embedded styles via style elements in the body

   MUAs MUST NOT strip or ignore style elements based on their placement
   in the document.



Hackett                   Expires 16 July 2026                  [Page 7]

Internet-Draft                    URES                      January 2026


   MUAs MUST process multiple style elements in document order, applying
   standard CSS cascade rules.

   MUAs SHOULD support link rel="stylesheet" elements referencing
   external stylesheets, subject to security controls defined in
   Section 8.

   When an MUA chooses not to load external stylesheets for security
   reasons, it MUST still apply all inline and embedded styles.

4.  CSS Support Requirements

4.1.  MUST Support Properties

   Conforming MUAs MUST support the following CSS properties with full
   specification compliance:

4.1.1.  Box Model Properties

   margin, margin-top, margin-right, margin-bottom, margin-left,
   padding, padding-top, padding-right, padding-bottom, padding-left,
   border, border-width, border-style, border-color, border-top, border-
   right, border-bottom, border-left, border-radius, border-top-left-
   radius, border-top-right-radius, border-bottom-left-radius, border-
   bottom-right-radius, width, min-width, max-width, height, min-height,
   max-height, box-sizing

4.1.2.  Typography Properties

   font-family, font-size, font-weight, font-style, line-height, text-
   align, text-decoration, text-decoration-line, text-decoration-color,
   text-decoration-style, text-transform, letter-spacing, word-spacing,
   white-space, vertical-align

4.1.3.  Colour and Background Properties

   color, background-color, background-image (for gradients and data:
   URIs), background-position, background-repeat, background-size,
   background (shorthand), opacity

4.1.4.  Layout Properties

   display (block, inline, inline-block, none, table, table-row, table-
   cell, flex, inline-flex), position (static, relative), float, clear,
   overflow, overflow-x, overflow-y






Hackett                   Expires 16 July 2026                  [Page 8]

Internet-Draft                    URES                      January 2026


4.1.5.  CSS Selectors

   MUAs MUST support the following CSS selectors:

   Type selectors (p, div, table), Class selectors (.classname), ID
   selectors (#idname), Descendant combinator (div p), Child combinator
   (div > p), Adjacent sibling combinator (h1 + p), Attribute selectors
   ([attr], [attr=value], [attr~=value], [attr|=value], [attr^=value],
   [attr$=value], [attr*=value]), Pseudo-classes (:first-child, :last-
   child, :nth-child(), :hover, :active, :focus, :visited, :link),
   Pseudo-elements (::before, ::after, ::first-line, ::first-letter)

4.2.  Positioning Constraints

   For security reasons detailed in Section 8.2, MUAs MUST constrain the
   position property as follows:

4.2.1.  Permitted Values

   MUAs MUST support:

   *  position: static (default, normal flow)

   *  position: relative (offset from normal position)

4.2.2.  Prohibited Values in Web Clients

   Web-based MUAs (those running within a web browser context) MUST
   treat the following values as position: static:

   *  position: fixed

   *  position: absolute

   *  position: sticky

   When an email contains these prohibited position values, the MUA MUST
   either:

   a.  Render the element as position: static, OR

   b.  Render the element as position: relative with top, left, right,
       and bottom values clamped to values that cannot cause the element
       to escape its container.







Hackett                   Expires 16 July 2026                  [Page 9]

Internet-Draft                    URES                      January 2026


4.3.  z-index Handling

   The z-index property controls stacking order within a stacking
   context.  MUAs MUST implement z-index handling that prevents
   malicious overlay attacks.

4.3.1.  Stacking Context Isolation

   MUAs MUST create a new stacking context for email content that is
   isolated from the host application.  This means:

   *  z-index values within email content MUST NOT affect elements
      outside the email content container.

   *  The email content container MUST have a z-index lower than any
      application UI that could be targeted for spoofing.

4.3.2.  Maximum z-index

   MUAs SHOULD normalise z-index values within email content.  If an
   email specifies z-index: 2147483647 (the maximum 32-bit signed
   integer), this MUST still be rendered below application UI.

   Implementation approaches:

   a.  Contain email content in an iframe with srcdoc

   b.  Apply CSS containment (contain: strict)

   c.  Clamp z-index values to a maximum safe value

   d.  Render email in a separate compositing layer

4.4.  Flexbox

   MUAs MUST support CSS Flexible Box Layout [CSS-FLEXBOX-1] including:

   display: flex, display: inline-flex, flex-direction, flex-wrap, flex-
   flow, justify-content, align-items, align-content, order, flex-grow,
   flex-shrink, flex-basis, flex, align-self

4.5.  CSS Grid (SHOULD Support)

   MUAs SHOULD support CSS Grid Layout [CSS-GRID-1].  Where supported,
   MUAs MUST implement:






Hackett                   Expires 16 July 2026                 [Page 10]

Internet-Draft                    URES                      January 2026


   display: grid, display: inline-grid, grid-template-columns, grid-
   template-rows, grid-template-areas, grid-gap, gap, row-gap, column-
   gap, grid-column, grid-row, grid-area

5.  Dark Mode Adaptation

   Dark mode support is critical for email legibility.  This section
   defines requirements for consistent dark mode behaviour.

5.1.  Colour Scheme Meta Tag

   MUAs MUST recognise and honour the color-scheme meta tag:

   <meta name="color-scheme" content="light dark">

   Valid values:

   *  "light" - Email is designed for light mode only

   *  "dark" - Email is designed for dark mode only

   *  "light dark" - Email supports both modes

   *  "only light" - Email MUST NOT be adapted for dark mode

   *  "only dark" - Email MUST NOT be adapted for light mode

   When color-scheme is set to "only light", MUAs MUST NOT invert,
   adjust, or otherwise modify the colours specified by the email
   author, even when the MUA or operating system is in dark mode.

5.2.  Media Query Support

   MUAs MUST support the prefers-color-scheme media query:

   @media (prefers-color-scheme: dark) {
     body {
       background-color: #1a1a1a;
       color: #ffffff;
     }
   }

   @media (prefers-color-scheme: light) {
     body {
       background-color: #ffffff;
       color: #1a1a1a;
     }
   }



Hackett                   Expires 16 July 2026                 [Page 11]

Internet-Draft                    URES                      January 2026


   When the user has selected dark mode in their MUA or operating
   system, prefers-color-scheme: dark MUST match.

   MUAs MUST NOT strip or ignore @media rules, including @media
   (prefers-color-scheme: ...) rules.

5.3.  Colour Inversion Rules

   When an MUA applies automatic dark mode adaptation to an email that
   has not opted out, the following rules MUST be followed:

5.3.1.  Inversion Pairing

   MUAs MUST NOT invert foreground colours without also inverting the
   corresponding background colour.  Specifically:

   *  If text colour is inverted from dark to light, the background
      behind that text MUST also be inverted from light to dark.

   *  If a background is inverted, all foreground elements (text,
      borders) on that background MUST be correspondingly adjusted.

5.3.2.  Contrast Preservation

   When inverting colours, MUAs MUST maintain a minimum contrast ratio
   of 4.5:1 for normal text and 3:1 for large text, as defined in WCAG
   2.1 [WCAG21].

6.  Image and Asset Handling

6.1.  Inline Base64 Images

   Inline images using data: URIs provide a tracking-free method for
   including images directly in email content.  MUAs MUST support this
   mechanism.

6.1.1.  Syntax

   <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
   AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
   9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">

6.1.2.  Required Support

   MUAs MUST render inline base64 images for the following MIME types:

   *  image/png




Hackett                   Expires 16 July 2026                 [Page 12]

Internet-Draft                    URES                      January 2026


   *  image/jpeg (including image/jpg as an alias)

   *  image/gif

   *  image/webp

   *  image/svg+xml (subject to security restrictions in Section 7)

6.1.3.  Size Limits

   MUAs MUST support inline images with encoded sizes of at least:

   *  Individual image: 1 MB (after base64 encoding)

   *  Total per email: 10 MB (cumulative across all inline images)

   MUAs MAY support larger sizes but MUST NOT fail to render images
   below these thresholds.

6.1.4.  Rendering Behaviour

   MUAs MUST render inline base64 images:

   *  Without requiring user interaction to "load images"

   *  Without displaying tracking/privacy warnings for these images

   *  Immediately upon email open (no lazy-load deferral)

   This behaviour is REQUIRED because inline images:

   *  Cannot be used for tracking (no external request is made)

   *  Are already fully downloaded as part of the email content

   *  Provide a privacy-preserving alternative to remote images

6.2.  CID (Content-ID) Images

   Content-ID references allow images attached to the email to be
   displayed inline.  MUAs MUST support this mechanism as defined in RFC
   2392 [RFC2392].

6.2.1.  Syntax

   In the HTML body:

   <img src="cid:image001@example.com" alt="Inline image">



Hackett                   Expires 16 July 2026                 [Page 13]

Internet-Draft                    URES                      January 2026


6.2.2.  Required Behaviour

   MUAs MUST:

   *  Resolve cid: URLs to the corresponding MIME part

   *  Render the image inline at the point of reference

   *  Support CID references in both img elements and CSS background-
      image properties

   *  Render CID images without requiring "load images" interaction

7.  SVG Rendering

   Scalable Vector Graphics provide resolution-independent images
   essential for logos, icons, charts and diagrams.  This section
   defines an "Executive-Safe" SVG profile that balances functionality
   with security.

7.1.  Executive-Safe SVG Profile

   The Executive-Safe SVG Profile defines a restricted subset of SVG
   that MUST be supported by conforming MUAs.  This profile is named to
   emphasise that SVG content—particularly logos and charts—must render
   correctly in email clients commonly used by business executives.

   The Executive-Safe profile includes:

   *  All SVG 1.1 shape elements

   *  Text elements

   *  Gradients and patterns

   *  Basic filters (subset)

   *  Symbols and use references (internal only)

   *  Styling via presentation attributes and internal stylesheets

   The Executive-Safe profile excludes:

   *  Script elements and event handlers

   *  External references

   *  Animation elements (use CSS animation instead)



Hackett                   Expires 16 July 2026                 [Page 14]

Internet-Draft                    URES                      January 2026


   *  ForeignObject element

   *  Certain filter primitives

7.2.  Prohibited SVG Elements

   MUAs MUST strip or neutralise the following SVG elements:

7.2.1.  Script and Event Handlers

   The script element and any element with on* attributes (onclick,
   onload, onerror, etc.)  MUST be stripped.

7.2.2.  External References

   The following MUST NOT be resolved:

   *  use href="external.svg#symbol"

   *  image href="external.png"

   *  a href="javascript:..."

   *  feImage xlink:href="external.svg"

   Note: Internal references within the same SVG document ARE permitted:

   <use href="#internal-symbol">   <!-- OK -->

8.  Security Considerations

   Email is a primary vector for phishing, malware distribution and
   social engineering attacks.  MUAs MUST implement robust security
   measures while rendering HTML content.

8.1.  Script Execution

   MUAs MUST NOT execute JavaScript or any other scripting language in
   email content.

8.1.1.  Prohibited Elements

   The following elements MUST be stripped or rendered inert:

   *  script element

   *  noscript element (SHOULD be displayed)




Hackett                   Expires 16 July 2026                 [Page 15]

Internet-Draft                    URES                      January 2026


8.1.2.  Prohibited Attributes

   The following attributes MUST be stripped from all elements:

   All on* event handlers: onclick, onload, onerror, onmouseover,
   onfocus, onblur, onsubmit, etc.

8.1.3.  JavaScript URLs

   The following URL schemes MUST NOT be executable:

   *  javascript:

   *  vbscript:

   *  data:text/html (when containing script)

   MUAs MUST either:

   a.  Strip href/src attributes containing these schemes, OR

   b.  Replace them with safe values (e.g., href="#")

8.2.  Positioning Attack Prevention

   In web-based MUAs, malicious use of CSS positioning could overlay
   deceptive content atop the webmail UI.

8.2.1.  Fixed Position Blocking

   MUAs MUST NOT render position: fixed as specified.  Such elements:

   *  MUST be rendered as position: static or position: relative

   *  MUST remain within the email content area

   *  MUST NOT overlay any part of the MUA interface

8.2.2.  z-index Sandboxing

   MUAs MUST ensure that email content z-index values cannot cause
   elements to render above the MUA interface.

   Implementation: Create a new stacking context for email content that
   is positioned below all MUA UI elements.

8.3.  Tracking Prevention




Hackett                   Expires 16 July 2026                 [Page 16]

Internet-Draft                    URES                      January 2026


8.3.1.  Pixel Tracking

   Remote images are commonly used as tracking pixels.  MUAs SHOULD:

   *  Block remote images by default

   *  Provide clear UI indication when images are blocked

   *  Allow users to load images per-email or per-sender

8.3.2.  Inline Content as Alternative

   The mandatory support for base64 inline images (Section 6.1) and CID
   images (Section 6.2) provides senders with tracking-free alternatives
   for embedding images.

9.  Accessibility

   Email content MUST be accessible to users with disabilities.  MUAs
   MUST NOT strip or alter HTML that supports accessibility.

9.1.  Semantic HTML

   MUAs MUST correctly interpret and render semantic HTML elements:

   header, footer, nav, main, article, section, aside, h1 through h6, p,
   ul, ol, li, dl, dt, dd, table, th, td (with scope attributes),
   figure, figcaption, blockquote, cite, strong, em

   MUAs MUST NOT flatten semantic structure (e.g., converting all
   elements to div or span).

9.2.  Alternative Text

   MUAs MUST:

   *  Display alt attribute text when images are not loaded

   *  Expose alt text to assistive technologies

   *  Support role and aria-* attributes

   MUAs MUST NOT strip:

   alt, title, role, aria-label, aria-labelledby, aria-describedby,
   aria-hidden, aria-live, aria-atomic, aria-relevant





Hackett                   Expires 16 July 2026                 [Page 17]

Internet-Draft                    URES                      January 2026


9.3.  Colour Contrast

   When MUAs apply automatic dark mode adaptation (Section 5.3), the
   resulting colour combinations MUST maintain WCAG 2.1 AA contrast
   ratios:

   *  Normal text: 4.5:1

   *  Large text: 3:1

   *  UI components and graphics: 3:1

10.  Conformance Levels

   To facilitate gradual adoption, this specification defines three
   conformance levels.

10.1.  URES Level 1 (Baseline)

   An MUA conforming to URES Level 1 MUST:

   *  Support all properties in Section 4.1

   *  Support inline base64 images (Section 6.1)

   *  Support CID images (Section 6.2)

   *  Strip all JavaScript (Section 8.1)

   *  Implement positioning constraints (Section 4.2)

   *  Support prefers-color-scheme media query (Section 5.2)

   *  Preserve semantic HTML (Section 9.1)

10.2.  URES Level 2 (Enhanced)

   An MUA conforming to URES Level 2 MUST:

   *  Meet all Level 1 requirements

   *  Support the Executive-Safe SVG Profile (Section 7)

   *  Support CSS Flexbox (Section 4.4)

   *  Implement dark mode adaptation rules (Section 5.3)

   *  Support picture element



Hackett                   Expires 16 July 2026                 [Page 18]

Internet-Draft                    URES                      January 2026


   *  Support CSS custom properties (variables)

10.3.  URES Level 3 (Full)

   An MUA conforming to URES Level 3 MUST:

   *  Meet all Level 2 requirements

   *  Support CSS Grid (Section 4.5)

   *  Support @font-face

   *  Support CSS animations (with user preference for reduced motion)

   *  Implement full CSP

   *  Provide tracking prevention (Section 8.3)

11.  Adoption Considerations

   This section addresses practical considerations for adoption of this
   specification by email client vendors.

11.1.  Open Source Reference Implementations

   The authors recognise that some email client vendors have
   historically been reluctant to invest in standards-compliant
   rendering engines, preferring instead to repurpose existing
   technologies (such as word processing engines) that were never
   designed for standards-compliant HTML/CSS rendering.

   To address this, the community intends to develop and maintain open
   source reference implementations of URES-compliant rendering
   components.  These implementations will be:

   *  Licensed under permissive terms (MIT, Apache 2.0, or similar)

   *  Designed for embedding in both native and web-based clients

   *  Maintained by the community with regular security updates

   *  Tested against the URES conformance test suite

   Vendors who have historically chosen not to invest in standards-
   compliant rendering may simply adopt these community-maintained
   implementations when ready, rather than continuing to maintain
   proprietary solutions that diverge from industry consensus.




Hackett                   Expires 16 July 2026                 [Page 19]

Internet-Draft                    URES                      January 2026


11.2.  Precedent for Community-Driven Adoption

   This approach mirrors successful adoption patterns across the
   software industry, where vendors have benefited from community-
   developed standards and implementations rather than maintaining
   proprietary alternatives:

   *  React (Meta): Now embedded across enterprise applications,
      including those from vendors who initially resisted component-
      based UI architectures.

   *  GraphQL (Meta): Adopted by major cloud platforms after community
      momentum demonstrated clear benefits over proprietary query
      languages.

   *  OpenTelemetry (CNCF): Observability standard now integrated across
      all major cloud providers, replacing fragmented proprietary
      instrumentation.

   *  Chromium (Google): The rendering engine now powers multiple
      browsers from vendors who previously maintained independent
      engines, including Microsoft Edge.

   *  VS Code / Monaco Editor (Microsoft): An acknowledgement that
      community-driven tooling often surpasses proprietary alternatives.

   Vendors currently maintaining non-compliant rendering engines face an
   ongoing maintenance burden for technology that provides no
   competitive advantage.  The availability of URES-compliant open
   source alternatives offers a path to reduced maintenance costs while
   improving interoperability for their users.

11.3.  Incremental Adoption Path

   Vendors need not adopt all conformance levels simultaneously.  The
   three-tier conformance structure (Section 10) enables:

   1.  Level 1 adoption with minimal investment, addressing the most
       critical rendering inconsistencies.

   2.  Level 2 adoption as community implementations mature, adding
       modern layout and dark mode support.

   3.  Level 3 adoption for full feature parity with web browsers,
       enabled by proven, stable open source components.






Hackett                   Expires 16 July 2026                 [Page 20]

Internet-Draft                    URES                      January 2026


   This graduated approach ensures that even conservative vendors can
   adopt URES without significant risk, leveraging battle-tested
   implementations developed and maintained by the broader community.

12.  IANA Considerations

   This document registers a new media feature for the prefers-color-
   scheme-only media query:

   Name:  prefers-color-scheme-only

   Values:  light | dark

   Applies to:  visual media

   Description:  Indicates that the email author has requested no
      automatic colour scheme adaptation.

   This document requests registration of the following HTTP header for
   use in email content negotiation:

   Header field name:  X-Email-Renderer-Level

   Applicable protocol:  HTTP (for web-based MUAs)

   Status:  Informational

   Author/Change controller:  IETF

   Specification document(s):  This document

   Values:  1 | 2 | 3

   Example:  X-Email-Renderer-Level: 2

13.  References

13.1.  Normative References

   [CSS-FLEXBOX-1]
              Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS
              Flexible Box Layout Module Level 1", W3C Candidate
              Recommendation, November 2018,
              <https://www.w3.org/TR/css-flexbox-1/>.







Hackett                   Expires 16 July 2026                 [Page 21]

Internet-Draft                    URES                      January 2026


   [CSS-GRID-1]
              Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS Grid
              Layout Module Level 1", W3C Candidate Recommendation,
              December 2020, <https://www.w3.org/TR/css-grid-1/>.

   [HTML5]    WHATWG, "HTML Living Standard",
              <https://html.spec.whatwg.org/>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, August 1998,
              <https://www.rfc-editor.org/info/rfc2392>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008, <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

13.2.  Informative References

   [CANIEMAIL]
              Community project, "Can I email... Support tables for HTML
              and CSS in emails", <https://www.caniemail.com/>.

   [WCAG21]   W3C, "Web Content Accessibility Guidelines (WCAG) 2.1",
              W3C Recommendation, June 2018,
              <https://www.w3.org/TR/WCAG21/>.

Appendix A.  Known Client Inconsistencies

   This appendix documents specific inconsistencies in current email
   clients that this RFC aims to address.  Data sourced from caniemail
   project [CANIEMAIL] and direct testing as of January 2026.








Hackett                   Expires 16 July 2026                 [Page 22]

Internet-Draft                    URES                      January 2026


A.1.  CSS Support Matrix (Selected Properties)

   +====================+=========+=====+=========+=====+=====+========+
   | Property           | Gmail   |O.com| O.app   |Apple|Yahoo| T-bird |
   +====================+=========+=====+=========+=====+=====+========+
   | style in head      | Partial |Yes  | Yes     |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | display: flex      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | display: grid      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | position: fixed    | No      |No   | No      |No   |No   | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | position:          | No      |No   | Yes     |Yes  |No   | Yes    |
   | absolute           |         |     |         |     |     |        |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | background-image   | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | border-radius      | Yes     |Yes  | Partial |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | @media queries     | No      |Yes  | Yes     |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | CSS variables      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | @font-face         | No      |Yes  | No      |Yes  |No   | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+
   | ::before/::after   | No      |Yes  | No      |Yes  |Yes  | Yes    |
   +--------------------+---------+-----+---------+-----+-----+--------+

                                  Table 1

   Legend: Gmail (web), O.com (Outlook.com), O.app (Outlook desktop),
   Apple (Apple Mail), Yahoo (Yahoo Mail), T-bird (Thunderbird)

Acknowledgements

   The author wishes to acknowledge the work of the Email Standards
   Project (2007-2011), the W3C HTML for Email Community Group
   (2014-2023), and the caniemail.com project for documenting the
   inconsistencies that this specification aims to address.

Author's Address

   Will Hackett
   London
   United Kingdom
   Email: will@willhackett.uk
   URI:   https://willhackett.uk



Hackett                   Expires 16 July 2026                 [Page 23]


name: draft-liu-dmsc-acps-arc
rev: 03
title: Agent Collaboration Protocols Architecture for Internet of Agents
time: 2026-01-29T11:53:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-02T11:53:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:06.864859+00:00
abstract:
Internet of Agents (IoA) aims to facilitate interconnection and
   collaboration among heterogeneous agents to address complex tasks and
   support diverse applications.

   This IETF draft proposes the Agent Collaboration Protocols (ACPs)
   architecture, which includes conceptual domains, functional
   components and reference interfaces, to achieve agent interconnection
   and collaboration.  ACPs cover all stages of agents in the network,
   from their access to collaboration, supporting agent trusted
   registration, agent identity authentication, agent discovery, agent
   interaction, tool invocation, and agent monitoring.  The long-term
   vision of ACPs is to support the future large-scale interconnected
   agents and construct the key infrastructure for IoA.

full_text:
DMSC Working Group                                                J. Liu
Internet-Draft                                                     K. Yu
Intended status: Informational                                     K. Li
Expires: 2 August 2026                                           K. Chen
                      Beijing University of Posts and Telecommunications
                                                         29 January 2026


   Agent Collaboration Protocols Architecture for Internet of Agents
                       draft-liu-dmsc-acps-arc-03

Abstract

   Internet of Agents (IoA) aims to facilitate interconnection and
   collaboration among heterogeneous agents to address complex tasks and
   support diverse applications.

   This IETF draft proposes the Agent Collaboration Protocols (ACPs)
   architecture, which includes conceptual domains, functional
   components and reference interfaces, to achieve agent interconnection
   and collaboration.  ACPs cover all stages of agents in the network,
   from their access to collaboration, supporting agent trusted
   registration, agent identity authentication, agent discovery, agent
   interaction, tool invocation, and agent monitoring.  The long-term
   vision of ACPs is to support the future large-scale interconnected
   agents and construct the key infrastructure for IoA.

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

Copyright Notice

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



Liu, et al.               Expires 2 August 2026                 [Page 1]

Internet-Draft              ACPs Architecture               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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  ACPs Architecture from Functional Perspective . . . . . . . .   5
     4.1.  ACPs Architecture Overview  . . . . . . . . . . . . . . .   5
     4.2.  Conceptual Domains  . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  User Domain . . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Agent Domain  . . . . . . . . . . . . . . . . . . . .   6
       4.2.3.  Identity Management Domain  . . . . . . . . . . . . .   6
       4.2.4.  Interconnection Service Domain  . . . . . . . . . . .   7
       4.2.5.  Resource Access Domain  . . . . . . . . . . . . . . .   7
     4.3.  Functional Components . . . . . . . . . . . . . . . . . .   7
       4.3.1.  Functional Components in the Agent Domain . . . . . .   8
       4.3.2.  Functional Components in the Identity Management
               Domain  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.3.3.  Functional Components in the Interconnection Service
               Domain  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.3.4.  Functional Components in the Resource Access
               Domain  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Reference Interfaces  . . . . . . . . . . . . . . . . . .  11
       4.4.1.  Core Interfaces . . . . . . . . . . . . . . . . . . .  11
       4.4.2.  Interface Semantics . . . . . . . . . . . . . . . . .  12
   5.  Typical Operational Scenarios . . . . . . . . . . . . . . . .  13
     5.1.  Agent Onboarding: Identity, Credential, and Capability
           Description . . . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Agent Discovery and Partner Selection . . . . . . . . . .  13
     5.3.  Agent Interaction with Point-to-point and Grouping
           Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.4.  Tool Invocation . . . . . . . . . . . . . . . . . . . . .  14
     5.5.  Agent Monitoring  . . . . . . . . . . . . . . . . . . . .  14
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16



Liu, et al.               Expires 2 August 2026                 [Page 2]

Internet-Draft              ACPs Architecture               January 2026


1.  Introduction

   With the rapid development of artificial intelligence (AI),
   particularly large language model (LLM) technology, the number of AI
   agents has grown dramatically.  With the capability of autonomous
   perception, decision-making, and execution, agents' applications are
   becoming increasingly widespread.

   To overcome the limitations of single-agent systems, and to break
   free from the constraints of proprietary multi-agent frameworks
   developed by various vendors, the Internet of Agents (IoA) has
   emerged.  IoA aims to enable seamless connectivity and efficient
   collaboration among agents, through standardized communication
   protocols and interfaces.

   This draft proposes the functional architecture of Agent
   Collaboration Protocols (ACPs) [ACPs-Github], which is designed for
   IoA to enable wide-area connectivity, cross-domain interoperability,
   and secure collaboration among heterogeneous agents.  The main
   characteristics of ACPs are as follows:

   *  Multi-centralized architecture, which consists of multiple
      autonomous domains, each domain containing its own management
      nodes (such as registration, authentication, and discovery
      functions), to support efficient, reliable, and manageable large-
      scale agent interconnection scenarios.

   *  Standardized communication mechanisms with peer-to-peer and
      grouping mode, allowing agents to self-organize and negotiate
      autonomously, to facilitate rapid and accurate information
      exchange, as well as efficient task Collaboration.

   *  Robust registration and authentication mechanisms, to ensure the
      trusted access of agents and prevent unauthorized access and data
      breaches.

   *  Reliable registration and management of agent capability, along
      with intra-domain and cross-domain discovery based on capability
      matching, to support universal and efficient discovery of
      collaborative agents.

   *  Real-time monitoring of agent status and behavior, to support more
      complex application requirements such as agent auditing and
      transactions.

   ACPs cover all stages of agents in the IoA, from their access to
   collaboration, to construct the key infrastructure for agent
   communication, task collaboration and resource allocation.



Liu, et al.               Expires 2 August 2026                 [Page 3]

Internet-Draft              ACPs Architecture               January 2026


2.  Conventions

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

3.  Terminology

   Agent: An agent is a software or hardware entity with autonomous
   decision-making and execution capabilities, capable of perceiving the
   environment, acquiring contextual information, reasoning, and
   learning.  Agent can perform tasks independently or collaboratively
   with other agents.  Each agent is created by a specific agent
   provider and needs to complete processes such as registration and
   authentication before providing services to obtain a legitimate
   identity and relevant credentials.

   Agent Identity Code (AIC): AIC is a certifiable, globally unique
   identity that represents the identity of an agent.  AIC MAY contain
   the following information: the registration service center, the agent
   provider, the serial number of agent entity and instance, and the
   check code.

   Agent Capability Specification (ACS): ACS is a detailed description
   of an agent's capabilities and information that can be saved and
   retrieved.  ACS MAY use the JSON [RFC8259] format, typically
   including the following information: AIC, the functional capabilities
   of agent, the technical characteristics, and the service interfaces.

   Agent Credential: Agent Credential is a tamper-resistant data object
   issued by a credential authority (e.g., certificate, token) , used by
   an agent to prove identity attributes and/or authorization to a
   relying party.

   Tool: A tool is a device, software component, or service that
   provides a specific function and can be accessed and used by an
   agent.

   Agent Autonomous Domain: Agent Autonomous Domain is an administrative
   and governance domain organized and managed by a specific IoA service
   provider.  It MAY include service functions such as identity
   management, credential management, capability description management,
   agent discovery, message distribution, and agent monitoring.








Liu, et al.               Expires 2 August 2026                 [Page 4]

Internet-Draft              ACPs Architecture               January 2026


4.  ACPs Architecture from Functional Perspective

   This section defines a functional architecture for agent autonomous
   domain in IoA.  The interconnection environment is divided into
   different conceptual domains.  Each conceptual domain includes
   several functional components, and there are different interfaces
   between functional components.

4.1.  ACPs Architecture Overview

   The overall functional architecture of ACPs is as follows.

   +--------------------------+        +--------------------------+
   | Identity Management      |        | Interconnection Service  |
   | Domain                   |        | Domain                   |
   |                          |        |                          |
   |   +-------+  +-------+   |--------|   +-------+  +-------+   |
   |   | AIMgF |  | CMgF  |   |        |   | ADMgF |  |  ADF  |   |
   |   +-------+  +-------+   |        |   +-------+  +-------+   |
   |   +-------+              |        |   +-------+  +-------+   |
   |   |  IVF  |              |        |   |  MDF  |  | DTMgF |   |
   |   +-------+              |        |   +-------+  +-------+   |
   +-------------+------------+        +-------------+------------+
                 |                                   |
                 |                                   |
                 |                                   |
   +-------------+-----------------------------------+------------+
   |                         Agent Domain                         |
   |                                                              |
   |     +------+ +------+ +------+ +------+ +------+ +------+    |
   |     | AIMF | | ADMF | | IAF  | | AIF  | | TAF  | | AMF  |    |
   |     +------+ +------+ +------+ +------+ +------+ +------+    |
   +-------------+-----------------------------------+------------+
                 |                                   |
                 |                                   |
                 |                                   |
   +-------------+------------+        +-------------+------------+
   | Resource Access Domain   |        |        User Domain       |
   |                          |        |                          |
   |         +------+         |        |                          |
   |         | TSF  |         |        |                          |
   |         +------+         |        |                          |
   +--------------------------+        +--------------------------+

                   Figure 1: ACPs functional architecture

   The agent interconnection environment is organized into five
   conceptual domains:



Liu, et al.               Expires 2 August 2026                 [Page 5]

Internet-Draft              ACPs Architecture               January 2026


   1.  User Domain

   2.  Agent Domain

   3.  Identity Management Domain

   4.  Interconnection Service Domain

   5.  Resource Access Domain

   The lines between conceptual domains represent information exchange
   relationships.

   Domains are not necessarily physical network segments; they represent
   responsibility and governance boundaries.  A deployment MAY collapse
   multiple domains into one system, or MAY distribute them across
   multiple organizations.

4.2.  Conceptual Domains

4.2.1.  User Domain

   The User Domain is the set of users and user environments that
   initiate tasks and consume final results.  A user MAY be a person or
   an organization.

4.2.2.  Agent Domain

   The Agent Domain contains agents and agent-side functions required
   for agent interconnection and collaboration, such as agent
   description, agent interaction, agent identity maintenance,
   interconnection authentication, and tool access.

   The agent is the core execution unit of agent interconnection and
   collaboration.  An agent is typically provided and operated by an
   agent provider.  Agents in this domain MUST be able to present
   identity and comply with authentication / authorization decisions
   when interacting with other domains.

4.2.3.  Identity Management Domain

   The Identity Management Domain contains functions for identity
   lifecycle management, credential lifecycle management, and identity
   verification.  It provides services for registering agents, issuing
   credentials, and verifying identity claims during interconnection.






Liu, et al.               Expires 2 August 2026                 [Page 6]

Internet-Draft              ACPs Architecture               January 2026


4.2.4.  Interconnection Service Domain

   The Interconnection Service Domain contains functions that enable
   agents to find and collaborate with each other, including agent
   capability description management, agent discovery, and message
   distribution for group interactions.

4.2.5.  Resource Access Domain

   The Resource Access Domain contains tool and resource service
   functions that agents can invoke, such as tool registries, tool
   execution services, data services, and other external resources.

4.3.  Functional Components

   The functional components are grouped by conceptual domains.  The
   list below is a quick index.  The detailed descriptions are provided
   in Table 1.

   User Domain
     - User

   Agent Domain
     - Agent
     - Agent Identity Maintenance Function (AIMF)
     - Agent Description Maintenance Function (ADMF)
     - Interconnection Authentication Function (IAF)
     - Agent Interaction Function (AIF)
     - Tool Access Function (TAF)
     - Agent Monitoring Function (AMF)

   Identity Management Domain
     - Agent Identity Management Function (AIMgF)
     - Credential Management Function (CMgF)
     - Identity Verification Function (IVF)

   Interconnection Service Domain
     - Agent Description Management Function (ADMgF)
     - Agent Discovery Function (ADF)
     - Message Distribution Function (MDF)
     - Domain Trust Management Function (DTMgF)

   Resource Access Domain
     - Tool Service Function (TSF)

         Figure 2: Functional component index by conceptual domain
                               (informative)




Liu, et al.               Expires 2 August 2026                 [Page 7]

Internet-Draft              ACPs Architecture               January 2026


      +=================+=============+=============================+
      | Conceptual      | Functional  | Function Description        |
      | Domain          | Components  |                             |
      +=================+=============+=============================+
      | User Domain     | User        | Initiate tasks; provide     |
      |                 |             | authorization and policy    |
      |                 |             | input; consume results.     |
      +-----------------+-------------+-----------------------------+
      | Agent Domain    | Agent,      | Execute tasks; maintain     |
      |                 | AIMF, ADMF, | local identity and          |
      |                 | IAF, AIF,   | capability description;     |
      |                 | TAF, AMF    | interact with other agents; |
      |                 |             | access tools; record logs.  |
      +-----------------+-------------+-----------------------------+
      | Identity        | AIMgF,      | Manage identity and         |
      | Management      | CMgF, IVF   | credential lifecycle;       |
      | Domain          |             | verify identity claims and  |
      |                 |             | credential status.          |
      +-----------------+-------------+-----------------------------+
      | Interconnection | ADMgF, ADF, | Manage/publish capability   |
      | Service Domain  | MDF, DTMgF  | descriptions; enable        |
      |                 |             | discovery; support group    |
      |                 |             | messaging and domain        |
      |                 |             | federation policies.        |
      +-----------------+-------------+-----------------------------+
      | Resource Access | TSF         | Expose and control access   |
      | Domain          |             | to tools/resources; obtain  |
      |                 |             | results.                    |
      +-----------------+-------------+-----------------------------+

                   Table 1: Functional components summary

   The functional boundaries defined here are intended to support
   interoperability and clear interface definition.  A deployment MAY
   realize a functional component as software, hardware, or a managed
   service, and MAY consolidate multiple functional components into one
   product.

4.3.1.  Functional Components in the Agent Domain

   *1.  Agent Identity Maintenance Function (AIMF)*

   AIMF maintains the agent's identity information (e.g., AIC) and
   credentials.  AIMF SHOULD support secure storage and update of
   identity.

   *2.  Agent Description Maintenance Function (ADMF)*




Liu, et al.               Expires 2 August 2026                 [Page 8]

Internet-Draft              ACPs Architecture               January 2026


   ADMF maintains agent capability description information (e.g., ACS)
   used for interconnection.  It supports creating, updating, and
   withdrawing descriptions.  ADMF SHOULD ensure that descriptions
   remain consistent with the agent's current identity and capability
   state.

   *3.  Interconnection Authentication Function (IAF)*

   IAF performs authentication and authorization checks for
   interconnection, including mutual verification of peer agents and
   validation of presented credentials.  IAF SHOULD support multiple
   authentication mechanisms.  Deployments are RECOMMENDED to use
   standardized security protocols such as TLS 1.3 [RFC8446] and mutual
   authentication where appropriate.

   *4.  Agent Interaction Function (AIF)*

   AIF provides standardized interaction semantics for agent-to-agent
   communication.  It is responsible for session establishment, message
   exchange, task/context management, and applying security
   requirements.  AIF SHOULD support at least one of point-to-point and
   grouping interaction patterns between agents.

   *5.  Tool Access Function (TAF)*

   TAF provides the agent-side capability to invoke tools and resources
   in the Resource Access Domain.  It supports discovering available
   tools, invoking a selected tool, handling tool results, and enforcing
   access control decisions.

   *6.  Agent Monitoring Function (AMF)*

   AMF exports monitoring and logging data produced by the agent and
   agent-side functions.  It SHOULD support integrity protection and
   privacy controls.

4.3.2.  Functional Components in the Identity Management Domain

   *1.  Agent Identity Management Function (AIMgF)*

   AIMgF performs identity lifecycle management for agents, including
   allocation, update, and de-registration of AICs.  AIMgF MUST define
   the policies for uniqueness and governance of issued AICs within its
   scope.

   *2.  Credential Management Function (CMgF)*





Liu, et al.               Expires 2 August 2026                 [Page 9]

Internet-Draft              ACPs Architecture               January 2026


   CMgF issues and manages Agent Credentials associated with AICs.  CMgF
   SHOULD support credential issuance, renewal, suspension, revocation,
   and status query.

   *3.  Identity Verification Function (IVF)*

   IVF verifies identity claims and credential validity for relying
   parties.  IVF MAY be offered by the same operator as CMgF or by an
   independent third party.  IVF SHOULD support validation of credential
   authenticity, validity period, and status (e.g., revoked/suspended).

4.3.3.  Functional Components in the Interconnection Service Domain

   *1.  Agent Description Management Function (ADMgF)*

   ADMgF manages the lifecycle of agent capability descriptions in the
   interconnection ecosystem.  It supports accepting capability
   description submissions, validating required fields, reviewing and
   approving publication policies, publishing descriptions, and de-
   listing descriptions.

   *2.  Agent Discovery Function (ADF)*

   ADF enables capability-based discovery of candidate partner agents.
   It receives discovery queries, matches them against available agent
   descriptions, and returns a candidate set.  ADF SHOULD support in-
   domain discovery; and cross-domain discovery is OPTIONAL, within a
   configured trust scope.

   *3.  Message Distribution Function (MDF)*

   MDF provides message distribution services for group interactions,
   such as publish/subscribe or queue-based delivery.  MDF is typically
   used when agents interact in grouping mode.

   *4.  Domain Trust Management Function (DTMgF)*

   DTMgF maintains trust relationships between autonomous domains (e.g.,
   trusted peer domain lists, federation policy).  If present, it
   constrains cross-domain discovery and service-to-service
   interactions.

4.3.4.  Functional Components in the Resource Access Domain

   *1.  Tool Service Function (TSF)*






Liu, et al.               Expires 2 August 2026                [Page 10]

Internet-Draft              ACPs Architecture               January 2026


   TSF provides access to tools and resources for agents.  TSF SHOULD
   support tool registration or exposure, tool invocation handling,
   result return, and access control enforcement.  TSF MAY represent a
   single tool, a tool gateway, or a tool execution environment.

4.4.  Reference Interfaces

   The reference interfaces between functional components are identified
   as ACP-IF-XX.  An ACP-IF interface definition specifies what
   information is exchanged and what behavior is expected.  It does not
   mandate a specific protocol.

4.4.1.  Core Interfaces

       +===========+==========+==========+=========================+
       | Interface | Function | Function | Interface description   |
       | ID        | A        | B        |                         |
       +===========+==========+==========+=========================+
       | ACP-IF-01 | AIMF     | AIMgF    | Apply for / update /    |
       |           |          |          | de-register an AIC;     |
       |           |          |          | synchronize identity    |
       |           |          |          | lifecycle state.        |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-02 | AIMF     | CMgF     | Apply for / renew /     |
       |           |          |          | revoke Agent            |
       |           |          |          | Credentials bound to an |
       |           |          |          | AIC.                    |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-03 | IAF      | IVF      | Verify a peer agent's   |
       |           |          |          | claimed identity and    |
       |           |          |          | presented credentials;  |
       |           |          |          | obtain a verification   |
       |           |          |          | result / assertion.     |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-04 | AIMgF    | CMgF     | Coordinate identity-to- |
       |           |          |          | credential binding;     |
       |           |          |          | synchronize identity    |
       |           |          |          | and credential status.  |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-05 | CMgF     | IVF      | Query credential status |
       |           |          |          | and validation material |
       |           |          |          | (e.g., issuer keys,     |
       |           |          |          | revocation state).      |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-06 | ADMF     | ADMgF    | Submit / update /       |
       |           |          |          | withdraw Agent          |
       |           |          |          | Descriptions; receive   |
       |           |          |          | publication status.     |



Liu, et al.               Expires 2 August 2026                [Page 11]

Internet-Draft              ACPs Architecture               January 2026


       +-----------+----------+----------+-------------------------+
       | ACP-IF-07 | ADMgF    | ADF      | Synchronize published   |
       |           |          |          | Agent Descriptions and  |
       |           |          |          | metadata for discovery  |
       |           |          |          | indexing.               |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-08 | AIF      | AIF      | Agent-to-agent          |
       |           |          |          | interaction (session,   |
       |           |          |          | task, message exchange) |
       |           |          |          | under an agreed         |
       |           |          |          | interaction mode.       |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-09 | AIF      | MDF      | Group interaction via   |
       |           |          |          | message distribution    |
       |           |          |          | (create / join group,   |
       |           |          |          | publish / subscribe,    |
       |           |          |          | deliver messages).      |
       +-----------+----------+----------+-------------------------+
       | ACP-IF-10 | TAF      | TSF      | Tool / resource         |
       |           |          |          | invocation (discover    |
       |           |          |          | tools, invoke tools,    |
       |           |          |          | obtain results, manage  |
       |           |          |          | context).               |
       +-----------+----------+----------+-------------------------+

                   Table 2: Reference interfaces summary

4.4.2.  Interface Semantics

   *  *Identity and credential interfaces (ACP-IF-01..05)* provide the
      basis for trust establishment.  Implementations SHOULD support
      auditability of lifecycle operations.

   *  *Description and discovery interfaces (ACP-IF-06..07)* enable
      capability-based agent discovery.  Implementations SHOULD support
      versioning and de-listing of descriptions.

   *  *Agent interaction interfaces (ACP-IF-08..09)* define how agents
      exchange tasks, messages, and context.  Implementations SHOULD
      support confidentiality, integrity, replay protection, and access
      control.

   *  *Tool access interface (ACP-IF-10)* enables secure invocation of
      external tools or resources.  Implementations SHOULD support
      least-privilege access and result integrity.






Liu, et al.               Expires 2 August 2026                [Page 12]

Internet-Draft              ACPs Architecture               January 2026


5.  Typical Operational Scenarios

   This section illustrates how the functional architecture with
   conceptual domains, functional components, and interfaces is applied
   in typical operational scenarios.

5.1.  Agent Onboarding: Identity, Credential, and Capability Description

   A typical agent onboarding workflow includes:

   1.  The agent (via AIMF) registers identity with AIMgF (ACP-IF-01)
       and obtains an AIC.

   2.  The agent (via AIMF) obtains credentials from CMgF (ACP-IF-02).
       CMgF and AIMgF coordinate binding and status (ACP-IF-04).

   3.  The agent (via ADMF) submits an ACS to ADMgF (ACP-IF-06).  The
       ACS links to the agent's AIC and includes access and capability
       information.

   4.  ADMgF publishes the ACS and synchronizes to ADF (ACP-IF-07) for
       discovery indexing.

5.2.  Agent Discovery and Partner Selection

   In ACPs, the interaction between agents is task-driven, based on
   which agents can be divided into two roles:

   *  Leader: Agent who issues tasks and organizes interactions.  There
      should only be one Leader in a complete task execution process.

   *  Partner: Agent who accepts tasks and provides services.  After
      Partner receives a task from the Leader, it executes and returns
      the execution result.

   A typical agent discovery workflow includes:

   1.  A Leader determines required capabilities for a task.

   2.  The Leader queries ADF with constraints derived from the task
       (discovery request semantics are realized by ADP).

   3.  ADF returns a ranked candidate set of Partner agents.

   4.  The Leader (via IAF) authenticates selected Partners (ACP-IF-03)
       before starting interaction.





Liu, et al.               Expires 2 August 2026                [Page 13]

Internet-Draft              ACPs Architecture               January 2026


5.3.  Agent Interaction with Point-to-point and Grouping Mode

   In AIP, there are three interaction modes between the Leader and the
   Partner: peer-to-peer mode, grouping mode and hybrid mode.

   *  peer-to-peer mode: In this mode, the Leader maintains separate
      communication connections with each Partner, ensuring context
      isolation.  Each message in this mode has only one sender and
      receiver.

   *  Grouping mode: In this mode, interaction messages between agents
      are distributed through a message queue.  A message in this mode
      has only one sender but may has multiple receivers.

   *  Hybrid mode: In this mode, the Leader and Partner may interact
      directly or through the message queue according to the Leader's
      task planning.

   In point-to-point mode, the Leader and each Partner communicate
   directly via ACP-IF-08.

   In grouping mode, a message distribution service (MDF) is used.
   Agents create/join groups and exchange messages via ACP-IF-09, while
   still using ACP-IF-03 for authentication / authorization decisions.

5.4.  Tool Invocation

   When an agent needs external tools / resources, a typical tool
   invocation workflow includes:

   1.  The agent uses TAF to discover available tools (locally cached or
       via TSF).

   2.  The agent invokes a tool (ACP-IF-10).

   3.  TSF executes or brokers the tool and returns results to the
       agent.

5.5.  Agent Monitoring

   If agent monitoring is required, agents and services export logs /
   events via AMF.  Monitoring data can be used for troubleshooting,
   policy enforcement, auditing, and governance.








Liu, et al.               Expires 2 August 2026                [Page 14]

Internet-Draft              ACPs Architecture               January 2026


6.  Conclusions

   This draft introduces the Agent Collaboration Protocols (ACPs)
   architecture for Internet of Agents.  By defining a functional
   architecture with conceptual domains, functional components and
   reference interfaces, ACPs can support trusted registration, identity
   authentication, agent discovery, agent interaction, tool invocation,
   and agent monitoring.  ACPs address the core requirements for
   interoperability and secure collaboration among heterogeneous agents.
   The long-term goal of the ACPs is to enable IoA to serve as the
   critical infrastructure for agent collaboration on complex tasks, as
   well as to support the future large-scale and diverse applications.

7.  Security Considerations

   This document focuses on the Agent Collaboration Protocols
   architecture for IoA.  Security of IoA is not detailed in this
   document.  Security considerations relevant to deployment with
   multiple agent service providers are suggested to be deeply discussed
   through other proposals.

8.  IANA Considerations

   This document makes no request for IANA action.

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

   [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/info/rfc8259>.

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

9.2.  Informative References

   [ACPs-Github]
              "ACPs GitHub repository", n.d.,
              <https://github.com/AIP-PUB>.



Liu, et al.               Expires 2 August 2026                [Page 15]

Internet-Draft              ACPs Architecture               January 2026


Authors' Addresses

   Jun Liu
   Beijing University of Posts and Telecommunications
   10 Xitucheng Road, Haidian District
   Beijing
   100876
   China
   Email: liujun@bupt.edu.cn


   Ke Yu
   Beijing University of Posts and Telecommunications
   10 Xitucheng Road, Haidian District
   Beijing
   100876
   China
   Email: yuke@bupt.edu.cn


   Ke Li
   Beijing University of Posts and Telecommunications
   10 Xitucheng Road, Haidian District
   Beijing
   100876
   China
   Email: like1990@bupt.edu.cn


   Keliang Chen
   Beijing University of Posts and Telecommunications
   10 Xitucheng Road, Haidian District
   Beijing
   100876
   China
   Email: chenkl@bupt.edu.cn















Liu, et al.               Expires 2 August 2026                [Page 16]


name: draft-vandoulas-aidp
rev: 02
title: Agent Interaction & Delegation Protocol (AIDP)
time: 2026-01-18T09:11:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-22T09:11:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864862+00:00
abstract:
This document specifies the Agent Interaction & Delegation Protocol
   (AIDP), a control-plane protocol for secure, auditable, and
   interoperable software agents.  AIDP defines standardized mechanisms
   for expressing intent, enforcing authority, delegating capabilities,
   executing actions, and binding execution results to agent reasoning
   across heterogeneous systems and administrative domains.

full_text:
Internet-Draft                                           Ioannis Vandoulas
Intended status: Informational                                 January 2026
Expires: 15 July 2026


             Agent Interaction & Delegation Protocol (AIDP)
                 draft-vandoulas-aidp-02


Abstract

   This document specifies the Agent Interaction & Delegation Protocol
   (AIDP), a control-plane protocol for secure, auditable, and
   interoperable software agents.  AIDP defines standardized mechanisms
   for expressing intent, enforcing authority, delegating capabilities,
   executing actions, and binding execution results to agent reasoning
   across heterogeneous systems and administrative domains.


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


License Notice

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

        This document is subject to BCP 78 and the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info) in effect on the date of
        publication of this document.  Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.

Table of Contents

   1.  Introduction
   2.  Terminology and Conventions
   3.  Architecture Overview
   4.  Relation to Existing Work
   5.  Agent Identity Model
   6.  Authority & Capability Model
   7.  Intent Envelope
   8.  Execution Model
   9.  Observation & Feedback Binding
   10.  Multi-Agent Interaction
   11. Security Considerations
   12. Governance & Compliance
   13. Extensibility
   14. IANA Considerations
   15. Acknowledgements
   16. References
   17. Wire Format
   18. Message Schemas
   19. Example Messages
   20. Example Flows
   21. Reference Architecture
   22. HTTP Transport Binding
       22.1 Overview
       22.2 Media Types
       22.3 Endpoints
       22.4 Error Handling
       22.5 Webhook Verification
       22.6 Reference Validation Pipeline
   23. Conformance Test Suite Outline


1. Introduction
1.1 Motivation
Recent advances in Large Language Models (LLMs) have enabled the construction of software agents capable of complex reasoning,
planning, and adaptive behavior. While such agents increasingly participate in real-world computational
processes—interacting with servers, services, and other agents—there exists no standardized protocol governing how agents express intent,
exercise authority, delegate capabilities, or bind execution outcomes to their internal reasoning.
Current implementations rely on ad-hoc mechanisms that lack formal identity, revocation semantics,
delegation safety, and cross-domain trust guarantees. This absence of standardization creates systemic risks,
including privilege escalation, confused-deputy vulnerabilities, audit failures, and uncontrolled delegation chains.
The Agent Interaction & Delegation Protocol (AIDP) defines a formal, interoperable framework for agent-based interaction,
enabling secure, auditable, and revocable agency across heterogeneous systems and administrative domains.

1.2 Goals
AIDP defines a protocol that:
-	Enables agents to express verifiable intent toward external systems.
-	Provides formal identity and authority models for agents.
-	Supports constrained, revocable delegation across trust boundaries.
-	Binds execution results to originating intent.
-	Enables deterministic, auditable agent control loops.
-	Remains transport-agnostic and model-agnostic.

1.3 Non-Goals
AIDP does not specify:
-	Specific cryptographic algorithms.
-	Concrete serialization formats.
-	Transport protocols.
-	LLM architectures or prompting strategies.
These concerns are explicitly layered beneath the AIDP control plane.

2. Terminology and Conventions

2.1 Definitions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.
Agent:
An autonomous software entity capable of producing Intent Envelopes and processing Observations.
Intent Envelope:
A protocol message expressing a requested action, including its governance and security context.
Authority:
A verifiable capability granting an Agent permission to perform specific actions under defined constraints.
Delegation:
The controlled transfer of a subset of authority from one Agent to another.
Execution Boundary:
The component responsible for enforcing authorization, executing actions, and producing Observations.
Observation:
A protocol message binding the outcome of execution to the originating Intent Envelope.
Trust Boundary:
A boundary across which identity, authority, and delegation MUST be revalidated.


3. Architecture Overview

3.1 System Components
An AIDP-compliant system consists of the following logical components:
-	Reasoning Engine: Produces Intent Envelopes and consumes Observations.
-	Agent Runtime: Hosts the Reasoning Engine and manages agent state.
-	Execution Boundary: Enforces authority, executes actions, and emits Observations.
-	Authority Service: Issues, validates, and revokes authority objects.
-	Observation Channel: Delivers bound execution outcomes to agents.
These components MAY be co-located or distributed.

3.2 Layered Model
AIDP defines a layered architecture:
Layer               Description
------------------  -----------------------------------
Agency Control      Intent, Delegation, Authority
Trust               Identity, Validation, Revocation
Execution           Action dispatch and enforcement
Transport           Delivery mechanism (out of scope)

Each layer MUST operate independently of specific transport or serialization technologies.

3.3 Control Loop
The normative agent control loop is:
A.IntentEnvelope B.Authority Validation C.Execution D.Observation E.Reasoning F.Next IntentEnvelope
An Agent MAY have multiple outstanding Intent Envelopes at any given
time.

An Agent MUST NOT generate a new Intent Envelope whose semantics
causally depend on the outcome of a prior outstanding Intent Envelope
unless the corresponding Observation has been received and validated.

This constraint applies only to causally dependent intents and does not
prohibit parallel or independent intent dispatch.

4. Relation to Existing Work

   This section describes how AIDP relates to existing work in the areas
   of authorization, identity management, and capability-based security.
   The intent is to clarify scope and positioning, and to avoid
   ambiguity regarding overlap with prior protocols.

4.1  Grant Negotiation and Authorization Protocol (GNAP)

   AIDP shares architectural similarities with GNAP in that both define
   a control-plane interaction model based on structured requests and
   policy evaluation, rather than static, scope-based authorization.

   GNAP focuses on negotiating authorization grants for access to
   protected resources among clients, authorization servers, and
   resource servers.  AIDP, by contrast, addresses delegated agentic
   action, where autonomous or semi-autonomous agents express intent,
   exercise constrained authority, and receive execution-bound
   observations.

   Execution semantics, post-execution observation, reasoning failure
   handling, and runtime accountability are explicitly within scope for
   AIDP and are outside the scope of GNAP.  GNAP may therefore be used as
   an authorization mechanism within an AIDP-compliant system, but it
   does not define the full interaction lifecycle specified by AIDP.

4.2  OAuth 2.0 Rich Authorization Requests (RAR)

   OAuth 2.0 Rich Authorization Requests define a mechanism for
   expressing fine-grained authorization requirements beyond simple
   scope strings.

   AIDP adopts a similar principle by supporting structured expressions
   of authority, but applies it in a broader context.  In AIDP, such
   expressions are embedded within Intent Envelopes and are evaluated in
   conjunction with agent identity, delegation chains, and execution
   constraints.

   Unlike OAuth RAR, AIDP does not assume a client-resource server
   architecture and is not limited to access control semantics.

4.3  Capability-Based Authorization (ZCAPs and UCAN)

   AIDP is conceptually aligned with capability-based authorization
   systems such as ZCAPs and UCAN, particularly with respect to explicit
   capabilities and delegation chains.

   As in these systems, authority in AIDP is represented as a
   transferable object that can be delegated across multiple actors
   without reliance on a centralized authorization server.

   AIDP differs in that capability delegation is integrated into an
   agent interaction and execution lifecycle, where capabilities are
   evaluated as part of intent processing and execution rather than
   solely as access credentials.

4.4  Identity Management and SCIM

   AIDP assumes the existence of stable and verifiable agent identities
   and is compatible with identity provisioning and lifecycle
   management systems such as the System for Cross-domain Identity
   Management (SCIM).

   SCIM defines mechanisms for identity representation, provisioning,
   and synchronization across administrative domains.  AIDP builds upon
   such identity systems to specify how authority is delegated and
   exercised during agent interaction and execution.

4.5  Summary

   AIDP does not replace existing authorization or identity protocols.
   Instead, it composes concepts from prior work into a unified
   control-plane protocol for agent interaction, delegation, execution,
   and accountability.

   Existing mechanisms such as GNAP, OAuth 2.0 Rich Authorization
   Requests, capability-based authorization systems, and SCIM may be
   used as complementary components within an AIDP-compliant
   architecture.


5. Agent Identity Model

5.1 Identity Requirements
Every Agent participating in AIDP MUST possess a verifiable identity.
An Agent Identity MUST provide the following properties:
-	Uniqueness: A globally unique identifier.
-	Issuance: Identification of the issuing authority.
-	Lifetime: Explicit validity interval.
-	Revocability: Capability to be invalidated independently of expiration.
-	Referencability: Stable reference suitable for inclusion in protocol messages.
An Agent Identity MUST NOT be implicitly inferred from transport, host, or network context.

5.2 Identity Resolution and Validation
Identity references MUST be resolved and validated at every Trust
Boundary crossing.

For cross-domain interoperability, an identity reference MUST conform
to one of the following profiles:

(A) Dereferenceable Identity Profile:
    The identity_ref MUST be resolvable by the verifying domain via a
    deterministic and reachable resolution mechanism defined by the
    issuer.

(B) Self-Contained Identity Profile:
    The identity_ref MUST be accompanied by cryptographically verifiable
    identity assertions sufficient to establish authenticity without
    issuer reachability.

If neither profile can be satisfied, the receiving domain MUST reject
the request or apply fail-closed behavior according to its risk policy.

6. Authority & Capability Model
6.1 Authority Objects
Authority is represented as a first-class object, hereafter termed a Capability.
A Capability MUST contain:
-	Subject: Agent Identity to which authority is granted.
-	Action: Permitted operation(s).
-	Resource: Target resource(s).
-	Constraints: Scope, quantity, temporal, and contextual limits.
-	Issuer: Authority that issued the capability.
-	Revocation Pointer: Mechanism for revocation verification.
Capabilities MUST be evaluated independently of any agent claims.

6.2 Capability Delegation
Agents MAY delegate authority only by issuing new Capabilities with strictly reduced scope.
Delegation MUST satisfy:
-	Subsetting Rule: Delegated authority MUST NOT exceed original authority.
-	Traceability: Each delegated capability MUST reference its parent.
-	Revocability: Revocation of a parent capability MUST invalidate all derived capabilities.
Delegation chains MUST be preserved and transmitted with each Intent Envelope.

6.3 Revocation Semantics
Revocation MUST be supported for:
-	Agent Identity
-	Capabilities
-	Delegation chains
Revocation MUST take effect immediately upon verification and MUST NOT depend on token expiration alone.

7. Intent Envelope

7.1 Envelope Structure
An Intent Envelope is the fundamental protocol message produced by an Agent.
Each Intent Envelope MUST contain:
-	envelope_id: Globally unique, non-reusable identifier.
-	timestamp: Time of issuance.
-	actor_ref: Reference to Agent Identity.
-	authority_ref: Reference to Capability.
-	intent_body: Declared action, target, and parameters.
-	constraints: Execution limitations.
-	delegation_chain: Ordered list of delegated Capabilities.
-	observability_hooks: Declaration of required observation behavior.

7.2 Envelope Validation Rules
Upon receipt, the Execution Boundary MUST verify:
1.	Actor identity validity.
2.	Capability authenticity and scope.
3.	Delegation chain integrity.
4.	Revocation status for all identities and capabilities.
5.	Constraint satisfaction.
6.	Non-reuse of envelope_id (replay protection).
Failure of any validation step MUST abort execution.

7.3 Authority Separation Principle
Agents MUST NOT modify:
-	actor_ref
-	authority_ref
-	delegation_chain
These elements are managed exclusively by the Authority Service and Execution Boundary.

8. Execution Model
8.1 Execution Boundary
The Execution Boundary is the sole component authorized to perform actions on behalf of an Agent.
The Execution Boundary MUST:
-	Enforce identity and authority validation.
-	Apply constraint verification.
-	Execute the requested action.
-	Emit a bound Observation.
The Execution Boundary MUST NOT accept any action request outside of a validated Intent Envelope.

8.2 Authorization & Enforcement Flow
Normative execution flow:
1.	Receive Intent Envelope.
2.	Validate identity.
3.	Validate authority and delegation chain.
4.	Verify revocation status.
5.	Enforce constraints.
6.	Execute action.
7.	Generate Observation.
8.	Deliver Observation via Observation Channel.
Any failure in steps 2–5 MUST result in rejection.

9. Observation & Feedback Binding

9.1 Observation Structure
Each Observation MUST contain:
-	envelope_id
-	execution_id
-	status
-	result
-	side_effects
-	timestamp
-	attestation

9.2 Binding Requirements
Reasoning progression within an Agent MUST be gated on validated
Observations for all intents upon which subsequent reasoning steps
depend.

Independent intents MAY be issued and processed concurrently, provided
that their resulting Observations are correctly bound to their
respective envelope_id values.

9.3 Replay Protection & Determinism
The tuple (envelope_id, execution_id, timestamp) MUST provide replay protection.
Agent reasoning loops MUST be deterministic with respect to received Observations.

10. Multi-Agent Interaction

10.1 Trust Boundaries
At every Trust Boundary crossing, the receiving domain MUST independently validate:
-	Agent Identity
-	Capability authenticity
-	Delegation chain
-	Revocation status
No implicit trust MAY cross a Trust Boundary.

10.2 Cross-Domain Delegation
Delegation across domains MUST follow:
-	Capability subsetting rules
-	Explicit delegation chain construction
-	Independent revocation enforcement
Shared secrets or inherited credentials MUST NOT be used as delegation mechanisms.

10.3 Agent-to-Agent Protocol Flow
Normative multi-agent interaction:
Agent A → Intent Envelope → Trust Boundary → Agent B
Agent B → Execution Boundary → Observation → Agent A
Every stage MUST preserve auditability and authority constraints.

11. Security Considerations
11.1 Scope
This section defines the threat model for AIDP systems, including attacker capabilities, assets, trust boundaries, and normative mitigations. Unless explicitly stated otherwise, all requirements in this section are normative.

11.2 Assets
An AIDP deployment MUST treat the following as protected assets:
-	AIDP Identity Material: Agent Identity objects and their validation artifacts.
-	Capabilities: Authority objects, including parent/derived relationships and constraint sets.
-	Delegation Chains: Ordered proof of authority derivation across one or more domains.
-	Intent Envelopes: Including envelope_id, actor_ref, authority_ref, constraints, and hooks.
-	Observations: Including attestation and bindings to prior intents.
-	Audit Trail: Immutable records sufficient to reconstruct intent-execution-observation causality.
-	Execution Targets: External resources/services whose state can be modified by actions.

11.3 Trust Boundaries and Security Domains
AIDP recognizes the following boundaries:
-	TB-1: Agent Runtime ↔ Execution Boundary
The Agent Runtime is untrusted for enforcement. The Execution Boundary is the policy enforcement point.
-	TB-2: Domain A ↔ Domain B
Cross-domain interactions MUST assume zero implicit trust.
-	TB-3: Authority Service ↔ Verifiers
Capability issuance and revocation status MUST be independently verifiable.
-	TB-4: Observation Channel ↔ Agent
Observation delivery MUST prevent substitution, replay, and confusion of results.
Crossing any Trust Boundary MUST trigger independent identity, authority, chain, and revocation validation.

11.4 Attacker Model
Attackers MAY possess one or more of the following capabilities:
-	Network Adversary: Can observe, replay, delay, or reorder messages across a transport.
-	Malicious Agent: Can generate arbitrary Intent Envelopes and attempt to induce execution.
-	Compromised Agent Runtime: Can manipulate prompts, local state, tool outputs, and message ordering.
-	Compromised Execution Target: Can respond with misleading outputs or partial failures.
-	Insider: Possesses legitimate credentials or access in one domain.
-	Supply Chain/Implementation Bugs: Leverages parser ambiguities, canonicalization issues, and validation gaps.
AIDP MUST remain secure against malicious agents and network adversaries. Compromise of the Execution Boundary is out of scope (if it fails, enforcement fails), but audit and containment SHOULD still limit blast radius.

11.5 Security Goals
An AIDP system MUST provide:
-	G-1 Least Privilege: Capabilities constrain what may be executed.
-	G-2 Non-Repudiation of Control Flow: Audit can reconstruct who requested what and what executed.
-	G-3 Replay Resistance: Intents and observations cannot be reused to re-trigger actions.
-	G-4 Delegation Safety: Delegation cannot amplify privileges; revocation propagates.
-	G-5 Outcome Integrity: Observations are bound to the originating intent and execution.
-	G-6 Compromise Containment: A compromised agent cannot exceed granted authority.
-	G-7 Cross-Domain Robustness: No implicit trust crosses domain boundaries.

11.6 Threats and Mitigations

11.6.1 Confused Deputy
Threat: A less-privileged agent induces a more-privileged system/component to perform actions outside the attacker’s authority.
Mitigations (normative):
-	The Execution Boundary MUST authorize based solely on validated authority_ref and delegation_chain, not on agent-provided explanations or natural-language intent.
-	The Execution Boundary MUST verify that the capability subject matches actor_ref (or matches a valid delegation subject in the chain).
-	Capabilities MUST encode the target resource(s) and permitted action(s) explicitly; wildcards SHOULD be avoided or constrained.

11.6.2 Privilege Escalation via Delegation
Threat: An agent delegates authority beyond what it possesses (scope amplification), or a receiver misinterprets delegation semantics.
Mitigations:
-	Delegated capabilities MUST be strict subsets of parent capabilities (Subsetting Rule).
-	Delegation chains MUST be validated end-to-end at execution time.
-	Receivers MUST reject any chain that contains an invalid or unverifiable link.
-	Revocation of a parent capability MUST invalidate all derived capabilities.

11.6.3 Replay of Intent Envelopes
Threat: Reuse of an Intent Envelope to trigger repeated execution (financial transfers, destructive actions).
Mitigations:
-	envelope_id MUST be globally unique and MUST NOT be accepted more than once per relevant replay window.
-	Execution Boundaries MUST maintain replay state appropriate to the risk profile of the action class.
-	Constraints SHOULD include explicit idempotency requirements for side-effectful actions.
-	When an Execution Boundary (EB) receives an Intent Envelope (IE) whose
envelope_id has already been processed, the EB MUST treat the request
as a replay and MUST NOT re-execute the intent.

If a corresponding Observation (OB) has already been produced and is
still within the EB's observation retention window, the EB SHOULD
return the previously generated Observation or provide a deterministic
mechanism for the Agent to retrieve it (e.g., via an observation
retrieval endpoint).

A replayed envelope_id MUST NOT result in a new execution or a
semantically distinct outcome.

Whether a replayed Intent results in an inline Observation,
a retrieval pointer, or a REPLAY_DETECTED Problem Details response
is deployment- and transport-binding-specific. In all cases,
the EB MUST NOT re-execute the intent.

11.6.4 Replay or Substitution of Observations
Threat: An attacker replays a prior Observation or substitutes a different Observation to steer reasoning.
Mitigations:
-	Observations MUST include envelope_id and execution_id.
-	Observations MUST carry an attestation from the Execution Boundary.
-	Agents MUST reject Observations that do not match an outstanding Intent Envelope.
-	Agents MUST NOT progress reasoning for an intent until a valid bound Observation is received.

11.6.5 Parameter Confusion and Canonicalization Attacks
Threat: Ambiguities in serialization or parsing allow an attacker to smuggle parameters or exploit differences between validators and executors.
Mitigations:
-	Implementations MUST define a canonical representation for signing/verifying
	(even if encoding is out of scope, the “to-be-verified” form MUST be unambiguous).
-	Validators and executors MUST share identical parsing and validation logic.
-	Unknown fields in security-relevant sections MUST be rejected or handled by strict extension rules.

11.6.6 Time-of-Check / Time-of-Use (TOCTOU) on Revocation
Threat: A capability is valid at validation time but revoked before execution completes; or cache staleness causes use of revoked authority.
Mitigations:
-	Execution Boundaries MUST check revocation status at execution time, not solely at receipt time, for high-risk actions.
-	Revocation mechanisms MUST support near-immediate effect.
-	Deployments SHOULD define risk tiers: low-risk actions MAY tolerate bounded staleness; high-risk actions MUST NOT.

11.6.7 Compromised Agent Runtime / Prompt Injection
Threat: The agent runtime is manipulated so the reasoning engine emits malicious intents or misinterprets observations.
Mitigations:
-	Enforcement MUST occur at the Execution Boundary, not in the agent.
-	Capabilities MUST be constrained such that unintended intents have limited impact.
-	Observation binding MUST prevent fabricated “success” states.
-	High-risk capabilities SHOULD require additional policy controls (e.g., approvals) outside agent reasoning.

11.6.8 Cross-Domain Identity and Issuer Spoofing
Threat: An attacker forges identities/capabilities from an untrusted issuer or exploits issuer confusion.
Mitigations:
-	Domains MUST maintain explicit trust anchors for issuers.
-	All identities and capabilities MUST include issuer identification.
-	If issuer validation fails, the intent MUST be rejected.

11.6.9 Audit Trail Gaps and Non-Attribution
Threat: Missing logs prevent reconstruction of actions, enabling undetected abuse.
Mitigations:
-	Execution Boundaries MUST log Intent Envelope receipt, authorization decision, execution outcome, and Observation emission.
-	Audit records MUST include envelope_id, execution_id, actor_ref, authority_ref, and a digest of intent_body.

11.6.10 Denial of Service
Threat: Flooding the Execution Boundary with envelopes or forcing expensive validation.
Mitigations:
-	Implementations SHOULD rate-limit by actor/issuer.
-	Validation SHOULD be staged (cheap rejection first).
-	Deployments MAY require preflight checks for costly operations.

11.7 Residual Risk and Out-of-Scope Conditions
-	If the Execution Boundary is fully compromised, authorization cannot be trusted. Deployments SHOULD still maintain independent audit and anomaly detection.
-	If the Execution Target returns misleading results, AIDP can ensure binding/attestation but cannot guarantee target truthfulness beyond attestation scope.
-	Human approvals, legal policies, and organizational controls are deployment concerns and are not specified by AIDP, though AIDP enables their enforcement hooks.

11.8 Security Requirements Summary
Implementations claiming AIDP compliance MUST, at minimum:
-	Validate identity and issuer trust anchors at each Trust Boundary.
-	Enforce capabilities and delegation chain subsetting at execution time.
-	Support revocation with near-immediate effect for high-risk actions.
-	Provide replay protection for intents and bound observations.
-	Produce attestable observations linked to intents and executions.
-	Maintain auditable records sufficient for forensic reconstruction.

12. Governance & Compliance Considerations
AIDP deployments SHOULD provide:
-	Comprehensive audit trails.
-	Policy-driven revocation procedures.
-	Capability lifecycle management.
-	Regulatory compliance support.
Governance mechanisms MUST remain external to agent reasoning processes.

13. Extensibility Model
AIDP is intentionally extensible.
Extensions MUST:
-	Preserve all normative validation requirements.
-	Avoid weakening identity, authority, or revocation semantics.
-	Declare compatibility with base AIDP semantics.

14. IANA Considerations
This document does not require any IANA actions at this time.

15. Acknowledgements
The authors acknowledge the emerging agent systems community whose practical challenges motivated the creation of this protocol.

16. References

16.1 Normative references

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

16.2  Informative References

[GNAP]    Hardt, D., Parecki, A., and T. Lodderstedt,
          "Grant Negotiation and Authorization Protocol",
          Internet-Draft, work in progress,
          draft-ietf-gnap-core.

[RAR]     Lodderstedt, T., McGloin, M., and P. Hunt,
          "OAuth 2.0 Rich Authorization Requests",
          RFC 9396, August 2023.

[ZCAP]    Sporny, M., Longley, D., and D. Chadwick,
          "Authorization Capabilities for Linked Data",
          W3C Recommendation,
          https://www.w3.org/TR/vc-data-model/.

[UCAN]    Fission Codes,
          "User Controlled Authorization Networks (UCAN)",
          https://ucan.xyz/.

[SCIM]    Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
          and C. Mortimore,
          "System for Cross-domain Identity Management: Core Schema",
          RFC 7643, September 2015.


17. Wire Format

17.1 Serialization Families
AIDP messages MUST be representable in at least one of the following serialization families:
-	AIDP-JS (JSON): Human-readable encoding for debugging, documentation, and early adoption.
-	AIDP-CB (CBOR): Binary encoding for production deployments with strict canonicalization.
An implementation MAY support additional encodings, provided that:
1.	The semantic model is preserved exactly, and
2.	A deterministic canonical signing input (Section 16.3) is defined.

17.2 Message Types
AIDP defines three primary wire messages:
-	Intent Envelope (IE): request to execute a governed action.
-	Observation (OB): bound result of an execution.
-	Problem Details (PD): structured rejection / error.
Each message MUST carry:
-	aidp_version
-	msg_type
-	payload

17.3 Canonical Signing Input
To prevent canonicalization attacks, AIDP requires an unambiguous signing input.
Canonical AIDP-JS encoding requires:

- UTF-8 encoding
- Deterministic lexicographic ordering of object members
- No duplicate object member names
- Deterministic number and string representations
JSON messages containing duplicate object member names MUST be rejected.
This rejection MUST occur during parsing, prior to schema validation or
canonicalization.

-	For AIDP-CB, the signing input MUST use:
-	CBOR canonical encoding (deterministic)
The signing input MUST be computed over the payload object only (not transport metadata). The exact canonicalization profile MUST be declared as canon.

17.4 Attestations and Proofs
AIDP supports two proof-bearing fields:
-	proof: signature or MAC over canonical signing input
-	proof_chain: optional chain of proofs for delegation links
Intent Envelopes SHOULD be signed by the Agent Runtime when any
non-trivial authority is exercised. Observations MUST be attested by
the Execution Boundary.

17.5 Common Header
All AIDP wire messages MUST include:
-	aidp_version (string, e.g. "1.0-draft")
-	msg_type (string: "IE" | "OB" | "PD")
-	canon (string: canonicalization profile identifier)
-	payload (object)
-	proof (object, OPTIONAL unless required by local policy)

18. Wire Schemas
Below are normative field sets. Implementations MUST reject unknown fields in security-critical sub-objects unless explicitly permitted by the Extensibility Model.

18.1 Intent Envelope Payload (IE)
Required:
-	envelope_id (string/UUID)
-	timestamp (RFC3339 string)
-	actor_ref (object)
-	authority_ref (object)
-	intent_body (object)
-	constraints (object)
-	delegation_chain (array, MAY be empty)
-	observability_hooks (object)

18.1.1 actor_ref
-	agent_id (string)
-	issuer (string)
-	identity_ref (string) — dereferenceable URI/URN-like reference (transport-agnostic)

18.1.2 authority_ref
-	cap_id (string)
-	issuer (string)
-	cap_ref (string) — dereferenceable reference
-	rev_ref (string) — revocation pointer reference

18.1.3 intent_body
-	action (string)
-	target (object)
-	parameters (object)
target MUST include at least:
-	resource (string)
-	domain (string) — security domain identifier

18.1.4 constraints
Constraints SHOULD include (as applicable):
-	not_before / not_after (RFC3339)
-	max_cost (number)
-	max_uses (integer)
-	risk_tier (string: "low"|"med"|"high", OPTIONAL but RECOMMENDED)
-	idempotency_key (string, OPTIONAL)

The idempotency_key is OPTIONAL and is intended for application-level
idempotency across transport retries or envelope re-issuance scenarios.

Protocol-level replay protection and execution idempotency are
primarily enforced via the envelope_id. Implementations MUST NOT
require the presence of idempotency_key to provide replay safety or
result recovery.


18.1.5 delegation_chain
Each element MUST include:
-	cap_id
-	issuer
-	cap_ref
-	parent_cap_id (string)
-	rev_ref
-	link_proof (object) — proof binding child to parent

18.1.6 observability_hooks
The return_to field specifies the destination for Observation delivery.

The specified endpoint MUST be pre-registered, pre-approved, or
otherwise explicitly authorized for the identity identified by
actor_ref.

Execution Boundaries MUST NOT deliver Observations to arbitrary or
unverified endpoints supplied dynamically by an Agent.

18.2 Observation Payload (OB)
Required:
-	envelope_id
-	execution_id (string)
-	timestamp (RFC3339)
-	status (string: accepted|rejected|executed|failed|partially_executed)
-	result (object, MAY be empty)
-	side_effects (array, MAY be empty)
-	attestation (object)

18.2.1 attestation
-	boundary_id (string)
-	issuer (string)
-	attest_profile (string)
-	decision (string: authorized|not_authorized|constraint_violation|invalid_chain|revoked|replay)
-	policy_digest (string) — hash/reference to policy version used
-	evidence (object, OPTIONAL) — minimal additional evidence (non-sensitive by default)
Observations MUST be signed/attested by the Execution Boundary (i.e., proof REQUIRED for OB by default).

18.2.x execution_advice (OPTIONAL)

The execution_advice object provides non-binding guidance to the Agent
Runtime regarding retry, backoff, or revision expectations following
an Observation that does not represent successful execution.

The execution_advice object MAY include:
- retriable (boolean):
    Indicates whether retrying the same intent MAY succeed.
- retry_after_sec (integer):
    Suggested minimum delay before attempting a retry.
- reason_code (string):
    Machine-readable classification of the failure condition
    (e.g., CONSTRAINT_VIOLATION, BUDGET_EXCEEDED, RATE_LIMITED,
    POLICY_REFUSED, NOT_AUTHORIZED).

18.3 Problem Details Payload (PD)
Required:
-	envelope_id (if applicable)
-	timestamp
-	error_code (string)
-	error_message (string)
-	details (object, OPTIONAL)
Recommended error_code values:
-	INVALID_IDENTITY
-	UNTRUSTED_ISSUER
-	REVOKED
-	INVALID_CAPABILITY
-	INVALID_DELEGATION_CHAIN
-	CONSTRAINT_VIOLATION
-	REPLAY_DETECTED
-	MALFORMED_MESSAGE
-	UNSUPPORTED_VERSION

Problem Details messages MAY include an execution_advice object
with the same semantics as defined for Observation messages.

When present, execution_advice applies to the failed Intent Envelope
identified by envelope_id.

19. Example Wire Messages (AIDP-JS)

19.1 Intent Envelope (single-agent → server)
{
  "aidp_version": "1.0-draft",
  "msg_type": "IE",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:00+02:00",
    "actor_ref": {
      "agent_id": "agent:alpha",
      "issuer": "did:example:issuerA",
      "identity_ref": "urn:aidp:id:issuerA:agent-alpha"
    },
    "authority_ref": {
      "cap_id": "cap:alpha:pay-v1",
      "issuer": "did:example:authA",
      "cap_ref": "urn:aidp:cap:authA:cap-alpha-pay-v1",
      "rev_ref": "urn:aidp:rev:authA:list-01"
    },
    "intent_body": {
      "action": "payment.create",
      "target": { "domain": "svc:payments", "resource": "acct:merchant-123" },
      "parameters": { "amount": 50, "currency": "EUR", "memo": "invoice-8841" }
    },
    "constraints": {
      "not_before": "2026-01-13T09:14:00+02:00",
      "not_after": "2026-01-13T09:19:00+02:00",
      "max_uses": 1,
      "risk_tier": "high",
      "idempotency_key": "idem-3d7f0d"
    },
    "delegation_chain": [],
    "observability_hooks": {
      "delivery_mode": "push",
      "return_to": { "type": "inbox", "ref": "urn:aidp:inbox:agent:alpha" },
      "required_fields": ["envelope_id", "execution_id", "status", "attestation"],
      "timeout_sec": 30
    }
  },
  "proof": {
    "alg": "ed25519",
    "kid": "key:agent-alpha-1",
    "sig": "BASE64URL(...)"
  }
}

19.2 Observation (Execution Boundary → agent)
{
  "aidp_version": "1.0-draft",
  "msg_type": "OB",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "execution_id": "exec-9c2d1a",
    "timestamp": "2026-01-13T09:14:02+02:00",
    "status": "executed",
    "result": { "payment_id": "pay_7712", "state": "captured" },
    "side_effects": [
      { "resource": "acct:merchant-123", "delta": { "captured_eur": 50 } }
    ],
    "attestation": {
      "boundary_id": "boundary:payments-gw-1",
      "issuer": "did:example:paymentsDomain",
      "attest_profile": "AIDP-OB-Attest1",
      "decision": "authorized",
      "policy_digest": "sha256:5d3a...e91"
    }
  },
  "proof": {
    "alg": "ed25519",
    "kid": "key:boundary-payments-1",
    "sig": "BASE64URL(...)"
  }
}

19.3 Problem Details (rejection example)
{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:01+02:00",
    "error_code": "REVOKED",
    "error_message": "Capability or identity has been revoked.",
    "details": { "rev_ref": "urn:aidp:rev:authA:list-01", "cap_id": "cap:alpha:pay-v1" }
  },
  "proof": {
    "alg": "ed25519",
    "kid": "key:boundary-payments-1",
    "sig": "BASE64URL(...)"
  }
}

20. Example Flows

20.1 Flow 1 — Single-Agent Action (Agent ↔ Server)
Goal: Agent requests a state-changing action on an external service with bounded authority.
Steps (normative):
1.	Agent Runtime obtains/holds a capability authority_ref.
2.	Agent produces an Intent Envelope (IE) referencing actor_ref and authority_ref.
3.	Execution Boundary validates: identity, issuer trust anchors, capability scope, revocation, constraints, replay.
4.	Execution Boundary executes the action on the target service.
5.	Execution Boundary emits an Observation (OB) bound to envelope_id and execution_id.
6.	Agent MUST NOT proceed for that intent until OB is received and validated.
Key security properties:
-	Enforcement at Execution Boundary, not the LLM
-	Replay resistance via envelope_id
-	Outcome integrity via OB attestation

20.2 Flow 2 — Delegation (Agent A → Agent B → Execution)
Goal: Agent A delegates limited authority to Agent B to perform a specific action.
Steps:
1.	Agent A possesses parent capability cap:A0.
2.	Authority Service issues delegated capability cap:B1 with:
-	parent_cap_id = cap:A0
-	scope subset (e.g., only resource=X, only max_uses=1, only within 2 minutes)
3.	Agent A sends IE to Agent B with delegation_chain = [cap:B1 link proof ...]
4.	Agent B either:
-	accepts responsibility and forwards IE to its Execution Boundary, or
-	rejects (policy/local risk)
5.	Execution Boundary validates entire chain end-to-end (including parent/child linkage proofs).
6.	Execution produces OB, returned to the return_to hook (Agent A and/or B depending on hook policy).
Key security properties:
-	No credential sharing
-	Subsetting rule enforced at execution
-	Revocation propagates along chain

20.3 Flow 3 — Revocation Mid-Flight (TOCTOU)
Goal: Capability revoked after IE issuance but before execution finalization.
Steps:
1.	IE is received and preliminarily validated.
2.	Before executing high-risk action, Execution Boundary MUST re-check revocation status (per risk tier/policy).
3.	If revoked, execution MUST abort and PD returned with REVOKED.
4.	Audit record MUST note decision and revocation evidence used.
Key security properties:
-	Near-immediate revocation effect
-	Clear failure semantics and auditability

20.4 Flow 4 — Observation Substitution Attempt
Goal: Network attacker tries to replay an old OB to trick the agent.
Steps:
1.	Attacker replays OB with mismatched or already-settled envelope_id.
2.	Agent validates OB proof and checks if envelope_id is outstanding.
3.	Agent MUST reject OB if:
o	envelope_id not outstanding, or
o	OB proof invalid, or
o	attestation issuer untrusted
4.	Agent continues waiting or initiates recovery (out of scope).
Key security properties:
-	OB binding prevents confusion
-	Agent loop does not advance without valid OB

20.5 Flow 5 — Multi-Domain Boundary Crossing
Goal: Agent in Domain A requests execution in Domain B.
Steps:
1.	Domain B applies TB rules: zero implicit trust.
2.	Domain B validates issuer trust anchors for identities and capabilities.
3.	Domain B validates revocation pointers accessible/acceptable under its policy.
4.	If any issuer untrusted, reject with UNTRUSTED_ISSUER.

21. Reference Architecture

21.1 Overview
This section defines a reference architecture for AIDP deployments. The architecture is model-agnostic (LLM vendor-independent) and transport-agnostic. It separates reasoning from enforcement and binds execution outcomes to originating intents.
AIDP systems MUST implement an Execution Boundary as the enforcement point. Agent reasoning components MUST NOT be relied upon for authorization, revocation, replay prevention, or audit integrity.

21.2 Logical Components
An AIDP deployment consists of the following logical components. Components MAY be co-located or distributed.
1.	Reasoning Engine (RE)
Produces Intent Envelopes and consumes Observations. (Often an LLM, but not required.)
2.	Agent Runtime (AR)
Hosts the RE; manages local state, memory, and tool mediation. The AR is not a policy enforcement point.
3.	Execution Boundary (EB)
Policy enforcement and action execution component. Validates identity/capabilities/delegation, checks revocation, prevents replay, executes actions, and attests Observations.
4.	Authority Service (AS)
Issues Capabilities, manages lifecycle, and provides revocation status via rev_ref.
5.	Identity Provider / Issuer (IdP)
Issues Agent Identity artifacts referenced by actor_ref.
6.	Observation Channel (OC)
Delivers Observations to agents via push and/or pull. (e.g., inbox, queue, webhook)
7.	Audit Log (AL)
Append-only event record of intent receipt, authorization decisions, execution results, and observation emission.
8.	Execution Targets (ET)
External systems acted upon (APIs, services, websites via automation, databases, etc.).

21.3 Trust Boundaries
AIDP defines explicit trust boundaries. Crossing a trust boundary MUST trigger independent validation.
-	TB-AR/EB: Agent Runtime to Execution Boundary
AR is untrusted for enforcement; EB MUST validate all incoming IEs regardless of origin.
-	TB-Domain: Cross-domain boundary
Identity, capabilities, issuer trust, and revocation MUST be revalidated in the receiving domain.
-	TB-OC: Observation Channel boundary
Observations MUST be attested by EB and verified by the Agent Runtime/RE.

21.4 Reference Architecture Diagram
+--------------------- Domain A ----------------------+
|                                                     |
|  +-----------+      +----------------------------+  |
|  | Reasoning  |      | Agent Runtime (AR)        |  |
|  | Engine (RE)|<---->| - builds IE payload       |  |
|  +-----------+      | - validates OB proofs      |  |
|        ^            | - manages local state      |  |
|        |            +--------------+-------------+  |
|        |                           | IE (AIDP)      |
|        |                           v                 |
|  +-----+-----+          TB-AR/EB  +----------------+|
|  | Observation|<------------------| Execution       ||
|  | Channel (OC)|   OB (AIDP)      | Boundary (EB)   ||
|  +-----------+-+                  | - validates IE  ||
|              |                    | - checks rev    ||
|              |                    | - replay store  ||
|              |                    | - executes      ||
|              |                    | - attests OB    ||
|              |                    +---+---------+---+|
|              |                        |         |    |
|              |                        |         |    |
|              |                    +---v--+   +--v---+|
|              |                    | Audit |   | Auth ||
|              |                    | Log   |   |Svc(AS)|
|              |                    +------+   +-------+|
|              |                                 ^      |
|              |                                 | rev_ref
|              |                                 |
|              |                           +-----+-----+
|              |                           | Identity  |
|              |                           | Issuer(IdP)|
|              |                           +-----------+
|              |
|              | actions
|              v
|        +----------------+
|        | Execution      |
|        | Targets (ET)   |
|        +----------------+
+-----------------------------------------------------+

21.5 Normative Interfaces
This section defines the conceptual interfaces between components.

21.5.1 IE Submission Interface (AR → EB)
-	Input: AIDP Intent Envelope (IE)
-	Output: Immediate PD or async OB (or both if policy allows)
EB MUST implement:
-	Identity validation for actor_ref
-	Capability validation for authority_ref
-	Delegation chain validation
-	Revocation checks via rev_ref
-	Replay detection for envelope_id
-	Constraint enforcement
AR MAY implement preflight validation, but EB validation is authoritative.

21.5.2 Authority Resolution Interface (EB ↔ AS)
-	EB dereferences cap_ref and rev_ref
-	EB verifies:
-	capability authenticity
-	scope/constraints
-	revocation status (including parents in chain)
-	issuer trust anchor
AS MUST support:
-	capability retrieval (or verification artifacts)
-	revocation status lookup with bounded latency for high-risk actions

21.5.3 Identity Validation Interface (EB ↔ IdP)
-	EB dereferences identity_ref and validates issuer trust
-	EB checks identity revocation status
IdP MUST support:
-	identity verification artifacts
-	revocation status

21.5.4 Observation Delivery Interface (EB → OC → AR)
-	EB emits Observation (OB) with attestation proof
-	OC delivers via:
-	push (webhook/queue) and/or
-	pull (inbox retrieval)
AR MUST verify:
-	OB proof (attestation)
-	envelope_id matches outstanding intent
-	issuer trust anchor for the EB attestation

21.5.5 Audit Interface (EB → AL)
EB MUST record:
-	receipt of IE (digest)
-	authorization decision and reasons
-	execution_id
-	status/outcome
-	emitted OB digest
AL SHOULD be append-only. Tamper-evidence is RECOMMENDED.

21.6 Data Flow Specifications

21.6.1 Standard Single-Domain Flow
RE -> AR: propose action
AR -> EB: IE(envelope_id, actor_ref, authority_ref, constraints, hooks)
EB -> AS/IdP: validate capability + identity + revocation
EB -> ET: execute action
EB -> AL: write audit events
EB -> OC: emit OB(attested)
OC -> AR: deliver OB
AR -> RE: provide validated OB for next-step reasoning

21.6.2 Cross-Domain Flow (Domain A → Domain B)
Domain A: AR_A -> EB_B (IE)
          (crosses TB-Domain)
Domain B: EB_B validates issuers/trust anchors independently
          EB_B executes, attests OB
          OB delivered back per hooks (possibly to OC_A and/or OC_B)
Receiving domains MUST NOT assume trust in issuer sets unless explicitly configured.

21.7 Policy Enforcement Points
EB is the required enforcement point. The following controls MUST be enforced at EB:
-	Revocation checks (risk-tier dependent strictness)
-	Replay protection
-	Constraint verification (time, uses, scope)
-	Delegation chain integrity
-	Audit emission
AR/RE controls are advisory only.

21.8 Minimal Deployment Profiles

21.8.1 Minimal Profile (Single Domain)
Required: RE, AR, EB, AS (or embedded capability verifier), OC, AL
Optional: external IdP (can be embedded issuer)

21.8.2 Multi-Domain Profile
Required: EB and trust anchor policy per domain, cross-domain issuer validation, revocation accessibility policy, OC bridging rules.

21.9 Failure Modes and Required Behaviors
-	If AS/IdP is unreachable for a high-risk action, EB MUST fail closed (reject) unless local policy explicitly permits bounded staleness.
-	If OB delivery fails, EB SHOULD support pull-based retrieval via OC to avoid “lost observations”.
-	If replay is detected, EB MUST reject with REPLAY_DETECTED and log the attempt.

22. Concrete Transport Binding: HTTP (AIDP-HTTP)

22.1 Overview
This section specifies a concrete transport binding for AIDP using HTTP. It defines:
-	submission of Intent Envelopes (IE) to an Execution Boundary (EB),
-	delivery/retrieval of Observations (OB),
-	structured error reporting (PD),
-	minimal requirements for replay safety and correlation.
This binding is compatible with AIDP-JS (JSON) payloads as specified in Sections 16–19. AIDP-CB (CBOR) MAY be supported via content negotiation.

22.2 Resources and Roles
-	Client: Agent Runtime (AR) or Agent-facing proxy.
-	Server: Execution Boundary (EB).
-	Observation Channel: either:
-	push: EB calls an AR webhook, or
-	pull: AR polls an EB-hosted inbox.

22.3 Media Types
Implementations MUST support JSON.
-	IE: application/aidp+json; msg=IE
-	OB: application/aidp+json; msg=OB
-	PD: application/aidp+json; msg=PD
Servers MAY additionally support CBOR:
-	application/aidp+cbor; msg=IE|OB|PD

22.4 Common HTTP Headers
Clients and servers MUST use:
-	Content-Type: as above
-	Accept: one or more supported AIDP media types
The following headers are RECOMMENDED:
-	Idempotency-Key: value of constraints.idempotency_key (when present)
-	X-AIDP-Envelope-ID: mirrors payload.envelope_id (for tracing; not authoritative)

22.5 Authorization at HTTP Layer
AIDP authorization is enforced via authority_ref/capabilities at the AIDP layer. However, the HTTP channel itself MUST be authenticated to prevent anonymous flooding and to enable policy decisions.
EB deployments MUST require at least one of:
-	mutual TLS (mTLS), or
-	OAuth 2.0 Bearer token, or
-	another mutually authenticated mechanism.
Important: HTTP-layer auth MUST NOT be treated as sufficient authorization for actions. EB MUST still validate AIDP identity/capability/delegation/revocation per the core spec.

22.6 Endpoint: Submit Intent Envelope
POST /v1/aidp/intents
Request body: an IE message.
Success responses:
-	202 Accepted: intent accepted for processing; OB will be delivered via hooks (push) and/or made available for pull.
-	200 OK: intent executed synchronously and OB is returned in the response body (allowed for low latency operations).
Failure responses:
-	400 Bad Request: malformed AIDP message (PD returned)
-	401 Unauthorized: HTTP-layer auth failure (PD OPTIONAL; may be plain HTTP)
-	403 Forbidden: AIDP authorization failure (PD returned)
-	409 Conflict: replay detected / envelope_id reuse (PD returned)
-	415 Unsupported Media Type: unsupported encoding
-	429 Too Many Requests: rate limiting (PD OPTIONAL but RECOMMENDED)
-	500/503: server failure / dependency failure (PD RECOMMENDED)
Response body:
-	For 200: an OB
-	For 202: either empty or a minimal acknowledgment object (OPTIONAL). If included, it MUST NOT claim execution success.
-	For failures: a PD SHOULD be returned.

22.6.1 Correlation Rules
-	EB MUST treat payload.envelope_id as authoritative.
-	If X-AIDP-Envelope-ID is present and does not match the payload, EB MUST reject with MALFORMED_MESSAGE.

22.6.2 Synchronous vs Asynchronous Execution
EB MAY execute synchronously (200) when:
-	action is low-risk and low-latency, and
-	revocation checks can be performed inline.
Otherwise EB SHOULD default to 202 + asynchronous OB.

22.7 Endpoint: Retrieve Observation (Pull Mode)
GET /v1/aidp/observations/{envelope_id}
Returns:
-	200 OK + OB if available
-	404 Not Found if unknown (or not yet available)
-	410 Gone if envelope_id is known but observation expired/garbage-collected (PD RECOMMENDED)
-	409 Conflict if multiple observations exist and client must page (see 21.7.1)
EB SHOULD retain observations for a configurable retention window.

Execution Boundaries MUST retain Observations for a deployment-defined
retention period sufficient to allow Agents to recover results in the
presence of delivery failure, Agent restarts, or network partition.

If an Observation cannot be returned inline due to replay detection,
the EB MUST expose a deterministic retrieval mechanism bound to the
envelope_id.


22.7.1 Multiple Observations per Envelope
In advanced deployments, an envelope may yield multiple OBs (e.g., accepted then executed). If multiple are retained, EB MUST support:
GET /v1/aidp/observations?envelope_id=...&after=...&limit=...
Returning either:
-	a single latest OB (default), or
-	a list of OBs when mode=all.

22.8 Endpoint: Observation Inbox (Pull Mode, Queue Semantics)
GET /v1/aidp/inbox
Query params:
-	cursor (opaque)
-	limit (1–100)
Returns 200 OK with:
-	items: array of OB messages
-	next_cursor: cursor for pagination
EB MUST only deliver observations intended for the authenticated caller per observability_hooks.return_to.

22.9 Observation Delivery (Push Mode)
If observability_hooks.delivery_mode = "push", return_to MUST include a webhook URL reference or a resolvable endpoint reference.
EB will deliver via:
POST <agent_webhook_url>
Body: an OB message.
Expected responses by AR:
-	200 OK: received and accepted
-	409 Conflict: duplicate delivery (idempotent accept)
-	410 Gone: endpoint deprecated (EB SHOULD fall back to pull if configured)
EB MUST implement retries with backoff. Duplicate deliveries MUST be possible; AR MUST handle idempotently using (envelope_id, execution_id).

Execution Boundaries MUST enforce SSRF protections when performing
Observation delivery, including but not limited to:

- Rejection of loopback, link-local, private, or non-globally routable
  addresses
- Domain allowlisting or identity-bound endpoint registration
- Protection against DNS rebinding

If an endpoint cannot be validated or authorized, the EB MUST fall back
to inbox-based or pull-based Observation retrieval.

22.10 Problem Details over HTTP
PD is carried as the response body for AIDP-layer errors.
Mapping guidance:
-	INVALID_IDENTITY, UNTRUSTED_ISSUER, REVOKED, INVALID_DELEGATION_CHAIN → 403
-	CONSTRAINT_VIOLATION → 403 (or 409 if semantic conflict)
-	REPLAY_DETECTED → 409
-	MALFORMED_MESSAGE, UNSUPPORTED_VERSION → 400
-	UNSUPPORTED_MEDIA_TYPE → 415

22.11 HTTP Caching
Responses containing OB or PD MUST include headers preventing intermediary caching:
-	Cache-Control: no-store

22.12 Transport-Level Integrity and Confidentiality
AIDP-HTTP MUST be carried over TLS. mTLS is RECOMMENDED for high-risk tiers.

22.13 Minimal HTTP Sequence Examples

22.13.1 Submit IE (Async)
1.	AR → EB
POST /v1/aidp/intents with IE
EB → AR
202 Accepted
2.	EB → AR webhook
POST https://agent.example/aidp/ob with OB
AR → EB
200 OK

22.13.2 Submit IE (Sync)
AR → EB
POST /v1/aidp/intents with IE
EB → AR
200 OK with OB

22.13.3 Pull OB
AR → EB
GET /v1/aidp/observations/{envelope_id}
EB → AR
200 OK with OB (or 404 Not Found until ready)

22.14 Full HTTP Examples
All of the above assume:
-	TLS active
-	Content-Type: application/aidp+json; msg=...
-	canon: AIDP-JS-Canon1
-	sig are placeholders

22.14.1 Async Success (202 + webhook OB)
Request (AR → EB)
POST /v1/aidp/intents HTTP/1.1
Host: eb.payments.example
Content-Type: application/aidp+json; msg=IE
Accept: application/aidp+json; msg=OB, application/aidp+json; msg=PD
Idempotency-Key: idem-3d7f0d
X-AIDP-Envelope-ID: 0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10
Authorization: Bearer eyJ... (transport auth; not sufficient for AIDP auth)
Cache-Control: no-store

{
  "aidp_version": "1.0-draft",
  "msg_type": "IE",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:00+02:00",
    "actor_ref": { "agent_id": "agent:alpha", "issuer": "did:example:issuerA", "identity_ref": "urn:aidp:id:issuerA:agent-alpha" },
    "authority_ref": { "cap_id": "cap:alpha:pay-v1", "issuer": "did:example:authA", "cap_ref": "urn:aidp:cap:authA:cap-alpha-pay-v1", "rev_ref": "urn:aidp:rev:authA:list-01" },
    "intent_body": {
      "action": "payment.create",
      "target": { "domain": "svc:payments", "resource": "acct:merchant-123" },
      "parameters": { "amount": 50, "currency": "EUR", "memo": "invoice-8841" }
    },
    "constraints": {
      "not_before": "2026-01-13T09:14:00+02:00",
      "not_after": "2026-01-13T09:19:00+02:00",
      "max_uses": 1,
      "risk_tier": "high",
      "idempotency_key": "idem-3d7f0d"
    },
    "delegation_chain": [],
    "observability_hooks": {
      "delivery_mode": "push",
      "return_to": { "type": "webhook", "ref": "https://agent.example/aidp/ob" },
      "required_fields": ["envelope_id", "execution_id", "status", "attestation"],
      "timeout_sec": 30
    }
  },
  "proof": { "alg": "ed25519", "kid": "key:agent-alpha-1", "sig": "BASE64URL(...)" }
}
Response (EB → AR)
HTTP/1.1 202 Accepted
Cache-Control: no-store
Content-Type: application/aidp+json; msg=PD

{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:01+02:00",
    "error_code": "ACCEPTED_ASYNC",
    "error_message": "Accepted for processing; observation will be delivered via hooks.",
    "details": { "estimated": "not_provided" }
  },
  "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
}
Note: use of PD as “ack” for 202 to have a structured message. Alternatively it can be blank.
Webhook Delivery (EB → AR endpoint)
POST /aidp/ob HTTP/1.1
Host: agent.example
Content-Type: application/aidp+json; msg=OB
Accept: application/aidp+json; msg=PD
Cache-Control: no-store
X-AIDP-Delivery-ID: deliv-77a1
X-AIDP-Envelope-ID: 0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10

{
  "aidp_version": "1.0-draft",
  "msg_type": "OB",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "execution_id": "exec-9c2d1a",
    "timestamp": "2026-01-13T09:14:02+02:00",
    "status": "executed",
    "result": { "payment_id": "pay_7712", "state": "captured" },
    "side_effects": [{ "resource": "acct:merchant-123", "delta": { "captured_eur": 50 } }],
    "attestation": {
      "boundary_id": "boundary:payments-gw-1",
      "issuer": "did:example:paymentsDomain",
      "attest_profile": "AIDP-OB-Attest1",
      "decision": "authorized",
      "policy_digest": "sha256:5d3a...e91"
    }
  },
  "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
}
Webhook Response (AR → EB)
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/aidp+json; msg=PD

{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:03+02:00",
    "error_code": "DELIVERY_OK",
    "error_message": "Observation received."
  }
}

22.14.2 Revoked Capability (403 + PD)
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Type: application/aidp+json; msg=PD

{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:01+02:00",
    "error_code": "REVOKED",
    "error_message": "Capability or identity has been revoked.",
    "details": {
      "rev_ref": "urn:aidp:rev:authA:list-01",
      "cap_id": "cap:alpha:pay-v1",
      "decision": "revoked"
    }
  },
  "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
}

22.14.3 Replay Detected (409 + PD)
HTTP/1.1 409 Conflict
Cache-Control: no-store
Content-Type: application/aidp+json; msg=PD

{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:14:01+02:00",
    "error_code": "REPLAY_DETECTED",
    "error_message": "Envelope ID has already been processed.",
    "details": { "replay_window": "configured", "first_seen": "2026-01-13T09:14:00+02:00" }
  },
  "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
}

22.14.4 Constraint Violation (403 + PD)
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Type: application/aidp+json; msg=PD

{
  "aidp_version": "1.0-draft",
  "msg_type": "PD",
  "canon": "AIDP-JS-Canon1",
  "payload": {
    "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
    "timestamp": "2026-01-13T09:20:10+02:00",
    "error_code": "CONSTRAINT_VIOLATION",
    "error_message": "Constraint check failed.",
    "details": {
      "violations": [
        { "field": "constraints.not_after", "reason": "expired" },
        { "field": "constraints.max_uses", "reason": "already_consumed" }
      ]
    }
  },
  "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
}

22.15 Webhook Verification Model (Push Observations)

22.15.1 Trust Anchors
Each Agent Runtime (AR) MUST maintain a set of trust anchors for validating incoming Observation deliveries. These trust anchors MUST include:
-	Approved issuers of Execution Boundary (EB) attestations (e.g., did:example:paymentsDomain)
-	(OPTIONAL) Explicit allowlists of specific EB instances identified by boundary_id
The AR MUST reject any webhook-delivered Observation if:
-	attestation.issuer is not included in the trust anchors, or
-	the public key referenced by proof.kid cannot be resolved for the declared issuer, or
-	the boundary_id is disallowed by local policy.

22.15.2 Required Verification Steps (AR-side)
Upon receipt of an Observation via webhook, the Agent Runtime MUST perform the following steps, in order:
1.	Parse and schema-validate the Observation message using strict validation rules.
2.	Verify the attestation proof (proof) over the canonical signing input.
3.	Validate issuer trust, ensuring attestation.issuer is trusted.
4.	Bind the Observation to an outstanding Intent:
o	payload.envelope_id MUST correspond to a currently pending Intent Envelope, otherwise the Observation MUST be rejected or quarantined according to policy.
5.	Enforce replay protection:
o	The tuple (envelope_id, execution_id) MUST be accepted at most once.
6.	OPTIONAL but RECOMMENDED: Verify attestation.policy_digest against a locally known policy registry when available.
If any verification step fails, the AR MUST NOT accept the Observation and MUST respond with a non-2xx HTTP status code.

22.15.3 Delivery Idempotency
Execution Boundaries MUST treat webhook delivery as retry-safe.
Agent Runtimes MUST process webhook Observations idempotently, keyed by:
(envelope_id, execution_id)
If a duplicate delivery is received, the AR MUST NOT re-apply any state transition and SHOULD return either:
-	409 Conflict (duplicate), or
-	200 OK with a Problem Details payload indicating duplicate acceptance.

22.15.4 Webhook Channel Authentication
In addition to cryptographic attestation inside the Observation itself, the webhook transport channel SHOULD be protected using:
-	Mutual TLS (mTLS), or
-	An HTTP authentication mechanism that cryptographically binds the EB identity to the TLS session.
Channel-level authentication mitigates denial-of-service attacks and prevents unauthenticated injection of traffic toward the AR.

22.15.5 Anti-Substitution Rules
The Agent Runtime MUST enforce the following anti-substitution rules:
-	The payload.envelope_id in the Observation MUST correspond exactly to the pending Intent Envelope.
-	If the AR maintains a local digest of the submitted Intent Envelope, it SHOULD ensure the received Observation corresponds to that digest entry.
-	All fields declared in observability_hooks.required_fields MUST be present before the Observation is accepted.
Failure of any rule MUST cause the Observation to be rejected.

22.15.6 Error Responses from Webhook Endpoint
The AR webhook endpoint MUST use the following status codes:
HTTP Code	Meaning
200	Observation accepted
409	Duplicate delivery
400	Malformed Observation
403	Untrusted issuer or invalid proof
410	Endpoint deprecated
429	Rate limited

22.15.7 Fallback to Pull Mode
If repeated webhook deliveries fail, the Execution Boundary SHOULD:
-	Retain the Observation for retrieval via GET /v1/aidp/observations/{envelope_id}, and
-	Optionally emit a Problem Details message indicating push delivery failure.

22.16 Reference Validation Pipeline
This section defines the normative validation and execution pipeline that every AIDP-compliant Execution Boundary (EB) and Agent Runtime (AR) MUST implement.
Any deviation from this sequence constitutes a protocol violation.

22.16.1 Execution Boundary Validation Pipeline
Upon receipt of an Intent Envelope over HTTP, the EB MUST execute the following steps in order:
1. Transport Authentication
2. Message Parsing
3. Canonicalization
4. Proof Verification
5. Schema Validation
6. Identity Validation
7. Capability Resolution
8. Delegation Chain Validation
9. Revocation Checks
10. Constraint Enforcement
11. Replay Protection
12. Authorization Decision
13. Execution
14. Observation Construction
15. Attestation & Emission
16. Audit Recording

22.16.2 Detailed Step Semantics

1. Transport Authentication
The EB MUST verify HTTP-layer authentication (mTLS, OAuth, etc.) and reject unauthenticated clients.
Transport authentication does not grant execution authority.

2. Message Parsing
The EB MUST parse the incoming message strictly.
Malformed messages MUST be rejected with MALFORMED_MESSAGE.
During message parsing, Execution Boundaries and Agent Runtimes MUST use
a JSON parser configuration that detects and rejects duplicate object
member names.

Messages that contain duplicate keys MUST be rejected before any
validation, canonicalization, or cryptographic verification is
performed.


3. Canonicalization
The EB MUST canonicalize the payload using the declared canon profile.
Failure MUST abort processing.

4. Proof Verification
If present, proof MUST be verified against the canonical payload.
Failure MUST abort processing.

5. Schema Validation
The EB MUST validate the payload against the AIDP schema for the declared message type.
Unknown fields in security-critical objects MUST cause rejection.

6. Identity Validation
The EB MUST resolve and validate actor_ref.identity_ref and issuer trust.
Failures MUST result in INVALID_IDENTITY or UNTRUSTED_ISSUER.

7. Capability Resolution
The EB MUST resolve authority_ref.cap_ref, validate issuer trust, and load associated constraints.

8. Delegation Chain Validation
If delegation_chain is present, the EB MUST:
-	Validate every link’s proof
-	Enforce subsetting rules
-	Verify parent-child relationships
-	Reject any amplification of authority
Failures MUST result in INVALID_DELEGATION_CHAIN.

9. Revocation Checks
The EB MUST consult all rev_ref references (identity, capability, delegation parents).
For high-risk actions, revocation checks MUST be performed immediately prior to execution.

10. Constraint Enforcement
All constraints MUST be enforced:
-	time windows
-	usage limits
-	resource scope
-	risk tier policies
Failures MUST result in CONSTRAINT_VIOLATION.

11. Replay Protection
The EB MUST verify that envelope_id has not been previously accepted.
Replay MUST result in REPLAY_DETECTED.

12. Authorization Decision
If and only if all prior steps succeed, the EB MUST authorize the action.

13. Execution
The EB executes the action on the target system.
Execution failures MUST still produce an Observation with status = failed.

14. Observation Construction
The EB MUST construct an Observation bound to:
-	envelope_id
-	execution_id
-	decision
-	result
-	side effects
-	applied policy

15. Attestation & Emission
The EB MUST:
-	attach an attestation
-	sign the Observation
-	deliver it via the configured Observation Channel

16. Audit Recording
The EB MUST record:
-	envelope digest
-	decision
-	execution_id
-	final status
-	emitted Observation digest

22.16.3 Agent Runtime Validation Pipeline (OB/PD)
Upon receiving an Observation or Problem Details message, the AR MUST perform:
1. Parse & Schema Validate
2. Canonicalize
3. Verify Attestation Proof
4. Verify Issuer Trust
5. Bind to Outstanding Intent
6. Enforce Replay Protection
7. Accept and Release Intent
8. Failure Classification and Retry Suppression

If an Observation or Problem Details message indicates a deterministic
failure (including but not limited to CONSTRAINT_VIOLATION,
NOT_AUTHORIZED, POLICY_REFUSED, or any non-retriable execution_advice),
the Agent Runtime MUST NOT re-issue an Intent Envelope whose canonical
payload is identical to the failed intent.

The Agent Runtime MUST either:
- revise the intent semantics (e.g., constraints or intent_body), or
- abort the reasoning path, or
- require explicit operator or policy override.
To enforce retry suppression deterministically, the Agent Runtime
SHOULD maintain a cache of recently failed intent digests, computed as
a hash over the canonical signing input of the Intent Envelope payload.

Re-issuance of an Intent with an identical digest following a
deterministic failure SHOULD be suppressed for a deployment-defined
cooldown period.

If any step fails, the Observation MUST be rejected and MUST NOT advance agent reasoning.

Deterministic failures are failures for which re-execution of an
identical intent is not expected to yield a different outcome, absent
a change in constraints, authority, or policy state.

Examples include constraint violations, authorization failures, and
explicit policy refusals.

22.16.4 Deterministic Agent Loop Guarantee
An agent loop is compliant if and only if:
No agent reasoning step that causally depends on an Intent Envelope
occurs without a validated Observation for that Intent.

22.16.5 Minimal Conformance Checklist
An implementation claiming AIDP-HTTP compliance MUST implement:
-	full EB pipeline
-	full AR pipeline
-	replay store
-	revocation resolver
-	attestation verification
-	audit logging

23. AIDP Conformance Test Suite — Outline

23.1 Purpose
This document defines the test framework for validating whether an implementation is compliant with the AIDP specification.
It enables:
-	certification of implementations,
-	interoperability between vendors,
-	objective security verification.

23.2. Certification Levels
Level 1 — AIDP-Core
Minimal functional compliance.
Level 2 — AIDP-Secure
Includes full security & revocation semantics.
Level 3 — AIDP-Enterprise
Includes auditability, cross-domain, governance & recovery.

23.3 Test Domains
Domain	        Focus
-----------     -------------------------
Identity	Agent identity validation
Authority	Capability enforcement
Delegation	Subsetting & chain validation
Revocation	Immediate invalidation

Intent	Schema & canonicalization
Execution	Enforcement correctness
------------    ------------------------
Observation	Binding & integrity
Replay	        Duplicate detection
Audit	        Traceability & non-repudiation
Cross-Domain	Trust boundary handling

23.4 Core Test Categories

23.4.1 Identity & Trust
-	T-ID-01: Reject invalid issuer
-	T-ID-02: Reject expired identity
-	T-ID-03: Enforce trust anchors
-	T-ID-04: Revalidate across trust boundary

23.4.2 Capability & Authority
-	T-AUTH-01: Enforce action scope
-	T-AUTH-02: Enforce resource scope
-	T-AUTH-03: Enforce constraints
-	T-AUTH-04: Reject capability amplification

23.4.3 Delegation
-	T-DEL-01: Validate delegation chain
-	T-DEL-02: Reject broken chain
-	T-DEL-03: Enforce subsetting rule
-T-DEL-04: Revoke parent invalidates children

23.4.4 Revocation
-	T-REV-01: Immediate revocation enforcement
-	T-REV-02: Revocation after acceptance but before execution
-	T-REV-03: Revocation during execution (high risk path)

23.4.5 Intent Envelope
-	T-IE-01: Canonicalization correctness
-	T-IE-02: Proof verification
-	T-IE-03: Reject malformed envelope
-	T-IE-04: Enforce required fields

23.4.6 Execution & Enforcement
-	T-EX-01: Reject without valid authority
-	T-EX-02: Enforce constraints before execution
-	T-EX-03: Execute only after full validation
-	T-EX-04: Reject on replay

23.4.7 Observation & Feedback Binding
-	T-OB-01: Bind OB to correct envelope_id
-	T-OB-02: Reject mismatched OB
-	T-OB-03: Enforce deterministic agent loop
-	T-OB-04: Reject unsigned OB

23.4.8 Replay & Ordering
-	T-RPL-01: Detect duplicate envelope_id
-	T-RPL-02: Reject reused execution_id
-	T-RPL-03: Maintain replay window

23.4.9 Audit & Compliance
-	T-AUD-01: Record full action trace
-	T-AUD-02: Reconstruct causal chain
-	T-AUD-03: Verify non-repudiation

23.4.10 Cross-Domain & Federation
-	T-XD-01: Enforce trust boundary
-	T-XD-02: Reject untrusted issuer
-	T-XD-03: Preserve delegation semantics across domains

23.5 Failure Injection Tests
-	Network failure mid-execution
-	Revocation during processing
-	Observation delivery failure
-	Duplicate webhook delivery
-	Corrupted attestation
-	Malicious agent input

23.6 Required Artifacts for Certification
An implementation seeking certification MUST provide:
-	Test harness access
-	Public verification endpoints
-	Audit logs
-	Policy configuration
-	Revocation interface
-	Capability issuance interface

23.7 Compliance Declaration
An implementation MAY claim:
“AIDP-Compliant: Level X”
only after passing all tests for that certification level.


Appendix A. Changes Since draft-vandoulas-aidp-00

This section summarizes substantive changes introduced since
draft-vandoulas-aidp-00.

- Clarified replay semantics to explicitly distinguish replay detection
  from re-execution, and to require deterministic result recovery
  without side effects (Sections 10.6.3, 21.7).

- Introduced explicit Observation retention and pull-based recovery
  requirements to prevent loss of execution outcomes due to delivery
  failure (Sections 21.7, 20.9).

- Refined agent control loop semantics to permit parallel,
  causally-independent intents while preserving deterministic reasoning
  for dependent actions (Sections 3.3, 8.2).

- Hardened canonicalization and parsing requirements by mandating
  rejection of duplicate JSON object member names during parsing,
  prior to validation and cryptographic verification (Sections 16.3,
  21.16.2).

- Added explicit identity resolution profiles to support interoperable
  cross-domain validation, including dereferenceable and self-contained
  identity models (Section 4.2).

- Strengthened observability hook security by restricting Observation
  delivery endpoints to pre-authorized destinations and mandating SSRF
  protections with deterministic fallback to pull-based retrieval
  (Sections 17.1.6, 21.9).

- Introduced execution_advice as an optional, non-binding mechanism for
  communicating retry, backoff, and failure classification guidance in
  both Observation and Problem Details messages (Sections 17.2, 17.3).

- Added deterministic retry suppression and anti-loop requirements to
  the Agent Runtime validation pipeline to prevent infinite re-issuance
  of semantically identical intents following deterministic failures
  (Section 21.16.3).

- Clarified deterministic agent loop guarantees to ensure reasoning
  progression is gated only on Observations for causally dependent
  intents, rather than enforcing global serialization (Section 21.16.4).


Authors' Addresses

   Ioannis Vandoulas
   Email: jvandoul@gmail.com



