# drafts

name: draft-altanai-aipref-realtime-protocol-bindings
rev: 00
title: AI Preferences for Real-Time Protocol Bindings
time: 2026-02-03T21:27:26Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-07T21:27:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.517140+00:00
source: ietf
abstract:
  This document defines how Artificial Intelligence (AI) preference
     expressions are bound to signaling and media protocols used for real-
     time, session-based communications such as the Session Initiation
     Protocol (SIP) and associated Session Description Protocol (SDP)
     offers.  It specifies a reusable binding model, concrete SIP header
     field conventions, and SDP attributes that allow endpoints,
     intermediary services, and AI assistants to advertise, negotiate, and
     enforce requirements about AI-driven processing of session metadata,
     media control events, and telemetry.  The goal is to align real-time
     protocol behavior with the AI Preferences (AIPREF) vocabulary without
     disrupting existing call control semantics.

full_text:
  AI Preferences                                                  A. Bisht
  Internet-Draft                                              Cisco Meraki
  Intended status: Standards Track                         3 February 2026
  Expires: 7 August 2026


               AI Preferences for Real-Time Protocol Bindings
             draft-altanai-aipref-realtime-protocol-bindings-00

  Abstract

     This document defines how Artificial Intelligence (AI) preference
     expressions are bound to signaling and media protocols used for real-
     time, session-based communications such as the Session Initiation
     Protocol (SIP) and associated Session Description Protocol (SDP)
     offers.  It specifies a reusable binding model, concrete SIP header
     field conventions, and SDP attributes that allow endpoints,
     intermediary services, and AI assistants to advertise, negotiate, and
     enforce requirements about AI-driven processing of session metadata,
     media control events, and telemetry.  The goal is to align real-time
     protocol behavior with the AI Preferences (AIPREF) vocabulary without
     disrupting existing call control semantics.

  About This Document

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

     The latest revision of this draft can be found at
     https://altanai.github.io/aipref-realtime-protocol-bindings/draft-
     altanai-aipref-realtime-protocol-bindings.html.  Status information
     for this document may be found at https://datatracker.ietf.org/doc/
     draft-altanai-aipref-realtime-protocol-bindings/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/altanai/aipref-realtime-protocol-bindings.

  Status of This Memo

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






  Bisht                     Expires 7 August 2026                 [Page 1]


  Internet-Draft             AI Pref RT Bindings             February 2026


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

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

     This Internet-Draft will expire on 7 August 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Binding Requirements  . . . . . . . . . . . . . . . . . . . .   5
     4.  Binding Model . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  SIP Signaling Binding . . . . . . . . . . . . . . . . . . . .   6
       5.1.  AI-Pref Header Field  . . . . . . . . . . . . . . . . . .   6
         5.1.1.  Usage Rules . . . . . . . . . . . . . . . . . . . . .   7
         5.1.2.  Compact Tokens and URIs . . . . . . . . . . . . . . .   7
         5.1.3.  Error Handling  . . . . . . . . . . . . . . . . . . .   7
       5.2.  SIP Body Considerations . . . . . . . . . . . . . . . . .   8
     6.  SDP and Media Binding . . . . . . . . . . . . . . . . . . . .   8
       6.1.  a=aipref Attribute  . . . . . . . . . . . . . . . . . . .   8
       6.2.  RTP Control and Telemetry . . . . . . . . . . . . . . . .   8
     7.  Preference Discovery and Synchronization  . . . . . . . . . .   9
       7.1.  Retrieval via HTTPS . . . . . . . . . . . . . . . . . . .   9
       7.2.  Repository Interaction  . . . . . . . . . . . . . . . . .   9
       7.3.  Conflict Resolution . . . . . . . . . . . . . . . . . . .   9



  Bisht                     Expires 7 August 2026                 [Page 2]


  Internet-Draft             AI Pref RT Bindings             February 2026


     8.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
       9.1.  Privacy and End-User Impact Considerations  . . . . . . .  10
         9.1.1.  Impact on User Autonomy and Consent . . . . . . . . .  10
         9.1.2.  Avoiding Over-Restriction of Beneficial Uses  . . . .  11
         9.1.3.  Transparency to Participants  . . . . . . . . . . . .  11
         9.1.4.  Intermediary Handling and Privacy Leakage . . . . . .  12
         9.1.5.  Compatibility with Archiving and Research . . . . . .  12
         9.1.6.  Avoiding Platform-Level Overreach . . . . . . . . . .  13
         9.1.7.  Interoperability and Open Ecosystem Considerations  .  13
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
       10.1.  SIP Header Field Registration  . . . . . . . . . . . . .  13
       10.2.  SDP Attribute Registration . . . . . . . . . . . . . . .  14
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
       Normative References  . . . . . . . . . . . . . . . . . . . . .  14
       Informative References  . . . . . . . . . . . . . . . . . . . .  15
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

     Real-time communications (RTC) deployments are increasingly assisted
     by AI-driven components that evaluate signaling metadata, media
     control messages, and quality of experience (QoE) measurements.
     Examples include AI-based call routing, automated troubleshooting,
     adaptive encoding, or compliance monitoring.  When these components
     operate on user or service provider data, the AI Preferences (AIPREF)
     working group requires that stakeholders can express and enforce
     preferences that describe what AI systems may inspect, retain, or
     export.

     Existing AIPREF documents define preference vocabularies and
     repository behavior, but do not specify how those preferences are
     conveyed through session control protocols.  This document fills that
     gap for SIP-based systems and applies the same pattern to other RTC
     bindings that reuse SIP constructs (including SIP events, PUBLISH,
     and WebRTC gateways).  The binding guidance is protocol-agnostic
     where possible so that additional RTC protocols (such as XMPP Jingle
     or proprietary session controllers) can follow the same pattern.

  1.1.  Goals

     The binding framework MUST:

     1.  Preserve backwards compatibility with SIP user agents, gateways,
         and middleboxes that are unaware of AI preference signaling.





  Bisht                     Expires 7 August 2026                 [Page 3]


  Internet-Draft             AI Pref RT Bindings             February 2026


     2.  Permit endpoints and administrative domains to advertise locally
         enforced AI policies and to consume peer policies before AI
         processing begins.

     3.  Support mid-dialog updates so that AI processing can adapt when
         session context changes (e.g., escalation from audio to video,
         invoking transcription services, or triggering automated
         remediation workflows).

     4.  Allow binding of AI preferences to both signaling-layer artifacts
         (message bodies, header fields, event packages) and media-layer
         descriptions (SDP attributes, record routes, and telemetry
         streams).

  1.2.  Scope

     This document describes:

     *  A binding model that maps AIPREF vocabulary elements to SIP dialog
        state and SDP descriptions.

     *  A compact token and URI-based encoding carried in SIP header
        fields and bodies.

     *  Procedures for preference discovery, negotiation, and error
        handling across dialogs, subscriptions, and conferencing
        primitives.

     *  Operational recommendations for intermediaries, policy servers,
        and AI enforcement points.

     This document does not standardize AI algorithms, privacy-preserving
     enforcement techniques, or the semantics of individual AIPREF
     vocabularies beyond referencing existing definitions in other working
     group documents such as [I-D.aipref-network-privacy-control].

  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.








  Bisht                     Expires 7 August 2026                 [Page 4]


  Internet-Draft             AI Pref RT Bindings             February 2026


  2.  Terminology

     The terminology defined in RFC3261, RFC3264, and the AIPREF framework
     documents applies.  This document additionally uses the following
     conventions:

     *  *AI Preference Token (APT)*: A compact, possibly signed
        representation of one or more AIPREF statements, retrievable via
        URI or carried inline.

     *  *Preference Attacher*: The SIP entity that injects an APT into
        signaling or SDP (e.g., originating user agent, outbound proxy, or
        application server).

     *  *Preference Enforcement Point (PEP)*: A network element or AI
        component that validates and enforces APT requirements prior to
        processing protected data.

     *  *Real-Time Preference Channel*: Any mechanism that conveys updated
        APTs after a dialog is established (e.g., re-INVITE, UPDATE, INFO,
        SUBSCRIBE/NOTIFY pair).

  3.  Binding Requirements

     The following requirements guide bindings for SIP and related RTC
     protocols:

     *  *Visibility*: APTs SHOULD be visible to the entities that are
        expected to enforce them, including downstream AI assistants.
        When hop-by-hop protection (e.g., TLS) is applied, intermediaries
        outside the trust domain MUST NOT rely on APTs they cannot
        validate.

     *  *Integrity*: APTs SHOULD be signed or integrity-protected when
        transported across untrusted proxies to prevent unauthorized
        downgrades.

     *  *Idempotency*: Repeated delivery of identical APTs MUST NOT cause
        state divergence.  Implementations MAY treat the most recent valid
        APT as authoritative.

     *  *Granularity*: Bindings MUST allow preferences scoped to dialogs,
        media sections, or individual features (e.g., telemetry streams,
        AI feature lists).  APTs therefore include target metadata
        identifying the scope (dialog-id, media mid, or subscription
        identifier).





  Bisht                     Expires 7 August 2026                 [Page 5]


  Internet-Draft             AI Pref RT Bindings             February 2026


     *  *Fallback*: Endpoints that cannot satisfy received preferences
        MUST reject or redirect the request using standard SIP procedures
        (e.g., 488 Not Acceptable Here) and SHOULD include diagnostic
        information.

  4.  Binding Model

     The model in Figure 1 illustrates how preferences flow through RTC
     signaling.

     ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Preference │ APT
     │ SIP Binding │ APT │ Enforcement │ │ Originator ├─────▶│ Transport
     ├─────▶│ Point / AI │ └──────────────┘ └──────────────┘
     └──────────────┘ ▲ │ │ │ Publish / Fetch │ Dialog signaling │ Media /
     Data └──────────────────────┴─────────────────────┘

     1.  An originator (user agent, operator policy engine, or regulator)
         issues an APT identifier or token.

     2.  The preference attacher embeds the token using one or more
         bindings defined in this document.

     3.  Enforcement points inside AI workloads retrieve, validate, and
         apply the referenced constraints before consuming protected data.

     Bindings MUST reference the same canonical APT identifier when
     expressing preferences across signaling and media layers to avoid
     ambiguity.

  5.  SIP Signaling Binding

  5.1.  AI-Pref Header Field

     This document defines the AI-Pref SIP header field.  Each instance
     conveys metadata that allows receivers to retrieve or validate an
     APT.

     AI-Pref = "AI-Pref" HCOLON pref-value *(COMMA pref-value) pref-value
     = pref-id *(SEMI pref-param) pref-id = token / quoted-string ;
     identifier or opaque token pref-param = ("scope" EQUAL token) /
     ("type" EQUAL token) / ("version" EQUAL 1*DIGIT) / ("integrity" EQUAL
     token) / ("uri" EQUAL LAQUOT absoluteURI RAQUOT)









  Bisht                     Expires 7 August 2026                 [Page 6]


  Internet-Draft             AI Pref RT Bindings             February 2026


  5.1.1.  Usage Rules

     1.  *Initial INVITE*: The originating user agent server (UAC) SHOULD
         include an AI-Pref header referencing all preferences that govern
         AI handling of dialog metadata or media diagnostics.  The header
         MAY appear multiple times when different scopes are advertised
         (e.g., scope=dialog, scope=media).

     2.  *Provisional Responses*: Proxies and user agent servers (UAS) MAY
         add AI-Pref headers to responses in order to enumerate additional
         policies that downstream AI components MUST accept before the
         session is confirmed.

     3.  *ACK and PRACK*: These messages MUST echo the latest accepted AI-
         Pref identifiers when the UAS requires confirmation.  Absence of
         AI-Pref in ACK implies acceptance of the most recent set.

     4.  *Mid-Dialog Updates*: Re-INVITE and UPDATE requests MUST include
         AI-Pref whenever the preference scope of any media stream is
         modified.  This allows AI systems that adapt encoders, perform
         transcription, or modify layouts to obey updated constraints.

     5.  *SUBSCRIBE/NOTIFY*: Event packages (e.g., dialog package, KPML,
         presence) MAY carry AI-Pref headers so that AI assistants
         consuming event payloads adhere to the advertised constraints.

  5.1.2.  Compact Tokens and URIs

     pref-id values can represent:

     *  Inline tokens that encode the full preference statement (e.g.,
        CBOR Web Token referencing vocabulary keys).

     *  Handles that require dereferencing via HTTPS using the uri
        parameter.

     *  Versioned identifiers that map to entries in a policy repository.

     Receivers MUST treat unknown parameters according to RFC3261 rules
     (ignore them) and MUST NOT assume that the absence of AI-Pref implies
     permission to process data without AI constraints.

  5.1.3.  Error Handling

     *  If a UAS cannot comply with mandatory preferences, it SHOULD reply
        with 488 Not Acceptable Here and include a Warning header value of
        399 aipref "Preference unsupported".




  Bisht                     Expires 7 August 2026                 [Page 7]


  Internet-Draft             AI Pref RT Bindings             February 2026


     *  When integrity verification fails, the recipient SHOULD respond
        with 403 Forbidden and MAY include diagnostic details in a Reason
        header referencing AI-Integrity-Failure.

     *  Gateways that strip AI-Pref MUST insert a History-Info entry
        explaining the removal so downstream entities understand why
        enforcement data is missing.

  5.2.  SIP Body Considerations

     When APTs are too large for header fields, this document RECOMMENDS
     embedding them inside a multipart body part with media type
     application/aipref+json or application/aipref+cbor and referencing
     that part via Content-ID.  This allows richer metadata (e.g., signed
     manifests) without overloading SIP header processing.

  6.  SDP and Media Binding

  6.1.  a=aipref Attribute

     An SDP media description MAY include one or more a=aipref attributes,
     each binding a specific media stream to an APT identifier.

     a=aipref:<scope> <identifier> [<parameter>=<value> ...]

     Valid scopes include session, group, and mid.  Parameters align with
     the AI Pref vocabulary, for example:

     *  features=media-metrics,rtcp-xr

     *  retention=24h

     *  export=aggregated-only

     Endpoints MUST ensure that SDP attributes remain consistent with SIP-
     level AI-Pref headers.  If SDP renegotiation removes an attribute,
     the corresponding AI processing MUST stop or transition to the
     remaining allowed scope.

  6.2.  RTP Control and Telemetry

     RTP control protocols such as RTCP, RTCP XR, and RTP/RTCP extensions
     for feedback may carry AI-relevant telemetry.  Implementations SHOULD
     map telemetry streams to the same APT identifiers declared in SDP by
     including the identifier in RTCP SDES items or header extensions
     defined for this purpose.  When that is not feasible, implementations
     MAY rely on the dialog-level AI-Pref scope while documenting the
     implicit association.



  Bisht                     Expires 7 August 2026                 [Page 8]


  Internet-Draft             AI Pref RT Bindings             February 2026


  7.  Preference Discovery and Synchronization

  7.1.  Retrieval via HTTPS

     Preferences referenced via uri MUST be retrievable over HTTPS with
     mutual authentication when sensitive.  Servers SHOULD support
     conditional requests and caching so intermediaries can reuse
     validated APTs across multiple dialogs.

  7.2.  Repository Interaction

     Policy repositories MAY expose a REST interface where clients submit
     dialog metadata (Call-ID, From-tag, To-tag) and receive the
     authoritative list of applicable APT identifiers.  This pattern is
     especially useful for large conferencing services where centralized
     policy engines coordinate AI workloads.

  7.3.  Conflict Resolution

     When multiple APTs apply to the same resource, the following
     precedence rules apply unless a policy repository states otherwise:

     1.  User-specific preferences override domain defaults.

     2.  Domain-level regulatory requirements override individual
         relaxations.

     3.  The most restrictive constraint wins when two preferences
         conflict on the same vocabulary key.

     Endpoints MAY advertise their conflict-resolution policy through the
     policy parameter inside AI-Pref headers (e.g., policy=strictest-
     wins).

  8.  Operational Considerations

     *  *Logging*: Preference attachers SHOULD log emitted APT identifiers
        alongside Call-ID values to support audits and incident response.

     *  *Testing*: Interoperability testing MUST verify that dialogs
        proceed when AI-Pref is absent, ensuring that legacy devices
        remain compatible.

     *  *Scaling*: Implementations SHOULD compress header fields using SIP
        over HTTP/3 (RFC9397) or similar transports when large preference
        sets are common.





  Bisht                     Expires 7 August 2026                 [Page 9]


  Internet-Draft             AI Pref RT Bindings             February 2026


     *  *Federation*: Peering domains MAY translate local preference
        identifiers into a shared namespace.  Translation MUST NOT weaken
        constraints without explicit consent from the originator.

  9.  Security Considerations

     Preferences often contain sensitive information about user intent,
     regulatory exposure, or organizational policy.  Therefore:

     *  Transport security such as TLS (for SIP over TLS, WebSocket, or
        HTTP/3) MUST be used whenever an AI-Pref header or body carries
        tokens that could be replayed or tampered with.

     *  APT signatures SHOULD be validated before AI systems act on the
        encapsulated instructions.  Validation includes issuer
        authentication, expiration checks, and revocation status.

     *  Implementations MUST guard against downgrade attacks where a
        malicious intermediary strips AI-Pref headers.  Techniques include
        SIPS-only routing, end-to-end integrity with S/MIME, or redundant
        signaling through policy repositories.

     *  Preference tokens SHOULD minimize personally identifiable
        information.  Instead of embedding explicit user identifiers, use
        pseudonymous handles that map to access-controlled directories.

     *  Systems MUST treat AI enforcement failures as security incidents
        when they result in unauthorized data processing.  Telemetry
        SHOULD be rate-limited to avoid revealing preference patterns to
        attackers probing the signaling fabric.

  9.1.  Privacy and End-User Impact Considerations

     Real-time and session-oriented communication protocols (e.g., SIP,
     SDP, WebRTC, RTP/RTCP, QUIC-RTC) directly mediate human-to-human
     interaction.  Introducing AI-usage preference signaling into these
     protocols therefore has immediate consequences for end users,
     including creators, participants, accessibility users, researchers,
     and the general public.  This section outlines considerations
     necessary to ensure that AIPREF signaling in real-time environments
     does not unintentionally restrict legitimate uses, undermine user
     autonomy, or create new privacy risks.

  9.1.1.  Impact on User Autonomy and Consent

     AI-usage preferences expressed at the signaling or media layer may be
     interpreted as binding restrictions by downstream systems.
     Implementations MUST ensure that:



  Bisht                     Expires 7 August 2026                [Page 10]


  Internet-Draft             AI Pref RT Bindings             February 2026


     *  Preferences are treated as expressions of intent, not as
        access-control mechanisms.

     *  End users retain the ability to override platform-imposed defaults
        when they are the originators of the content.

     *  Intermediaries (e.g., conferencing platforms, SIP proxies, TURN
        servers, media mixers) do not silently substitute or modify
        user-provided preferences.

     Because real-time sessions often involve multiple participants,
     systems SHOULD provide clear and accessible mechanisms for users to
     understand what AI-related preferences are being signaled on their
     behalf.

  9.1.2.  Avoiding Over-Restriction of Beneficial Uses

     Real-time communication is frequently used for accessibility
     (captioning, translation), education, archiving, and research.
     Overly broad or ambiguous preference categories—particularly those
     related to “AI Input” or “AI Training”—may unintentionally block
     beneficial, lawful, or expected uses.

     Implementations SHOULD:

     *  Distinguish between AI-assisted user features (e.g., live
        transcription) and model-building uses (e.g., training).

     *  Avoid treating a single preference (e.g., ai-input=n) as a blanket
        prohibition on all automated processing.

     *  Provide clear documentation on how preferences interact with
        accessibility features.

     Preference categories defined in AIPREF vocabulary drafts (e.g.,
     search, ai-input, ai-train) SHOULD be interpreted narrowly and
     consistently.

  9.1.3.  Transparency to Participants

     Real-time sessions may involve dynamic negotiation (e.g., via SDP
     offer/answer).  When AI-usage preferences are conveyed:

     *  Endpoints SHOULD surface these preferences to human participants
        in a clear and non-technical manner.






  Bisht                     Expires 7 August 2026                [Page 11]


  Internet-Draft             AI Pref RT Bindings             February 2026


     *  Systems SHOULD indicate when preferences differ between
        participants or when intermediaries have applied additional
        constraints.

     *  If preferences affect session features (e.g., disabling
        transcription), participants SHOULD be notified.

     Lack of transparency may create a chilling effect, where users avoid
     lawful or beneficial uses due to uncertainty.

  9.1.4.  Intermediary Handling and Privacy Leakage

     Signaling AI-usage preferences at the session layer may inadvertently
     reveal information about user intent, content sensitivity, or
     organizational policy.  For example, a preference of ai-train=n may
     imply that the content is proprietary or confidential.

     To mitigate this:

     *  Intermediaries MUST NOT add, remove, or alter AI-usage preferences
        unless explicitly authorized by the originating endpoint.

     *  Preferences SHOULD be encrypted or integrity-protected when
        carried in protocols that support such mechanisms (e.g.,
        DTLS-SRTP, QUIC).

     *  Implementations SHOULD avoid exposing preferences in logs,
        analytics, or telemetry unless necessary and with appropriate
        safeguards.

  9.1.5.  Compatibility with Archiving and Research

     Real-time communication is often recorded for compliance, education,
     or archival purposes.  AI-usage preferences SHOULD NOT be interpreted
     as prohibiting:

     *  lawful archiving,

     *  time-shifted review,

     *  accessibility processing, or

     *  research uses permitted by local law.

     Where preferences do apply to stored recordings, systems SHOULD
     preserve the preferences alongside the stored media, consistent with
     the behavior defined in draft-ietf-aipref-attach for HTTP
     representations.



  Bisht                     Expires 7 August 2026                [Page 12]


  Internet-Draft             AI Pref RT Bindings             February 2026


  9.1.6.  Avoiding Platform-Level Overreach

     Large communication platforms may be tempted to apply AI-usage
     preferences globally on behalf of users.  This can undermine user
     autonomy and distort the intent of AIPREF.

     Platforms SHOULD:

     *  Allow per-participant and per-stream preferences.

     *  Avoid applying organization-wide defaults without clear user
        visibility.

     *  Provide APIs for endpoints to express their own preferences
        without mediation.

  9.1.7.  Interoperability and Open Ecosystem Considerations

     Real-time protocols are used across diverse environments, including
     open-source clients, small organizations, and global platforms.  To
     avoid fragmentation:

     *  Preferences SHOULD be optional and non-blocking.

     *  Absence of a preference MUST NOT be interpreted as consent.

     *  Implementations SHOULD follow the vocabulary and semantics defined
        in AIPREF drafts to ensure consistent interpretation across
        ecosystems.

  10.  IANA Considerations

     IANA is requested to perform the following actions.

  10.1.  SIP Header Field Registration

     Register the AI-Pref header field in the "Header Fields" sub-registry
     under "Session Initiation Protocol (SIP) Parameters" with the
     following values:

     *  Header Name: AI-Pref

     *  Compact Form: none

     *  Reference: This document






  Bisht                     Expires 7 August 2026                [Page 13]


  Internet-Draft             AI Pref RT Bindings             February 2026


  10.2.  SDP Attribute Registration

     Register the aipref attribute in the "att-field (media level only)"
     registry defined by RFC4566 with the following values:

     *  Attribute name: aipref

     *  Type of attribute: media / session

     *  Subject to charset: no

     *  Purpose: Associates SDP media sections with AI preference tokens

     *  Reference: This document

  Acknowledgments

     This work is informed by discussions within the AIPREF working group,
     including contributions on network privacy controls and media quality
     automation.

  References

  Normative References

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

     [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                DOI 10.17487/RFC3261, June 2002,
                <https://www.rfc-editor.org/rfc/rfc3261>.

     [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
                with Session Description Protocol (SDP)", RFC 3264,
                DOI 10.17487/RFC3264, June 2002,
                <https://www.rfc-editor.org/rfc/rfc3264>.

     [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
                UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
                2002, <https://www.rfc-editor.org/rfc/rfc3311>.

     [RFC6665]  Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
                DOI 10.17487/RFC6665, July 2012,
                <https://www.rfc-editor.org/rfc/rfc6665>.



  Bisht                     Expires 7 August 2026                [Page 14]


  Internet-Draft             AI Pref RT Bindings             February 2026


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

     [RFC8830]  Alvestrand, H., "WebRTC MediaStream Identification in the
                Session Description Protocol", RFC 8830,
                DOI 10.17487/RFC8830, January 2021,
                <https://www.rfc-editor.org/rfc/rfc8830>.

  Informative References

     [I-D.aipref-network-privacy-control]
                "*** BROKEN REFERENCE ***".

     [RFC3265]  Roach, A. B., "Session Initiation Protocol (SIP)-Specific
                Event Notification", RFC 3265, DOI 10.17487/RFC3265, June
                2002, <https://www.rfc-editor.org/rfc/rfc3265>.

     [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
                Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
                July 2006, <https://www.rfc-editor.org/rfc/rfc4566>.

     [RFC7587]  Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format
                for the Opus Speech and Audio Codec", RFC 7587,
                DOI 10.17487/RFC7587, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7587>.

     [RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
                Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
                <https://www.rfc-editor.org/rfc/rfc8831>.

  Author's Address

     Altanai Bisht
     Cisco Meraki
     Email: albisht@cisco.com















  Bisht                     Expires 7 August 2026                [Page 15]


name: draft-miller-ssh-agent
rev: 17
title: SSH Agent Protocol
abstract:
  This document describes a key agent protocol for use in the Secure
  Shell (SSH) protocol.

time: 2024-11-07T12:54:32Z
group: sshm
group_uri: /api/v1/group/group/2430/
expires: 2025-04-21T01:36:49Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:04.596439+00:00
source: ietf
full_text:
  Internet Engineering Task Force                                D. Miller
  Internet-Draft                                                   OpenSSH
  Intended status: Informational                           18 October 2024
  Expires: 21 April 2025


                             SSH Agent Protocol
                         draft-miller-ssh-agent-17

  Abstract

     This document describes a key agent protocol for use in the Secure
     Shell (SSH) protocol.

  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 21 April 2025.

  Copyright Notice

     Copyright (c) 2024 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.







  Miller                    Expires 21 April 2025                 [Page 1]


  Internet-Draft             SSH Agent Protocol               October 2024


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Messages . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Generic server responses  . . . . . . . . . . . . . . . .   4
       3.2.  Adding keys to the agent  . . . . . . . . . . . . . . . .   4
         3.2.1.  DSA keys  . . . . . . . . . . . . . . . . . . . . . .   5
         3.2.2.  ECDSA keys  . . . . . . . . . . . . . . . . . . . . .   5
         3.2.3.  EDDSA keys  . . . . . . . . . . . . . . . . . . . . .   6
         3.2.4.  RSA keys  . . . . . . . . . . . . . . . . . . . . . .   6
         3.2.5.  Other keys  . . . . . . . . . . . . . . . . . . . . .   7
         3.2.6.  Adding keys from a token  . . . . . . . . . . . . . .   7
         3.2.7.  Key Constraints . . . . . . . . . . . . . . . . . . .   8
       3.3.  Public key encoding . . . . . . . . . . . . . . . . . . .   9
       3.4.  Removing keys from the agent  . . . . . . . . . . . . . .   9
       3.5.  Requesting a list of keys . . . . . . . . . . . . . . . .  10
       3.6.  Private key operations  . . . . . . . . . . . . . . . . .  10
         3.6.1.  Signature flags . . . . . . . . . . . . . . . . . . .  11
       3.7.  Locking and unlocking an agent  . . . . . . . . . . . . .  11
       3.8.  Extension mechanism . . . . . . . . . . . . . . . . . . .  12
         3.8.1.  Query extension . . . . . . . . . . . . . . . . . . .  12
     4.  Forwarding access to an agent . . . . . . . . . . . . . . . .  13
       4.1.  Advertising agent forwarding support  . . . . . . . . . .  13
       4.2.  Requesting agent forwarding . . . . . . . . . . . . . . .  13
       4.3.  Agent connection requests . . . . . . . . . . . . . . . .  14
     5.  Protocol numbers  . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.  Message numbers . . . . . . . . . . . . . . . . . . . . .  15
         5.1.1.  Reserved message numbers  . . . . . . . . . . . . . .  15
       5.2.  Constraint identifiers  . . . . . . . . . . . . . . . . .  16
       5.3.  Signature flags . . . . . . . . . . . . . . . . . . . . .  16
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
       6.1.  New registry: SSH agent protocol numbers  . . . . . . . .  16
       6.2.  New registry: SSH agent key constraint numbers  . . . . .  18
       6.3.  New registry: SSH agent signature flags . . . . . . . . .  19
       6.4.  New registry: SSH agent extension request names . . . . .  19
       6.5.  Additions to SSH Extension Names  . . . . . . . . . . . .  20
       6.6.  Additions to SSH Connection Protocol Channel Request
             Names . . . . . . . . . . . . . . . . . . . . . . . . . .  20
       6.7.  Additions to SSH Connection Protocol Channel Types  . . .  20
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  23
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  24




  Miller                    Expires 21 April 2025                 [Page 2]


  Internet-Draft             SSH Agent Protocol               October 2024


  1.  Introduction

     Secure Shell (SSH) is a protocol for secure remote connections and
     login over untrusted networks.  It supports multiple authentication
     mechanisms, including public key authentication.  This document
     describes the protocol for interacting with an agent that holds
     private keys.  Clients (and possibly servers) can invoke the agent
     via this protocol to perform operations using public and private keys
     held in the agent.

     Holding keys in an agent offers usability and security advantages to
     loading and unwrapping them at each use.  Moreover, the agent
     implements a simple protocol and presents a smaller attack surface
     than a key loaded into a full SSH server or client.

     This agent protocol is already widely used and a de-facto standard,
     having been implemented by a number of popular SSH clients and
     servers for many years.  The purpose of this document is to describe
     the protocol as it has been implemented.

  1.1.  Requirements Language

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

  2.  Protocol Overview

     The agent protocol is a packetised request-response protocol, solely
     driven by the client.  It consists of a number of requests sent from
     the client to the server and a set of reply messages that are sent in
     response.  At no time does the server send messages except in
     response to a client request.  Replies are sent in order.

     Agents MAY implement support for only a subset of operations or
     available key types, and MAY additionally refuse abitrary operations
     in particular contexts.  For example, an agent may allow only local
     clients of an agent to add or remove keys, or make particular subsets
     of keys available to a given client.  For this reason, clients of the
     agent SHOULD be prepared to fail gracefully if any operation is
     refused.

     Note that this protocol is separate to and incompatible with the one
     described in the similarly-named [draft-ietf-secsh-agent-02].





  Miller                    Expires 21 April 2025                 [Page 3]


  Internet-Draft             SSH Agent Protocol               October 2024


  3.  Protocol Messages

     All values in the agent protocol are encoded using the SSH wire
     representations specified by [RFC4251].  Messages consist of a
     length, type and contents.

        uint32            length
        byte              type
        byte[length - 1]  contents

  3.1.  Generic server responses

     The following generic messages may be sent by the server in response
     to requests from the client.  On success the agent may reply either
     with:

        byte              SSH_AGENT_SUCCESS

     or a request-specific success message.  On failure, the agent may
     reply with:

        byte              SSH_AGENT_FAILURE

     SSH_AGENT_FAILURE messages are also sent in reply to requests with
     unknown types.

  3.2.  Adding keys to the agent

     Keys may be added to the agent using the SSH_AGENTC_ADD_IDENTITY or
     SSH_AGENTC_ADD_ID_CONSTRAINED messages.  The latter variant allows
     adding keys with optional constraints on their usage.

     The generic format for the key SSH_AGENTC_ADD_IDENTITY message is:

         byte             SSH_AGENTC_ADD_IDENTITY
         string           key type
         byte[]           key contents
         string           key comment

     Here "type" is the specified key type name, for example "ssh-rsa" for
     a RSA key as defined by [RFC4253]. "contents" consists of the public
     and private components of the key and vary by key type, they are
     listed below for standard and commonly used key types. "comment" is
     an optional human-readable key name or comment as a UTF-8 string that
     may serve to identify the key in user-visible messages.

     The SSH_AGENTC_ADD_ID_CONSTRAINED is similar, but adds a extra field:




  Miller                    Expires 21 April 2025                 [Page 4]


  Internet-Draft             SSH Agent Protocol               October 2024


         byte             SSH_AGENTC_ADD_ID_CONSTRAINED
         string           type
         byte[]           contents
         string           comment
         constraint[]     constraints

     Constraints are used to place limits on the validity or use of keys.
     Section 3.2.7 details constraint types and their format.

     An agent should reply with SSH_AGENT_SUCCESS if the key was
     successfully loaded as a result of one of these messages, or
     SSH_AGENT_FAILURE otherwise.

     An agent MAY support only a subset of the key types defined here and
     may support additional key types as described below.  If an agent
     does not recognise the type name in a request to add a key, then it
     MUST fail gracefully and respond with a SSH_AGENT_FAILURE reply.

  3.2.1.  DSA keys

     DSA keys have key type "ssh-dss" and are defined in [RFC4253].  They
     may be added to the agent using the following message.  The
     "constraints" field is only present for the
     SSH_AGENTC_ADD_ID_CONSTRAINED message.

         byte             SSH_AGENTC_ADD_IDENTITY or
                          SSH_AGENTC_ADD_ID_CONSTRAINED
         string           "ssh-dss"
         mpint            p
         mpint            q
         mpint            g
         mpint            y
         mpint            x
         string           comment
         constraint[]     constraints

     The "p", "q", "g" values are the DSA domain parameters. "y" and "x"
     are the public and private keys respectively.  These values are as
     defined by [FIPS.186-4].

  3.2.2.  ECDSA keys

     ECDSA keys have key types starting with "ecdsa-sha2-" and are defined
     in [RFC5656].  They may be added to the agent using the following
     message.  The "constraints" field is only present for the
     SSH_AGENTC_ADD_ID_CONSTRAINED message.





  Miller                    Expires 21 April 2025                 [Page 5]


  Internet-Draft             SSH Agent Protocol               October 2024


         byte             SSH_AGENTC_ADD_IDENTITY or
                          SSH_AGENTC_ADD_ID_CONSTRAINED
         string           key type
         string           ecdsa_curve_name
         string           Q
         mpint            d
         string           comment
         constraint[]     constraints

     The values "Q" and "d" are the ECDSA public and private values
     respectively.  Both are defined by [FIPS.186-4].

  3.2.3.  EDDSA keys

     [RFC8709] defines Ed25519 and Ed448 with key type names "ssh-ed25519"
     and "ssh-ed448" respectively.  These may be added to the agent using
     the following message.  The "key constraints" field is only present
     for the SSH_AGENTC_ADD_ID_CONSTRAINED message.

         byte             SSH_AGENTC_ADD_IDENTITY or
                          SSH_AGENTC_ADD_ID_CONSTRAINED
         string           "ssh-ed25519" or "ssh-ed448"
         string           ENC(A)
         string           k || ENC(A)
         string           comment
         constraint[]     constraints

     The first value is the EDDSA public key ENC(A).  The second value is
     a concatenation of the private key k and the public ENC(A) key.  The
     contents and interpretation of the ENC(A) and k values are defined by
     [RFC8032].

  3.2.4.  RSA keys

     RSA keys have key type "ssh-rsa" and are defined in [RFC4253].  They
     may be added to the agent using the following message.  The "key
     constraints" field is only present for the
     SSH_AGENTC_ADD_ID_CONSTRAINED message.













  Miller                    Expires 21 April 2025                 [Page 6]


  Internet-Draft             SSH Agent Protocol               October 2024


         byte             SSH_AGENTC_ADD_IDENTITY or
                          SSH_AGENTC_ADD_ID_CONSTRAINED
         string           "ssh-rsa"
         mpint            n
         mpint            e
         mpint            d
         mpint            iqmp
         mpint            p
         mpint            q
         string           comment
         constraint[]     constraints

     "n" is the public composite modulus.  "p" and "q" are its constituent
     private prime factors. "e" is the public exponent.  "iqmp" is the
     inverse of "q" modulo "p".  All these values except "iqmp" (which can
     be calculated from the others) are defined by [FIPS.186-4].

  3.2.5.  Other keys

     Agents and their clients MAY support additional key types not
     documented here.  Vendor-specific key types should use the domain-
     qualified naming convention defined in Section 4.2 of [RFC4251].

  3.2.6.  Adding keys from a token

     Keys hosted on smart-cards or other hardware tokens may be added
     using the SSH_AGENTC_ADD_SMARTCARD_KEY and
     SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED requests.  Note that
     "constraints" field is only included for the
     SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED variant of this message.

         byte             SSH_AGENTC_ADD_SMARTCARD_KEY or
                          SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
         string           id
         string           PIN
         constraint[]     constraints

     Here "id" is an opaque identifier for the hardware token and "PIN" is
     an optional password or PIN to unlock the key.  The interpretation of
     "id" is not defined by the protocol but is left solely up to the
     agent.

     Typically only the public components of any keys supported on a
     hardware token will be loaded into an agent so, strictly speaking,
     this message really arranges future private key operations to be
     delegated to the hardware token in question.





  Miller                    Expires 21 April 2025                 [Page 7]


  Internet-Draft             SSH Agent Protocol               October 2024


     An agent should reply with SSH_AGENT_SUCCESS if one or more keys were
     successfully loaded as a result of one of these messages, or
     SSH_AGENT_FAILURE if no keys were found.  The agent should also
     return SSH_AGENT_FAILURE if the token "id" was not recognised or if
     the agent doesn't support token-hosted keys at all.

  3.2.7.  Key Constraints

     A number of constraints and may be used in the constrained variants
     of the key add messages.  Each constraint is represented by a type
     byte followed by zero or more value bytes.

     Zero or more constraints may be specified when adding a key with one
     of the *_CONSTRAINED requests.  Multiple constraints are appended
     consecutively to the end of the request:

         byte             constraint1_type
         byte[]           constraint1_data
         byte             constraint2_type
         byte[]           constraint2_data
         ....
         byte             constraintN_type
         byte[]           constraintN_data

     If an agent does not recognise or support a requested constraint it
     MUST refuse the request and return a SSH_AGENT_FAILURE message to the
     client.

     The following constraints are defined.

  3.2.7.1.  Key lifetime constraint

     This constraint requests that the agent limit the key's lifetime by
     deleting it after the specified duration (in seconds) has elapsed
     from the time the key was added to the agent.

         byte             SSH_AGENT_CONSTRAIN_LIFETIME
         uint32           seconds

  3.2.7.2.  Key confirmation constraint

     This constraint requests that the agent require explicit user
     confirmation for each private key operation using the key.  For
     example, the agent could present a confirmation dialog before
     completing a signature operation.

         byte             SSH_AGENT_CONSTRAIN_CONFIRM




  Miller                    Expires 21 April 2025                 [Page 8]


  Internet-Draft             SSH Agent Protocol               October 2024


  3.2.7.3.  Constraint extensions

     Agents may implement experimental or private-use constraints through
     a extension constraint that supports named constraints.

         byte             SSH_AGENT_CONSTRAIN_EXTENSION
         string           extension name
         byte[]           extension-specific details

     The extension name MUST consist of a UTF-8 string suffixed by the
     implementation domain following the naming scheme defined in
     Section 4.2 of [RFC4251], e.g.  "foo@example.com".

  3.3.  Public key encoding

     Keys previously loaded into an agent are referred to by their public
     key blob, which is the standard SSH wire encoding for public keys.
     SSH protocol key encodings are defined in [RFC4253] for "ssh-rsa" and
     "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys and in [RFC8709]
     for "ssh-ed25519" and "ssh-ed448" keys.

  3.4.  Removing keys from the agent

     A client may request that an agent remove all keys that it stores:

         byte             SSH_AGENTC_REMOVE_ALL_IDENTITIES

     On receipt of such a message, an agent shall delete all keys that it
     is holding and reply with SSH_AGENT_SUCCESS.

     Specific keys may also be removed:

         byte             SSH_AGENTC_REMOVE_IDENTITY
         string           key blob

     Where "key blob" is the standard public key encoding of the key to be
     removed (Section 3.3).

     An agent shall reply with SSH_AGENT_SUCCESS if the key was deleted or
     SSH_AGENT_FAILURE if it was not found.

     Smartcard keys may be removed using:

         byte             SSH_AGENTC_REMOVE_SMARTCARD_KEY
         string           reader id
         string           PIN





  Miller                    Expires 21 April 2025                 [Page 9]


  Internet-Draft             SSH Agent Protocol               October 2024


     Where "reader id" is an opaque identifier for the smartcard reader
     and "PIN" is an optional password or PIN (not typically used).
     Requesting deletion of smartcard-hosted keys SHOULD cause the agent
     to remove all keys loaded from that smartcard.

     An agent shall reply with SSH_AGENT_SUCCESS if the key was deleted or
     SSH_AGENT_FAILURE if it was not found.

  3.5.  Requesting a list of keys

     A client may request a list of keys from an agent using the following
     message:

         byte             SSH_AGENTC_REQUEST_IDENTITIES

     The agent shall reply with a message with the following preamble.

         byte             SSH_AGENT_IDENTITIES_ANSWER
         uint32           nkeys

     Where "nkeys" indicates the number of keys to follow.  Following the
     preamble are zero or more keys, each encoded as:

         string           key blob
         string           comment

     Where "key blob" is the standard public key encoding of the key
     (Section 3.3) and "comment" is a human-readable comment encoded as a
     UTF-8 string.

  3.6.  Private key operations

     A client may request the agent perform a private key signature
     operation using the following message:

         byte             SSH_AGENTC_SIGN_REQUEST
         string           key blob
         string           data
         uint32           flags

     Where "key blob" is the key requested to perform the signature
     (encoded as per Section 3.3), "data" is the data to be signed and
     "flags" is a bitfield containing the bitwise OR of zero or more
     signature flags (see below).







  Miller                    Expires 21 April 2025                [Page 10]


  Internet-Draft             SSH Agent Protocol               October 2024


     If the agent does not support the requested flags, or is otherwise
     unable or unwilling to generate the signature (e.g.  because it
     doesn't have the specified key, or the user refused confirmation of a
     constrained key), it must reply with a SSH_AGENT_FAILURE message.

     On success, the agent shall reply with:

         byte             SSH_AGENT_SIGN_RESPONSE
         string           signature

     The signature format is specific to the algorithm of the key type in
     use.  SSH protocol signature formats are defined in [RFC4253] for
     "ssh-rsa" and "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys
     and in [RFC8709] for "ssh-ed25519" and "ssh-ed448" keys.

  3.6.1.  Signature flags

     Two flags are currently defined for signature request messages:
     SSH_AGENT_RSA_SHA2_256 and SSH_AGENT_RSA_SHA2_512.  These two flags
     are only valid for "ssh-rsa" keys and request that the agent return a
     signature using the "rsa-sha2-256" or "rsa-sha2-512" signature
     methods respectively.  These signature schemes are defined in
     [RFC8332].

  3.7.  Locking and unlocking an agent

     The agent protocol supports requesting that an agent temporarily lock
     itself with a pass-phrase.  When locked an agent should suspend
     processing of sensitive operations (private key signature operations
     at the very least) until it has been unlocked with the same pass-
     phrase.

     The following message requests agent locking

         byte             SSH_AGENTC_LOCK
         string           passphrase

     The agent shall reply with SSH_AGENT_SUCCESS if locked successfully
     or SSH_AGENT_FAILURE otherwise (e.g. if the agent was already
     locked).

     The following message requests unlocking an agent:

         byte             SSH_AGENTC_UNLOCK
         string           passphrase






  Miller                    Expires 21 April 2025                [Page 11]


  Internet-Draft             SSH Agent Protocol               October 2024


     If the agent is already locked and the pass-phrase matches the one
     used to lock it then it should unlock and reply with
     SSH_AGENT_SUCCESS.  If the agent is unlocked or if the the pass-
     phrase does not match it should reply with SSH_AGENT_FAILURE.  An
     agent SHOULD take countermeasures against brute-force guessing
     attacks against the pass-phrase.

  3.8.  Extension mechanism

     The agent protocol includes an optional extension mechanism that
     allows vendor-specific and experimental messages to be sent via the
     agent protocol.  Extension requests from the client consist of:

         byte             SSH_AGENTC_EXTENSION
         string           extension type
         byte[]           extension request-specific contents

     The extension type indicates the type of the extension message as a
     UTF-8 string.  Implementation-specific extensions should be suffixed
     by the implementation domain following the extension naming scheme
     defined in Section 4.2 of [RFC4251], e.g. "foo@example.com".

     An agent that does not support extensions of the supplied type MUST
     reply with an empty SSH_AGENT_FAILURE message.  This reply is also
     sent by agents that do not support the extension mechanism at all.

     The contents of successful extension reply messages are specific to
     the extension type.  Extension requests may return SSH_AGENT_SUCCESS
     on success or the extension-specific response message:

         byte             SSH_AGENT_EXTENSION_RESPONSE
         string           extension type
         byte[]           extension response-specific contents

     Where the extension type is the same as that in the request.

     Extension failure should be signaled using the
     SSH_AGENT_EXTENSION_FAILURE code - extensions should not use the
     standard SSH_AGENT_FAILURE message.  This allows failed requests to
     be distinguished from the extension not being supported.

  3.8.1.  Query extension

     A single, optional extension request "query" is defined to allow a
     client to query which, if any, extensions are supported by an agent.

         byte             SSH_AGENTC_EXTENSION
         string           "query"



  Miller                    Expires 21 April 2025                [Page 12]


  Internet-Draft             SSH Agent Protocol               October 2024


     If an agent supports the query extension is should reply with a list
     of supported extension names.

         byte             SSH_AGENT_EXTENSION_RESPONSE
         string           "query"
         string[]         supported extension types

  4.  Forwarding access to an agent

     The agent protocol may be forwarded over a SSH connection, using the
     [RFC4254] connection protocol, allowing agent forwarding to be
     requested for any session channel, using a model that is similar to
     the connection protocol's support for X11 Forwarding (Section 6.3 of
     [RFC4254]).  This feature is OPTIONAL for SSH protocol and agent
     implementations.

     Note that the deployed integration with the SSH protocol uses vendor-
     specific names.

  4.1.  Advertising agent forwarding support

     Support for agent forwarding may be advertised by a SSH protocol
     server using the [RFC8308] extension mechanism using the name "agent-
     forward" in the SSH_MSG_EXT_INFO message.

         string           "agent-forward"
         string           "0" (version)

     Note that this protocol substantially predates the existence of the
     [RFC8308] extension mechanism and several widely-deployed SSH
     implementations that support agent forwarding do not advertise their
     ability to do so.  Clients MAY opportunitically attempt to request
     agent forwarding in the absence of an [RFC8308] advertisment using
     the vendor-specific names mentioned below.  Likewise, servers MAY
     implement the vendor-specific names in addition to the one described
     here.

  4.2.  Requesting agent forwarding

     A client may request agent forwarding for a previously-opened session
     (Section 6.1 of [RFC4254]) using the following channel request.  This
     request is sent after the channel has been opened, but before a
     shell, command or subsystem has been executed.

         byte             SSH_MSG_CHANNEL_REQUEST
         string           channel_id
         string           "agent-req" or "auth-agent-req@openssh.com"
         boolean          want_reply



  Miller                    Expires 21 April 2025                [Page 13]


  Internet-Draft             SSH Agent Protocol               October 2024


     Where channel_id is the identifier for an established session channel
     (as returned from a previous SSH_MSG_CHANNEL_OPEN request, and the
     want_reply flag indicates whether the server should respond with a
     confirmation of whether the request was successful (as specified in
     Section 5.4 of [RFC4254])

     If a SSH server accepts this request, typically it will arrange to
     make a endpoint (e.g. a listening socket) available and advertise
     this fact to the subordinate session.  Most implementations on Unix-
     like systems do this by providing a user-private listening Unix
     domain socket and recording its location in an environment variable
     $SSH_AUTH_SOCK.

     As mentioned previously, many deployed implementations only support
     the former, pre-standardisation "auth-agent-req@openssh.com" request
     name.  The latter "agent-req" name SHOULD only be used if support was
     explicitly advertised as per Section 4.1.

  4.3.  Agent connection requests

     After a client has requested that a session have agent forwarding
     enabled, the server later may request a connection to the forwarded
     agent.  The server does this by requesting a dedicated channel to
     communicate with the client's agent.

         byte             SSH_MSG_CHANNEL_OPEN
         string           "agent-connect" or "auth-agent@openssh.com"
         uint32           channel_id
         uint32           local_window
         uint32           local_maxpacket

     The channel_id, local_window and local_maxpacket fields should be
     interpreted as specified by Section 5.1 of [RFC4254].

     As above, the latter "agent-connect" open type name SHOULD only be
     used if support was explicitly advertised as per Section 4.1.

     A client SHOULD be prepared to handle multiple concurrent active
     agent connections.  A client MAY accept agent connection requests
     (subject to authorisation) without a prior agent forwarding request
     having been made to support the situation where agent forwarding
     without opening a session is desired.  Similarly, a client MAY
     continue to accept agent connection requests after the session for
     which agent forwarding was requested has closed.

     A client MUST refuse unauthorised agent connection requests, i.e.
     when agent forwarding was not desired or requested but a server sends
     an agent connection request anyway.



  Miller                    Expires 21 April 2025                [Page 14]


  Internet-Draft             SSH Agent Protocol               October 2024


     Note the connection request provides no way to identify which session
     channel a given agent connection request relates to.  This implies
     that a SSH connection can functionally forward access to only a
     single client-side agent concurrently using this protocol.

  5.  Protocol numbers

  5.1.  Message numbers

     The following numbers are used for requests from the client to the
     agent.

         SSH_AGENTC_REQUEST_IDENTITIES                  11
         SSH_AGENTC_SIGN_REQUEST                        13
         SSH_AGENTC_ADD_IDENTITY                        17
         SSH_AGENTC_REMOVE_IDENTITY                     18
         SSH_AGENTC_REMOVE_ALL_IDENTITIES               19
         SSH_AGENTC_ADD_SMARTCARD_KEY                   20
         SSH_AGENTC_REMOVE_SMARTCARD_KEY                21
         SSH_AGENTC_LOCK                                22
         SSH_AGENTC_UNLOCK                              23
         SSH_AGENTC_ADD_ID_CONSTRAINED                  25
         SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED       26
         SSH_AGENTC_EXTENSION                           27

     The following numbers are used for replies from the agent to the
     client.

         SSH_AGENT_FAILURE                               5
         SSH_AGENT_SUCCESS                               6
         SSH_AGENT_IDENTITIES_ANSWER                     12
         SSH_AGENT_SIGN_RESPONSE                         14
         SSH_AGENT_EXTENSION_FAILURE                     28
         SSH_AGENT_EXTENSION_RESPONSE                    29

  5.1.1.  Reserved message numbers

     The following message numbers are reserved for implementations that
     implement support for the legacy SSH protocol version 1: 1-4, 7-9 and
     24 (inclusive).  These message numbers MAY be used by an
     implementation supporting the legacy protocol but MUST NOT be reused
     otherwise.

     The range of message numbers 240-255 are reserved for organization-
     local extensions to the agent protocol and MUST NOT be used by
     generic implementations.





  Miller                    Expires 21 April 2025                [Page 15]


  Internet-Draft             SSH Agent Protocol               October 2024


  5.2.  Constraint identifiers

     The following numbers are used to identify key constraints.  These
     are only used in key constraints and are not sent as message numbers.

         SSH_AGENT_CONSTRAIN_LIFETIME                    1
         SSH_AGENT_CONSTRAIN_CONFIRM                     2
         SSH_AGENT_CONSTRAIN_EXTENSION                   255

  5.3.  Signature flags

     The following numbers may be present in signature request
     (SSH_AGENTC_SIGN_REQUEST) messages.  These flags form a bit field by
     taking the logical OR of zero or more flags.

         SSH_AGENT_RSA_SHA2_256                          2
         SSH_AGENT_RSA_SHA2_512                          4

     The flag value 1 is reserved for historical implementations.

  6.  IANA Considerations

     This protocol requires three registries be established, one for
     message numbers, one for constraints and one for signature request
     flags.

  6.1.  New registry: SSH agent protocol numbers

     This registry, titled "SSH agent protocol numbers" records the
     message numbers for client requests and agent responses.  Its initial
     state should consist of the following numbers and reservations.
     Future message number allocations shall occur via EXPERT REVIEW as
     per [RFC8126].

     +===========+==========================================+===========+
     | Number(s) | Identifier                               | Reference |
     +===========+==========================================+===========+
     | 1         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 2         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 3         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 4         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |



  Miller                    Expires 21 April 2025                [Page 16]


  Internet-Draft             SSH Agent Protocol               October 2024


     +-----------+------------------------------------------+-----------+
     | 5         | SSH_AGENT_FAILURE                        | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 6         | SSH_AGENT_SUCCESS                        | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 7         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 8         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 9         | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 10        | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 11        | SSH_AGENTC_REQUEST_IDENTITIES            | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 12        | SSH_AGENT_IDENTITIES_ANSWER              | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 13        | SSH_AGENTC_SIGN_REQUEST                  | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 14        | SSH_AGENT_SIGN_RESPONSE                  | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 15        | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 16        | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 17        | SSH_AGENTC_ADD_IDENTITY                  | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 18        | SSH_AGENTC_REMOVE_IDENTITY               | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 19        | SSH_AGENTC_REMOVE_ALL_IDENTITIES         | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 20        | SSH_AGENTC_ADD_SMARTCARD_KEY             | Section   |
     |           |                                          | 5.1       |



  Miller                    Expires 21 April 2025                [Page 17]


  Internet-Draft             SSH Agent Protocol               October 2024


     +-----------+------------------------------------------+-----------+
     | 21        | SSH_AGENTC_REMOVE_SMARTCARD_KEY          | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 22        | SSH_AGENTC_LOCK                          | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 23        | SSH_AGENTC_UNLOCK                        | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 24        | reserved                                 | Section   |
     |           |                                          | 5.1.1     |
     +-----------+------------------------------------------+-----------+
     | 25        | SSH_AGENTC_ADD_ID_CONSTRAINED            | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 26        | SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 27        | SSH_AGENTC_EXTENSION                     | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 28        | SSH_AGENT_EXTENSION_FAILURE              | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 29        | SSH_AGENT_EXTENSION_RESPONSE             | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+
     | 240-255   | Reserved for organizational use          | Section   |
     |           |                                          | 5.1       |
     +-----------+------------------------------------------+-----------+

                                   Table 1

  6.2.  New registry: SSH agent key constraint numbers

     This registry, titled "SSH agent key constraint numbers" records the
     message numbers for key use constraints.  Its initial state should
     consist of the following numbers.  Future message number allocations
     shall occur via EXPERT REVIEW as per [RFC8126].











  Miller                    Expires 21 April 2025                [Page 18]


  Internet-Draft             SSH Agent Protocol               October 2024


           +========+===============================+=============+
           | Number | Identifier                    | Reference   |
           +========+===============================+=============+
           | 1      | SSH_AGENT_CONSTRAIN_LIFETIME  | Section 5.2 |
           +--------+-------------------------------+-------------+
           | 2      | SSH_AGENT_CONSTRAIN_CONFIRM   | Section 5.2 |
           +--------+-------------------------------+-------------+
           | 255    | SSH_AGENT_CONSTRAIN_EXTENSION | Section 5.2 |
           +--------+-------------------------------+-------------+

                                   Table 2

  6.3.  New registry: SSH agent signature flags

     This registry, titled "SSH agent signature flags records the values
     for signature request (SSH_AGENTC_SIGN_REQUEST) flag values.  Its
     initial state should consist of the following numbers.  Note that as
     the flags are combined by bitwise OR, all flag values must be powers
     of two and the maximum available flag value is 0x80000000.

     Future message number allocations shall occur via EXPERT REVIEW as
     per [RFC8126].

               +========+========================+=============+
               | Number | Identifier             | Reference   |
               +========+========================+=============+
               | 0x01   | reserved               | Section 5.3 |
               +--------+------------------------+-------------+
               | 0x02   | SSH_AGENT_RSA_SHA2_256 | Section 5.3 |
               +--------+------------------------+-------------+
               | 0x04   | SSH_AGENT_RSA_SHA2_512 | Section 5.3 |
               +--------+------------------------+-------------+

                                    Table 3

  6.4.  New registry: SSH agent extension request names

     This registry, titled "SSH agent extension request names" records the
     names used in the generic extension request message
     (SSH_AGENTC_EXTENSION).  Its initial state should consist of the
     following names.

     Future message number allocations shall occur via EXPERT REVIEW as
     per [RFC8126].







  Miller                    Expires 21 April 2025                [Page 19]


  Internet-Draft             SSH Agent Protocol               October 2024


                      +================+===============+
                      | Extension Name | Reference     |
                      +================+===============+
                      | query          | Section 3.8.1 |
                      +----------------+---------------+

                                   Table 4

  6.5.  Additions to SSH Extension Names

     IANA is requested to insert the following entries into the table
     Extension Names [IANA-SSH-EXT] under Secure Shell (SSH) Protocol
     Parameters [RFC4250].

                       +================+=============+
                       | Extension Name | Reference   |
                       +================+=============+
                       | agent-forward  | Section 4.1 |
                       +----------------+-------------+

                                   Table 5

  6.6.  Additions to SSH Connection Protocol Channel Request Names

     IANA is requested to insert the following entries into the table
     Connection Protocol Channel Request Names [IANA-SSH-CHANREQ] under
     Secure Shell (SSH) Protocol Parameters [RFC4250].

                       +================+=============+
                       | Extension Name | Reference   |
                       +================+=============+
                       | agent-forward  | Section 4.2 |
                       +----------------+-------------+

                                   Table 6

  6.7.  Additions to SSH Connection Protocol Channel Types

     IANA is requested to insert the following entries into the table
     Connection Protocol Channel Types [IANA-SSH-CHANTYPE] under Secure
     Shell (SSH) Protocol Parameters [RFC4250].










  Miller                    Expires 21 April 2025                [Page 20]


  Internet-Draft             SSH Agent Protocol               October 2024


                       +================+=============+
                       | Extension Name | Reference   |
                       +================+=============+
                       | agent-connect  | Section 4.3 |
                       +----------------+-------------+

                                   Table 7

  7.  Security Considerations

     The agent is a service that is tasked with retaining and providing
     controlled access to what are typically long-lived login
     authentication credentials.  It is by nature a sensitive and trusted
     software component.  Moreover, the agent protocol itself does not
     include any authentication or transport security; ability to
     communicate with an agent is usually sufficient to invoke it to
     perform private key operations.

     Since being able to access an agent is usually sufficient to perform
     private key operations, it is critically important that the agent
     only be exposed to its owner and their authorised delegates.

     The primary design intention of an agent is that an attacker with
     unprivileged access to their victim's agent should be prevented from
     gaining a copy of any keys that have been loaded into it.  This may
     not preclude the attacker from stealing use of those keys (e.g.  if
     they have been loaded without a confirmation constraint).

     Given this, the agent should, as far as possible, prevent its memory
     being read by other processes to direct theft of loaded keys.  This
     typically include disabling debugging interfaces and preventing
     process memory dumps on abnormal termination.

     Another, more subtle, means by which keys may be stolen are via
     cryptographic side-channels.  Private key operations may leak
     information about the contents of keys via differences in timing,
     power use or by side-effects in the memory subsystems (e.g.  CPU
     caches) of the host running the agent.  For the case of a local
     attacker and an agent holding unconstrained keys, the only limit on
     the number of private key operations the attacker may be able to
     observe is the rate at which the CPU can perform signatures.  This
     grants the attacker an almost ideal oracle for side-channel attacks.
     While a full treatment of side-channel attacks is beyond the scope of
     this specification, agents SHOULD use cryptographic implementations
     that are resistant to side-channel attacks and MAY take additional
     measures to hide the actual time spent processing private key
     operations.




  Miller                    Expires 21 April 2025                [Page 21]


  Internet-Draft             SSH Agent Protocol               October 2024


     Forwarding access to a local agent over a SSH connection (Section 4)
     inherently creates a transitive trust relationship.  SSH
     implementations SHOULD NOT forward use of an agent by default and MAY
     implement additional controls over key visibility and use for
     forwarded agent connections.

  8.  References

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

     [RFC4250]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
                Protocol Assigned Numbers", RFC 4250,
                DOI 10.17487/RFC4250, January 2006,
                <https://www.rfc-editor.org/info/rfc4250>.

     [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
                January 2006, <https://www.rfc-editor.org/info/rfc4251>.

     [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
                January 2006, <https://www.rfc-editor.org/info/rfc4253>.

     [RFC4254]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
                Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
                January 2006, <https://www.rfc-editor.org/info/rfc4254>.

     [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
                Integration in the Secure Shell Transport Layer",
                RFC 5656, DOI 10.17487/RFC5656, December 2009,
                <https://www.rfc-editor.org/info/rfc5656>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/info/rfc8032>.

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





  Miller                    Expires 21 April 2025                [Page 22]


  Internet-Draft             SSH Agent Protocol               October 2024


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

     [RFC8308]  Bider, D., "Extension Negotiation in the Secure Shell
                (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
                2018, <https://www.rfc-editor.org/info/rfc8308>.

     [RFC8332]  Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
                the Secure Shell (SSH) Protocol", RFC 8332,
                DOI 10.17487/RFC8332, March 2018,
                <https://www.rfc-editor.org/info/rfc8332>.

     [RFC8709]  Harris, B. and L. Velvindron, "Ed25519 and Ed448 Public
                Key Algorithms for the Secure Shell (SSH) Protocol",
                RFC 8709, DOI 10.17487/RFC8709, February 2020,
                <https://www.rfc-editor.org/info/rfc8709>.

     [FIPS.186-4]
                National Institute of Standards and Technology, "Digital
                Signature Standard (DSS)", FIPS PUB 186-4, July 2013.

  8.2.  Informative References

     [IANA-SSH-CHANREQ]
                IANA, "Connection Protocol Channel Types",
                <https://www.iana.org/assignments/ssh-parameters/>.

     [IANA-SSH-CHANTYPE]
                IANA, "Extension Names",
                <https://www.iana.org/assignments/ssh-parameters/>.

     [IANA-SSH-EXT]
                IANA, "Connection Protocol Channel Request Names",
                <https://www.iana.org/assignments/ssh-parameters/>.

     [draft-ietf-secsh-agent-02]
                Ylonen, T., Rinne, T. J., and S. Lehtinen, "Secure Shell
                Authentication Agent Protocol", January 2004,
                <https://datatracker.ietf.org/doc/html/draft-ietf-secsh-
                agent-02>.

  Acknowledgements

     This protocol was designed and first implemented by Markus Friedl,
     based on a similar protocol for an agent to support the legacy SSH
     version 1 by Tatu Ylonen.




  Miller                    Expires 21 April 2025                [Page 23]


  Internet-Draft             SSH Agent Protocol               October 2024


     Thanks to Simon Tatham, Niels Möller and James Spencer who reviewed
     and helped improve this document.

  Author's Address

     Damien Miller
     OpenSSH
     Email: djm@openssh.com
     URI:   https://www.openssh.com/










































  Miller                    Expires 21 April 2025                [Page 24]


name: draft-zhao-nmrg-ai-agent-for-ndt
rev: 00
title: AI Agent Architecture for Network Digital Twin
time: 2026-03-02T14:54:38Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T14:54:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Other AI/agent"]
tags: []
fetched_at: 2026-03-04T00:00:04.631229+00:00
source: ietf
abstract:
  This document proposes an AI agent architecture for Network Digital
     Twin (NDT) that integrates AI agents with digital twin technology.

full_text:
  nmrg                                                        J. Zhao, Ed.
  Internet-Draft                                              R. Pang, Ed.
  Intended status: Standards Track                           S. Zhang, Ed.
  Expires: 3 September 2026                                   China Unicom
                                                               H. Shi, Ed.
                                                               C. Sun, Ed.
                                              Purple Mountain Laboratories
                                                              2 March 2026


               AI Agent Architecture for Network Digital Twin
                    draft-zhao-nmrg-ai-agent-for-ndt-00

  Abstract

     This document proposes an AI agent architecture for Network Digital
     Twin (NDT) that integrates AI agents with digital twin technology.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 3 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.



  Zhao, et al.            Expires 3 September 2026                [Page 1]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  AI Agent Architecture for Network Digital Twin  . . . . . . .   2
     3.  Architecture Components . . . . . . . . . . . . . . . . . . .   3
       3.1.  Network Digital Twin Management AI Agent  . . . . . . . .   3
       3.2.  Functional Model AI Agent . . . . . . . . . . . . . . . .   4
       3.3.  Basic Model AI Agent  . . . . . . . . . . . . . . . . . .   4
       3.4.  Data Repository AI Agent  . . . . . . . . . . . . . . . .   4
     4.  Agent Interactions  . . . . . . . . . . . . . . . . . . . . .   5
     5.  Intelligent Use Case Realization  . . . . . . . . . . . . . .   5
       5.1.  Automated IP Network Configuration Generation . . . . . .   5
         5.1.1.  Intent Understanding and Policy Generation  . . . . .   5
         5.1.2.  Multi-Level Simulation and Verification . . . . . . .   6
         5.1.3.  Model Evolution and Feedback Loop . . . . . . . . . .   6
       5.2.  Cutover Simulation (Scenario Construction)  . . . . . . .   6
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Digital twins have emerged as a powerful paradigm for network
     management, providing virtual representations of physical networks
     that enable simulation, analysis, and optimization.  However,
     traditional digital twin architectures often lack the autonomous
     decision-making capabilities needed for modern network environments.
     This document proposes an architecture that combines digital twin
     concepts with intelligent AI agents, creating a more dynamic and
     responsive network management system.

     The architecture is designed to be compatible with existing digital
     twin architectures.  This approach enables distributed decision-
     making, adaptive behavior, and enhanced collaboration between digital
     twin components.

  2.  AI Agent Architecture for Network Digital Twin

     Based on the concept of the Network Management Agent (NMA)
     [I-D.zhao-nmop-network-management-agent], we propose an AI Agent
     architecture for Network Digital Twin (NDT)
     [I-D.irtf-nmrg-network-digital-twin-arch].  This architecture extends
     the traditional network digital twin by integrating AI agents into
     each core component.  While preserving the fundamental structure of
     digital twins, the architecture introduces enhanced autonomous
     capabilities and intelligent decision-making across the network
     management lifecycle.



  Zhao, et al.            Expires 3 September 2026                [Page 2]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


     +-------------------------------------------------------------------------------------------+
     |                        Network Digital Twin Management AI Agent                           |
     |                                                                                           |
     |  - Resource & Health Monitoring        - Intent Parsing & Logic Translation               |
     |  - NDT Instance Lifecycle Management   - Multi-Agent Session Orchestration                |
     |  - Virtual-Physical State Sync Control - Business Intent & Policy Derivation              |
     +-------------------------------------------------------------------------------------------+
                 |                                                              |
                 |                                                              |
     +---------------------------------------+               +----------------------------------+
     |         Functional Model Agent        |               |      Data Repository Agent       |
     |                                       |               |                                  |
     | - Service Model Optimization          |<------------->| - Real-time Telemetry Ingestion  |
     | - Automated Configuration Synthesis   |               |   & Anomaly Detection            |
     | - Multi-Vendor Syntax Mapping         |               |                                  |
     | - Hierarchical Simulation Sandbox     |               | - Historical Data Intelligence   |
     |   (Compliance, Logic, Impact)         |               |   & Pattern Mining               |
     | - Scenario-specific Modeling          |               |                                  |
     | - Verification Feedback Loop          |               | - Knowledge Base Management      |
     +---------------------------------------+               |   (Vendor Docs/Best Practice)    |
                 |                                           |                                  |
                 |                                           | - Adaptive Data Retrieval        |
     +---------------------------------------+               |   & Conflict Resolution          |
     |           Basic Model Agent           |               |                                  |
     |                                       |<------------->| - Standardized Validation        |
     | - Network Element Digital Models      |               |   Report Storage                 |
     |   (Config, State, Env)                |               +----------------------------------+
     | - Topology & Connectivity Models      |
     | - Real-time Model Self-Updates        |
     +---------------------------------------+

         Figure 1: AI Agent Architecture for Network Digital Twin

     The following figure illustrates the hierarchical interaction between
     the Management, Functional, Basic, and Data agents.

  3.  Architecture Components

  3.1.  Network Digital Twin Management AI Agent

     The Network Digital Twin Management Agent serves as the central
     coordination and management component, providing the following key
     functionalities:

     *  Resource Monitoring: Continuously tracks and monitors the status,
        performance metrics, and operational health of all resources
        within the digital twin environment.




  Zhao, et al.            Expires 3 September 2026                [Page 3]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


     *  Lifecycle Management: Governs the complete lifecycle of NDT
        instances, encompassing instantiation, configuration, state
        synchronization, maintenance, and termination.

     *  Session Control: Orchestrates communication sessions and
        interactions among various AI agents to ensure coherent operation.

     *  Intent Translation & Policy Derivation: Derives executable
        policies from high-level business intents through semantic parsing
        and internal logic models.

     *  Virtual-Physical Synchronization Control: Manages bidirectional
        data flow between the NDT and the physical network to ensure
        accurate representation.

  3.2.  Functional Model AI Agent

     The Functional Model Agent is responsible for advanced service
     modeling, configuration generation, and optimization.  It
     autonomously invokes required functional models per validation
     policies and refines them via historical data analysis.

     *  Service Model Optimization: Refines models through performance
        analysis and adaptive learning algorithms.

     *  Automated Configuration Synthesis: Generates vendor-specific
        configurations or intermediate policy representations based on the
        intent model.

     *  Hierarchical Simulation Sandbox: Provides a multi-stage
        environment to verify configurations across compliance, logic, and
        business impact layers.

     TBD.

  3.3.  Basic Model AI Agent

     The Basic Model Agent maintains fundamental network element and
     topology representations.  It is capable of updating digital models
     in real-time based on physical network changes to ensure the accuracy
     of validation.

  3.4.  Data Repository AI Agent

     The Data Repository AI Agent serves as the intelligent data
     governance and provisioning component.  It autonomously manages the
     data lifecycle with the following capabilities:




  Zhao, et al.            Expires 3 September 2026                [Page 4]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


     *  Real-time Data Collection: Implements multi-protocol ingestion for
        streaming telemetry while autonomously detecting data anomalies.

     *  Historical Data Intelligence: Curates structured data and
        knowledge graphs to support pattern mining, and model training.

     *  Adaptive Data Services: Provides context-aware data retrieval with
        intelligent caching and conflict resolution.

     *  Knowledge Base Integration: Stores network configurations, vendor
        documents, and best practices to support incremental model
        updates.

     *  Validation Reporting: Generates standardized, machine-readable
        validation reports including rule IDs, configuration items, and
        evidence.

  4.  Agent Interactions

     The architecture employs bidirectional Agent-to-Agent (A2A)
     communication: the Functional and Basic Model Agents interact with
     the Data Repository Agent for data synchronization, while the
     Management Agent centrally orchestrates these interactions to
     maintain a coherent workflow.

     Inter-agent interactions SHOULD support state rollback mechanisms to
     ensure the virtual state remains synchronized with the physical
     network during failed intent decompositions.

  5.  Intelligent Use Case Realization

  5.1.  Automated IP Network Configuration Generation

     This use case demonstrates how the AI Agent architecture automates
     the end-to-end lifecycle of network configuration.

  5.1.1.  Intent Understanding and Policy Generation

     *  Intent Parsing: The Management Agent receives declarative intents,
        identifying network objects and resolving logic conflicts between
        multiple intents.

     *  Config Generation: The Functional Model Agent produces vendor-
        specific configurations.  It maintains context awareness by
        retrieving current states from the Basic Model Agent.






  Zhao, et al.            Expires 3 September 2026                [Page 5]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


     *  Vendor-agnostic Abstraction: The system uses an intermediate
        policy representation to ensure functional consistency across
        heterogeneous hardware.

  5.1.2.  Multi-Level Simulation and Verification

     Before deployment, configurations MUST undergo a multi-stage
     verification process:

     *  Semantic Consistency Verification: Ensures that synthesized
        configurations result in deterministic network behavior, bridging
        the gap between probabilistic AI generation and deterministic
        network operations..

     *  Hierarchical Validation: The Functional Model Agent executes
        simulations in a sandbox layer-by-layer: 1.  Compliance: Detecting
        syntax errors and policy violations. 2.  Functional Correctness:
        Verifying reachability and protocol convergence via the Basic
        Model Agent. 3.  Service Impact: Evaluating potential performance
        degradation using traffic patterns from the Data Repository Agent.

  5.1.3.  Model Evolution and Feedback Loop

     *  Closed-loop Optimization: If verification fails, the Management
        Agent feeds error reports back to the generation models of the
        Functional Model Agent for iterative optimization.

     *  Incremental Learning: Experts can manually correct AI outputs,
        which are stored in the Data Repository Agent to fine-tune future
        generation and verification models.

  5.2.  Cutover Simulation (Scenario Construction)

     *  Process Reproduction: The architecture simulates the complete
        cutover lifecycle, including device startup/shutdown, routing
        adjustments, and configuration delivery.

     *  Risk Mitigation: By monitoring link status and business capacity
        in the NDT, the Network Digital Twin Management AI Agent and
        Functional Model Agent jointly identify plan loopholes and
        optimize emergency response sequences before physical execution.

  6.  Security Considerations

     AI-Generated Risks: Specific checks must be implemented to detect
     "hallucinated" commands or non-compliant security policies generated
     by large language models.




  Zhao, et al.            Expires 3 September 2026                [Page 6]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


  7.  IANA Considerations

     TBD.

  8.  Informative References

     [I-D.irtf-nmrg-network-digital-twin-arch]
                Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
                Q., Boucadair, M., and C. Jacquenet, "Network Digital
                Twin: Concepts and Reference Architecture", Work in
                Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
                twin-arch-12, 27 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
                network-digital-twin-arch-12>.

     [I-D.zhao-nmop-network-management-agent]
                XingZhao, Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and
                J. Zhou, "AI based Network Management Agent(NMA): Concepts
                and Architecture", Work in Progress, Internet-Draft,
                draft-zhao-nmop-network-management-agent-04, 26 February
                2026, <https://datatracker.ietf.org/doc/html/draft-zhao-
                nmop-network-management-agent-04>.

  Authors' Addresses

     Jing Zhao (editor)
     China Unicom
     Beijing
     China
     Email: zhaoj501@chinaunicom.cn


     Ran Pang (editor)
     China Unicom
     Beijing
     China
     Email: pangran@chinaunicom.cn


     Shuai Zhang (editor)
     China Unicom
     Beijing
     China
     Email: zhangs366@chinaunicom.cn







  Zhao, et al.            Expires 3 September 2026                [Page 7]


  Internet-Draft        AI Agent Architecture for NDT           March 2026


     Hongwei Shi (editor)
     Purple Mountain Laboratories
     Nanjing
     China
     Email: shihongwei@pmlabs.com.cn


     Chen Su (editor)
     Purple Mountain Laboratories
     Nanjing
     China
     Email: suchen@pmlabs.com.cn







































  Zhao, et al.            Expires 3 September 2026                [Page 8]


name: draft-liu-agent-protocol-over-moq
rev: 00
title: Agent Protocol over MoQ
time: 2026-03-03T00:03:45Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-04T00:03:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:04.681074+00:00
source: ietf
abstract:
  This document specifies a Agent-to-Agent communication framework
     enabling structured, low-latency, and semantically rich communication
     between autonomous agents over the Media over QUIC (MoQ) protocol.
     It leverages MoQ's efficient media transport capabilities while
     introducing a new application-layer framing mechanism to support
     control signaling, session management, and large data fragmentation.
     The design supports both intra-domain and inter-domain deployment,
     with an emphasis on interoperability, extensibility, and minimal
     overhead.

full_text:
  Network Working Group                                             D. Liu
  Internet-Draft                                             Alibaba Cloud
  Intended status: Standards Track                             S. Krishnan
  Expires: 3 September 2026                                          Cisco
                                                                March 2026


                          Agent Protocol over MoQ
                    draft-liu-agent-protocol-over-moq-00

  Abstract

     This document specifies a Agent-to-Agent communication framework
     enabling structured, low-latency, and semantically rich communication
     between autonomous agents over the Media over QUIC (MoQ) protocol.
     It leverages MoQ's efficient media transport capabilities while
     introducing a new application-layer framing mechanism to support
     control signaling, session management, and large data fragmentation.
     The design supports both intra-domain and inter-domain deployment,
     with an emphasis on interoperability, extensibility, and minimal
     overhead.

  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 September 2026.

  Copyright Notice

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

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



  Liu & Krishnan          Expires 3 September 2026                [Page 1]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Requirements and Terminology  . . . . . . . . . . . . . . . .   3
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     4.  Agent to Agent Communication Frame Structure  . . . . . . . .   6
       4.1.  Frame Header Format . . . . . . . . . . . . . . . . . . .   6
       4.2.  Frame Payload . . . . . . . . . . . . . . . . . . . . . .   7
       4.3.  Message Encoding Formats  . . . . . . . . . . . . . . . .   7
         4.3.1.  JSON Encoding . . . . . . . . . . . . . . . . . . . .   7
         4.3.2.  Binary Encoding for STREAM and DATA . . . . . . . . .   8
       4.4.  Message Type Details  . . . . . . . . . . . . . . . . . .   8
         4.4.1.  CMD Message Format  . . . . . . . . . . . . . . . . .   8
         4.4.2.  Subscription Management Fields  . . . . . . . . . . .   9
         4.4.3.  DATA Message Format . . . . . . . . . . . . . . . . .  10
         4.4.4.  STREAM Message Format . . . . . . . . . . . . . . . .  10
         4.4.5.  HEARTBEAT Message Format  . . . . . . . . . . . . . .  11
       4.5.  MoQ Mapping and Transport Considerations  . . . . . . . .  11
       4.6.  Pub/Sub Mechanism Integration . . . . . . . . . . . . . .  12
     5.  Session and Communication Model . . . . . . . . . . . . . . .  12
       5.1.  In-Session Communication (Recommended)  . . . . . . . . .  12
       5.2.  Session-Less Communication  . . . . . . . . . . . . . . .  13
     6.  Fragmentation and Large Data Handling . . . . . . . . . . . .  13
       6.1.  Small Signals (< 1400 bytes)  . . . . . . . . . . . . . .  13
       6.2.  Large Data (> 1400 bytes) . . . . . . . . . . . . . . . .  13
       6.3.  Streaming Media . . . . . . . . . . . . . . . . . . . . .  14
     7.  Transport and Domain Considerations . . . . . . . . . . . . .  14
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
       9.1.  Agent Protocol over MoQ Magic Number Registry . . . . . .  15
       9.2.  Agent Protocol over MoQ Version Registry  . . . . . . . .  15
       9.3.  Agent Protocol over MoQ Message Type Registry . . . . . .  15
       9.4.  Agent Protocol over MoQ Frame Flags Registry  . . . . . .  16
       9.5.  Well-Known URI Registration . . . . . . . . . . . . . . .  17
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  17
     11. Informative References  . . . . . . . . . . . . . . . . . . .  17
     Appendix A.  Appendix A: Usage Examples . . . . . . . . . . . . .  18
       A.1.  A.1 Scenario Overview . . . . . . . . . . . . . . . . . .  18
       A.2.  A.2 Stateless Communication (Session-Less)  . . . . . . .  18
         A.2.1.  A.2.1 Heartbeat Interaction . . . . . . . . . . . . .  18
       A.3.  A.3 Stateful Communication with Streaming Media . . . . .  18
         A.3.1.  A.3.1 Real-time Video Stream for Design Feedback  . .  19
         A.3.2.  A.3.2 Subscription Management Example . . . . . . . .  19



  Liu & Krishnan          Expires 3 September 2026                [Page 2]


  Internet-Draft           Agent Protocol over MoQ              March 2026


       A.4.  A.4 Stateful Communication with Large Data Blocks . . . .  20
         A.4.1.  A.4.1 Sending High-Res Design Assets  . . . . . . . .  20
       A.5.  A.5 Deployment Scenarios  . . . . . . . . . . . . . . . .  21
         A.5.1.  A.5.1 Intra-Domain (Same Edge Cluster)  . . . . . . .  21
         A.5.2.  A.5.2 Inter-Domain (Cross-Cloud Invocation) . . . . .  21
       A.6.  A.6 Summary Table of Interaction Types  . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     The multimodal capabilities of AI Agents, has created a need for a
     real-time communication framework that supports both media streaming
     and structured control signaling.  Existing protocols such as HTTP/2,
     gRPC, either suffer from head-of-line blocking or lack native support
     for real-time media and bidirectional streaming.

     Media over QUIC (MoQ) offers a compelling transport foundation with
     its low-latency, multiplexed, and connection-robust design.  However,
     MoQ is originally optimized for media delivery and lacks native
     semantics for agent-to-agent control, session establishment, and
     structured data exchange.

     This document proposes an application-layer protocol framework that
     operates over MoQ.  It introduces:

     *  A binary framing structure to carry both control and media
        payloads.

     *  A session management mechanism for multi-turn agent dialogues.

     *  Strategies for fragmenting large control signals with partial
        reliability.

     *  Support for both MoQ domain-local and internet-wide communication.

     The proposed framework is designed to be minimal, modular, and
     compatible with existing MoQ implementations.  It does not modify
     MoQ's transport semantics but instead defines a new application-layer
     envelope that can be carried within MoQ Objects or Datagrams.

  2.  Requirements and 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].

     MoQ:  Media over QUIC, a protocol for real-time media delivery.




  Liu & Krishnan          Expires 3 September 2026                [Page 3]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     Agent:  An autonomous entity capable of sending and receiving
        structured commands and media.

     Session:  A logical dialogue between two agents, identified by a
        Session ID.

     Frame:  The basic unit of agent to agent communication, consisting of
        a header and payload.

  3.  Architecture Overview

     Agent Protocol over MoQ operates as an application-layer protocol on
     top of MoQ.  The protocol stack is illustrated below:






































  Liu & Krishnan          Expires 3 September 2026                [Page 4]


  Internet-Draft           Agent Protocol over MoQ              March 2026


        +-------------------------------------------------------------+
        |     Agent to Agent Communication - Application Logic        |
        |  (Agent Reasoning, Command Execution, Media Processing)     |
        +-------------------------------------------------------------+
                                      |
                                      v
        +-------------------------------------------------------------+
        |                                                             |
        |   Agent Protocol over MoQ Frame Layer (Header + Payload)    |
        |                                                             |
        |  +-------------------+  +-------------------------------+   |
        |  |   Frame Header    |  |       Frame Payload           |   |
        |  | - Magic Number    |  | - CMD (JSON)                  |   |
        |  | - Version         |  | - DATA (Binary chunks)        |   |
        |  | - Message Type    |  | - STREAM (Media samples)      |   |
        |  | - Session ID      |  | - HEARTBEAT (Empty)           |   |
        |  | - Stream ID       |  |                               |   |
        |  | - Flags           |  |                               |   |
        |  | - Payload Length  |  |                               |   |
        |  +-------------------+  +-------------------------------+   |
        +-------------------------------------------------------------+
                                      |
                                      v
        +-------------------------------------------------------------+
        |              Media Transport Layer (MoQ)                    |
        |                                                             |
        |   Track Management  |  Group/Object  |  Datagram Support    |
        |   Subscribe/Publish |  Prioritization|  Low-latency         |
        +-------------------------------------------------------------+
                                      |
                                      v
        +-------------------------------------------------------------+
        |                  Transport Layer (QUIC)                     |
        |                                                             |
        |   UDP-based  |  0-RTT Handshake  |  Stream Multiplexing     |
        |   TLS 1.3    |  Loss Recovery    |  Flow Control            |
        +-------------------------------------------------------------+

              Figure 1: Protocol Stack of Agent Protocol over MoQ

     The stack consists of four main layers:

     *  Transport Layer (QUIC): Provides UDP-based, low-latency transport
        with built-in encryption (TLS 1.3), 0-RTT connection
        establishment, stream multiplexing, and congestion control.






  Liu & Krishnan          Expires 3 September 2026                [Page 5]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     *  Media Transport Layer (MoQ): Handles track-based pub/sub, group
        and object organization, priority management, and datagram support
        for real-time media delivery.

     *  Application Framing Layer: Defines the Agent Protocol over MoQ
        binary frame structure with fixed header fields and variable
        payload, enabling efficient encapsulation of different message
        types.

     *  Application Logic: Implements agent-specific functionality
        including reasoning engines, command interpretation, media
        processing, and business logic.

     Agents establish a MoQ session (via WebTransport or native QUIC
     client) and use one or more Tracks for communication.  Each agent-to-
     agent message is encapsulated in a binary frame before being sent as
     a MoQ Object or Datagram.  The framing layer provides session
     management, fragmentation support, and extensibility through version
     and flag fields.

  4.  Agent to Agent Communication Frame Structure

     The Agent to Agent Communication frame is a binary structure designed
     for efficiency and extensibility.  It consists of a fixed-length
     header and a variable-length payload.

  4.1.  Frame Header Format

     +=========+=========+============================+==================+
     | Field   |  Length | Description                | MoQ Mapping      |
     |         | (bytes) |                            |                  |
     +=========+=========+============================+==================+
     | Magic   |    2    | Identifier: 0xA2A2         | Detects agent-   |
     | Number  |         |                            | to-agent         |
     |         |         |                            | traffic          |
     +---------+---------+----------------------------+------------------+
     | Version |    1    | Protocol version (e.g.,    | Forward          |
     |         |         | 0x01)                      | compatibility    |
     +---------+---------+----------------------------+------------------+
     | Msg     |    1    | Message type: CMD(0x01),   | Route to         |
     | Type    |         | DATA(0x02), STREAM(0x03),  | handler          |
     |         |         | HEARTBEAT(0x04)            |                  |
     +---------+---------+----------------------------+------------------+
     | Session |    8    | Unique session identifier  | Correlate        |
     | ID      |         | (UUIDv7 or hash)           | multi-turn       |
     |         |         |                            | dialogues        |
     +---------+---------+----------------------------+------------------+
     | Stream  |    4    | Identifier for fragmented  | Reassemble       |



  Liu & Krishnan          Expires 3 September 2026                [Page 6]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     | ID      |         | streams                    | large data       |
     +---------+---------+----------------------------+------------------+
     | Flags   |    1    | Bitmask: compressed(0x01), | Processing       |
     |         |         | encrypted(0x02),           | hints            |
     |         |         | fragmented(0x04)           |                  |
     +---------+---------+----------------------------+------------------+
     | Payload |    4    | Length of the following    | Parse boundary   |
     | Len     |         | payload                    |                  |
     +---------+---------+----------------------------+------------------+

                                    Table 1

  4.2.  Frame Payload

     The payload is interpreted based on the Msg Type and Flags:

     *  CMD: JSON or MessagePack-encoded command structure.

     *  DATA: Raw binary chunk of a large file or buffer.

     *  STREAM: Raw media sample or simplified RTP-like header + frame.

     *  HEARTBEAT: Empty payload; used for liveness detection.

  4.3.  Message Encoding Formats

     Agent Protocol over MoQ uses JSON (JavaScript Object Notation) as the
     standard encoding format for structured message content:

  4.3.1.  JSON Encoding

     JSON (JavaScript Object Notation) is used for all CMD and control
     messages:

     *  *Human-readable* and widely supported across programming languages

     *  *Self-describing* with key-value pairs

     *  *Schema-flexible* allowing dynamic field addition

     *  *Standard library support* in most modern languages

     Example CMD message in JSON:








  Liu & Krishnan          Expires 3 September 2026                [Page 7]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     {
       "action": "session_init",
       "session_id": "abc-123-def-456",
       "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
       "capabilities": {
         "media_types": ["video/h264", "audio/opus"],
         "max_fragment_size": 1400
       }
     }

                                    Figure 2

  4.3.2.  Binary Encoding for STREAM and DATA

     Media streams and large data payloads use raw binary encoding:

     *  *STREAM messages*: Raw media samples (H.264, Opus, etc.) without
        additional encoding overhead

     *  *DATA messages*: Raw binary chunks for file transfers and large
        payloads

     *  *Maximum efficiency* for bandwidth-constrained scenarios

  4.4.  Message Type Details

     Each message type has specific field requirements and processing
     rules:

  4.4.1.  CMD Message Format

     CMD messages carry structured commands encoded in JSON.  In addition
     to session management commands, CMD messages include specific actions
     for subscription management in pub/sub scenarios.

















  Liu & Krishnan          Expires 3 September 2026                [Page 8]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     +==========+=======+=============+===========+===========================+
     |Field     |Type   |Required     |Description|Example                    |
     +==========+=======+=============+===========+===========================+
     |action    |String |Yes          |Command    |"session_init",            |
     |          |       |             |identifier |"session_ack",             |
     |          |       |             |           |"subscribe_request",       |
     |          |       |             |           |"unsubscribe_request",     |
     |          |       |             |           |"track_ready"              |
     +----------+-------+-------------+-----------+---------------------------+
     |session_id|String/|Yes (for     |Session    |"abc-123-def-456"          |
     |          |UUID   |session cmds)|identifier |                           |
     +----------+-------+-------------+-----------+---------------------------+
     |auth_token|String |Yes (for     |JWT with   |"eyJhbGciOiJIUzI1NiIsIn..."|
     |          |       |session_init)|operation  |                           |
     |          |       |             |claim      |                           |
     +----------+-------+-------------+-----------+---------------------------+
     |status    |String |No           |Response   |"approved", "denied",      |
     |          |       |             |status     |"error"                    |
     +----------+-------+-------------+-----------+---------------------------+
     |error_code|Integer|No           |Error      |401, 403, 500              |
     |          |       |             |identifier |                           |
     +----------+-------+-------------+-----------+---------------------------+
     |payload   |Any    |No           |Command-   |{"key": "value"}           |
     |          |       |             |specific   |                           |
     |          |       |             |data       |                           |
     +----------+-------+-------------+-----------+---------------------------+

                                    Table 2

  4.4.2.  Subscription Management Fields

     For subscription-related actions such as "subscribe_request" and
     "unsubscribe_request", CMD messages include additional fields:


















  Liu & Krishnan          Expires 3 September 2026                [Page 9]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     +==============+======+==========+============+=========================+
     |Field         |Type  |Required  |Description |Example                  |
     +==============+======+==========+============+=========================+
     |track_name    |String|Yes (for  |Name of the |"agent2.session456.video"|
     |              |      |subscribe)|track to    |                         |
     |              |      |          |subscribe to|                         |
     +--------------+------+----------+------------+-------------------------+
     |quality_params|Object|No        |Quality     |{"resolution": "1080p",  |
     |              |      |          |parameters  |"fps": 30}               |
     |              |      |          |for the     |                         |
     |              |      |          |subscription|                         |
     +--------------+------+----------+------------+-------------------------+
     |subscriber_id |String|Yes (for  |ID of the   |"agent1"                 |
     |              |      |subscribe)|subscribing |                         |
     |              |      |          |agent       |                         |
     +--------------+------+----------+------------+-------------------------+

                                    Table 3

  4.4.3.  DATA Message Format

     DATA messages carry raw binary chunks for large file transfers.

     +==============+=========+===========+==============+===============+
     | Field        | Type    | Required  | Description  | Constraints   |
     +==============+=========+===========+==============+===============+
     | chunk_index  | Integer | Yes       | Position in  | 0-based,      |
     |              |         |           | sequence     | sequential    |
     +--------------+---------+-----------+--------------+---------------+
     | total_chunks | Integer | Yes (last | Total number | Must match    |
     |              |         | chunk)    | of chunks    | in all        |
     |              |         |           |              | chunks        |
     +--------------+---------+-----------+--------------+---------------+
     | checksum     | String  | No        | Data         | SHA-256 hex   |
     |              |         |           | integrity    | encoded       |
     |              |         |           | hash         |               |
     +--------------+---------+-----------+--------------+---------------+
     | metadata     | Object  | No        | File/type    | {"filename":  |
     |              |         |           | information  | "file.txt"}   |
     +--------------+---------+-----------+--------------+---------------+

                                    Table 4

  4.4.4.  STREAM Message Format

     STREAM messages carry media samples with optional timing information.





  Liu & Krishnan          Expires 3 September 2026               [Page 10]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     +=================+=======+==========+=============+===============+
     | Field           |Type   | Required | Description | Example       |
     +=================+=======+==========+=============+===============+
     | timestamp       |Integer| Yes      | Sample      | 1678901234567 |
     |                 |       |          | timestamp   |               |
     |                 |       |          | (ms)        |               |
     +-----------------+-------+----------+-------------+---------------+
     | media_type      |String | Yes      | Media       | "video/h264", |
     |                 |       |          | content     | "audio/opus"  |
     |                 |       |          | type        |               |
     +-----------------+-------+----------+-------------+---------------+
     | sequence_number |Integer| Yes      | Frame       | 12345         |
     |                 |       |          | sequence    |               |
     +-----------------+-------+----------+-------------+---------------+
     | key_frame       |Boolean| No       | Is key      | true          |
     |                 |       |          | frame       |               |
     +-----------------+-------+----------+-------------+---------------+
     | bitrate         |Integer| No       | Current     | 1000000       |
     |                 |       |          | bitrate     |               |
     |                 |       |          | (bps)       |               |
     +-----------------+-------+----------+-------------+---------------+

                                   Table 5

  4.4.5.  HEARTBEAT Message Format

     HEARTBEAT messages have empty payload and are used for liveness
     detection.

     +================+==========+======================================+
     | Field          | Value    | Description                          |
     +================+==========+======================================+
     | Payload Length | 0        | No payload data                      |
     +----------------+----------+--------------------------------------+
     | Processing     | Ack only | Recipient should acknowledge receipt |
     +----------------+----------+--------------------------------------+

                                   Table 6

  4.5.  MoQ Mapping and Transport Considerations

     Agent Protocol over MoQ frames are mapped to MoQ Objects and
     Datagrams based on their reliability and latency requirements:

     *  *CMD frames*: Mapped to MoQ Objects to ensure reliable delivery of
        control messages.  These require acknowledgment and retransmission
        if lost.




  Liu & Krishnan          Expires 3 September 2026               [Page 11]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     *  *STREAM frames*: Mapped to MoQ Objects by default for ordered
        delivery.  May use MoQ Datagrams for loss-tolerant real-time
        streams where occasional packet loss is acceptable.

     *  *DATA frames*: Large data chunks are mapped to MoQ Objects for
        reliable transfer.  Small data may use MoQ Datagrams for lower
        latency.

     *  *HEARTBEAT frames*: Mapped to MoQ Datagrams for efficient keep-
        alive functionality without requiring acknowledgments.

     This mapping ensures that the transport characteristics of MoQ align
     with the application requirements of agent-to-agent communication.

  4.6.  Pub/Sub Mechanism Integration

     The MoQ pub/sub mechanism is integrated with Agent Protocol over MoQ
     through specific CMD message types that manage subscriptions at the
     application layer:

     *  *Subscription Requests*: Agents send CMD messages with action
        "subscribe_request" to initiate track subscriptions.

     *  *Subscription Management*: The "subscribe_request" includes track
        name, quality parameters, and authorization tokens.

     *  *Track Naming Convention*: Track names follow the format
        "{agent_id}.{session_id}.{stream_type}", e.g., "agent1.abc-
        123-video".

     *  *Authorization*: Subscription requests are validated against the
        agent's authorization token before establishing the underlying MoQ
        subscription.

     This approach provides application-layer control over the underlying
     MoQ pub/sub mechanism, allowing fine-grained access control and
     session management.

  5.  Session and Communication Model

     Agent Protocol over MoQ supports two communication modes:

  5.1.  In-Session Communication (Recommended)

     Agents establish a session using a handshake that includes
     authorization verification.  Once a session is established, agents
     can use subscription management commands to establish pub/sub
     relationships:



  Liu & Krishnan          Expires 3 September 2026               [Page 12]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     *  Agent A obtains an authorization JWT containing an operation claim
        as defined in [I-D.liu-agent-operation-authorization].

     *  Agent A sends a CMD frame with {action: "session_init",
        session_id: 0x123..., auth_token: "<JWT>"}.

     *  Agent B validates the JWT and verifies the operation permissions
        before responding.

     *  Agent B responds with CMD {action: "session_ack", session_id:
        0x123..., status: "approved|denied"}.

     *  Subsequent messages use the same Session ID in the frame header.

     The session terminates with a *session_bye* command or MoQ session
     closure.

  5.2.  Session-Less Communication

     For stateless interactions (e.g., heartbeat, fire-and-forget
     command), agents may send frames without session setup.  The *Session
     ID* field is set to zero.  Authorization for such interactions is
     typically pre-established or implicit.

  6.  Fragmentation and Large Data Handling

     Agent Protocol over MoQ defines three strategies based on payload
     size:

  6.1.  Small Signals (< 1400 bytes)

     Sent as a single MoQ Datagram or Object.  No application-layer
     fragmentation.  Ideal for commands and heartbeats.

  6.2.  Large Data (> 1400 bytes)

     Application-layer fragmentation is required:

     *  Data is split into chunks (e.g., 1400 bytes).

     *  Each chunk is encapsulated in an agent protocol over MoQ frame
        with the same Stream ID.

     *  The last chunk sets the fragmented flag to 0 and includes final
        metadata.

     Reassembly is performed at the receiver using Stream ID and order of
     arrival.



  Liu & Krishnan          Expires 3 September 2026               [Page 13]


  Internet-Draft           Agent Protocol over MoQ              March 2026


  6.3.  Streaming Media

     Continuous media (audio/video) is sent as a sequence of agent
     protocol over MoQ *STREAM* frames.  Each frame carries one media
     sample.  Loss of a single frame does not block subsequent ones,
     leveraging MoQ's partial reliability.

  7.  Transport and Domain Considerations

     Agent Protocol over MoQ is designed to operate in two modes:

     *  Intra-MoQ-Domain: Agents communicate within the same MoQ
        infrastructure (e.g., same edge cluster).  Low latency, high
        trust.  MoQ-native discovery is RECOMMENDED.

     *  Inter-Domain (Internet-wide): Agents communicate across networks.
        STUN/TURN/ICE MAY be used if direct QUIC path fails.

     Agent Protocol over MoQ does not define its own discovery mechanism
     but RECOMMENDS integration with MoQ's track discovery or external
     service directories.

  8.  Security Considerations

     Agent Protocol over MoQ inherits security from the underlying
     transport:

     *  QUIC provides TLS 1.3 encryption and 0-RTT resumption.

     *  Application-layer authorization uses JWT with operation claim as
        defined in [I-D.liu-agent-operation-authorization].

     *  Session establishment requires validation of authorization tokens
        before communication begins.

     Implementations MUST validate authorization tokens before processing
     any agent-to-agent communication.  Session IDs MUST be
     cryptographically random to prevent session hijacking.

  9.  IANA Considerations

     This document requests IANA to create new registries and register
     initial values for the Agent Protocol over MoQ.








  Liu & Krishnan          Expires 3 September 2026               [Page 14]


  Internet-Draft           Agent Protocol over MoQ              March 2026


  9.1.  Agent Protocol over MoQ Magic Number Registry

     IANA is requested to create a new registry for Agent Protocol over
     MoQ Magic Numbers under the "Media over QUIC (MoQ)" group.  The
     registration procedure is Standards Action as defined in [RFC8126].

     Initial registration:

       +========+====================================+=================+
       | Value  | Description                        | Reference       |
       +========+====================================+=================+
       | 0xA2A2 | Agent-to-Agent Communication Frame | [This document] |
       +--------+------------------------------------+-----------------+

                                    Table 7

  9.2.  Agent Protocol over MoQ Version Registry

     IANA is requested to create a new registry for Agent Protocol over
     MoQ Versions.  The registration procedure is Standards Action.

     Initial registration:

        +=======+===================================+=================+
        | Value | Description                       | Reference       |
        +=======+===================================+=================+
        | 0x01  | Agent Protocol over MoQ Version 1 | [This document] |
        +-------+-----------------------------------+-----------------+

                                    Table 8

     Values 0x00 and 0xFF are reserved.  Values 0x02-0xFE are available
     for assignment.

  9.3.  Agent Protocol over MoQ Message Type Registry

     IANA is requested to create a new registry for Agent Protocol over
     MoQ Message Types.  The registration procedure is Specification
     Required as defined in [RFC8126].

     Initial registrations:










  Liu & Krishnan          Expires 3 September 2026               [Page 15]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     +=======+==============+=========================+=================+
     | Value | Message Type | Description             | Reference       |
     +=======+==============+=========================+=================+
     | 0x00  | Reserved     | Reserved for future use | [This document] |
     +-------+--------------+-------------------------+-----------------+
     | 0x01  | CMD          | Command message with    | [This document] |
     |       |              | structured payload      |                 |
     +-------+--------------+-------------------------+-----------------+
     | 0x02  | DATA         | Raw binary data chunk   | [This document] |
     +-------+--------------+-------------------------+-----------------+
     | 0x03  | STREAM       | Media stream sample     | [This document] |
     +-------+--------------+-------------------------+-----------------+
     | 0x04  | HEARTBEAT    | Liveness detection      | [This document] |
     |       |              | message                 |                 |
     +-------+--------------+-------------------------+-----------------+

                                   Table 9

     Values 0x05-0xFE are available for assignment.  Value 0xFF is
     reserved.

  9.4.  Agent Protocol over MoQ Frame Flags Registry

     IANA is requested to create a new registry for Agent Protocol over
     MoQ Frame Flags.  The registration procedure is Specification
     Required.  Each flag is represented by a bit position (0-7).

     Initial registrations:

     +=====+============+==============================+=================+
     | Bit | Flag Name  | Description                  | Reference       |
     +=====+============+==============================+=================+
     | 0   | Compressed | Payload is compressed (0x01) | [This           |
     |     |            |                              | document]       |
     +-----+------------+------------------------------+-----------------+
     | 1   | Encrypted  | Payload has application-     | [This           |
     |     |            | layer encryption (0x02)      | document]       |
     +-----+------------+------------------------------+-----------------+
     | 2   | Fragmented | Frame is part of a           | [This           |
     |     |            | fragmented stream (0x04)     | document]       |
     +-----+------------+------------------------------+-----------------+
     | 3-7 | Unassigned | Available for assignment     | [This           |
     |     |            |                              | document]       |
     +-----+------------+------------------------------+-----------------+

                                    Table 10





  Liu & Krishnan          Expires 3 September 2026               [Page 16]


  Internet-Draft           Agent Protocol over MoQ              March 2026


  9.5.  Well-Known URI Registration

     IANA is requested to register a new well-known URI in the "Well-Known
     URIs" registry as defined in [RFC8615].

     The "/.well-known/a2a" endpoint facilitates agent discovery in inter-
     domain deployments.  When accessed via HTTPS GET, the endpoint
     returns a JSON response containing the MoQ endpoint information for
     Agent Protocol over MoQ communication.

     URI suffix:  a2a

     Change controller:  IETF

     Specification document:  This document

     Related information:  Used for WebTransport-based Agent Protocol over
        MoQ endpoint discovery.  The endpoint returns a JSON object with
        the MoQ endpoint information, e.g., { "moq_endpoint":
        "quic://api.example.com:443" }

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

     [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
                and Secure Transport", RFC 9000, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

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

  11.  Informative References

     [MOQ]      Nisancioglu, M. D., Enghardt, T., and C. Perkins, "Media
                over QUIC (MoQ) - Internet Draft", I-D ietf-moq-00, 2024.

     [WEBTRANS] Jansson, P. and J. Uberti, "WebTransport over HTTP/3",
                RFC 9220, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9220>.



  Liu & Krishnan          Expires 3 September 2026               [Page 17]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     [I-D.liu-agent-operation-authorization]
                Liu, D., Zhu, H., and S. Krishnan, "Agent Operation
                Authorization Policy", I-D liu-agent-operation-
                authorization, January 2026.

  Appendix A.  Appendix A: Usage Examples

     This appendix provides detailed examples of Agent Protocol over MoQ
     interactions based on a multimodal collaborative design scenario.

  A.1.  A.1 Scenario Overview

     *Agents:*

     *  *Agent 1 (Personal Assistant):* Resides on a user's smartphone.

     *  *Agent 2 (Professional Designer):* Resides on a cloud server.

  A.2.  A.2 Stateless Communication (Session-Less)

     Used for lightweight, fire-and-forget interactions like liveness
     checks or simple status updates.

  A.2.1.  A.2.1 Heartbeat Interaction

     Agent 1 sends a heartbeat to Agent 2 to maintain the MoQ track
     activity.

     Header:
     - Magic Number: 0xA2A2
     - Version: 0x01
     - Msg Type: 0x04 (HEARTBEAT)
     - Session ID: 0 (Stateless)
     - Stream ID: 0
     - Flags: 0x00
     - Payload Len: 0
     Payload: (Empty)

                    Figure 3: Heartbeat Frame Implementation

  A.3.  A.3 Stateful Communication with Streaming Media

     Used for complex dialogues requiring continuous media processing,
     such as real-time video analysis.







  Liu & Krishnan          Expires 3 September 2026               [Page 18]


  Internet-Draft           Agent Protocol over MoQ              March 2026


  A.3.1.  A.3.1 Real-time Video Stream for Design Feedback

     *Step 1: Session Handshake with Authorization*

     Agent 1 (Smartphone)                    Agent 2 (Cloud)
             |                                      |
             |  CMD {action:"session_init",         |
             |       session_id:"abc-123",          |
             |       auth_token:"<JWT>"}            |
             |------------------------------------->|
             |                                      |
             |  CMD {action:"session_ack",          |
             |       session_id:"abc-123",          |
             |       status:"approved"}             |
             |<-------------------------------------|

                    Figure 4: Session Establishment Sequence

     *Step 2: Media Streaming*

     Agent 1 captures video and sends it as STREAM frames within the
     established session.

     Header:
     - Magic Number: 0xA2A2
     - Version: 0x01
     - Msg Type: 0x03 (STREAM)
     - Session ID: abc-123
     - Flags: 0x00
     - Payload Len: 1200
     Payload: [Raw H.264/HEVC NAL Unit]

                  Figure 5: Video Sample Frame Implementation

  A.3.2.  A.3.2 Subscription Management Example

     *Step 1: Subscription Request*

     Agent 1 wants to subscribe to Agent 2's video feed.  It sends a
     subscription request within the established session.











  Liu & Krishnan          Expires 3 September 2026               [Page 19]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     Agent 1 (Subscriber)                    Agent 2 (Publisher)
             |                                                 |
             |  CMD {action:"subscribe_request",               |
             |       session_id:"abc-123",                     |
             |       track_name:"agent2.video.h264",           |
             |       subscriber_id:"agent1"}                   |
             |------------------------------------------------>|
             |                                                 |
             |  CMD {action:"track_ready",                     |
             |       session_id:"abc-123",                     |
             |       status:"approved",                        |
             |       track_url:"moq://track/agent2.video.h264"}|
             |<------------------------------------------------|

                    Figure 6: Subscription Request Sequence

     *Step 2: Media Streaming via MoQ pub/sub*

     After successful subscription negotiation via CMD messages, the
     actual media stream flows through the underlying MoQ pub/sub
     mechanism.

  A.4.  A.4 Stateful Communication with Large Data Blocks

     Used for transferring high-resolution assets or large model weights.

  A.4.1.  A.4.1 Sending High-Res Design Assets

     Agent 2 sends a 5MB design file back to Agent 1.

     *Fragmentation Strategy:* The file is split into chunks of 1400
     bytes.

     Header:
     - Msg Type: 0x02 (DATA)
     - Session ID: abc-123
     - Stream ID: 101 (File Transfer Stream)
     - Flags: 0x04 (Fragmented = 1)
     - Payload Len: 1400
     Payload: [First 1400 bytes of the file]

                          Figure 7: First Chunk Frame









  Liu & Krishnan          Expires 3 September 2026               [Page 20]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     Header:
     - Msg Type: 0x02 (DATA)
     - Session ID: abc-123
     - Stream ID: 101
     - Flags: 0x00 (Fragmented = 0)
     - Payload Len: 800
     Payload: [Final 800 bytes of the file]

                           Figure 8: Last Chunk Frame

  A.5.  A.5 Deployment Scenarios

  A.5.1.  A.5.1 Intra-Domain (Same Edge Cluster)

     Agents are deployed in the same regional data center (e.g., Alibaba
     Cloud Hangzhou Region).

     *  *Discovery:* Uses MoQ-native track discovery.

     *  *Latency:* Extremely low (< 5ms).

     *  *Trust:* High; encryption is present but overhead is minimal due
        to short physical distance.

  A.5.2.  A.5.2 Inter-Domain (Cross-Cloud Invocation)

     Agent 1 (on Smartphone) calls Agent 2 (on Cloud).

     Agent 1 (Smartphone)  .well-known/a2a    Agent 2 (Cloud)
             |                    |                          |
             | GET https://cloud.example.com/.well-known/a2a |
             |---------------------------------------------->|
             |                    |                          |
             | { "moq_endpoint": "quic://api.cloud.example.com:443" } |
             |<----------------------------------------------|
             |                    |                          |
             | QUIC/MoQ Handshake (0-RTT)                    |
             |---------------------------------------------->|
             |                    |                          |
             | Agent Protocol over MoQ Frame                 |
             | (Session Init with Auth)                      |
             |---------------------------------------------->|

                     Figure 9: Inter-Domain Connection Flow

     *  *Discovery:* Uses HTTPS Well-Known URI as a bootstrap.

     *  *Traversal:* Relies on QUIC's robustness against NAT changes.



  Liu & Krishnan          Expires 3 September 2026               [Page 21]


  Internet-Draft           Agent Protocol over MoQ              March 2026


     *  *Security:* Inherits TLS 1.3 from QUIC; ensures end-to-end privacy
        across public networks.

  A.6.  A.6 Summary Table of Interaction Types

      +================+=======+=========+============+=================+
      | Type           |Session|Msg Type |Typical     | MoQ Mapping     |
      |                |ID     |         |Usage       |                 |
      +================+=======+=========+============+=================+
      | *Session-Less* |0      |HEARTBEAT|Keep-alive, | MoQ Datagram    |
      |                |       |/ CMD    |Simple      | (HEARTBEAT),    |
      |                |       |         |Queries     | MoQ Object      |
      |                |       |         |            | (CMD)           |
      +----------------+-------+---------+------------+-----------------+
      | *Streaming*    |UUID   |STREAM   |Audio/Video/| MoQ Object      |
      |                |       |         |Sensor      | (Ordered        |
      |                |       |         |Stream      | Delivery), MoQ  |
      |                |       |         |            | Datagram (Loss- |
      |                |       |         |            | Tolerant)       |
      +----------------+-------+---------+------------+-----------------+
      | *Bulk Data*    |UUID   |DATA     |Large Files,| MoQ Object      |
      |                |       |         |Images      | (Reliable), MoQ |
      |                |       |         |            | Datagram (Small |
      |                |       |         |            | Data)           |
      +----------------+-------+---------+------------+-----------------+
      | *Control*      |UUID   |CMD      |Logic       | MoQ Object      |
      |                |       |         |Execution,  | (Reliable)      |
      |                |       |         |ACKs,       |                 |
      |                |       |         |Subscription|                 |
      |                |       |         |Management  |                 |
      +----------------+-------+---------+------------+-----------------+

                                    Table 11

  Authors' Addresses

     Dapeng Liu
     Alibaba Cloud
     Email: max.ldp@alibaba-inc.com


     Suresh Krishnan
     Cisco
     Email: suresh.krishnan@gmail.com







  Liu & Krishnan          Expires 3 September 2026               [Page 22]


name: draft-wang-lisp-ai-agent
rev: 00
title: Using LISP as a Network Substrate for AI Agent Communication
time: 2026-02-28T02:24:39Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T02:24:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops"]
tags: []
fetched_at: 2026-03-04T00:00:04.947586+00:00
source: ietf
abstract:
  The emergence of distributed artificial intelligence (AI) systems,
     particularly those composed of autonomous agents operating across
     cloud, edge, and endpoint environments, introduces new networking
     requirements.  These include location transparency, seamless
     mobility, multi-homing, and logical isolation at scale.  This
     document explores how the Locator/ID Separation Protocol (LISP) can
     serve as a robust network substrate to meet these requirements.  The
     document outlines use cases, design considerations, and minimal
     extensions to the existing LISP framework to support context-aware
     mapping and AI agent-centric communication.

full_text:
  LISP Working Group                                               W. Wang
  Internet-Draft                                                    C. Xie
  Intended status: Informational                             China Telecom
  Expires: 1 September 2026                               28 February 2026


        Using LISP as a Network Substrate for AI Agent Communication
                        draft-wang-lisp-ai-agent-00

  Abstract

     The emergence of distributed artificial intelligence (AI) systems,
     particularly those composed of autonomous agents operating across
     cloud, edge, and endpoint environments, introduces new networking
     requirements.  These include location transparency, seamless
     mobility, multi-homing, and logical isolation at scale.  This
     document explores how the Locator/ID Separation Protocol (LISP) can
     serve as a robust network substrate to meet these requirements.  The
     document outlines use cases, design considerations, and minimal
     extensions to the existing LISP framework to support context-aware
     mapping and AI agent-centric communication.

  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 September 2026.

  Copyright Notice

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

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



  Wang & Xie              Expires 1 September 2026                [Page 1]


  Internet-Draft                lisp-ai-agent                February 2026


     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Requirements from AI agent communication  . . . . . . . . . .   4
       3.1.  Persistent identity across mobility . . . . . . . . . . .   4
       3.2.  Logical isolation of Agent Groups . . . . . . . . . . . .   4
       3.3.  Context-aware routing . . . . . . . . . . . . . . . . . .   4
     4.  LISP as a Network Substrate . . . . . . . . . . . . . . . . .   4
       4.1.  AI agent identity as EID  . . . . . . . . . . . . . . . .   4
       4.2.  Attachment points as RLOCs  . . . . . . . . . . . . . . .   4
       4.3.  Instance ID for Agent Groups  . . . . . . . . . . . . . .   5
     5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
       5.1.  The architecture of LISP for AI agent communication.  . .   5
       5.2.  Data Flow Example . . . . . . . . . . . . . . . . . . . .   6
     6.  New requirements to LISP  . . . . . . . . . . . . . . . . . .   6
       6.1.  Context-Aware Mapping Database Extension  . . . . . . . .   6
       6.2.  Policy-Based RLOC Selection . . . . . . . . . . . . . . .   7
       6.3.  Enhanced Map-Request/Map-Reply Semantics  . . . . . . . .   7
       6.4.  Support for Agent Group Mobility  . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Modern AI systems are increasingly distributed, comprising autonomous
     software entities referred to as AI agents that collaborate across
     heterogeneous infrastructure, including public clouds, private data
     centers, edge nodes, and end-user devices.  These AI agents may
     migrate dynamically (e.g., due to resource constraints, latency
     optimization, or failure recovery), yet their communication sessions
     must remain uninterrupted.

     Traditional IP networking binds identity and location into a single
     address, making seamless mobility and multi-homing challenging
     without application-layer intervention (e.g., session re-
     establishment or DNS updates).  The Locator/ID Separation Protocol
     (LISP) [RFC9300], however, decouples identity from location, enabling
     transparent mobility and flexible traffic engineering.  This document
     proposes using LISP as a network substrate for AI agent



  Wang & Xie              Expires 1 September 2026                [Page 2]


  Internet-Draft                lisp-ai-agent                February 2026


     communication.  We show how LISP’s existing architecture naturally
     supports key requirements of AI agent communications, and we propose
     minimal, backward-compatible extensions to enable context-aware
     routing decisions driven by agent-level semantics.

     The goal is not to redefine LSP, but to illustrate how it can be
     leveraged and slightly enhanced to serve as a foundational layer for
     next-generation intelligent systems.

  1.1.  Requirements Language

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

  2.  Terminology

     The following terms are used in this draft:

     *  Endpoint Identifier (EID) [RFC9299]: Addresses assigned
        topologically to network attachment points.  Typically routed
        inter-domain.

     *  xTR [RFC9299]: A router that implements both ITR and ETR
        functionalities.

     *  Map-Server [RFC9301]: A network infrastructure component that
        learns of EID-Prefix mapping entries from an ETR, via the
        registration mechanism described below, or some other
        authoritative source if one exists.  A Map-Server publishes these
        EID-Prefixes in a mapping database.

     *  Map-Resolver [RFC9301]: A network infrastructure component that
        accepts LISP Encapsulated Map-Requests, typically from an ITR, and
        determines whether or not the destination IP address is part of
        the EID namespace; if it is not, a Negative Map-Reply is returned.
        Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
        mapping by consulting a mapping database system.

     *  Instance ID (IID) [RFC9299]: A 24-bit identifier used to create
        isolated LISP namespaces.

     *  AI agent: A software entity capable of perception, decision-
        making, and action, often operating autonomously or in
        coordination with other AI agents.




  Wang & Xie              Expires 1 September 2026                [Page 3]


  Internet-Draft                lisp-ai-agent                February 2026


     *  Agent Group: A logical group of AI agents sharing a common task,
        security policy, or administrative boundary.  Each domain MAY be
        mapped to a unique LISP Instance ID.


  3.  Requirements from AI agent communication

  3.1.  Persistent identity across mobility

     AI agents must maintain a consistent network identity when migrating
     across hosts or networks; if traditional IP addresses are used as
     identity identifiers, any change in address will disrupt existing
     communication sessions and require upper-layer applications to
     reestablish connections, thereby compromising communication
     continuity and the overall capability of AI systems.

  3.2.  Logical isolation of Agent Groups

     Even when multiple Agent Groups operate on the same physical or
     virtual network infrastructure, they must be isolated from one
     another to prevent interference and ensure that their respective
     security policies are strictly enforced.

  3.3.  Context-aware routing

     The network should dynamically select the most appropriate
     transmission path based on the communication intent of AI agents,
     such as their requirements for latency or security.

  4.  LISP as a Network Substrate


  4.1.  AI agent identity as EID

     Each AI agent is assigned a stable EID.  This EID serves as its
     permanent network identity, independent of where it executes.  The
     EID is only routed within the AI agent’s local site; global
     reachability is achieved via LISP encapsulation.

  4.2.  Attachment points as RLOCs

     When an AI agent runs on a host connected to the network, the local
     xTR registers the AI agent’s EID along with one or more RLOCs.
     Multiple RLOCs enable multi-homing, with each RLOC annotated with
     capabilities.






  Wang & Xie              Expires 1 September 2026                [Page 4]


  Internet-Draft                lisp-ai-agent                February 2026


  4.3.  Instance ID for Agent Groups

     LISP Instance IDs [RFC9299] allow multiple virtual networks over the
     same physical infrastructure.  Each agent group is assigned a unique
     IID.  Packets are encapsulated with the IID in the LISP header,
     ensuring isolation between different agent groups even if EIDs
     overlap.  IID enables scalable, secure multi-tenancy for
     heterogeneous workloads.

  5.  Architecture Overview

  5.1.  The architecture of LISP for AI agent communication.

     The LISP provides the network substrate that enables stable identity,
     mobility, multi-homing, and policy-aware routing for AI agents.  It
     consists of several logically distinct but tightly coordinated
     components, as illustrated in Figure 1.

        Please view in a fixed-width font such as Courier.

     +--------------------------------------------------+
     |                AI Agent Host                     |
     |  +----------------+    +---------------------+   |
     |  | AI Agent       |    | xTR                 |   |
     |  | (EID = e1)     |<-->| Encap / Decap       |   |
     |  +----------------+    +----------+----------+   |
     |                                   ^              |
     +-----------------------------------|--------------+
                                         |
               Map-Register (EID->RLOC)  |  Map-Request/Reply
                                         v
     +------------------+      +----------------------+
     |   Map-Server     |<---->|   Map-Resolver       |
     | (stores bindings)|      | (resolves queries)   |
     +------------------+      +----------+-----------+
                                          |
                                          | Recursive lookup
                                          v
                               +--------------------+
                               | Mapping Hierarchy  |
                               | (e.g., DDT tree)   |
                               +--------------------+

     Figure 1 The architecture of LISP for AI agent communication.







  Wang & Xie              Expires 1 September 2026                [Page 5]


  Internet-Draft                lisp-ai-agent                February 2026


  5.2.  Data Flow Example

     Consider Agent A (EID_A) sending a message to Agent B (EID_B):

     1.  Agent A sends a standard IP packet to EID_B.

     2.  The local xTR (acting as ITR) intercepts the packet.

     3.  ITR queries the mapping system via a Map-Resolver for EID_B.

     4.  The mapping system returns a Map-Reply containing one or more
         RLOCs for EID_B, possibly filtered by context.

     5.  ITR encapsulates the original packet in a LISP header (with
         optional IID) and forwards it to the selected RLOC_B.

     6.  The destination xTR (ETR) decapsulates and delivers the packet to
         Agent B.

     If Agent B migrates to a new host, it registers its EID with a new
     RLOC.  Subsequent Map-Requests return the updated mapping, and
     communication resumes transparently.

  6.  New requirements to LISP

     To effectively support the requirements of AI agent systems outlined
     in Section 3, the LISP architecture requires specific enhancements.
     These enhancements focus on extending the mapping database to carry
     richer context information and enabling the data plane to make
     routing decisions based on agent-specific semantics.

  6.1.  Context-Aware Mapping Database Extension

     The LISP Mapping System MUST be extended to support the storage and
     retrieval of Agent Context Attributes alongside the standard EID-to-
     RLOC mappings.  These attributes are used by Ingress Tunnel Routers
     (ITRs) to select the optimal RLOC based on the specific needs of the
     AI agent communication.

     The following attributes SHOULD be supported as optional fields in
     the Map-Reply message or the EID-to-RLOC record:

     *  Processing Latency (Latency_SLA): A metric indicating the
        computational latency of the host where the AI agent resides
        (e.g., "Low", "Medium", "High").  This allows routing decisions
        based on real-time performance requirements.





  Wang & Xie              Expires 1 September 2026                [Page 6]


  Internet-Draft                lisp-ai-agent                February 2026


     *  Hardware Capability Tags: Indicators of available hardware
        resources.  This enables affinity-based routing where an AI agent
        can specifically request a host with certain hardware.

     *  AI agent State: Information regarding the current operational
        state of the AI agent.  This prevents packets from being sent to
        AI agents that are in an invalid state.


  6.2.  Policy-Based RLOC Selection

     The ETR registration process MUST be augmented to allow AI agents or
     their hosting environments to dynamically advertise their context
     attributes to the Map-Server.  The registration mechanism SHOULD
     support:

     *  Dynamic Metadata Update: The ability for an ETR to update the
        context attributes (e.g., load, latency) of an EID registration
        without de-registering and re-registering the EID prefix, ensuring
        minimal disruption during state changes.

     *  Context-Aware Filtering: The Map-Server and Map-Resolver MUST
        support filtering mechanisms.  When an ITR sends a Map-Request, it
        MAY include desired context attributes (e.g., "I need a GPU").
        The mapping system SHOULD return only those RLOCs that match the
        requested attributes.

  6.3.  Enhanced Map-Request/Map-Reply Semantics

     To facilitate context-aware routing, the LISP control plane messages
     require the following modifications:

     *  Extended Map-Request: ITRs MUST be able to include "Context
        Constraints" in the Map-Request message.  These constraints
        specify the requirements of the source AI agent for the
        destination (e.g., minimum security level, required hardware).

     *  Prioritized RLOC List: The Map-Reply message MUST support
        returning a prioritized list of RLOCs based on the context match
        score, rather than just topology.  The priority field in the RLOC
        record SHOULD be interpreted as a combination of network topology
        and agent-specific suitability.

  6.4.  Support for Agent Group Mobility

     To support seamless mobility, the LISP architecture MUST ensure fast
     convergence during EID re-registration:




  Wang & Xie              Expires 1 September 2026                [Page 7]


  Internet-Draft                lisp-ai-agent                February 2026


     *  Incremental Updates: The mapping database system SHOULD support
        incremental updates to minimize latency when an AI agent migrates
        and updates its RLOC registration.

  7.  Security Considerations

     LISP inherits security considerations from [RFC9300].  Additional
     aspects for AI agent scenarios include:

     *  EID Spoofing: An attacker could impersonate an AI agent by using
        its EID.

     *  Mapping System Abuse: Malicious Map-Requests could overload the
        system.  Rate limiting and source validation are RECOMMENDED.

     Logical isolation via Instance IDs provides strong tenant separation,
     reducing cross-domain attack surface.

  8.  IANA Considerations

     None.

  9.  Normative References

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

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

     [RFC9299]  Cabellos, A. and D. Saucez, Ed., "An Architectural
                Introduction to the Locator/ID Separation Protocol
                (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
                <https://www.rfc-editor.org/info/rfc9299>.

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

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




  Wang & Xie              Expires 1 September 2026                [Page 8]


  Internet-Draft                lisp-ai-agent                February 2026


  Authors' Addresses

     Wei Wang
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: weiwang94@foxmail.com


     Chongfeng Xie
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: xiechf@chinatelecom.cn

































  Wang & Xie              Expires 1 September 2026                [Page 9]


name: draft-chen-oauth-scope-agent-extensions
rev: 00
title: Structured and Constraint Extensions for OAuth Scopes
time: 2026-03-01T13:50:56Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-02T13:50:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-03-04T00:00:04.960025+00:00
source: ietf
abstract:
  This specification defines an extension to the OAuth 2.0 scope
     parameter, as specified in RFC 6749, which is used to express the
     permissions granted to an access token.  The proposed extension
     introduces a structured syntax for scope values to enable fine-
     grained authorization for the installation and execution of Modular
     Capability Units (encapsulated and reusable functional modules such
     as skills) within Agent ecosystems.  However, current mechanisms for
     authorizing such modules generally lack a standardized way to express
     and obtain consent for the complex, fine-grained permissions they
     require during installation.

     This document addresses this limitation by defining a structured
     format for the scope parameter.  The format extends the simple space-
     delimited strings with a colon-separated syntax:
     [resource_type]:[action]:[target][:constraints].  This syntax allows
     for the precise description of permissions for operations such as
     file system access, command-line execution, network access, tool
     invocation, and scheduled tasks.  These extensions provide a
     standardized, machine-readable way to request, convey, and validate
     detailed permissions, thereby enhancing users' security control over
     their resources while maintaining compatibility with the existing
     OAuth token issuance and validation flows.

full_text:
  oauth                                                            J. Chen
  Internet-Draft                                                   M. Chen
  Intended status: Standards Track                                   L. Su
  Expires: 2 September 2026                                   China Mobile
                                                              1 March 2026


           Structured and Constraint Extensions for OAuth Scopes
                 draft-chen-oauth-scope-agent-extensions-00

  Abstract

     This specification defines an extension to the OAuth 2.0 scope
     parameter, as specified in RFC 6749, which is used to express the
     permissions granted to an access token.  The proposed extension
     introduces a structured syntax for scope values to enable fine-
     grained authorization for the installation and execution of Modular
     Capability Units (encapsulated and reusable functional modules such
     as skills) within Agent ecosystems.  However, current mechanisms for
     authorizing such modules generally lack a standardized way to express
     and obtain consent for the complex, fine-grained permissions they
     require during installation.

     This document addresses this limitation by defining a structured
     format for the scope parameter.  The format extends the simple space-
     delimited strings with a colon-separated syntax:
     [resource_type]:[action]:[target][:constraints].  This syntax allows
     for the precise description of permissions for operations such as
     file system access, command-line execution, network access, tool
     invocation, and scheduled tasks.  These extensions provide a
     standardized, machine-readable way to request, convey, and validate
     detailed permissions, thereby enhancing users' security control over
     their resources while maintaining compatibility with the existing
     OAuth token issuance and validation flows.

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







  Chen, et al.            Expires 2 September 2026                [Page 1]


  Internet-Draft            extensions for Scope                March 2026


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

     This Internet-Draft will expire on 2 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Need for scope Extensions in AI Agent Ecosystems  . .   3
       1.2.  Role Mapping for the Skill Installation and Authorization
             Context . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Authorization Flow Illustrating scope Negotiation . . . . . .   4
     3.  Structured scope Format Extension . . . . . . . . . . . . . .   6
       3.1.  Forward Compatibility Principle:  . . . . . . . . . . . .   9
       3.2.  Example scope parameter values  . . . . . . . . . . . . .   9
       3.3.  Security Considerations . . . . . . . . . . . . . . . . .  10
     4.  Error Response  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  OAuth Authorization Server Metadata . . . . . . . . . . .  10
       5.2.  OAuth Extensions Error Registry . . . . . . . . . . . . .  11
     6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
     7.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11











  Chen, et al.            Expires 2 September 2026                [Page 2]


  Internet-Draft            extensions for Scope                March 2026


  1.  Introduction

     The OAuth 2.0 scope parameter [RFC6749] serves as a widely adopted
     mechanism for expressing permissions, defining the access token's
     authority.  However, in emerging scenarios such as the installation
     and execution of third-party skills within Agent ecosystems which
     require the declaration of complex, fine-grained operational
     permissions its expressive power becomes limited.

  1.1.  The Need for scope Extensions in AI Agent Ecosystems

     In current Agent architectures, users typically extend their Agent's
     functionality by installing third-party developed Modular Capability
     Units.  These Modular Capability Units MAY be specifically called
     "Skills" etc.,

     but their essence is installable components that add specific
     capabilities to an Agent.  However, this installation process
     presents significant security and privacy risks:

     *  Lack of Source Authentication: Users cannot verify the identity of
        the capability module's publisher or the integrity of its code.

     *  Coarse-Grained or No Permission Control: During installation,
        capability modules either obtain all requested permissions (often
        presented as a broad, unstructured list) or rely entirely on user
        trust, lacking a standardized process for fine-grained,
        interactive authorization confirmation at installation time.

     *  Runtime Permission Abuse Risk: Once installed, capability modules
        MAY access local or remote resources with permissions exceeding
        user expectations.

        The OAuth 2.0 framework [RFC6749] provides a standardized
        mechanism for delegated authorization.  This proposal applies this
        framework to the Agent skill authorization model and, crucially,
        extends the OAuth scope parameter to support the expression of
        fine-grained permissions required by Modular Capability Units such
        as skills.  This allows the installation and execution of a skill
        to be modeled as a process where a client obtains user consent for
        a specific set of structured permissions (scope), which are then
        executed during resource access.









  Chen, et al.            Expires 2 September 2026                [Page 3]


  Internet-Draft            extensions for Scope                March 2026


  1.2.  Role Mapping for the Skill Installation and Authorization Context

     This proposal applies the OAuth framework to a specific interaction
     pattern within Agent ecosystems: the installation and subsequent
     execution of Modular Capability Units (such as skills).  To provide
     context for how the extended scopeparameter is used within this
     pattern, the entities involved are mapped to standard OAuth 2.0 roles
     as follows:

     Resource Owner (RO): The end-user, who grants permissions.

     Client: The personal Agent.  It initiates skill installation and
     execution requests on behalf of the user.

     Authorization Server (AS): A trusted entity responsible for verifying
     the skill's source/integrity, managing scope policies, authenticating
     the user, and issuing access tokens containing the granted scope.

     Resource Server (RS): (1) a Modular Capability Unit Management Server
     that hosts the unit repository and performs installation upon valid
     token presentation, and (2) a User Resource Server that controls
     access to the user's specific resources (e.g., file system, network,
     tools) during a unit's execution.

  1.3.  Terminology

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

     This document uses the terms "Authorization Server" (AS), "Client",
     "Resource Server" (RS), and "Access Token" as defined in The OAuth
     2.0 Authorization Framework [RFC6749].

  2.  Authorization Flow Illustrating scope Negotiation

     The following abstract flow illustrates how the extended scope
     parameter is negotiated and used within a modified OAuth
     Authorization Code flow:










  Chen, et al.            Expires 2 September 2026                [Page 4]


  Internet-Draft            extensions for Scope                March 2026


           +--------+                                +---------------+
           |        |--(A)-------------------------->|               |
           |        |                                |               |
           |        |<-(B)---------------------------|               |
           |        |                                |               |
           |        |                                |    Resource   |
           |        |        +--------------+        |      Owner    |
           | Client |        |Authorization |--(D)-->|               |
           |        |--(C)-->|    Server    |        |               |
           |        |<-(F)---|              |<-(E)---|               |
           |        |        +--------------+        |               |
           |        |                                |               |
           |        |                                +---------------+
           |        |                                +---------------+
           |        |--(G)-------------------------->|    Resource   |
           |        |                                |     Server    |
           |        |<-(H)---------------------------|               |
           +--------+                                +---------------+

     *Figure 1: Skill Installation and Authorization Flow*

     (A) Client Requests Installation from Resource Owner.

     (B) Resource Owner Initiates Authorization.

     (C) Client Initiates Authorization Request to AS.

     (D) AS Verifies Module and Negotiates Permissions: The Authorization
     Server performs the following sub-steps (omitting the AS's
     authentication of the Resource Owner):

     *  Fetches and verifies the capability module's metadata (including
        its requested initial permission list scope_initial) and its
        source and integrity (e.g., verifying publisher signature).

     *  Based on internal permission scope policies, maps or tailors
        scope_initial to a set of permissions scope_request (scope_request
        subset of scope_initial) that can be requested from the Resource
        Owner.












  Chen, et al.            Expires 2 September 2026                [Page 5]


  Internet-Draft            extensions for Scope                March 2026


     *  Generates authorization consent interface information, presenting
        scope_request clearly to the Resource Owner.  (E) Resource Owner
        Authorizes and Provides Consent: The Resource Owner reviews the
        authorization consent interface, can choose to accept, reject, or
        further adjust the authorization scope, forming the final
        consented permission set scope_granted (scope_granted subset of
        scope_request).  After the Resource Owner confirms authorization,
        this authorization result (i.e., the authorization grant) is
        returned to the Client via interface interaction.

     (F) AS Issues Authorization Code to Client.

     (G) Client Requests Access Token.

     (H) AS Issues Access Token.

     (H) AS Issues Access Token:The AS issues an access token whose scope
     parameter value is set to scope_granted.

     RS Validates Token and Scope:During skill execution, the RS validates
     the token and ensures the operation is within the token's
     scope_granted.

  3.  Structured scope Format Extension

     To meet the needs of Agent skills for describing complex, fine-
     grained operation permissions, this specification defines a
     structured extension to the OAuth scope parameter value syntax,
     building upon the ABNF defined in [RFC6749] :

     The value of the scope parameter is expressed as a list of space-
     delimited, case-sensitive *structured scope tokens*. The syntax for a
     structured scope token is defined as:


















  Chen, et al.            Expires 2 September 2026                [Page 6]


  Internet-Draft            extensions for Scope                March 2026


     structured-scope-token = resource-type
                              ":" action
                              ":" target
                              [ ":" constraints ]
                              [ ":" reserve ]


     resource-type  = 1*( %x21-2F    ; visible chars except ":" and ";"
                      / %x30-3A
                      / %x3C-7E
                      )

     action         = 1*( %x21-2F / %x30-3A / %x3C-7E )
     target         = 1*( %x21-2F / %x30-3A / %x3C-7E )

     constraints    = constraint *( ":" constraint )
     constraint     = 1*( %x21-2F    ; often key=value pairs
                      / %x30-3A
                      / %x3C-7E
                      )

     *  resource-type: Identifier for the type of resource.  This field is
        REQUIRED.  New types introduced by this extension include:

        -  fs: File system operations.

        -  cmd: Command-line execution.

        -  net: Network access.

        -  tool: Tool/API invocation.

        -  scheduler: Scheduled tasks.

        -  othertype: Other resource types are reserved for resource types
           not defined in this specification. the specific semantics of
           other resource types are defined by the target component and/or
           through agreement between the AS and RS.

     *  action: The operation permitted on the specific resource type.
        This field is REQUIRED.  For example:

        -  For fs: read, write, list, delete.

        -  For cmd: execute.

        -  For net: connect, send, receive.




  Chen, et al.            Expires 2 September 2026                [Page 7]


  Internet-Draft            extensions for Scope                March 2026


        -  For tool: invoke.

        -  For scheduler: create, read, update, delete.

        -  For all resource-type: otheraction (Other operations.  The
           precise operation is defined by the combination of resource-
           type and target.  Implementations MUST be prepared to handle
           unknown action values for a given resource-type`.)

     *  target: Identifier for the target of the operation.  This field is
        REQUIRED.  Its syntax and meaning depend on resource-type and
        action.  For example:

        -  File path: /home/user/documents/*

        -  Command line: /usr/bin/git

        -  Network endpoint: api.example.com:443

        -  Tool ID: weather_forecast

        -  Scheduled task ID: daily_backup

        -  When resource-type is othertype or action is otheraction, the
           target field MAY contain an implementation-specific or a more
           complex structured identifier (e.g., a URI or a name spaced
           string.

     *  constraints (Optional): Additional constraints on the
        authorization, in the form of key=value pairs.  This field is
        OPTIONAL.  Multiple constraints are separated by :. For example:

        -  Time constraints: expires=2026-12-31T23:59:59Z, duration=PT2H
           (2 hours).

        -  Logical constraints: if_condition=user_consented.

        -  Regex constraints: path_regex=^/home/user/[^/]+/\.config$.

        -  Recursion and depth limits: recursive=true:max_depth=5.

        -  Authorization and resource servers SHOULD ignore any constraint
           key they do not understand.








  Chen, et al.            Expires 2 September 2026                [Page 8]


  Internet-Draft            extensions for Scope                March 2026


     *  reserve (Optional): A reserved field for future extensibility.
        This field is OPTIONAL.  This field contains an opaque string
        whose syntax and semantics are defined by a future specification.
        Implementations that do not understand the content of the reserve
        field MUST ignore it.  This provides a standardized location for
        future extensions without breaking existing parsers.

  3.1.  Forward Compatibility Principle:

     This structured extension itself is optional to implement.  When
     parsing the scope value, the authorization server and resource server
     SHOULD first verify if a token's format conforms to the structured
     syntax defined in this specification.  A token is interpreted and
     processed as a structured scope only if the format is strictly
     compliant; otherwise, it MUST be treated as a plain (non-extended)
     scope token.

     Clients, AS, and RS implementing this specification SHOULD be
     designed to tolerate unknown values in the resource-type, action, and
     constraint keyfields.  The preferred behavior upon encountering an
     unknown component is to treat that specific structured scope token as
     not granting the requested permission, rather than failing the entire
     request or token validation, unless a policy explicitly mandates
     strict validation of all components.

  3.2.  Example scope parameter values

     Example scope parameter values (each line represents one possible
     space-delimited token within a scope string):

     fs:read:/home/user/documents/:recursive=true:max_depth=5

     cmd:execute:/usr/bin/git

     net:connect:api.example.com:443

     tool:invoke:weather_forecast

     scheduler:create::interval=P1D (create a daily task)

     The authorization server MAY fully or partially ignore the scope
     requested by the client, based on the authorization server policy or
     the resource owner's instructions.  If the issued access token scope
     is different from the one requested by the client, the authorization
     server MUST include the "scope" response parameter to inform the
     client of the actual scope granted, as per [RFC6749].





  Chen, et al.            Expires 2 September 2026                [Page 9]


  Internet-Draft            extensions for Scope                March 2026


  3.3.  Security Considerations

     *  scope Validation and Least Privilege: Authorization Servers and
        Resource Servers MUST strictly enforce validation of the
        structured scope.  The granted permissions scope_granted MUST be a
        subset explicitly consented to by the user.  When processing
        requests, the Resource Server MUST verify that the token's scope
        contains a structured token that precisely matches the requested
        operation, including resource-type, action, target, and any
        constraints.

     *  Skill Metadata Integrity: The Authorization Server's
        authentication of the skill's source and integrity (Step D) is
        critical.  Strong cryptographic signatures (e.g., code signing
        certificates) SHOULD be used to prevent injection or tampering
        with malicious skills, especially their advertised scope_initial.

     *  User Consent Interface: The authorization consent interface (Step
        E) MUST clearly and unambiguously present the specific meaning of
        the structured scope_request tokens to the user, avoiding
        situations where users over-authorize due to misunderstanding.

  4.  Error Response

     When a request is denied due to a failure in validating the
     structured scope(e.g., malformed syntax, unsupported resource-typeor
     action), the AS returns an error response with the following error
     code:

     Error Code: scope_validation_failed

     Description: The requested structured scope is invalid, malformed, or
     contains unsupported values.

     The AS SHOULD include an error_description parameter to provide
     developers with more specific diagnostic information (e.g.,
     "Unrecognized resource-type: 'custom_db'", "Malformed constraints
     segment").

  5.  IANA Considerations

  5.1.  OAuth Authorization Server Metadata

     This specification requests the registration of the following values
     in the OAuth Authorization Server Metadata registry established by
     [RFC8414] : - structured_scope_resource_types_supported:





  Chen, et al.            Expires 2 September 2026               [Page 10]


  Internet-Draft            extensions for Scope                March 2026


     OPTIONAL.  JSON array containing a list of the resource-typevalues
     (e.g., fs, cmd, net, tool, scheduler) that this authorization server
     supports and can process within structured scope tokens.

     *  structured_scope_actions_supported:

     OPTIONAL.  JSON array containing a list of the actionvalues (e.g.,
     read, write, execute, connect) that this authorization server
     supports and can process within structured scope tokens.

  5.2.  OAuth Extensions Error Registry

     This specification requests the registration of the following error
     code in the OAuth Extensions Error Registry:

     *  Error Code: scope_validation_failed

  6.  Acknowledgements

     This document based on RFC6749

  7.  Normative References

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

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8414>.

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

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

  Authors' Addresses

     Jia Chen
     China Mobile
     BeiJing
     China
     Email: chenjia@chinamobile.com



  Chen, et al.            Expires 2 September 2026               [Page 11]


  Internet-Draft            extensions for Scope                March 2026


     Meiling Chen
     China Mobile
     BeiJing
     China
     Email: chenmeiling@chinamobile.com


     Li Su
     China Mobile
     BeiJing
     China
     Email: suli@chinamobile.com







































  Chen, et al.            Expires 2 September 2026               [Page 12]


name: draft-hw-protocol-agent
rev: 00
title: AI Agent Protocols for Multi-modality
time: 2026-03-02T15:25:09Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T15:25:09Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:04.977042+00:00
source: ietf
abstract:
  With the advancement of AI technologies, AI Agent traffic will
     account for the majority of network traffic, driving an increasing
     demand for higher quality of multi-modal data transmissions.  Current
     networks lack awareness of the diverse transmission quality
     requirements for multi-modal data within a single traffic, leading to
     degraded service quality and inefficient utilization of network
     resources.  This document proposes methods to enable networks (e.g.,
     mobile network, transport network) to recognize the characteristics
     and the transmission requirement of AI Agent multi-modal data and
     outlines necessary capabilities and features of the AI Agent
     Protocols.

full_text:
  Network Working Group                                     Yixin Lin, Ed.
  Internet-Draft                                        Chenchen Yang, Ed.
  Intended status: Standards Track                         Kuan Zhang, Ed.
  Expires: 3 September 2026                                 Xueli An,, Ed.
                                                           Shaoyun Wu, Ed.
                                             Huawei Technologies Co., Ltd.
                                                Muhammad Awais Jadoon, Ed.
                                                  Sebastian Robitzsch, Ed.
                                                  InterDigital Europe Ltd.
                                                              2 March 2026


                   AI Agent Protocols for Multi-modality
                         draft-hw-protocol-agent-00

  Abstract

     With the advancement of AI technologies, AI Agent traffic will
     account for the majority of network traffic, driving an increasing
     demand for higher quality of multi-modal data transmissions.  Current
     networks lack awareness of the diverse transmission quality
     requirements for multi-modal data within a single traffic, leading to
     degraded service quality and inefficient utilization of network
     resources.  This document proposes methods to enable networks (e.g.,
     mobile network, transport network) to recognize the characteristics
     and the transmission requirement of AI Agent multi-modal data and
     outlines necessary capabilities and features of the AI Agent
     Protocols.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 3 September 2026.






  Yixin Lin, et al.       Expires 3 September 2026                [Page 1]


  Internet-Draft               Agent Protocol                   March 2026


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Agent Protocol Gap Analysis . . . . . . . . . . . . . . . . .   3
       2.1.  Multi-modality of AI Agent Traffic  . . . . . . . . . . .   3
       2.2.  Indistinguishable Multi-modal AI Agent Traffic  . . . . .   3
     3.  AI Agent Traffic Transmission Requirement on Underlying
             Networks  . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Quality of Service (QoS)  . . . . . . . . . . . . . . . .   5
       3.2.  Awareness of AI Agent Traffic Multi-modality  . . . . . .   5
     4.  Agent Protocols for Multi-modal Traffic . . . . . . . . . . .   5
       4.1.  Multiple Streams for Multi-modal Agent Traffic  . . . . .   5
         4.1.1.  Mapping Information Notification to Underlying
                 Networks  . . . . . . . . . . . . . . . . . . . . . .   5
         4.1.2.  Inter-stream Relationship Indicator . . . . . . . . .   7
       4.2.  Single Stream with Multi-modality . . . . . . . . . . . .   7
     5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.  Reference . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     The Agent protocols have garnered significant attention across
     diverse technical domains.  Agent protocols are being introduced by
     open-source and standardization organizations, e.g., A2A protocol by
     Google [1], Agent protocol proposals in IETF [2] [3] and ETSI [4].
     For mobile telecommunications, 3GPP has also expressed substantial
     interest in incorporating Agent capabilities within the future 6G
     network.  Numerous use cases for Agent-centric scenarios have been
     documented within the 3GPP SA1 working group [5].  The 3GPP SA2



  Yixin Lin, et al.       Expires 3 September 2026                [Page 2]


  Internet-Draft               Agent Protocol                   March 2026


     working group has reached consensus that the 6G network should
     support Agentic network and Agent communication [6].  Adaptations to
     End-to-End Agent protocols are needed to better support AI Agent
     traffic transmission and ensure the quality of such transmission,
     e.g., based on the characteristics of AI Agent traffic.
     Additionally, the 3GPP CT working groups are organizing studies on AI
     Agent protocols for the 6G network.  In this context, IETF AI Agent
     protocols are highly recommended as a reference [7].

  1.1.  Requirements Language

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

  2.  Agent Protocol Gap Analysis

  2.1.  Multi-modality of AI Agent Traffic

     An AI Agent traffic may consist of multiple “Part” with multi-modal
     data (e.g., text, file, sensor data, structured data, video, audio
     and image) [3].  Different “Part” of an AI Agent traffic may be
     delivered with different transmission modes (e.g., Streaming, Push
     Notification, Burst).

     Taking Google A2A protocol as an example [1], Message constitutes a
     communication unit between client and server, and Artifacts represent
     concrete outputs of task executions.  Both Messages and Artifacts
     transmit content composed of one or more Parts:

     *  A Part serves as a container for discrete communication content
        segments, which MUST contain exactly one content type:text (purely
        textual), raw (file-based:images, videos, etc.), url (resource
        locator), or data (structured blobs e.g., JSON).

  2.2.  Indistinguishable Multi-modal AI Agent Traffic

     There are two distinct methods by which an AI Agent client or server,
     acting as the source, can encapsulate multi-modal data.

     a) The multi-modal data of an AI Agent traffic can be encapsulated
     into multiple lower layers streams (e.g., HTTP streams, MoQ stream,
     QUIC Stream):






  Yixin Lin, et al.       Expires 3 September 2026                [Page 3]


  Internet-Draft               Agent Protocol                   March 2026


     *  the underlying network lacks awareness that these streams belong
        to the same AI Agent traffic.  Consequently, while network nodes
        (e.g., core network user plane function, radio access network base
        stations) can guarantee the QoS for individual stream during data
        forwarding, the overall performance (e.g., latency) for the
        traffic may increase.

     *  Moreover, in scenarios like multi-Agent systems, it may require
        the multi-modal data to arrive at different receiving Agent
        endpoints as simultaneously as possible.  This characteristic
        renders the existing techniques susceptible to introducing
        significant overall performance (e.g., latency) decrease if the
        underlying network lacks awareness.

     b) The multi-modal data of an AI Agent traffic can be encapsulated
     within a single lower layer stream (e.g., HTTP stream, MoQ stream,
     QUIC Stream), this stream exhibits inherent multi-modal
     characteristics:

     *  This manifests as significant variance in Part sizes (e.g., text
        snippets vs. video files) and divergent quality of service (QoS)
        criticality across Parts, e.g., regarding transmission urgency and
        latency tolerance thresholds.

     *  Limitation: Content of different Parts are encapsulated within a
        single lower layer stream (e.g., as payload of HTTP protocol, MoQ
        protocol, QUIC protocol), the underlying network (e.g., mobile
        network, transport network) remains unaware of the distinct Parts
        and their individual requirements, such as specific QoS needs.

     _The Following figure illustrates the interaction between Agent
     Client and Agent Server via underlying Network:_

     +--------+                  +--------+
     | Agent  |                  | Agent  |
     | Client |                  | Server |
     +--------+                  +--------+
         |                            |
         |       +------------+       |
         +-------| Underlying |-------+
                 |  Network   |
                 +------------+

     _Figure 1.  Interaction between Agent Client and Agent Server via
     underlying Network._

  3.  AI Agent Traffic Transmission Requirement on Underlying Networks




  Yixin Lin, et al.       Expires 3 September 2026                [Page 4]


  Internet-Draft               Agent Protocol                   March 2026


  3.1.  Quality of Service (QoS)

     Multi-modal AI Agent traffic should be transmitted appropriately by
     underlying network.  Taking 3GPP mobile network as an example of
     underlying network, QoS framework controls and manages transmission
     of traffic to ensure performance.  QoS framework governs how diverse
     traffics are treated to meet specific performance requirements (e.g.,
     latency, reliability, data rate, packet loss) [5], [6], [8].  It
     operates primarily through QoS Flows, which are granular data streams
     bound with specific QoS parameters and characteristics.  These
     parameters and characteristics indicate the packet forwarding
     treatment (e.g., scheduling weights, admission thresholds, queue
     management) applied throughout the network, from the User Equipment
     (UE) to the mobile network (e.g., core network, radio access
     network).  Multi-modal data of an AI Agent traffic should be
     transmitted with differentiated QoS to increase the overall
     performance and resource utilization.

  3.2.  Awareness of AI Agent Traffic Multi-modality

     The underlying network should be aware of the AI Agent traffic
     characteristics.  Different transmission treatment policies may be
     configured and bounded to the different multi-modal data of an AI
     Agent traffic based on their different traffic characteristics (e.g.,
     delay budget, priority, error rate).  Taking mobile network as an
     example, the Application Server may influence QoS treatment by
     notifying service requirements to the mobile network functions.
     Based on this, the mobile network provisions and configures the
     corresponding QoS enforcement policies.  Subsequently, the mobile
     network maps incoming packets of application traffic to the
     appropriate QoS Flows by matching against the enforcement policies
     and the traffic information (e.g., typically IP 5-tuple).  Similarly,
     the AI Agent client and server need to notify necessary information
     on its AI Agent traffic to the underlying network for better
     performance.

  4.  Agent Protocols for Multi-modal Traffic

  4.1.  Multiple Streams for Multi-modal Agent Traffic

  4.1.1.  Mapping Information Notification to Underlying Networks

     Using method a) mentioned in 3.2, a source Agent (client or server)
     transmits multi-modal data of an AI Agent traffic into distinct lower
     layers streams based on modality and QoS requirements.






  Yixin Lin, et al.       Expires 3 September 2026                [Page 5]


  Internet-Draft               Agent Protocol                   March 2026


     *  For example, a source Agent transmits multi-modal data of an AI
        Agent traffic into distinct HTTP streams.  Each HTTP stream is
        characterized by a unique IP 5-tuple and carries data of only one
        modality.

     *  As another example, multi-modal data of an AI Agent traffic is
        transmitted via distinct transport layer streams (e.g., MoQ
        streams, QUIC streams) or connections (e.g., TCP connections).

     The source Agent needs to notify the mapping information to the
     underlying network to make alignment.  Based on the mapping
     information, the underlying network can identify the correlation of
     the different lower layer streams, and execute dedicated QoS
     guarantee accordingly.

     The AI Agent protocols in the Agent client and server should have the
     capabilities and features to perform the actions above, e.g., mapping
     multi-modal data of Agent traffic to different lower layer streams,
     notifying the mapping relationship to the underlying network (e.g.,
     via control plane of mobile network), and notifying necessary
     information to lower layers to enable the latter to encapsulate Agent
     traffic assistance information.  The capabilities and features of the
     AI Agent protocol should be highlighted and standardized, e.g., in
     IETF working group(s).

     Moreover, it is possible that the Agent protocol layer and/or lower
     layers need some enhancements, e.g., to encapsulate AI Agent
     assistance information (e.g., traffic characteristics, multi-modal
     data types, correlation information).

  +------------------------------------------------------+
  |                    Agent Protocol                    |
  |               {Correlation Information}              |
  +------------------------------------------------------+   --+
  | e.g., HTTP Protocol       | e.g., MoQ                |     |
  | {Correlation Information} | {Correlation Information}|     |
  +------------------------------------------------------+     |-- Lower Layers
  |                   Transport Protocol                 |     |
  |               {Correlation Information}              |     |
  +------------------------------------------------------+   --+

     _Figure 2.  Enhancements in Agent protocol layer and/or lower
     layers._








  Yixin Lin, et al.       Expires 3 September 2026                [Page 6]


  Internet-Draft               Agent Protocol                   March 2026


  4.1.2.  Inter-stream Relationship Indicator

     As outlined in 2.2, there is a potential concern associated with
     correlated multi-stream transmission.  In this case, an inter-stream
     relationship indicator, as an example of the correlation information,
     is introduced to explicitly signal that multiple distinct streams
     belong to the same AI Agent traffic.  This indicator could take a
     form of a unique ID that determined by source Agent(s), or it can be
     assigned by the underlying network.  The sending entity encapsulates
     this indicator within the headers of all associated streams.  Upon
     processing streams containing this indicator, the underlying network
     transmission nodes can leverage it to perform coordinated
     transmission operations.  For example, base stations in mobile
     network can hold data from related streams to facilitate
     synchronization, and apply scheduling algorithms that consider the
     temporal relationship between streams.  This enables the base station
     to orchestrate the transmission of data from these related streams to
     minimize arrival time variance to the receiver(s), ensuring data
     arrives as simultaneously as possible at intended endpoint(s).

     This inter-stream relationship indicator can be encapsulated in the
     header of Agent Protocol Layer or lower layers, e.g., HTTP Layer,
     Transport Layer, etc.

     +-------------------------------------------------+
     | POST /rpc/ HTTP/2.0                             |
     +-------------------------------------------------+
     | Host: agent.example.com                         |
     | Content-Type: application/json                  |
     | Content-Length: xxx                             |
     | Correlation Information: Relationship indictor  |
     +-------------------------------------------------+

     _Figure 3. *Correlation Information* in the HTTP header._

  4.2.  Single Stream with Multi-modality

     Using method b) mentioned in 2.2, the source Agent can encapsulate
     multi-modal data of an AI Agent traffic (e.g., as separate Parts)
     within a single lower layer stream.  One of the limitations of this
     method is that the underlying network remains unaware of individual
     Parts and their associated QoS requirements.

     To address this limitation, the source Agent is required to perform
     Part segmentation during encapsulation: it should separate different
     Parts with clear boundaries, and embed supplementary metadata (e.g.,
     traffic information, QoS requirements) corresponding to each Part
     within the packet header or sub-headers.  This supplementary metadata



  Yixin Lin, et al.       Expires 3 September 2026                [Page 7]


  Internet-Draft               Agent Protocol                   March 2026


     enables the underlying network to identify assistance information on
     specific Parts (e.g., their different traffic characteristics and
     respective QoS requirements).

     a) In one implementation, supplementary metadata of each Part can be
     encapsulated in the packet header (e.g., Agent protocol header, or
     lower layer header) as in Figure 4.  For example, the header contains
     fields such as:

     *  the total number of Parts,

     *  sequence number of each Part and the corresponding traffic
        information (e.g. size of a Part, modality of a Part, and
        transmission mode of a Part), QoS requirements (e.g., latency,
        error rate, priority, privacy), etc.

     The contents of different Parts will be encapsulated in the payload
     in sequence with the same order of the supplementary metadata in the
     header.

  +----------------------------+-------------+-------------+-------------+
  |Header{                     |             |             |             |
  |   Number of Parts,         |             |             |             |
  |   {Part 1,                 |             |             |             |
  |      {Traffic information, |             |             |             |
  |       QoS requirements},   |   Payload   |   Payload   |     ...     |
  |    Part 2,                 |   (Part1)   |   (Part2)   |             |
  |      {...},                |             |             |             |
  |   ...                      |             |             |             |
  |   }                        |             |             |             |
  |}                           |             |             |             |
  +----------------------------+-------------+-------------+-------------+

     _Figure 4.  Supplementary metadata in the *header*._

     b) In another implementation, supplementary metadata of each Part can
     be encapsulated in the sub-header of the sub-PDU as in Figure 5.  For
     example, each sub-header contains fields such as:

     *  sequence number of each Part and the corresponding traffic
        information (e.g. size of a Part, modality of a Part, and
        transmission mode of a Part), QoS requirements (e.g., latency,
        error rate, priority, privacy), etc.








  Yixin Lin, et al.       Expires 3 September 2026                [Page 8]


  Internet-Draft               Agent Protocol                   March 2026


     The contents of different Parts, on the other hand, will be
     encapsulated in the payload following the corresponding sub-header.
     In this case, a common header (e.g., in front of the subPDUs) can
     contain the field to indicate the total number of Parts of an AI
     Agent traffic.

                         +------------------------+
                         |Sub-header{             |
                         |   Part ID / SN,        |
                         |   Traffic information, |
                         |   QoS requirements     |
                         |}                       |
                         +------------------------+
                         |                       /
                         |                    /
                         |                 /
                         |              /
                         |           /
                         +------------------+  +------------------+
                         |Sub-header|Payload|  |Sub-header|Payload|
                         +------------------+  +------------------+
                         |                 /  /                  /
                         |                / /                   /
                         |               //                    /
     +---------------------------------------------------------------+
     |       Header      |               |                     |     |
     | number of subPDUs |     subPDU    |       subPDU        | ... |
     +---------------------------------------------------------------+

     _Figure 5.  Supplementary metadata in the *sub-headers*._

     Moreover, the source Agent may also inform the underlying network in
     advance about the supplementary metadata (e.g., traffic information,
     QoS requirements) corresponding to each distinct Part.  The
     underlying network then provision QoS parameters for each Part.  Upon
     receiving the stream, the underlying network can distinguish these
     multi-modal Parts based on their specific characteristics and
     associated QoS requirements.

     Upon data arrival at the receiving endpoint, the entity of underlying
     network can perform reassembly of data packets associated with an AI
     Agent traffic prior to delivery to the receiving Agent client/server.
     Or, the entity of Agent protocol layer in the receiving Agent client/
     server can reassemble the data packets.  Which one is better can be
     left for further study.






  Yixin Lin, et al.       Expires 3 September 2026                [Page 9]


  Internet-Draft               Agent Protocol                   March 2026


  5.  Summary

     In this paper, we address the challenge wherein the underlying
     network lacks awareness of multi-modality of AI Agent traffic.  We
     proposed two different ways for the source Agent client or server to
     encapsulate multi-modal data: one is to encapsulate multi-modal data
     into multiple streams, another one is to encapsulate multi-modal data
     into a single stream.  In the former case, the source Agent notifies
     stream correlation information to the underlying network.  In the
     latter case, the source Agent separates multi-modal data into
     different Parts, and embed supplementary metadata (e.g., traffic
     information and QoS requirements) within the header and/or sub-
     headers of Agent protocol layer or lower layers.  For both methods,
     upon receiving the stream(s), underlying network can apply
     differential treatment to individual Parts, e.g., based on their
     specific QoS requirements.

  6.  Reference

     [1] A2A Protocol.  "Specification". https://a2a-protocol.org/v0.2.5/
     specification/, 2025.

     [2] Jonathan Rosenberg , Cullen Fluffy Jennings, “Framework, Use
     Cases and Requirements for AI Agent Protocols”,
     https://datatracker.ietf.org/doc/draft-rosenberg-ai-protocols/,
     2025.05

     [3] Chenchen Yang , Huanhuan Huang, , Arashmid Akhavain , Faye Liu ,
     Xueli An, , Weijun Xing, , Jinyan Li , Aijun Wang , Yang Wencong,
     “Requirements and Enabling Technologies of Agent Protocols for 6G
     Networks.”

     [4] ETSI ENI ISG 055 Early Draft, “Use Cases and Requirements for AI
     Agents based Core Network”, 2025.06.04.

     [5] 3GPP TR 22.870 (V1.1.0): “Study on 6G Use Cases and Service
     Requirements; Stage 1 (Release 20)”.

     [6] 3GPP TR 23.801-01 (V0.3.0): “Study on Architecture for 6G System;
     Stage 2 (Release 20)”.

     [7] C3-260051, C4-260225, C1-260122, “New SID on Study on the
     Protocol for AI in the 6G System”, 2026.02.

     [8] 3GPP TR 23.501 (V20.0.0): “System architecture for the 5G System
     (5GS); Stage 2 (Release 20)”.





  Yixin Lin, et al.       Expires 3 September 2026               [Page 10]


  Internet-Draft               Agent Protocol                   March 2026


  7.  Security Considerations

     This document does not introduce any new security considerations.

  8.  IANA Considerations

     This document has no IANA actions.

  9.  Normative References

     [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
                D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
                (SRv6) Network Programming", RFC 8986,
                DOI 10.17487/RFC8986, February 2021,
                <https://www.rfc-editor.org/rfc/rfc8986>.

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

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

  Authors' Addresses

     Yixin Lin (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: linyixin6@huawei.com


     Chenchen Yang (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: yangchenchen7@huawei.com


     Kuan Zhang (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: zhangkuan3@huawei.com





  Yixin Lin, et al.       Expires 3 September 2026               [Page 11]


  Internet-Draft               Agent Protocol                   March 2026


     Xueli An, (editor)
     Huawei Technologies Co., Ltd.
     Munich
     Germany
     Email: Xueli.An@huawei.com


     Shaoyun Wu (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: wushaoyun@huawei.com


     Muhammad Awais Jadoon (editor)
     InterDigital Europe Ltd.
     London
     United Kingdom
     Email: Muhammad.AwaisJadoon@InterDigital.com


     Sebastian Robitzsch (editor)
     InterDigital Europe Ltd.
     London
     United Kingdom
     Email: Sebastian.Robitzsch@InterDigital.com

























  Yixin Lin, et al.       Expires 3 September 2026               [Page 12]


name: draft-klrc-aiagent-auth
rev: 00
title: AI Agent Authentication and Authorization
time: 2026-03-02T18:38:53Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T18:38:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:04.979764+00:00
source: ietf
abstract:
  This document proposes a model for authentication and authorization
     of AI agent interactions.  It leverages existing standards such as
     the Workload Identity in Multi-System Environments (WIMSE)
     architecture and OAuth 2.0 family of specifications.  Rather than
     defining new protocols, this document describes how existing and
     widely deployed standards can be applied or extended to establish
     agent authentication and authorization.  By doing so, it aims to
     provide a framework within which to use existing standards, identify
     gaps and guide future standardization efforts for agent
     authentication and authorization.

full_text:
  Network Working Group                                       P. Kasselman
  Internet-Draft                                          Defakto Security
  Intended status: Informational                               J. Lombardo
  Expires: 3 September 2026                                            AWS
                                                              Y. Rosomakho
                                                                   Zscaler
                                                               B. Campbell
                                                             Ping Identity
                                                              2 March 2026


                 AI Agent Authentication and Authorization
                         draft-klrc-aiagent-auth-00

  Abstract

     This document proposes a model for authentication and authorization
     of AI agent interactions.  It leverages existing standards such as
     the Workload Identity in Multi-System Environments (WIMSE)
     architecture and OAuth 2.0 family of specifications.  Rather than
     defining new protocols, this document describes how existing and
     widely deployed standards can be applied or extended to establish
     agent authentication and authorization.  By doing so, it aims to
     provide a framework within which to use existing standards, identify
     gaps and guide future standardization efforts for agent
     authentication and authorization.

  About This Document

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

     The latest revision of this draft can be found at
     https://PieterKas.github.io/agent2agent-auth-framework/draft-klrc-
     aiagent-auth.html.  Status information for this document may be found
     at https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/.

     Source for this draft and an issue tracker can be found at
     https://github.com/PieterKas/agent2agent-auth-framework.

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



  Kasselman, et al.       Expires 3 September 2026                [Page 1]


  Internet-Draft                   AI-Auth                      March 2026


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

     This Internet-Draft will expire on 3 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Agents are workloads  . . . . . . . . . . . . . . . . . . . .   4
     4.  Agent Identity Management System  . . . . . . . . . . . . . .   6
     5.  Agent Identifier  . . . . . . . . . . . . . . . . . . . . . .   7
     6.  Agent Credentials . . . . . . . . . . . . . . . . . . . . . .   8
     7.  Agent Attestation . . . . . . . . . . . . . . . . . . . . . .   9
     8.  Agent Credential Provisioning . . . . . . . . . . . . . . . .   9
     9.  Agent Authentication  . . . . . . . . . . . . . . . . . . . .  10
       9.1.  Transport Layer Authentication  . . . . . . . . . . . . .  10
         9.1.1.  Limitations . . . . . . . . . . . . . . . . . . . . .  11
       9.2.  Application Layer Authentication  . . . . . . . . . . . .  11
         9.2.1.  WIMSE Proof Tokens (WPTs) . . . . . . . . . . . . . .  11
         9.2.2.  HTTP Message Signatures . . . . . . . . . . . . . . .  12
         9.2.3.  Limitations . . . . . . . . . . . . . . . . . . . . .  12
     10. Agent Authorization . . . . . . . . . . . . . . . . . . . . .  13
       10.1.  Leverage OAuth 2.0 as a Delegation Authorization
              Framework  . . . . . . . . . . . . . . . . . . . . . . .  13
       10.2.  Use of OAuth 2.0 Access Tokens . . . . . . . . . . . . .  13
       10.3.  Obtaining an OAuth 2.0 Access Token  . . . . . . . . . .  14
         10.3.1.  User Delegates Authorization . . . . . . . . . . . .  14
         10.3.2.  Agent Obtains Own Authorization  . . . . . . . . . .  14
         10.3.3.  Agents Accessed by Systems or Other Agents . . . . .  15
         10.3.4.  OAuth 2.0 Security Best Practices  . . . . . . . . .  15
       10.4.  Risk Reduction with Transaction Tokens . . . . . . . . .  15



  Kasselman, et al.       Expires 3 September 2026                [Page 2]


  Internet-Draft                   AI-Auth                      March 2026


       10.5.  Cross Domain Access  . . . . . . . . . . . . . . . . . .  16
       10.6.  Human in the Loop  . . . . . . . . . . . . . . . . . . .  16
       10.7.  Tool-to-Service Access . . . . . . . . . . . . . . . . .  17
       10.8.  Privacy Considerations {privacy-considerations}  . . . .  18
       10.9.  OAuth 2.0 Discovery in Dynamic Environments  . . . . . .  18
         10.9.1.  Authorization Server Capability Discovery  . . . . .  18
         10.9.2.  Protected Resource Capability Discovery  . . . . . .  19
         10.9.3.  Client Capability Discovery  . . . . . . . . . . . .  19
     11. Agent Monitoring, Observability and Remediation . . . . . . .  19
     12. Agent Authentication and Authorization Policy . . . . . . . .  21
     13. Agent Compliance  . . . . . . . . . . . . . . . . . . . . . .  21
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  21
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  21
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     17. Normative References  . . . . . . . . . . . . . . . . . . . .  21
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  25
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     The rapid emergence of AI agents as autonomous workloads has sparked
     considerable innovation in authentication and authorization
     approaches.  However, many of these efforts develop solutions in
     isolation, often reinventing existing mechanisms unaware of
     applicable prior art.  This fragmentation risks creating incompatible
     implementations, duplicated development effort, and missed
     opportunities to leverage decades of established identity and
     authorization standards.

     This document aims to help close that gap by providing a
     comprehensive model demonstrating how existing, well-established
     standards and some emergent specifications can be composed and
     applied to solve agent authentication and authorization challenges.
     Rather than proposing new protocols, this work focuses on integrating
     proven standards into a coherent framework tailored to the specific
     requirements of AI agent workloads.

     By doing so, this document serves two complementary goals:

     1.  *Consolidation of prior art*: It establishes a baseline by
         showing how existing standards address the core identity,
         authentication, authorization, monitoring and observability needs
         of agent-based systems.  Implementers and standards developers
         can reference this framework to avoid redundant work and ensure
         interoperability.






  Kasselman, et al.       Expires 3 September 2026                [Page 3]


  Internet-Draft                   AI-Auth                      March 2026


     2.  *Foundation for future work*: As the agent ecosystem matures,
         having such a framework aids in identifying gaps and clarifies
         where extensions or profiles of existing standards are needed.
         This provides a foundation for more focused standardization
         efforts in areas needing novel work rather than variations of
         existing approaches.

  2.  Conventions and Definitions

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

  3.  Agents are workloads

     An Agent is a workload that iteratively interacts with a Large
     Language Model (LLM) and a set of Tools, Services and Resources.  An
     agent performs its operations until a terminating condition,
     determined either by the LLM or by the agent's internal logic, is
     reached.  It may receive input from a user, or act autonomously.
     Figure 1 shows a conceptual model of the AI Agent as a workload and
     illustrates the high-level interaction model between the User or
     System, the AI Agent, the Large Language Model (LLM), Tools,
     Services, and Resources.

     In this document, Tools, Services, and Resources are treated as a
     single category of external endpoints that an agent invokes or
     interacts with to complete a task.  Communication within or between
     Tools, Services, and Resources is out of scope.

                     +----------------+
                     | Large Language |
                     |   Model (LLM)  |
                     +----------------+
                           ▲   |
                          (2) (3)
                           |   ▼
     +--------+       +------------+       +-----------+
     |  User  |──(1)─►|  AI Agent  |──(4)─►|   Tools   |
     |   or   |       | (workload) |       | Services  |
     | System |◄─(6)──|            |◄─(5)──| Resources |
     +--------+       +------------+       +-----------+

                        Figure 1: AI Agent as a Workload





  Kasselman, et al.       Expires 3 September 2026                [Page 4]


  Internet-Draft                   AI-Auth                      March 2026


     1.  Optional: The User or System (e.g. a batch job or another Agent)
         provides an initial request or instruction to the AI Agent.

     2.  The AI Agent provides the available context to the LLM.  Context
         is implementation, and deployment, specific and may include User
         or System input, system prompts, Tool descriptions, prior Tool,
         Service and Resource outputs, and other relevant state.

     3.  The LLM returns output to the AI Agent facilitating selection of
         Tools, Services or Resources to invoke.

     4.  The AI Agent invokes one or more external endpoints of selected
         Tools, Services or Resources.  A Tool endpoint may itself be
         implemented by another AI agent.

     5.  The external endpoint of the Tools, Services or Resources returns
         a result of the operation to the AI Agent, which may send the
         information as additional context to the Large Language Model,
         repeating steps 2-5 until the exit condition is reached and the
         task is completed.

     6.  Optional: Once the exit condition is reached in step 5, the AI
         Agent may return a response to the User or System.  The AI Agent
         may also return intermediate results or request additional input.

     As shown in Figure 1, the AI agent is a workload that needs an
     identifier and credentials so it can be authenticated by the Tools,
     Services, Resources, Large Language Model, System and the User (via
     the underlying operating system or platform, similar to existing
     applications and services).  Once authenticated, these parties
     determine if the AI Agent is authorized to access the requested Large
     Language Model, Tools, Services or Resources.  If the AI Agent is
     acting on behalf of a User or System, the User or System needs to
     delegate authority to the AI Agent, and the User or System context is
     preserved and used as input to authorization decisions and recorded
     in audit trails.

     This document describes how AI Agents should leverage existing
     standards defined by SPIFFE [SPIFFE], WIMSE, OAuth and OpenID SSF
     [SSF].











  Kasselman, et al.       Expires 3 September 2026                [Page 5]


  Internet-Draft                   AI-Auth                      March 2026


  4.  Agent Identity Management System

     This document defines the term Agent Identity Management System
     (AIMS) as a conceptual model describing the set of functions required
     to establish, maintain, and evaluate the identity and permissions of
     an agent workload.  AIMS does not refer to a single product,
     protocol, or deployment architecture.  AIMS may be implemented by one
     component or distributed across multiple systems (such as identity
     providers, attestation services, authorization servers, policy
     engines, and runtime enforcement points).

     An Agent Identity Management System ensures that the right Agent has
     access to the right resources and tools at the right time for the
     right reason.  An Agent identity management system depends on the
     following components to achieve its goals:

     *  *Agent Identifiers:* Unique identifier assigned to every Agent.

     *  *Agent Credentials:* Cryptographic binding between the Agent
        Identifier and attributes of the Agent.

     *  *Agent Attestation:* Mechanisms for determining and assigning the
        identifier and issue credentials based on measurements of the
        Agent's environment.

     *  *Agent Credential Provisioning:* The mechanism for provisioning
        credentials to the agent at runtime.

     *  *Agent Authentication:* Protocols and mechanisms used by the Agent
        to authenticate itself to Large Language Models or Tools (resource
        or server) in the system.

     *  *Agent Authorization:* Protocols and systems used to determine if
        an Agent is allowed to access a Large Language Model or Tool
        (resource or server).

     *  *Agent Observability and Remediation:* Protocols and mechanisms to
        dynamically modify the authorization decisions based on observed
        behavior and system state.

     *  *Agent Authentication and Authorization Policy:* The configuration
        and rules for each of the Agent Identity Management System.

     *  *Agent Compliance:* Measurement of the state and functioning of
        the system against the stated policies.

     The components form a logical stack in which higher layers depend on
     guarantees provided by lower layers, as illustrated in Figure 2.



  Kasselman, et al.       Expires 3 September 2026                [Page 6]


  Internet-Draft                   AI-Auth                      March 2026


     +--------------+----------------------------------+-----------------+
     |    Policy    |     Monitoring, Observability    |    Compliance   |
     |              |          & Remediation           |                 |
     |              +----------------------------------+                 |
     |              |          Authorization           |                 |
     |              +----------------------------------+                 |
     |              |          Authentication          |                 |
     |              +----------------------------------+                 |
     |              |          Provisioning            |                 |
     |              +----------------------------------+                 |
     |              |           Attestation            |                 |
     |              +----------------------------------+                 |
     |              |           Credentials            |                 |
     |              +----------------------------------+                 |
     |              |           Identifier             |                 |
     +--------------+----------------------------------+-----------------+

                   Figure 2: Agent Identity Management System

  5.  Agent Identifier

     Agents MUST be uniquely identified in order to support
     authentication, authorization, auditing, and delegation.

     The Workload Identity in Multi-System Environments (WIMSE) identifier
     as defined by [WIMSE-ID] is the primary identifier for agents in this
     framework.

     A WIMSE identifier is a URI that uniquely identifies a workload
     within a trust domain.  Authorization decisions, delegation
     semantics, and audit records rely on this identifier remaining stable
     for the lifetime of the workload identity.

     The Secure Production Identity Framework for Everyone ([SPIFFE])
     identifier is a widely deployed and operationally mature
     implementation of the WIMSE identifier model.  A SPIFFE identifier
     ([SPIFFE-ID]) is a URI in the form of spiffe://<trust-domain>/<path>
     that uniquely identifies a workload within a trust domain.

     An agent participating in this framework MUST be assigned exactly one
     WIMSE identifier, which MAY be a SPIFFE ID.










  Kasselman, et al.       Expires 3 September 2026                [Page 7]


  Internet-Draft                   AI-Auth                      March 2026


  6.  Agent Credentials

     Agents MUST possess credentials that provide a cryptographic binding
     to the agent identifier.  These credentials are considered primary
     credentials that are provisioned at runtime.  An identifier alone is
     insufficient unless it can be verified to be controlled by the
     communicating agent through a cryptographic binding.

     WIMSE credentials ([WIMSE-CRED]) are defined as a profile of X.509
     certificates and Workload Identity Tokens (WITs), while SPIFFE
     defines SPIFFE Verified ID (SVID) profiles of JSON Web Token (JWT-
     SVID), X.509 certificates (X.509-SVID) and WIMSE Workload Identity
     Tokens (WIT-SVID).  SPIFFE SVID credentials are compatible with WIMSE
     defined credentials.  The choice of an appropriate format depends on
     the trust model and integration requirements.

     Agent credentials SHOULD be short-lived to minimize the risk of
     credential theft, MUST include an explicit expiration time after
     which it is no longer accepted, and MAY carry additional attributes
     relevant to the agent (for example trust domain, attestation
     evidence, or workload metadata).

     Deployments can improve the assurance of agent identity by protecting
     private keys using hardware-backed or isolated cryptographic storage
     such as TPMs, secure enclaves, or platform security modules when such
     capabilities are available.  These mechanisms reduce key exfiltration
     risk but are not required for interoperability.

     In some cases, agents MAY need secondary credentials to access a
     proprietary or legacy environment that is not compatible with the
     X.509, JWT or WIT it is provisioned with.  In these cases an agent
     MAY exchange their primary credentials through a credential exchange
     mechanisms (e.g., OAuth 2.0 Token Exchange [OAUTH-TOKEN-EXCHANGE],
     Transaction Tokens [OAUTH-TXN-TOKENS] or Workload Identity
     Federation).  This allows an agent to obtain a credential targeted to
     a specific environment by leveraging the primary credential in its
     possession.

     *Note*: Static API keys are an antipattern for agent identity.  They
     are bearer artifacts that are not cryptographically bound, do not
     convey identity, are typically long-lived and are operationally
     difficult to rotate, making them unsuitable for secure agent
     authentication or authorization.








  Kasselman, et al.       Expires 3 September 2026                [Page 8]


  Internet-Draft                   AI-Auth                      March 2026


  7.  Agent Attestation

     Agent attestation is the identity-proofing mechanism for AI agents.
     Just as humans rely on identity proofing during account creation or
     credential issuance, agents require a means to demonstrate what they
     are, how they were instantiated, and under what conditions they are
     operating.  Attestation evidence feeds into the credential issuance
     process and determines whether a credential is issued, the type of
     credential issued and the contents of the credential.

     Multiple attestation mechanisms exist, and the appropriate choice is
     deployment and risk specific.  These mechanisms may include hardware-
     based attestations (e.g., TEE evidence), software integrity
     measurements, supply-chain provenance, platform and orchestration-
     layer attestations, or operator assertions to name a few.  Depending
     on the risk involved, a single attestation may be sufficient, or, in
     higher risk scenarios, multi-attestation may be required.

     There are numerous systems that perform some form of attestation, any
     of which can contribute to establishing agent identity.  For example,
     SPIFFE implementations can attest workloads using platform and
     environment specific mechanisms.  At a high level, an attesting
     component gathers workload and execution context signals (such as
     where the workload is running and relevant platform identity
     attributes), presents those signals for verification to an issuer,
     and, as long as verification succeeds, binds the workload to a SPIFFE
     identifier and issues credentials (such as SVID) for subsequent
     authentication and authorization.

     An agent identity management system may incorporate multiple
     attestation mechanisms and implementations to collect evidence and
     supply it to credential provisioning components.  The selection of
     mechanisms depends on deployment constraints (such as the underlying
     platform and available identity signals) and the desired level of
     trust assurance.

  8.  Agent Credential Provisioning

     Agent credential provisioning refers to the runtime issuance,
     renewal, lifecycle state and rotation of the credentials an agent
     uses to authenticate and authorize itself to other agents.  Agents
     may be provisioned with one or more credential types as described in
     Section 6.  Unlike static secrets, agent credentials are provisioned
     dynamically and are intentionally short-lived, eliminating the
     operational burden of manual expiration management and reducing the
     impact of credential compromise.  Agent credential provisioning must
     operate autonomously, scale to high-churn environments, and integrate
     closely with the attestation mechanisms that establish trust in the



  Kasselman, et al.       Expires 3 September 2026                [Page 9]


  Internet-Draft                   AI-Auth                      March 2026


     agent at each issuance or rotation event.

     Agent credential provisioning typically includes two phases:

     1.  *Initial Provisioning*: The process by which an agent first
         acquires a credential bound to its identity.  This often occurs
         immediately after deployment or instantiation and is based on
         verified properties of the agent (e.g., deployment context,
         attestation evidence, or orchestration metadata).

     2.  *Rotation/Renewal*: The automatic refresh of short-lived
         credentials before expiration.  Continuous rotation ensures that
         credentials remain valid only for the minimum necessary time and
         that authorization state reflects current operational conditions.

     The use of short-lived credentials provides a significant improvement
     in the risk profile and risk of credential exposure.  It provides an
     alternative to explicit revocation mechanisms and simplifies
     lifecycle management in large, automated environments while removing
     the risks of downtime as a result of credential expiry.

     Deployed frameworks such as [SPIFFE] provide proven mechanisms for
     automated, short-lived credential provisioning at runtime.  In
     addition to issuing short-lived credentials, [SPIFFE] also provisions
     ephemeral cryptographic key material bound to each credential,
     further reducing the risks associated with compromising long-lived
     keys.

  9.  Agent Authentication

     Agents may authenticate using a variety of mechanisms, depending on
     the credentials they possess, the protocols supported in the
     deployment environment, and the risk profile of the application.  As
     described in the WIMSE Architecture [WIMSE-ARCH], authentication can
     occur at either the transport layer or the application layer, and
     many deployments rely on a combination of both.

  9.1.  Transport Layer Authentication

     Transport-layer authentication establishes trust during the
     establishment of a secure transport channel.  The most common
     mechanism used by agents is mutually-authenticated TLS (mTLS), in
     which both endpoints present X.509-based credentials and perform a
     bidirectional certificate exchange as part of the TLS negotiation.
     When paired with short-lived workload identities, such as those
     issued by SPIFFE or WIMSE, mTLS provides strong channel binding and
     cryptographic proof of control over the agent’s private key.




  Kasselman, et al.       Expires 3 September 2026               [Page 10]


  Internet-Draft                   AI-Auth                      March 2026


     mTLS is particularly well-suited for environments where transport-
     level protection, peer authentication, and ephemeral workload
     identity are jointly required.  It also simplifies authorization
     decisions by enabling agents to associate application-layer requests
     with an authenticated transport identity.  One example of this is the
     use of mTLS in service mesh architectures such as Istio or LinkerD.

  9.1.1.  Limitations

     There are scenarios where transport-layer authentication is not
     desirable or cannot be relied upon.  In architectures involving
     intermediaries, such as proxies, API gateways, service meshes, load
     balancers, or protocol translators, TLS sessions are often terminated
     and re-established, breaking the end-to-end continuity of transport-
     layer identity.  Similarly, some deployment models (such as
     serverless platforms, multi-tenant edge environments, or cross-domain
     topologies) may obscure or abstract identity presented at the
     transport layer, making it difficult to bind application-layer
     actions to a credential presented at the transport layer.  In these
     cases, application-layer authentication provides a more robust and
     portable mechanism for expressing agent identity and conveying
     attestation or policy-relevant attributes.

  9.2.  Application Layer Authentication

     Application-layer authentication allows agents to authenticate
     independently of the underlying transport.  This enables end-to-end
     identity preservation even when requests traverse proxies, load
     balancers, or protocol translation layers.

     The WIMSE working group defines WIMSE Proof Tokens and HTTP Message
     Signatures as authentication mechanisms that may be used by agents.

  9.2.1.  WIMSE Proof Tokens (WPTs)

     WIMSE Workload Proof Tokens (WPTs, [WIMSE-WPT]) are a protocol-
     independent, application-layer mechanism for proving possession of
     the private key associated with a Workload Identity Token (WIT).
     WPTs are generated by the agent, using the private key matching the
     public key in the WIT.  A WPT is defined as a signed JSON Web Token
     (JWT) that binds an agent’s authentication to a specific message
     context, for example, an HTTP request, thereby providing proof of
     possession rather than relying on bearer semantics.

     WPTs are designed to work alongside WITs [WIMSE-CRED] and are
     typically short-lived to reduce the window for replay attacks.  They
     carry claims such as audience (aud), expiration (exp), a unique token
     identifier (jti), and a hash of the associated WIT (wth).  A WPT may



  Kasselman, et al.       Expires 3 September 2026               [Page 11]


  Internet-Draft                   AI-Auth                      March 2026


     also include hashes of other related tokens (e.g., a Transaction
     Token) to bind the authentication contexts to specific transaction or
     authorizations details.

     Although the draft currently defines a protocol binding for HTTP (via
     a Workload-Proof-Token header), the core format is protocol-agnostic,
     making it applicable to other protocols.  Its JWT structure and
     claims model allow WPTs to be bound to different protocols and
     transports, including asynchronous or non-HTTP messaging systems such
     as Kafka and gRPC, or other future protocol bindings.  This design
     enables receiving systems to verify identity, key possession, and
     message binding at the application layer even in environments where
     transport-layer identity (e.g., mutual TLS) is insufficient or
     unavailable.

  9.2.2.  HTTP Message Signatures

     The WIMSE Workload-to-Workload Authentication with HTTP Signatures
     specification [WIMSE-HTTPSIG] defines an application-layer
     authentication profile built on the HTTP Message Signatures standard
     [HTTP-SIG].  It is one of the mechanisms WIMSE defines for
     authenticating workloads in HTTP-based interactions where transport-
     layer protections may be insufficient or unavailable.  The protocol
     combines a workload's Workload Identity Token (WIT) (which binds the
     agent's identity to a public key) with HTTP Message Signatures (using
     the corresponding private key), thereby providing proof of possession
     and message integrity for individual HTTP requests and responses.
     This approach ensures end-to-end authentication and integrity even
     when traffic traverses intermediaries such as TLS proxies or load
     balancers that break transport-layer identity continuity.  The
     profile mandates signing of some request components (e.g., method,
     request-target (which likely cover what you'd expect), content
     digest, and the WIT itself) and supports optional response signing.

  9.2.3.  Limitations

     Unlike transport-layer authentication, application-layer
     authentication does not inherently provide channel binding to the
     underlying secure transport.  As a result, implementations MUST
     consider the risk of message relay or replay if tokens or signed
     messages are accepted outside their intended context.  Deployments
     typically mitigate these risks through short token lifetimes,
     audience restrictions, nonce or unique identifier checks, and binding
     authentication to specific requests or transaction parameters.







  Kasselman, et al.       Expires 3 September 2026               [Page 12]


  Internet-Draft                   AI-Auth                      March 2026


  10.  Agent Authorization

     Agents act on behalf of a user, a system, or on their own behalf as
     shown in Figure 1 and need to obtain authorization when interacting
     with protected resources.

  10.1.  Leverage OAuth 2.0 as a Delegation Authorization Framework

     The widely deployed OAuth 2.0 Authorization Framework
     [OAUTH-FRAMEWORK] is a mechanism for delegated authorization that
     enables an Agent to obtain limited access to a protected resource
     (e.g., a service or API), intermediated by an Authorization Server,
     often with the explicit approval of the authenticated User.  An Agent
     uses OAuth 2.0-based mechanisms to obtain authorization from a User,
     a System, or on its own behalf.  OAuth 2.0 defines a wide range of
     authorization grant flows that supports these scenarios.  In these
     Oauth 2.0 flows, an Agent acts as an OAuth 2.0 Client to an OAuth 2.0
     Authorization Server, which receives the request, evaluate the
     authorization policy and returns an access token, which the Agent
     presents to the Resource Server (i.e. the protected resources such as
     the LLM or Tools in Figure 1, which can evaluate its authorization
     policy and complete the request.

  10.2.  Use of OAuth 2.0 Access Tokens

     An OAuth access token represents the authorization granted to the
     Agent.  In many deployments, access tokens are structured as JSON Web
     Tokens (JWTs) [OAUTH-ACCESSTOKEN-JWT], which include claims such as
     'client_id', 'sub', 'aud', 'scope', and other attributes relevant to
     authorization.  The access token includes the Agent identity as the
     'client_id' claim as defined in Section 2.2 of
     [OAUTH-ACCESSTOKEN-JWT].

     When the Agent is acting on-behalf of another User or System, the
     User or System identifier is conveyed in the 'sub' claim as defined
     in Section 2.2 of [OAUTH-ACCESSTOKEN-JWT].  These identifiers MUST be
     used by resource servers protected by the OAuth 2.0 authorization
     service, along with other claims in the access token, to determine if
     access to a resource should be allowed.  The access token typically
     includes additional claims to convey contextual, attestation-derived,
     or policy-related information that enables fine-grained access
     control.  The resource server uses the access token and the
     information it contains along with other authorization systems (e.g.
     policy based, attribute based or role based authorization systems)
     when enforcing access control.  JWT access tokens can be validated
     directly by resource servers while other formats that are opaque to
     the resource server can be validated through a mechanism that calls
     back to the authorization server (the mechanism is called



  Kasselman, et al.       Expires 3 September 2026               [Page 13]


  Internet-Draft                   AI-Auth                      March 2026


     introspection despite the word having nearly the opposite meaning).
     This framework supports both models and does not require a specific
     token format, provided that equivalent authorization semantics are
     maintained.

     A resource server in receipt of tokens opaque to it are able to
     obtain authorization and other information from the token through
     OAuth 2.0 Token Introspection [OAUTH-TOKEN-INTROSPECTION].  The
     introspection response provides the active state of the token and
     associated authorization attributes equivalent to those conveyed in
     structured tokens.

  10.3.  Obtaining an OAuth 2.0 Access Token

     OAuth 2.0 defines a number authorization grant flows in support of
     different authorization scenarios.  The appropriate flow depends on
     the specific authorization scenario and the nature of User
     involvement.  The following subsections describe the most relevant
     flows for Agent authorization.

  10.3.1.  User Delegates Authorization

     When a User grants authorization to an Agent for access to one or
     more resources (Tools, LLMs, etc.), the Authorization Code Grant, as
     described in Section 4.1 of [OAUTH-FRAMEWORK], is the canonical means
     of obtaining an access token.  This redirection-based flow involves
     an interactive authorization process in which the user authenticates
     to the authorization server and explicitly approves the requested
     access.  The resulting access token reflects the authorization
     delegated to the Agent by the User and can be used by the Agent to
     access resources on behalf of the user.

  10.3.2.  Agent Obtains Own Authorization

     Agents obtaining access tokens on their own behalf can use the Client
     Credentials Grant as described in Section 4.4 of [OAUTH-FRAMEWORK] or
     the JWT Authorization Grant as described in Section 2.1 of
     [OAUTH-CLIENTAUTH-JWT].  When using the Client Credentials Grant, the
     Agent authenticates itself using one of the mechanisms described in
     Section 9 and not with the use of static, long-lived client secrets.
     When using the JWT Authorization Grant, the Agent will be identified
     in the subject of the JWT assertion.









  Kasselman, et al.       Expires 3 September 2026               [Page 14]


  Internet-Draft                   AI-Auth                      March 2026


  10.3.3.  Agents Accessed by Systems or Other Agents

     Agents themselves can act in the role of an OAuth protected resource
     and be invoked by a System (e.g. a batch job) or another Agent.  The
     System obtains an access token using an appropriate mechanism and
     then invokes the Agent presenting the access token.

  10.3.4.  OAuth 2.0 Security Best Practices

     The Best Current Practice for OAuth 2.0 Security as described in
     [OAUTH-BCP] are applicable when requesting and using access tokens.

  10.4.  Risk Reduction with Transaction Tokens

     Resources servers, whether they are LLMs, Tools or Agents (in the
     Agent-to-Agent case) may be composed of multiple microservices that
     are invoked to complete a request.  The access tokens presented to
     the Agent, LLM or Tools can typically be used with multiple
     transactions and consequently have broader scope than needed to
     complete any specific transaction.  Passing the access token from one
     microservice to another within an invoked Agent, LLM or the Tools
     increases the risk of token theft and replay attacks.  For example,
     an attacker may discover and access token passed between
     microservices in a log file or crash dump, exfiltrate it, and use it
     to invoke a new transaction with different parameters (e.g. increase
     the transaction amount, or invoke an unrelated call as part of
     executing a lateral move).

     To avoid passing access tokens between microservices, the Agent, LLM
     or Tools can exchange the received access token for a transaction
     token, as defined in the Transaction Token specification
     [OAUTH-TXN-TOKENS].  The transaction token allows for identity and
     authorization information to be passed along the internal call chain
     of microservices.  The transaction token issuer enriches the
     transaction token with context of the caller that presented the
     access token (e.g. IP address, etc.), transaction context
     (transaction amount), identity information and a unique transaction
     identifier.  This results in a downscoped token that is bound to a
     specific transaction and cannot be used as an access token, with
     another transaction, or within the same transaction with modified
     transaction details (e.g. change in transaction amount).  Transaction
     tokens are typically short-lived, further limiting the risk in case
     they are obtained by an attacker by limiting the time window during
     which these tokens will be accepted.

     A transaction token MAY be used to obtain an access token to call
     another service (e.g. another Agent, Tool or LLM) by using OAuth 2.0
     Token Exchange as defined in [OAUTH-TOKEN-EXCHANGE].



  Kasselman, et al.       Expires 3 September 2026               [Page 15]


  Internet-Draft                   AI-Auth                      March 2026


  10.5.  Cross Domain Access

     Agents often require access to resources that are protected by
     different OAuth 2.0 authorization servers.  When the components in
     Figure 1 are protected by different logical authorization servers, an
     Agent SHOULD use OAuth Identity and Authorization Chaining Across
     Domains as defined in ([OAUTH-ID-CHAIN]), or a derived specification
     such as the Identity Assertion JWT Authorization Grant
     [OAUTH-JWT-ASSERTION], to obtain an access token from the relevant
     authorization servers.

     When using OAuth Identity and Authorization Chaining Across Domains
     ([OAUTH-ID-CHAIN]), an Agent SHOULD use the access token or
     transaction token it received to obtain a JWT authorization grant as
     described in Section 2.3 of [OAUTH-ID-CHAIN] and then use the JWT
     authorization grant it receives to obtain an access token for the
     resource it is trying to access as defined in Section 2.4 of
     [OAUTH-ID-CHAIN].

     When using the Identity Assertion JWT Authorization Grant
     [OAUTH-JWT-ASSERTION], the identity assertion (e.g. the OpenID
     Connect ID Token or SAML assertion) for the target end-user is used
     to obtain a JWT assertion as described in Section 4.3 of
     [OAUTH-JWT-ASSERTION], which is then used to obtain an access token
     as described in Section 4.4 of [OAUTH-JWT-ASSERTION].

     OAuth Identity and Authorization Chaining Across Domains
     ([OAUTH-ID-CHAIN]) provides a general mechanism for obtaining cross-
     domain access that can be used whether an identity assertion like a
     SAML or OpenID Connect token is available or not.  The Identity
     Assertion JWT Authorization Grant [OAUTH-JWT-ASSERTION] is optimized
     for cases where an identity assertion like a SAML or OpenID Connect
     token is available from an identity provider that is trusted by all
     the OAuth authorization servers as it removes the need for the user
     to re-authenticate.  This is typically used within enterprise
     deployments to simplify authorization delegation for multiple
     software-as-a-service offerings.

  10.6.  Human in the Loop

     An OAuth authorization server MAY conclude that the level of access
     requested by an Agent requires explicit user confirmation.  In such
     cases the authorization server SHOULD either decline the request or
     obtain additional authorization from the User.  An Agent, acting as
     an OAuth client, may use the OpenID Client Initiated Backchannel
     Authentication (CIBA) protocol.  This triggers an out-of-band
     interaction allowing the user to approve or deny the requested
     operation without exposing credentials to the agent (for example a



  Kasselman, et al.       Expires 3 September 2026               [Page 16]


  Internet-Draft                   AI-Auth                      March 2026


     push notification requesting the user to approve a request through an
     authenticator application on their mobile device).

     Interactive agent frameworks may also solicit user confirmation
     directly during task execution (for example tool invocation approval
     or parameter confirmation).  Such interactions do not by themselves
     constitute authorization and MUST be bound to a verifiable
     authorization grant issued by the authorization server.  The agent
     SHOULD therefore translate user confirmation into an OAuth
     authorization event (e.g., step-up authorization via CIBA) before
     accessing protected resources.

     This model aligns with user-solicitation patterns such as those
     described by the Model Context Protocol ([MCP]), where an agent
     pauses execution and requests user confirmation before performing
     sensitive actions.  The final authorization decision remains with the
     authorization server, and the agent MUST NOT treat local UI
     confirmation alone as sufficient authorization.

     *Note:* Additional specification or design work may be needed to
     define how out-of-band interactions with the User occur at different
     stages of execution.  CIBA itself only accounts for client
     initiation, which doesn't map well to cases that envision the need
     for User confirmation to occur mid-execution.

  10.7.  Tool-to-Service Access

     Tools expose interfaces to underlying services and resources.  Access
     to the Tools can be controlled by OAuth and augmented by policy,
     attribute or role based authorization systems (amongst others).  If
     the Tools are implemented as one or more microservices, it should use
     transaction tokens to reduce risk as described in Section 10.4 to
     avoid passing access tokens around within the Tool implementation.

     Access from the Tools to the resources and services MAY be controlled
     through a variety of authorization mechanisms, including OAuth.  If
     access is controlled through OAuth, the Tools can use OAuth 2.0 Token
     Exchange as defined in [OAUTH-TOKEN-EXCHANGE] to exchange the access
     token it received for a new access token to access the resource or
     service in question.  When the Tool needs access to a resource
     protected by an authorization server other than the Tool's own
     authorization server, the OAuth Identity and Authorization Chaining
     Across Domains ([OAUTH-ID-CHAIN]) can be used to obtain an access
     token from the authorization server protecting that resource.

     *Note:* It is an anti-pattern for Tools to forward access tokens it
     received from the Agent to Services or Resources.  It increases the
     risk of credential theft and lateral attacks.



  Kasselman, et al.       Expires 3 September 2026               [Page 17]


  Internet-Draft                   AI-Auth                      March 2026


  10.8.  Privacy Considerations {privacy-considerations}

     Authorization tokens may contain user identifiers, agent identifiers,
     audience restrictions, transaction details, and contextual
     attributes.  Deployments SHOULD minimize disclosure of personally
     identifiable or sensitive information in tokens and prefer audience-
     restricted and short-lived tokens.  Where possible, opaque tokens
     with introspection SHOULD be preferred when claim minimization is
     required.

     Agents SHOULD request only the minimum scopes and authorization
     details necessary to complete a task.  Resource servers SHOULD avoid
     logging full tokens and instead log token identifiers or hashes.
     When authorization context is propagated across services, derived or
     down-scoped tokens (such as transaction tokens) SHOULD be used to
     reduce correlation and replay risk.

     Implementations MUST ensure that user identity information delegated
     to agents is not exposed to unrelated services and that cross-domain
     authorization exchanges only disclose information required for the
     target authorization decision.

  10.9.  OAuth 2.0 Discovery in Dynamic Environments

     In dynamic Agent deployments (e.g., ephemeral workloads, multi-tenant
     services, and frequently changing endpoint topology), Agents and
     other participants MAY use OAuth discovery mechanisms to reduce
     static configuration and to bind runtime decisions to verifiable
     metadata.

  10.9.1.  Authorization Server Capability Discovery

     An Agent that needs to obtain tokens can discover authorization
     server endpoints and capabilities using OAuth 2.0 Authorization
     Server Metadata [OAUTH-SERVER-METADATA] and/or OpenID Connect
     Discovery [OpenIDConnect.Discovery].  This allows the Agent to learn
     the authorization server issuer identifier, authorization and token
     endpoints, supported grant types, client authentication methods,
     signing keys (via jwks_uri), and other relevant capabilities without
     preconfiguring them.











  Kasselman, et al.       Expires 3 September 2026               [Page 18]


  Internet-Draft                   AI-Auth                      March 2026


  10.9.2.  Protected Resource Capability Discovery

     When an Agent is invoking a Tool, the Agent MAY use OAuth 2.0
     Protected Resource Metadata [OAUTH-RESOURCE-METADATA] to discover how
     the resource is protected, including the resource identifier and the
     applicable Authorization Server(s) that protects Tool access.  This
     enables an Agent to select the correct issuer/audience and token
     acquisition flow at runtime, even when resources are deployed or
     moved dynamically.

     A Tool that attempts to access and OAuth protected resource MAY use
     OAuth 2.0 Protected Resource Metadata [OAUTH-RESOURCE-METADATA] in a
     similar way as an Agent.  Similarly, a System may use
     [OAUTH-RESOURCE-METADATA] when accessing an Agent.

  10.9.3.  Client Capability Discovery

     Other actors (e.g., Authorization Servers, registrars, or policy
     systems) may need to learn about any entities (System, Agent, Tool)
     that acts as OAuth clients.  Where supported, they MAY use Client ID
     Metadata Documents [OAUTH-CLIENT-METADATA], which allow a client to
     host its metadata at a URL-valued client_id so that the relying party
     can retrieve client properties (e.g., redirect URIs, display
     information, and other registered client metadata) without prior
     bilateral registration.

     As an alternative, entities acting as OAuth clients MAY register
     their capabilities with authorization servers as defined in the OAuth
     2.0 Dynamic Client Registration Protocol [OAUTH-REGISTRATION].

  11.  Agent Monitoring, Observability and Remediation

     Because agents may perform sensitive actions autonomously or on
     behalf of users, deployments MUST maintain sufficient monitoring and
     observability to reconstruct agent behavior and authorization context
     after execution.  Observability is therefore a security control, not
     solely an operational feature.

     Any participant in the system, including the Agent, Tool, System, LLM
     or other resources and service MAY subscribe to change notifications
     using eventing mechanisms such as the OpenID Shared Signals Framework
     [SSF] with either the Continuous Access Evaluation Profile [CAEP] or
     Risk Incident Sharing and Coordination [RISC] to receive security and
     authorization-relevant signals.  Upon receipt of a relevant signal
     (e.g., session revoked, risk level change, subject disabled, token
     replay suspected, risk elevated), the recipient SHOULD remediate by
     attenuating access, such as terminating local sessions, discarding
     cached tokens, re-acquiring tokens with updated constraints, reducing



  Kasselman, et al.       Expires 3 September 2026               [Page 19]


  Internet-Draft                   AI-Auth                      March 2026


     privileges, or re-running policy evaluation before continuing to
     allow access.  Recipients of such signals MUST ensure that revoked or
     downgraded authorization is enforced without undue delay.  Cached
     authorization decisions and tokens that are no longer valid MUST NOT
     continue to be used after a revocation or risk notification is
     received.

     To support detection, investigation, and accountability, deployments
     MUST produce durable audit logs covering authorization decisions and
     subsequent remediations.  Audit records MUST be tamper-evident and
     retained according to the security policy of the deployment.

     At a minimum, audit events MUST record:

     *  authenticated agent identifier

     *  delegated subject (user or system), when present

     *  resource or tool being accessed

     *  action requested and authorization decision

     *  timestamp and transaction or request correlation identifier

     *  attestation or risk state influencing the decision

     *  remediation or revocation events and their cause

     Monitoring / Observability systems SHOULD correlate events across
     Agents, Tools, Services, Resources and LLMs to detect misuse patterns
     such as replay, confused deputy behavior, privilege escalation, or
     unexpected action sequences.

     End-to-end audit is enabled when Agents, Users, Systems, LLMs, Tools,
     services and resources have stable, verifiable identifiers that allow
     auditors to trace "which entity did what, using which authorization
     context, and why access changed over time."

     Implementations SHOULD provide operators the ability to reconstruct a
     complete execution chain of an agent task, including delegated
     authority, intermediate calls, and resulting actions across service
     boundaries.









  Kasselman, et al.       Expires 3 September 2026               [Page 20]


  Internet-Draft                   AI-Auth                      March 2026


  12.  Agent Authentication and Authorization Policy

     The configuration and runtime parameters for Agent Identifiers
     Section 5, Agent Credentials Section 6, Agent Attestation Section 7,
     Agent Credential Provisioning Section 8, Agent Authentication
     Section 9, Agent Authorization Section 10 and Agent Monitoring,
     Observability and Remediation Section 11 collectively constitute the
     authentication and authorization policy within which the Agent
     operates.

     Because these parameters are highly deployment and risk-model-
     specific (and often reflect local governance, regulatory, and
     operational constraints), the policy model and document format are
     out of scope for this framework and are not recommended as a target
     for standardization within this specification.  Implementations MAY
     represent policy in any suitable “policy-as-code” or configuration
     format (e.g., JSON/YAML), provided it is versioned, reviewable, and
     supports consistent evaluation across the components participating in
     the end-to-end flow.

  13.  Agent Compliance

     Compliance for Agent-based systems SHOULD be assessed by auditing
     observed behavior and recorded evidence (logs, signals, and
     authorization decisions) against the deployment’s Agent
     Authentication and Authorization Policy Section 12.  Since compliance
     criteria are specific to individual deployments, organizations,
     industries and jurisdictions, they are out of scope for this
     framework though implementers SHOULD ensure strong observability and
     accountable governance, subject to their specific business needs.

  14.  Security Considerations

     TODO Security

  15.  Privacy Considerations

     TODO Privacy but there's also Section 15...

  16.  IANA Considerations

     This document has no IANA actions.

  17.  Normative References

     [A2A]      "Agent2Agent (A2A) Protocol", n.d.,
                <https://github.com/a2aproject/A2A>.




  Kasselman, et al.       Expires 3 September 2026               [Page 21]


  Internet-Draft                   AI-Auth                      March 2026


     [ACP]      "Agentic Commerce Protocol", n.d.,
                <https://www.agenticcommerce.dev/docs>.

     [AP2]      "Agent Payments Protocol (AP2)", n.d.,
                <https://github.com/google-agentic-commerce/AP2>.

     [CAEP]     "OpenID Continuous Access Evaluation Profile 1.0", n.d.,
                <https://openid.net/specs/openid-caep-1_0-final.html>.

     [HTTP-SIG] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
                Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
                February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

     [MCP]      "Model Context Protocol", n.d.,
                <https://modelcontextprotocol.io/specification>.

     [OAUTH-ACCESSTOKEN-JWT]
                Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
                Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
                2021, <https://www.rfc-editor.org/rfc/rfc9068>.

     [OAUTH-BCP]
                Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
                "Best Current Practice for OAuth 2.0 Security", BCP 240,
                RFC 9700, DOI 10.17487/RFC9700, January 2025,
                <https://www.rfc-editor.org/rfc/rfc9700>.

     [OAUTH-CLIENT-METADATA]
                Parecki, A. and E. Smith, "OAuth Client ID Metadata
                Document", Work in Progress, Internet-Draft, draft-ietf-
                oauth-client-id-metadata-document-01, 1 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                client-id-metadata-document-01>.

     [OAUTH-CLIENTAUTH-JWT]
                Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
                (JWT) Profile for OAuth 2.0 Client Authentication and
                Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
                2015, <https://www.rfc-editor.org/rfc/rfc7523>.

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

     [OAUTH-ID-CHAIN]
                Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
                M. J., and B. Campbell, "OAuth Identity and Authorization



  Kasselman, et al.       Expires 3 September 2026               [Page 22]


  Internet-Draft                   AI-Auth                      March 2026


                Chaining Across Domains", Work in Progress, Internet-
                Draft, draft-ietf-oauth-identity-chaining-08, 9 February
                2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
                oauth-identity-chaining-08>.

     [OAUTH-JWT-ASSERTION]
                Parecki, A., McGuinness, K., and B. Campbell, "Identity
                Assertion JWT Authorization Grant", Work in Progress,
                Internet-Draft, draft-ietf-oauth-identity-assertion-authz-
                grant-01, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                identity-assertion-authz-grant-01>.

     [OAUTH-REGISTRATION]
                Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
                P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
                RFC 7591, DOI 10.17487/RFC7591, July 2015,
                <https://www.rfc-editor.org/rfc/rfc7591>.

     [OAUTH-RESOURCE-METADATA]
                Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
                Protected Resource Metadata", RFC 9728,
                DOI 10.17487/RFC9728, April 2025,
                <https://www.rfc-editor.org/rfc/rfc9728>.

     [OAUTH-SERVER-METADATA]
                Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8414>.

     [OAUTH-TOKEN-EXCHANGE]
                Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/rfc/rfc8693>.

     [OAUTH-TOKEN-INTROSPECTION]
                Richer, J., Ed., "OAuth 2.0 Token Introspection",
                RFC 7662, DOI 10.17487/RFC7662, October 2015,
                <https://www.rfc-editor.org/rfc/rfc7662>.

     [OAUTH-TXN-TOKENS]
                Tulshibagwale, A., Fletcher, G., and P. Kasselman,
                "Transaction Tokens", Work in Progress, Internet-Draft,
                draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                transaction-tokens-07>.



  Kasselman, et al.       Expires 3 September 2026               [Page 23]


  Internet-Draft                   AI-Auth                      March 2026


     [OpenIDConnect.AuthZEN]
                Gazitt, O., Ed., Brossard, D., Ed., and A. Tulshibagwale,
                Ed., "Authorization API 1.0", 2026,
                <https://openid.net/specs/authorization-api-1_0.html>.

     [OpenIDConnect.CIBA]
                "OpenID Connect Client-Initiated Backchannel
                Authentication Flow - Core 1.0", n.d.,
                <https://openid.net/specs/openid-client-initiated-
                backchannel-authentication-core-1_0.html>.

     [OpenIDConnect.Discovery]
                "OpenID Connect Discovery 1.0", n.d.,
                <https://openid.net/specs/openid-connect-discovery-
                1_0-final.html>.

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

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

     [RISC]     "OpenID Risk Incident Sharing and Coordination Profile
                1.0", n.d.,
                <https://openid.net/specs/openid-risc-1_0-final.html>.

     [SPIFFE]   "Secure Production Identity Framework for Everyone", n.d.,
                <https://spiffe.io/docs/latest/spiffe-about/overview/>.

     [SPIFFE-ID]
                "SPIFFE-ID", n.d.,
                <https://github.com/spiffe/spiffe/blob/main/standards/
                SPIFFE-ID.md>.

     [SSF]      "OpenID Shared Signals Framework Specification 1.0", n.d.,
                <https://openid.net/specs/openid-sharedsignals-framework-
                1_0-final.html>.

     [WIMSE-ARCH]
                Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
                "Workload Identity in a Multi System Environment (WIMSE)
                Architecture", Work in Progress, Internet-Draft, draft-
                ietf-wimse-arch-07, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                arch-07>.



  Kasselman, et al.       Expires 3 September 2026               [Page 24]


  Internet-Draft                   AI-Auth                      March 2026


     [WIMSE-CRED]
                Campbell, B., Salowey, J. A., Schwenkschuster, A.,
                Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
                Credentials", Work in Progress, Internet-Draft, draft-
                ietf-wimse-workload-creds-00, 3 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                workload-creds-00>.

     [WIMSE-HTTPSIG]
                Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload
                Authentication with HTTP Signatures", Work in Progress,
                Internet-Draft, draft-ietf-wimse-http-signature-02, 1
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                ietf-wimse-http-signature-02>.

     [WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
                Work in Progress, Internet-Draft, draft-ietf-wimse-
                identifier-01, 29 December 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                identifier-01>.

     [WIMSE-WPT]
                Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
                Token", Work in Progress, Internet-Draft, draft-ietf-
                wimse-wpt-00, 3 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                wpt-00>.

  Appendix A.  Acknowledgments

     The authors would like to thank Sean O'Dell for providing valuable
     input and feedback on this work.

  Authors' Addresses

     Pieter Kasselman
     Defakto Security
     Email: pieter@defakto.security


     Jean-François Lombardo
     AWS
     Email: jeffsec@amazon.com


     Yaroslav Rosomakho
     Zscaler
     Email: yrosomakho@zscaler.com



  Kasselman, et al.       Expires 3 September 2026               [Page 25]


  Internet-Draft                   AI-Auth                      March 2026


     Brian Campbell
     Ping Identity
     Email: bcampbell@pingidentity.com
















































  Kasselman, et al.       Expires 3 September 2026               [Page 26]


name: draft-nandakumar-ai-agent-moq-transport
rev: 00
title: MOQ Transport for Agent Protocols
time: 2026-03-02T20:43:37Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T20:43:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:04.986229+00:00
source: ietf
abstract:
  This document defines a protocol abstraction layer that enables Media
     over QUIC Transport (MOQT) to serve as a unified transport substrate
     for inter-agent communication protocols.  The abstraction provides a
     common mapping of request-response and streaming patterns onto MOQT's
     publish/subscribe model, allowing diverse agent protocols to leverage
     MOQT's real-time streaming capabilities, built-in prioritization, and
     efficient multiplexing over QUIC.

     The document demonstrates the application of this abstraction to two
     prominent inter-agent protocols: the Agent-to-Agent (A2A) protocol
     [A2A], which focuses on agent discovery, task delegation, and
     collaboration; and the Model Context Protocol (MCP) [MCP], which
     provides tool and resource access for agents.  This unified approach
     enables interoperability across diverse agent ecosystems while
     preserving each protocol's semantics.

full_text:
  Media Over QUIC                                            S. Nandakumar
  Internet-Draft                                                     Cisco
  Intended status: Standards Track                             C. Jennings
  Expires: 1 September 2026                                  Cisco Systems
                                                          28 February 2026


                     MOQ Transport for Agent Protocols
               draft-nandakumar-ai-agent-moq-transport-00

  Abstract

     This document defines a protocol abstraction layer that enables Media
     over QUIC Transport (MOQT) to serve as a unified transport substrate
     for inter-agent communication protocols.  The abstraction provides a
     common mapping of request-response and streaming patterns onto MOQT's
     publish/subscribe model, allowing diverse agent protocols to leverage
     MOQT's real-time streaming capabilities, built-in prioritization, and
     efficient multiplexing over QUIC.

     The document demonstrates the application of this abstraction to two
     prominent inter-agent protocols: the Agent-to-Agent (A2A) protocol
     [A2A], which focuses on agent discovery, task delegation, and
     collaboration; and the Model Context Protocol (MCP) [MCP], which
     provides tool and resource access for agents.  This unified approach
     enables interoperability across diverse agent ecosystems while
     preserving each protocol's semantics.

  About This Document

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

     The latest revision of this draft can be found at https://ietf-wg-
     moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-nandakumar-ai-agent-moq-
     transport/.

     Discussion of this document takes place on the Media Over QUIC
     Working Group mailing list (mailto:moq@ietf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/moq/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-wg-moq/draft-a2a-moqt-transport.

  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 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction
       1.1.  Requirements Language
     2.  Transport Requirements and Architecture
     3.  MOQT Transport Mapping
       3.1.  Connection Establishment
       3.2.  Track Organization
         3.2.1.  Namespace Structure
         3.2.2.  Track Categories
       3.3.  Message Serialization
       3.4.  Priority and Quality of Service
         3.4.1.  Group Order
       3.5.  Operation Patterns
         3.5.1.  Discovery
         3.5.2.  Request/Response
         3.5.3.  Streaming
     4.  Protocol Bindings
       4.1.  Binding Architecture
       4.2.  A2A Binding
         4.2.1.  Namespace Structure
         4.2.2.  Track Categories
         4.2.3.  A2A Operation Mapping
         4.2.4.  Message Format
         4.2.5.  Priority Mapping
         4.2.6.  Streaming Support
         4.2.7.  Agent Card Format
       4.3.  MCP Binding
       4.4.  AutoGen Binding
         4.4.1.  Namespace Structure
         4.4.2.  Track Categories
         4.4.3.  Message Format
         4.4.4.  Conversation Patterns
         4.4.5.  Priority Mapping
       4.5.  Generic JSON-RPC Binding
         4.5.1.  Namespace Structure
         4.5.2.  Track Categories
         4.5.3.  Message Format
         4.5.4.  Extension Mechanism
       4.6.  Multi-Agent Orchestration Patterns
     5.  Benefits of MOQT for A2A
     6.  MOQT Relay Infrastructure for A2A
       6.1.  Relay Network Architecture
       6.2.  Message Caching Benefits
     7.  Security Considerations
     8.  IANA Considerations
     9.  References
       9.1.  Normative References
       9.2.  Informative References
     Appendix A.  Acknowledgments
     Authors' Addresses

  1.  Introduction

     The AI agent ecosystem has evolved rapidly, with multiple protocols
     emerging for different aspects of agent communication:

     *  *Agent-to-Agent (A2A)* [A2A] focuses on agent discovery, task
        delegation, and collaboration across platforms

     *  *Model Context Protocol (MCP)* [MCP] provides tool and resource
        access for agents

     *  *Framework-specific protocols* (AutoGen, Semantic Kernel,
        LangGraph) define multi-agent orchestration patterns

     Each of these protocols typically defines its own transport bindings,
     leading to fragmentation and interoperability challenges across agent
     ecosystems.

     Media over QUIC Transport (MOQT) [MoQ-TRANSPORT] provides a publish/
     subscribe model over QUIC with hierarchical data organization.
     MOQT's streaming model, prioritization capabilities, efficient
     multiplexing, and relay-based architecture make it well-suited as a
     unified transport substrate for real-time agent
     communication—enabling scalable message distribution across agent
     networks.

     This document defines a protocol abstraction layer that maps common
     inter-agent communication patterns—request-response, streaming, and
     notifications—onto MOQT primitives.  The abstraction enables diverse
     agent protocols to leverage MOQT's capabilities while preserving
     their native semantics.

     The document then demonstrates this abstraction through concrete
     bindings for two prominent protocols: A2A (which supports JSON-RPC
     2.0 over HTTP(S), gRPC, and HTTP+JSON/REST) and MCP.  These serve as
     reference implementations that other inter-agent protocols can
     follow.

  1.1.  Requirements Language

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

  2.  Transport Requirements and Architecture

     According to the A2A specification, all transport protocols MUST
     provide functional equivalence and support the following
     capabilities:

     *  Secure communication over encrypted channels

     *  Request/response messaging patterns

     *  Streaming data delivery capabilities

     *  Error handling and status reporting

     *  Agent discovery and capability negotiation

     *  Support for various data types (text, JSON, files)

     Figure 1 illustrates how this document layers agent protocols over
     the MOQT transport substrate.

        Agent Protocol Layer
        ┌─────────────────────────────────────────────────────────────┐
        │      A2A          │      MCP         │    Other Protocols   │
        │  ┌─────────────┐  │  ┌─────────────┐ │  ┌─────────────────┐ │
        │  │ Task Collab │  │  │ Tool Access │ │  │ AutoGen/Custom  │ │
        │  │ Discovery   │  │  │ Resources   │ │  │ Orchestration   │ │
        │  └─────────────┘  │  └─────────────┘ │  └─────────────────┘ │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │              Protocol Abstraction Layer                     │
        │    Namespace Mapping │ Message Serialization │ Priority     │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    MOQT Transport Layer                     │
        │  ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
        │  │ PUBLISH/     │ │ SUBSCRIBE/   │ │ Object Streaming     │ │
        │  │ PUBLISH_NS   │ │ SUBSCRIBE_NS │ │ Groups & Priority    │ │
        │  └──────────────┘ └──────────────┘ └──────────────────────┘ │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    QUIC/WebTransport                        │
        │   ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
        │   │ Encryption  │  │ Multiplexing│  │ Connection          │ │
        │   │ (TLS 1.3)   │  │ & Flow Ctrl │  │ Migration           │ │
        │   └─────────────┘  └─────────────┘  └─────────────────────┘ │
        └─────────────────────────────────────────────────────────────┘

                    Figure 1: Protocol Layering Architecture

  3.  MOQT Transport Mapping

  3.1.  Connection Establishment

     Agents using MOQT transport MUST establish either a native QUIC
     connection or a WebTransport session as defined in [MoQ-TRANSPORT].
     For native QUIC connections, agents MUST use the ALPN value "moqt".
     For WebTransport, the protocol is negotiated using the "WT-Available-
     Protocols" mechanism as specified in [MoQ-TRANSPORT].  The connection
     setup follows this sequence:

     Agent A                                                   Agent B
        |                                                        |
        |──── QUIC/WebTransport Connection ─────────────────────▶|
        |◄─── Connection Established ────────────────────────────|
        |                                                        |
        |──── MOQT CLIENT_SETUP ────────────────────────────────▶|
        |◄─── MOQT SERVER_SETUP ─────────────────────────────────|
        |                                                        |
        |──── PUBLISH_NAMESPACE (discovery) ────────────────────▶|
        |◄─── PUBLISH_NAMESPACE (discovery) ─────────────────────|
        |                                                        |
        |──── Capability Card Exchange ───────────────────────────▶|
        |◄─── Capability Card Exchange ──────────────────────────|
        |                                                        |
        |◄═══ Protocol Message Exchange ════════════════════════▶|

     During the MOQT setup phase, agents MUST negotiate the following
     setup parameters as MOQT extensions:

     *  agent-version (0x41475631): Supported agent protocol version
        string

     *  agent-protocols (0x41475032): Bitmask of supported agent protocols
        (A2A=0x01, MCP=0x02)

     *  agent-auth-schemes (0x41475033): Supported authentication schemes

  3.2.  Track Organization

     Agent protocol messages are mapped to MOQT tracks using a
     hierarchical namespace structure as defined in [MoQ-TRANSPORT].  MOQT
     namespaces consist of 1-32 ordered tuple fields, enabling relays to
     route based on hierarchical prefixes.

  3.2.1.  Namespace Structure

     Agent protocols over MOQT use a hierarchical namespace structure that
     enables relay routing and protocol multiplexing.  The general pattern
     is:

     Full Track Name Structure:

     Track Namespace (tuple fields):
     ┌──────────┬──────────┬────────────┬──────────────┐
     │ Field 1  │ Field 2  │  Field 3   │   Field 4    │
     │ protocol │ session  │  agent-id  │   category   │
     └──────────┴──────────┴────────────┴──────────────┘

     Track Name:
     ┌────────────────────────────────────────────────┐
     │              action or identifier              │
     └────────────────────────────────────────────────┘

     Example Full Track Names:
       {proto} / session-123 / agent-alice / request -- req-001
       {proto} / session-123 / agent-bob / discovery -- agent-card
       {proto} / session-123 / agent-alice / stream -- task-456

     The first namespace field identifies the protocol binding (e.g.,
     "a2a", "mcp", "autogen") enabling multiple protocols to coexist on
     shared relay infrastructure.  Protocol-specific namespace structures
     are defined in their respective binding sections (Section 4.2,
     Section 4.3).

  3.2.2.  Track Categories

     Agent protocols typically organize communication into the following
     logical track categories.  Protocol bindings define specific
     namespace patterns for each category.

     Request Tracks:  Used for outbound request messages.  Track name
        typically contains a request identifier for correlation.

     Response Tracks:  Used for response messages.  Track name contains
        the correlated request identifier.

     Resource/State Tracks:  Used for resource access or state
        synchronization.  Track name identifies the specific resource or
        state key.

     Notification Tracks:  Used for push notifications and asynchronous
        events.

     Discovery Tracks:  Used for agent/service discovery and capability
        exchange.

     Protocol-specific track categories and namespace patterns are defined
     in their respective binding sections.

  3.3.  Message Serialization

     Agent protocol messages are serialized and encapsulated within MOQT
     objects.  The serialization format is protocol-specific, but most
     agent protocols use JSON or JSON-RPC 2.0.  Each MOQT object contains:

     MOQT Object Structure:

     ┌─────────────────────────────────────────────────────────┐
     │                 MOQT Object Header                      │
     │  Track ID │ Group ID │ Object ID │ Priority │ ....      │
     └─────────────────────────────────────────────────────────┘
     ┌─────────────────────────────────────────────────────────┐
     │                 Protocol Message Payload                │
     │  ┌─────────────────────────────────────────────────────┐│
     │  │         Serialized Protocol Message                 ││
     │  │  (JSON, JSON-RPC 2.0, or protocol-specific format)  ││
     │  └─────────────────────────────────────────────────────┘│
     └─────────────────────────────────────────────────────────┘

     Protocol bindings specify the exact serialization format and any
     required message envelope structure.  Bindings SHOULD preserve native
     message formats where possible to maintain compatibility with
     existing protocol implementations.

  3.4.  Priority and Quality of Service

     MOQT uses a 0-255 priority scale where lower values indicate higher
     priority.  Protocol bindings map their message types to MOQT
     Publisher Priority ranges.  The following general priority tiers are
     recommended:

     +==================+===============+===============================+
     | Message Category | MOQT Priority | Description                   |
     +==================+===============+===============================+
     | Critical/Cancel  | 0-31          | Critical errors,              |
     |                  |               | cancellations, urgent control |
     +------------------+---------------+-------------------------------+
     | Interactive      | 32-63         | Responses requiring immediate |
     | Response         |               | delivery                      |
     +------------------+---------------+-------------------------------+
     | Standard Request | 64-95         | Normal request/response       |
     |                  |               | messages                      |
     +------------------+---------------+-------------------------------+
     | Streaming        | 96-127        | Incremental status and data   |
     | Updates          |               | updates                       |
     +------------------+---------------+-------------------------------+
     | Discovery        | 128-159       | Service/agent discovery and   |
     |                  |               | capability exchange           |
     +------------------+---------------+-------------------------------+
     | Background       | 160-191       | Non-critical notifications,   |
     |                  |               | telemetry                     |
     +------------------+---------------+-------------------------------+
     | Bulk Transfer    | 192-255       | Large file transfers, batch   |
     |                  |               | operations                    |
     +------------------+---------------+-------------------------------+

                                   Table 1

     Protocol bindings SHOULD define specific mappings from their message
     types to these priority ranges.  See Section 4.2 and Section 4.3 for
     protocol-specific priority assignments.

  3.4.1.  Group Order

     For streaming operations, MOQT Group Order determines whether groups
     are delivered in ascending (oldest first) or descending (newest
     first) order:

     *  Sequential processing streams: Ascending order (preserve execution
        sequence)

     *  Live notifications: Descending order (prioritize recent events)

     *  Ordered data transfers: Ascending order (sequential chunk
        delivery)

  3.5.  Operation Patterns

     This section defines common operation patterns that protocol bindings
     use to implement agent communication over MOQT.

  3.5.1.  Discovery

     Agent discovery over MOQT leverages the SUBSCRIBE_NAMESPACE and
     PUBLISH_NAMESPACE mechanisms defined in [MoQ-TRANSPORT] for efficient
     in-band discovery of agents within a session context.

     Agents use PUBLISH_NAMESPACE to advertise their presence and
     SUBSCRIBE_NAMESPACE to discover other agents:

     Discovery Flow Using Namespace Operations:

     Agent A                       MOQT Relay                      Agent B
        |                              |                             |
        |─ SUBSCRIBE_NAMESPACE────────▶|                             |
        |  ({proto}/{session}/discovery)|                            |
        |                              |◄─ SUBSCRIBE_NAMESPACE───────┤
        |                              |  ({proto}/{session}/discovery)|
        |                              |                             |
        |─ PUBLISH_NAMESPACE──────────▶|                             |
        |  ({proto}/{session}/discovery/|                            |
        |   agent-a)                   |                             |
        |                              |─ NAMESPACE ────────────────▶|
        |                              |  (agent-a available)        |
        |                              |                             |
        |                              |◄─ PUBLISH_NAMESPACE─────────┤
        |                              |  ({proto}/{session}/discovery/|
        |                              |   agent-b)                  |
        |◄─ NAMESPACE ─────────────────|                             |
        |  (agent-b available)         |                             |
        |                              |                             |
        |─ SUBSCRIBE ─────────────────▶|─ SUBSCRIBE ────────────────▶|
        |  (agent-b/discovery)         |  (agent-b/discovery)        |
        |◄─ OBJECT(Capability Card) ───|◄─ OBJECT(Capability Card) ──|

     Each agent publishes a capability card containing its identity,
     capabilities, and supported operations.  The card serves as the
     discovery mechanism through which agents advertise their presence and
     abilities to potential collaborators.  The card is published as an
     MOQT object on the agent's discovery track.

     A capability card typically includes:

     *  *Identity*: Name, description, and endpoint URL

     *  *Capabilities*: Supported features such as streaming or
        notifications

     *  *Authentication*: Supported authentication schemes

     *  *MOQT Extension*: Transport-specific configuration for MOQT
        connectivity

     Protocol-specific card formats are defined in their respective
     binding sections (e.g., A2A Agent Card in Section 4.2.7).

  3.5.2.  Request/Response

     Request/response interactions between agents are implemented using
     coordinated PUBLISH_NAMESPACE, SUBSCRIBE_NAMESPACE, and object
     delivery.  This pattern enables agents to exchange messages through
     MOQT relays without requiring direct connectivity.

     The following table describes how common agent communication patterns
     map to MOQT primitives:

       +==============+=====================+==========================+
       | Operation    | MOQT Mechanism      | Description              |
       | Pattern      |                     |                          |
       +==============+=====================+==========================+
       | One-shot     | PUBLISH + OBJECT    | Single request published |
       | request      |                     | to a track               |
       +--------------+---------------------+--------------------------+
       | Streaming    | PUBLISH + multiple  | Request with incremental |
       | request      | OBJECTs             | data across objects      |
       +--------------+---------------------+--------------------------+
       | Resource     | SUBSCRIBE + OBJECT  | Subscribe to retrieve a  |
       | fetch        |                     | specific resource        |
       +--------------+---------------------+--------------------------+
       | Resource     | SUBSCRIBE_NAMESPACE | Discover available       |
       | listing      |                     | resources via namespace  |
       +--------------+---------------------+--------------------------+
       | Cancellation | OBJECT on control   | Cancel signal published  |
       |              | track               | to control track         |
       +--------------+---------------------+--------------------------+
       | Subscription | SUBSCRIBE (ongoing) | Long-lived subscription  |
       |              |                     | for updates              |
       +--------------+---------------------+--------------------------+

                                    Table 2

     Protocol-specific operation mappings are defined in their respective
     binding sections.

     The following diagram illustrates the message flow for a typical
     request/response interaction between a client agent and a server
     agent through an MOQT relay.  The server agent first publishes its
     namespace to advertise availability.  The client discovers the server
     via namespace subscription, then publishes a request and subscribes
     to the corresponding response track.  The server processes the
     request and publishes the response, which the relay forwards to the
     subscribed client.

     Request/Response Flow:

     Client Agent                MOQT Relay               Server Agent
          |                           |                        |
          |                           |◄── PUBLISH_NAMESPACE ──|
          |                           |  ({proto}/{s}/{server})|
          |                           |                        |
          |── SUBSCRIBE_NAMESPACE ───▶|                        |
          |  ({proto}/{s}/{server})   |                        |
          |◄── NAMESPACE ─────────────|                        |
          |   (tracks available)      |                        |
          |                           |                        |
          |── PUBLISH ───────────────▶|── PUBLISH ────────────▶|
          |   ({server}/request)      |   ({server}/request)   |
          |                           |                        |
          |── SUBSCRIBE ─────────────▶|                        |
          |   ({server}/response/     |                        |
          |    {req-id})              |                        |
          |                           |                        |
          |── OBJECT ────────────────▶|── OBJECT ─────────────▶|
          |   (Request Message)       |   (forwarded)          |
          |                           |                        |
          |                           |◄── PUBLISH ────────────|
          |                           |   ({server}/response)  |
          |                           |                        |
          |                           |◄── OBJECT ─────────────|
          |◄── OBJECT ────────────────|   (Response Message)   |
          |   (Response Message)      |                        |

     Request-response correlation uses message IDs embedded in the
     protocol payload (e.g., JSON-RPC id field).  Both request and
     response track names include the request-specific ID to enable
     efficient subscription filtering and correlation.

  3.5.3.  Streaming

     Long-running operations like task execution or file transfer utilize
     MOQT's streaming capabilities.  Stream tracks carry incremental
     updates as separate MOQT objects organized into groups.

     Streaming leverages MOQT's object model to deliver incremental
     updates.  The client subscribes to an operation-specific track and
     receives a sequence of events as the server executes the operation.
     Each event is published as an MOQT object, organized into groups that
     represent logical phases of execution.

     Protocol bindings define specific event types for their streaming
     operations.  Common patterns include:

     Status Events:  Published when operation state changes.  Contains
        operation ID, current state, and optional status message.

     Data Events:  Published when operation produces output.  Contains
        result data with incremental or complete delivery.

     The following diagram illustrates a generic streaming flow.  The
     client subscribes to the operation track.  As the server executes, it
     publishes status and data updates as MOQT objects.  Objects are
     organized into groups representing execution phases.  The relay
     forwards each object to the subscribed client in real-time.

     Streaming Operation Flow:

     Client                     MOQT Relay                   Server
       |                           |                           |
       |── SUBSCRIBE ─────────────▶|                           |
       |   ({operation-track})     |── SUBSCRIBE ─────────────▶|
       |                           |                           |
       |                           |     [Group 0: Initialization]
       |                           |◄── Object 0 ──────────────|
       |◄── Status Event ──────────|   (state: "running")      |
       |                           |                           |
       |                           |     [Group 1: Progress]
       |                           |◄── Object 0 ──────────────|
       |◄── Data Event ────────────|   (partial result)        |
       |                           |                           |
       |                           |◄── Object 1 ──────────────|
       |◄── Data Event ────────────|   (more content)          |
       |                           |                           |
       |                           |     [Group 2: Completion]
       |                           |◄── Object 0 ──────────────|
       |◄── Data Event ────────────|   (final result)          |
       |                           |                           |
       |                           |◄── Object 1 ──────────────|
       |◄── Status Event ──────────|   (state: "completed")    |
       |                           |                           |
       |── UNSUBSCRIBE ───────────▶|── UNSUBSCRIBE ───────────▶|

     Groups serve as synchronization points within the stream.  The server
     advances to a new group when transitioning between execution phases,
     allowing clients to identify and process related updates together.

  3.5.3.1.  Late Joining and Caching

     MOQT groups serve as join points for late-arriving subscribers.
     Relays MAY cache recent groups to enable:

     *  Clients joining mid-stream receive the latest group

     *  Recovery from transient disconnections

     *  Efficient replay of recent operation history

  4.  Protocol Bindings

     To enable MOQT as a unified transport for multiple agent
     communication protocols, this document defines protocol bindings that
     map protocol-specific semantics to the transport patterns defined in
     Section 3.

  4.1.  Binding Architecture

  ┌─────────────────────────────────────────────────────────────────────┐
  │                    Agent Applications                                │
  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐ │
  │  │ A2A Agent   │  │ MCP Host    │  │ AutoGen     │  │ Custom      │ │
  │  │             │  │             │  │ Agent       │  │ Agent       │ │
  │  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘ │
  └─────────┼────────────────┼────────────────┼────────────────┼────────┘
            │                │                │                │
  ┌─────────▼────────────────▼────────────────▼────────────────▼────────┐
  │                 Protocol Binding Layer                               │
  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐ │
  │  │ A2A Binding │  │ MCP Binding │  │ AutoGen     │  │ Generic     │ │
  │  │             │  │             │  │ Binding     │  │ JSON-RPC    │ │
  │  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘ │
  └─────────┼────────────────┼────────────────┼────────────────┼────────┘
            │                │                │                │
  ┌─────────▼────────────────▼────────────────▼────────────────▼────────┐
  │                    MOQT Transport Layer                              │
  │         Namespace Management | Pub/Sub | Streaming | QoS             │
  └─────────────────────────────────────────────────────────────────────┘
                                  │
  ┌───────────────────────────────▼─────────────────────────────────────┐
  │                    QUIC / WebTransport                               │
  └─────────────────────────────────────────────────────────────────────┘

     Each protocol binding provides the following elements for MOQT
     integration:

     *  *Protocol Identifier*: A unique string identifying the protocol
        (e.g., "a2a", "mcp", "autogen") used to distinguish bindings.

     *  *Version*: The protocol version supported by the binding, enabling
        version negotiation and compatibility detection.

     *  *Namespace Prefix*: A tuple of strings forming the root namespace
        for the protocol's tracks, enabling namespace partitioning across
        different protocols on shared infrastructure.

     *  *Message Serialization*: Methods to convert protocol messages to
        bytes for MOQT object payloads and to parse received bytes back
        into protocol messages.

     *  *Track Mapping*: Logic to map protocol operations to appropriate
        MOQT track names, determining which track should carry each
        message type.

     *  *Priority Mapping*: Rules to assign MOQT publisher priorities
        based on message types, ensuring appropriate quality of service
        for different operations.

     *  *Namespace Event Handling*: Callbacks for processing MOQT
        namespace events such as ANNOUNCE and SUBSCRIBE_NAMESPACE,
        enabling protocol- specific discovery and subscription management.

     Different protocols use distinct namespace prefixes to enable
     coexistence on shared MOQT infrastructure:

      +========+=============================+==================+=======+
      |Protocol| Namespace Prefix            | Example          |Example|
      |        |                             | Namespace        |Track  |
      |        |                             |                  |Name   |
      +========+=============================+==================+=======+
      |A2A     | a2a/{session}/{agent}       | a2a/s1/agent-a/  |t1     |
      |        |                             | task             |       |
      +--------+-----------------------------+------------------+-------+
      |MCP     | mcp/{session}/{server}      | mcp/s1/fs-       |read   |
      |        |                             | server/tools     |       |
      +--------+-----------------------------+------------------+-------+
      |AutoGen | autogen/{session}/{runtime} | autogen/s1/rt1/  |msg    |
      |        |                             | agent            |       |
      +--------+-----------------------------+------------------+-------+
      |Generic | agent/{session}/{id}        | agent/s1/custom/ |call   |
      |        |                             | rpc              |       |
      +--------+-----------------------------+------------------+-------+

                                    Table 3

  4.2.  A2A Binding

     The Agent-to-Agent Protocol [A2A] binding maps A2A's task delegation
     and collaboration semantics to MOQT primitives using the patterns
     defined in Section 3.

  4.2.1.  Namespace Structure

     A2A uses the a2a namespace prefix with the following hierarchy:

     a2a/{session-id}/{agent-id}/{category}

     Where:

     *  session-id: Unique identifier for the collaboration session

     *  agent-id: Unique identifier for the publishing agent

     *  category: Message category (request, response, task, notify,
        discovery)

  4.2.2.  Track Categories

           +===========+====================+=====================+
           | Category  | Purpose            | Track Name Pattern  |
           +===========+====================+=====================+
           | request   | Outbound requests  | {request-id}        |
           +-----------+--------------------+---------------------+
           | response  | Request responses  | {request-id}        |
           +-----------+--------------------+---------------------+
           | task      | Task lifecycle     | {task-id}           |
           +-----------+--------------------+---------------------+
           | notify    | Push notifications | {notification-type} |
           +-----------+--------------------+---------------------+
           | discovery | Agent cards        | agent-card          |
           +-----------+--------------------+---------------------+

                                   Table 4

  4.2.3.  A2A Operation Mapping

     The following table maps A2A v0.3.0 operations to MOQT primitives.
     The Generic Pattern column references patterns from Section 3.5.2.

     +====================+===================+=================+============+
     |A2A Operation       |MOQT Mechanism     |Track Pattern    |Generic     |
     |                    |                   |                 |Pattern     |
     +====================+===================+=================+============+
     |SendMessage         |PUBLISH + OBJECT   |{agent}/request  |One-shot    |
     |                    |                   |-- {req-id}      |request     |
     +--------------------+-------------------+-----------------+------------+
     |SendStreamingMessage|PUBLISH + multiple |{agent}/stream --|Streaming   |
     |                    |OBJECTs            |{req-id}         |request     |
     +--------------------+-------------------+-----------------+------------+
     |GetTask             |SUBSCRIBE + OBJECT |{agent}/task --  |Resource    |
     |                    |fetch              |{task-id}        |fetch       |
     +--------------------+-------------------+-----------------+------------+
     |ListTasks           |SUBSCRIBE_NAMESPACE|{agent}/task     |Resource    |
     |                    |                   |                 |listing     |
     +--------------------+-------------------+-----------------+------------+
     |CancelTask          |OBJECT on request  |{agent}/request  |Cancellation|
     |                    |track              |-- cancel-{task- |            |
     |                    |                   |id}              |            |
     +--------------------+-------------------+-----------------+------------+
     |SubscribeToTask     |SUBSCRIBE (ongoing)|{agent}/task --  |Subscription|
     |                    |                   |{task-id}        |            |
     +--------------------+-------------------+-----------------+------------+
     |GetExtendedAgentCard|SUBSCRIBE + OBJECT |{agent}/discovery|Resource    |
     |                    |                   |-- agent-card    |fetch       |
     +--------------------+-------------------+-----------------+------------+

                                    Table 5

  4.2.4.  Message Format

     A2A messages are serialized as JSON-RPC 2.0 payloads within MOQT
     objects.  The binding preserves A2A's native message format without
     transformation.

  4.2.5.  Priority Mapping

                +======================+=====================+
                | A2A Message Type     | MOQT Priority Range |
                +======================+=====================+
                | Cancel/Error         | 0-31                |
                +----------------------+---------------------+
                | SendMessage response | 32-63               |
                +----------------------+---------------------+
                | SendMessage request  | 64-95               |
                +----------------------+---------------------+
                | Task updates         | 96-127              |
                +----------------------+---------------------+
                | Discovery            | 128-159             |
                +----------------------+---------------------+
                | Background           | 160-255             |
                +----------------------+---------------------+

                                   Table 6

  4.2.6.  Streaming Support

     A2A streaming operations (SendStreamingMessage, task subscriptions)
     map to MOQT groups and objects following the pattern in
     Section 3.5.3.

     A2A defines two streaming event types:

     TaskStatusUpdateEvent:  Published when task state changes.  Contains
        task ID, current state (queued, running, completed, failed,
        canceled), and optional message.

     TaskArtifactUpdateEvent:  Published when task produces output.
        Contains artifact data (text, files, structured data) with
        incremental or complete delivery.

     The mapping to MOQT objects:

     *  Each streaming response creates a new MOQT group

     *  Incremental updates are individual objects within the group

     *  TaskStatusUpdateEvent and TaskArtifactUpdateEvent map to objects

     *  Groups represent execution phases (initialization, progress,
        completion)

  4.2.7.  Agent Card Format

     Per A2A v0.3.0, each agent publishes an Agent Card containing
     identity, capabilities, and supported operations.  The A2A Agent Card
     extends the generic agent card structure with A2A-specific fields:

     {
       "name": "example-agent",
       "description": "An example A2A agent",
       "url": "https://example.com/agent",
       "protocolVersion": "0.3.0",
       "capabilities": {
         "streaming": true,
         "pushNotifications": true
       },
       "skills": [],
       "authentication": {
         "schemes": ["bearer", "oauth2"]
       },
       "moqt": {
         "namespace": "a2a/session-123/agent-example",
         "relayEndpoint": "moqt://relay.example.com:4443",
         "supportedExtensions": ["a2a-version", "a2a-protocols"]
       },
       "signature": "base64-encoded-signature"
     }

     The A2A-specific fields include:

     *  protocolVersion: The A2A protocol version supported (e.g.,
        "0.3.0")

     *  capabilities: A2A capability flags including streaming and
        pushNotifications

     *  skills: Array of skill definitions the agent can perform

     *  signature: Optional cryptographic signature for card verification

     The moqt extension provides MOQT transport configuration with the A2A
     namespace prefix.

  4.3.  MCP Binding

     The Model Context Protocol [MCP] can be transported over MOQT to
     enable tool and resource access for agents.  The complete
     specification for MCP over MOQT is defined in [MCP-MOQT].

     [MCP-MOQT] defines dedicated MOQT tracks for each MCP primitive:
     control tracks for session management and capability negotiation,
     resource tracks for server-published content delivery, tool tracks
     for invocation requests and responses, prompt tracks for template
     distribution, and notification tracks for asynchronous events
     (Section 3).  The specification covers protocol operations including
     session establishment, priority management for ensuring critical
     operations receive sufficient bandwidth, and comprehensive error
     handling (Section 4).

     A key contribution of [MCP-MOQT] is the Agent Skills architecture
     (Section 6), which extends AI capabilities beyond atomic tool
     operations.  Skills provide composed instructions for complex tasks
     and use progressive loading (metadata, instructions, resources) that
     aligns naturally with MOQT's object-based delivery, enabling
     efficient bandwidth utilization and aggressive caching.  The
     specification also describes relay support (Section 5) for scalable
     MCP deployments, including subscription aggregation where multiple
     client subscriptions are consolidated into single upstream requests,
     and content caching strategies optimized for AI workflows.

  4.4.  AutoGen Binding

     AutoGen [AutoGen] is a multi-agent conversation framework that
     enables complex LLM applications through agent collaboration.  This
     binding defines how AutoGen's conversation patterns map to MOQT.

  4.4.1.  Namespace Structure

     AutoGen uses the autogen namespace prefix:

     autogen/{session-id}/{runtime-id}/{agent-name}

     Where:

     *  session-id: Unique identifier for the AutoGen session

     *  runtime-id: Identifier for the AutoGen runtime instance

     *  agent-name: Name of the AutoGen agent

  4.4.2.  Track Categories

           +==========+======================+====================+
           | Category | Purpose              | Track Name Pattern |
           +==========+======================+====================+
           | message  | Inter-agent messages | {conversation-id}  |
           +----------+----------------------+--------------------+
           | control  | Runtime control      | {command}          |
           +----------+----------------------+--------------------+
           | state    | Agent state sync     | {state-key}        |
           +----------+----------------------+--------------------+
           | result   | Final outputs        | {task-id}          |
           +----------+----------------------+--------------------+

                                   Table 7

  4.4.3.  Message Format

     AutoGen messages are serialized as JSON with the following structure:

     {
       "sender": "agent-name",
       "recipient": "agent-name | broadcast",
       "content": "message content or structured data",
       "metadata": {
         "conversation_id": "conv-123",
         "turn": 5,
         "role": "assistant | user | system"
       }
     }

  4.4.4.  Conversation Patterns

     AutoGen's conversation patterns map to MOQT as follows:

     Two-Agent Chat:  Each agent publishes to their message track.  Agents
        subscribe to their conversation partner's track.

     Group Chat:  A coordinator agent manages turn-taking.  All agents
        subscribe to the coordinator's broadcast track.

     Nested Chat:  Hierarchical namespaces enable nested conversations:
        autogen/{session}/runtime-1/outer-agent/inner-runtime/inner-agent

  4.4.5.  Priority Mapping

                +======================+=====================+
                | AutoGen Message Type | MOQT Priority Range |
                +======================+=====================+
                | Termination signals  | 0-31                |
                +----------------------+---------------------+
                | Human input requests | 32-63               |
                +----------------------+---------------------+
                | Agent responses      | 64-95               |
                +----------------------+---------------------+
                | Function results     | 96-127              |
                +----------------------+---------------------+
                | State updates        | 128-159             |
                +----------------------+---------------------+
                | Logging/debug        | 160-255             |
                +----------------------+---------------------+

                                   Table 8

  4.5.  Generic JSON-RPC Binding

     This binding provides a minimal baseline for custom agent protocols
     that use JSON-RPC 2.0 messaging.  It serves as an extensible
     foundation for protocols not covered by specific bindings.

  4.5.1.  Namespace Structure

     Generic protocols use the agent namespace prefix:

     agent/{session-id}/{agent-id}/{protocol-name}

     Where:

     *  session-id: Unique session identifier

     *  agent-id: Unique agent identifier

     *  protocol-name: Custom protocol identifier

  4.5.2.  Track Categories

             +==========+==================+====================+
             | Category | Purpose          | Track Name Pattern |
             +==========+==================+====================+
             | rpc      | Request/response | {request-id}       |
             +----------+------------------+--------------------+
             | stream   | Streaming data   | {stream-id}        |
             +----------+------------------+--------------------+
             | event    | Async events     | {event-type}       |
             +----------+------------------+--------------------+

                                   Table 9

  4.5.3.  Message Format

     Messages follow standard JSON-RPC 2.0:

     {
       "jsonrpc": "2.0",
       "method": "protocol.method",
       "params": {},
       "id": "request-id"
     }

  4.5.4.  Extension Mechanism

     Custom protocols can extend this binding by:

     1.  Defining additional track categories

     2.  Specifying custom message schemas within the JSON-RPC params

     3.  Registering protocol-specific priorities

     4.  Adding custom metadata in MOQT extension headers

     Implementations SHOULD document their extensions and MAY register
     them in the IANA Protocol Bindings Registry.

  4.6.  Multi-Agent Orchestration Patterns

     The abstraction layer supports common multi-agent coordination
     patterns:

     TODO: Discuss each of the following patterns:

     *  Sequential Orchestration

     *  Concurrent (Broadcast) Pattern

     *  Handoff Pattern

     *  Hierarchical Teams

  5.  Benefits of MOQT for A2A

     MOQT provides significant advantages over traditional A2A transports,
     particularly for real-time agent collaboration and large-scale
     deployments.

     +===========+=============+==========+==========+===================+
     |Feature    | HTTP/JSON-  |gRPC      |REST      |MOQT               |
     |           | RPC         |          |          |                   |
     +===========+=============+==========+==========+===================+
     |Pub/Sub    | No          |Limited   |No        |Yes                |
     |Native     |             |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Multi-party| Polling     |N/A       |Polling   |Native             |
     |Broadcast  |             |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Relay/CDN  | Separate    |N/A       |CDN       |Built-in           |
     |Support    | infra       |          |possible  |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Priority   | Application |Per-stream|None      |Per-object (0-255) |
     |QoS        | layer       |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Connection | No          |Limited   |No        |QUIC native        |
     |Migration  |             |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Late Join  | N/A         |N/A       |N/A       |Group-based        |
     |Support    |             |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Streaming  | Message     |Stream    |N/A       |Object/Group       |
     |Granularity|             |          |          |                   |
     +-----------+-------------+----------+----------+-------------------+
     |Discovery  | Well-known  |Service   |Well-known|SUBSCRIBE_NAMESPACE|
     |Mechanism  | URI         |registry  |URI       |                   |
     +-----------+-------------+----------+----------+-------------------+

                                    Table 10

     MOQT enables real-time agent communication through low-latency
     streaming, priority-based message delivery, and built-in flow control
     that prevents overload during high-volume interactions.

     The publish/subscribe model provides scalability through one-to-many
     broadcasts, dynamic in-band discovery via SUBSCRIBE_NAMESPACE, and
     relay-based distribution that prevents connection explosion in large
     mesh networks.

     MOQT delivers reliability and resilience via QUIC connection
     migration, automatic retry mechanisms, graceful degradation, and
     object caching at relays for recovery from transient disconnections.

  6.  MOQT Relay Infrastructure for A2A

     MOQT relays provide critical infrastructure benefits for large-scale
     A2A deployments, enabling efficient message distribution and caching.

  6.1.  Relay Network Architecture

     MOQT relays form a hierarchical distribution network that optimizes
     A2A message delivery across geographic and organizational boundaries:

     Hierarchical Relay Network:

                         ┌─────────────────┐
                         │  Global Relay   │
                         │  (Federation)   │
                         └────────┬────────┘
                                  │
                ┌─────────────────┼─────────────────┐
                │                 │                 │
         ┌──────▼──────┐   ┌──────▼──────┐   ┌──────▼──────┐
         │ Region A    │   │ Region B    │   │ Region C    │
         │ Relay       │   │ Relay       │   │ Relay       │
         └──────┬──────┘   └──────┬──────┘   └──────┬──────┘
                │                 │                 │
          ┌─────┴─────┐     ┌─────┴─────┐     ┌─────┴─────┐
          │           │     │           │     │           │
        Agent A    Agent B Agent C   Agent D Agent E   Agent F

     This hierarchical structure provides:

     *  Regional optimization with local agent clusters

     *  Global connectivity for cross-region agent collaboration

     *  Load distribution to prevent single points of failure

     *  Configurable routing policies based on agent requirements

  6.2.  Message Caching Benefits

     MOQT relays implement intelligent caching strategies optimized for
     A2A communication patterns.  Caching tiers range from hot caches with
     short TTLs for real-time responses and task status updates, to warm
     caches for agent capability profiles and session metadata, to cold
     storage for historical task logs and compliance data.

  7.  Security Considerations

     TODO

  8.  IANA Considerations

     TODO

  9.  References

  9.1.  Normative References

     [A2A]      A2A Project, "Agent-to-Agent Protocol Specification",
                Version 0.3.0, 2025,
                <https://google.github.io/A2A/specification/>.

     [MCP]      Anthropic, "Model Context Protocol Specification",
                Version 2025-06-18, June 2025,
                <https://modelcontextprotocol.io/specification/>.

     [MoQ-TRANSPORT]
                Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
                I. Swett, "Media over QUIC Transport", Work in Progress,
                Internet-Draft, draft-ietf-moq-transport-16, January 2026,
                <https://datatracker.ietf.org/doc/draft-ietf-moq-
                transport/>.

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

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

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

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

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000>.

  9.2.  Informative References

     [AutoGen]  Wu, Q., Banber, G., Zhang, Y., Wu, Y., Li, B., Zhu, E.,
                and A. Awadallah, "AutoGen: Enabling Next-Gen LLM
                Applications via Multi-Agent Conversation",
                arXiv 2308.08155, 2023,
                <https://arxiv.org/abs/2308.08155>.

     [MCP-MOQT] Jennings, C., Swett, I., Rosenberg, J., and S. Nandakumar,
                "Model Context Protocol and Agent Skills over Media over
                QUIC Transport", Work in Progress, Internet-Draft, draft-
                mcp-over-moqt, 2025,
                <https://datatracker.ietf.org/doc/draft-mcp-over-moqt/>.

     [MoQ-C4M]  Jennings, S., "Common Access Token for Media over QUIC",
                Work in Progress, Internet-Draft, draft-ietf-moq-c4m,
                2025,
                <https://datatracker.ietf.org/doc/draft-ietf-moq-c4m/>.

     [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
                Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
                DOI 10.17487/RFC7540, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7540>.

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework",
                RFC 9297, August 2023,
                <https://www.rfc-editor.org/rfc/rfc9297>.

  Appendix A.  Acknowledgments

     TODO

  Authors' Addresses

     Suhas Nandakumar
     Cisco
     Email: snandaku@cisco.com


     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


name: draft-dunbar-agent-attachment
rev: 00
title: Agent Attachment Protocol
time: 2026-03-02T23:23:46Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T23:23:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-03-04T00:00:04.989459+00:00
source: ietf
abstract:
  This document describes the Agent Attachment Protocol (AAP),
     a network-centric mechanism that enables autonomous agents to
     securely attach to an overlay network infrastructure. The
     protocol defines procedures for agent attachment, identity
     validation, capability exchange, and secure session
     establishment between an agent and its local network edge
     node. Once attached, agents can communicate with remote
     agents through the overlay formed by interconnected edge
     nodes, without exposing the underlying network topology.

full_text:
  Network Working Group                                   L. Dunbar
  Internet Draft                                          Futurewei
  Intended status: Informational                       K. Majumdar
  Expires: September 2, 2026                              Oracle

                                                      March 2, 2026


                       Agent Attachment Protocol
                     draft-dunbar-agent-attachment-00

  Abstract
     This document describes the Agent Attachment Protocol (AAP),
     a network-centric mechanism that enables autonomous agents to
     securely attach to an overlay network infrastructure. The
     protocol defines procedures for agent attachment, identity
     validation, capability exchange, and secure session
     establishment between an agent and its local network edge
     node. Once attached, agents can communicate with remote
     agents through the overlay formed by interconnected edge
     nodes, without exposing the underlying network topology.


  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), its areas, and its working
     groups.  Note that other groups may also distribute working
     documents as Internet-Drafts.

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

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt





  xxx, et al.           Expires September 2, 2026         [Page 1]


  Internet-Draft             Agent-Attachment


     The list of Internet-Draft Shadow Directories can be accessed
     at http://www.ietf.org/shadow.html

     This Internet-Draft will expire on August 27, 2026  .

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date
     of publication of this document. Please review these
     documents carefully, as they describe your rights and
     restrictions with respect to this document. Code Components
     extracted from this document must include Simplified BSD
     License text as described in Section 4.e of the Trust Legal
     Provisions and are provided without warranty as described in
     the Simplified BSD License.

  Table of Contents

     1. Introduction..............................................3
     2. Conventions used in this document.........................4
     3. Problem Statement.........................................5
     4. Architecture Overview.....................................6
     5. Agent Gateway Discovery and Attachment....................9
        5.1. Discovery Mechanisms.................................9
           5.1.1. Anycast-Based Discovery.........................9
           5.1.2. DHCP-Based Bootstrapping.......................10
           5.1.3. DNS-Based Discovery via Directory Service......10
        5.2. Offer and Selection.................................10
        5.3. Handshake and Registration..........................10
     6. Messaging Forwarding and Routing.........................11
        6.1. Transport Header....................................11
        6.2. MFT Lookup and Forwarding...........................11
     7. Session Maintenance and Teardown.........................12
        7.1. Stateful Attachment Model...........................12
        7.2. Stateless (Soft-State) Attachment Model.............13
        7.3. Interoperability Considerations.....................13
     8. End-to-End Security......................................13
     9. Security Considerations..................................14



  Dunbar, et al.           Expires Dec 2, 2026            [Page 2]


  Internet-Draft             Agent-Attachment


     10. Manageability Considerations............................14
     11. IANA Considerations.....................................14
     12. References..............................................14
        12.1. Normative References...............................14
        12.2. Informative References.............................14
     13. Acknowledgments.........................................14
     Appendix A:.................................................15

  1. Introduction

    The Agent Attachment Protocol (AAP) defines a network centric
    mechanism that separates agent application logic from network
    attachment and forwarding functions. In this architecture,
    agents are identified by stable, location independent
    identifiers, while network edge nodes provide scalable,
    policy-controlled forwarding based on those identifiers.
    Agents attach to a local edge node, which serves as a domain
    boundary and provides access to an overlay network formed by
    interconnected edge nodes.

    AAP is limited to the attachment and access plane between an
    agent and its local network edge node. The protocol specifies
    procedures for agent discovery, secure attachment,
    authentication, capability exchange, session establishment,
    keepalive, and teardown. Once attached, agents communicate
    with remote agents via their respective network edge nodes,
    which forward messages based on transport-layer identifiers
    without inspecting, interpreting, or modifying application-
    layer content.

    The protocol is agnostic to the application layer messaging
    format (e.g., A2A, MCP, or other frameworks) and does not
    mandate specific end to end security mechanisms between
    agents. Agent Gateways operate solely on AAP transport headers
    and forwarding state, abstracting underlying network topology
    while enabling scalable identity-based forwarding.

    AAP supports operational requirements common to distributed
    agent systems, including mobility, multi-homing, and
    capability-based interaction. The protocol allows multiple
    bootstrap mechanisms for Agent to network edge discovery,
    including anycast based discovery, DHCP based provisioning,


  Dunbar, et al.           Expires Dec 2, 2026            [Page 3]


  Internet-Draft             Agent-Attachment


    and DNS based resolution. These discovery methods serve only
    as initial attachment mechanisms and do not alter the core
    attachment, authentication, and forwarding semantics defined
    in this document.

    AAP does not define inter-node overlay control-plane
    procedures or application-layer messaging semantics. Its scope
    is strictly limited to secure network attachment and transport
    enablement for agent communications in multi-domain
    environments.

  2. Conventions used in this document
     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 BCP14 [RFC2119] [RFC8174] when, and only when,
     they appear in all
     capitals, as shown here.

     The following acronyms and terms are used in this document:

     Agent: An autonomous software entity identified by an Agent
                 Identifier.

     Agent Gateway (GW): A network edge node that functions as
                 messaging routers within the agentic overlay
                 network that manages the Message Forwarding Table
                 (MFT) and handles bit-level transport for agents.

     Directory Service: A capability registry that maps agent
                 capabilities to the Agent ID.

     Message Forwarding Table (MFT): A forwarding table mapping
                 Agent ID prefixes to local interfaces or next-hop
                 Gateways.







  Dunbar, et al.           Expires Dec 2, 2026            [Page 4]


  Internet-Draft             Agent-Attachment


  3. Problem Statement

     The rapid emergence of AI-driven services and autonomous
     software agents has created increasing demand for agent-to-
     agent communication across administrative domains, cloud
     providers, and heterogeneous network environments. These
     agents may reside in enterprise networks, edge locations, or
     public cloud infrastructures, and often require secure,
     policy-controlled communication with remote agents outside
     their local domain.

     Existing approaches typically rely on direct IP connectivity,
     application-layer messaging systems, or ad hoc overlay
     mechanisms. When agents span multiple domains, these
     approaches introduce several operational and architectural
     challenges. Direct connectivity models may expose internal
     endpoint addressing or topology information that operators
     prefer to abstract. There is no standardized mechanism to
     enforce forwarding or transport policies consistently across
     administrative boundaries. As the number of agents grows,
     maintaining direct connectivity models becomes operationally
     complex and difficult to scale. Additionally, current systems
     lack a common framework for secure agent attachment, identity
     validation, and gateway-mediated encrypted forwarding.

     This document considers an architecture in which Agent
     Gateways (Agent GWs) serve as domain boundary nodes. Agents
     attach to a local Agent GW, and Agent GWs establish secure
     connectivity with other Agent GWs. Collectively, the
     interconnected Agent GWs form an overlay network that
     abstracts the underlying IP infrastructure, similar in
     concept to an SD-WAN overlay. In this model, end-to-end agent
     messages remain encrypted, while Agent GWs forward messages
     based on transport headers and policy controls without
     requiring visibility into application-layer semantics.

     While emerging industry efforts (e.g., agent communication
     frameworks proposed by major cloud and networking vendors)
     demonstrate growing interest in agent-to-agent communication,
     many focus primarily on discovery, directory inquiry, or
     application-layer semantics. The problem addressed in this
     document is different: it focuses on defining a transport
     substrate between Agent Gateways. The goal is to provide a
     lightweight, secure, and policy-aware overlay messaging
     framework formed by Agent GWs that enables scalable




  Dunbar, et al.           Expires Dec 2, 2026            [Page 5]


  Internet-Draft             Agent-Attachment


     forwarding of encrypted agent-to-agent messages across
     domains.

     The objective of this work is therefore to define an
     interoperable overlay transport protocol between Agent
     Gateways that supports secure agent attachment, controlled
     message forwarding, and domain-level policy enforcement,
     without mandating application-layer behavior or directory
     services.

  4. Architecture Overview

     Agent Gateway is a network edge node that functions as
     messaging routers within the agentic overlay network. They
     forward traffic based solely on information contained in the
     cleartext A2G transport header and local forwarding policy.
     Agent Gateways do not interpret, inspect, or modify
     application-layer payloads, and are not dependent on the
     semantics of the Agent-to-Agent (A2A) or MCP messaging
     carried within the transport.

     The Agent-to-Gateway (A2G) protocol establishes a logical
     messaging overlay that decouples an agent's identity and
     advertised capabilities from its physical network location.
     In this model, Agents are identified by stable AgentIDs,
     independent of IP addressing. In this model and the Agent
     Gateway (GW) acts as a specialized Messaging Router or
     Service Forwarder that anchors the agent's current network
     attachment and provides scalable, identity-based forwarding
     across the overlay.

     The architecture separates capability discovery from message
     delivery. A Directory Service provides "yellow-pages"
     functionality by mapping agent capabilities to stable Agent
     identifiers (AgentIDs). However, an agent's network
     attachment may change over time due to mobility, multi-
     homing, policy decisions, or operational conditions, and
     therefore cannot be reliably inferred from capability
     information alone.

     To address these dynamics, the A2G protocol defines a local
     discovery and handshake process in which an agent dynamically
     discovers an appropriate Agent Gateway, performs mutual
     authentication, and establishes a forwarding context. This
     attachment state is maintained at the Agent Gateway and
     reflected in its Message Forwarding Table (MFT), enabling


  Dunbar, et al.           Expires Dec 2, 2026            [Page 6]


  Internet-Draft             Agent-Attachment


     efficient routing based on AgentID while keeping discovery,
     identity, and forwarding responsibilities cleanly separated.

     +----------------------+           +-------------------+
     |  DIRECTORY SERVICE   |           |AGENT GATEWAY (GW) |
     |(Capability, AgentIDs)|           |(Dynamic Attachment|
     |                      |           |Msg Forwarding     |
     +----------^-----------+           +-----------+-------+
        (A)     |                                   |
  Capability)   |       (B)                 (C)     | (D)
      INQUIRY   |TARGET AgentIDs       GW-DISCOVER  | GW-OFFER
                |                                   |
          +-----+-----------------------------------+-----+
          |                 [ AGENT A ]                   |
          +-----------------------+-----------------------+
                                  |
                                  | (E) ENCRYPTED MESSAGE
                                  | [Header: Target AgentID]
                                  v
                       +-----------------------+
                       |    MFT LOOKUP &       |
                       |     FORWARDING        |
                       +-----------------------+
             Figure 1: Key Components of Agent to GW Transport

     Legend:

     (A) Agent queries "Who has Skill X?"

     (B) Directory returns "Agent B (AgentID-456)"

     (C) Agent initiates an Agent Gateway discovery process to locate an
     appropriate local Agent Gateway that serves as its ingress point to
     the agentic overlay network.

     (D) An Agent Gateway responds with a GW-OFFER, providing connection
     parameters and supported features. The Agent selects a Gateway and
     completes authentication and registration.

     (E) Once attached, the Agent sends end-to-end messages containing a
     cleartext transport header with the Target AgentID and an
     application-layer payload. In most practical deployments, the A2A
     or MCP messaging carried within the payload is expected to be
     encrypted; however, this is independent of A2G-MTP. The Agent
     Gateway performs a lookup in its Message Forwarding Table (MFT) and



  Dunbar, et al.           Expires Dec 2, 2026            [Page 7]


  Internet-Draft             Agent-Attachment


     forwards the payload, without inspecting or interpreting its
     contents, toward the Gateway currently serving the target agent.



     The following steps illustrate the high-level operation of
     the Agent-to-Agent Gateway transport:

       o Capability Discovery:
          Agent performs an out-of-band inquiry to the Directory
          Service ((e.g., "find an agent capable of JSON-to-XML
          translation")). The Directory Service returns one or
          more Target Agent IDs that satisfy the request. At this
          stage, the Agent identifies which agent(s) it intends to
          communicate with, but does not yet have information
          about where those agents are currently attached in the
          network. The mechanism used for this capability inquiry
          is outside the scope of this document.

       o Gateway Discovery:
          After identifying the target Agent ID(s), the Agent
          initiates an Agent Gateway discovery process by sending
          a GW-DISCOVER message (e.g., via anycast or other
          supported bootstrap mechanisms). One or more reachable
          Agent Gateways respond with GW-OFFER messages containing
          the Gateway identifier and connection parameters (such
          as a gRPC endpoint and supported features)

       o Handshake and Registration:
          The Agent selects an Agent Gateway and performs a mutual
          authentication handshake, providing its Agent ID and
          cryptographic proof of identity. Upon successful
          validation, the Agent Gateway establishes an attachment
          context and registers the Agent in its local Message
          Forwarding Table (MFT).

       o Message Forwarding and Table Management:
          Once attached, the Agent initiates messaging sessions by
          sending end-to-end payloads. Each message includes a
          cleartext A2G transport header that carries the Source
          Agent ID and Target Agent ID.

          Upon receiving a message, the Agent Gateway does not
          inspect the payload. Instead, it performs a lookup on
          the Target Agent ID in its MFT. If a matching entry
          exists, the Gateway forwards the message to the


  Dunbar, et al.           Expires Dec 2, 2026            [Page 8]


  Internet-Draft             Agent-Attachment


          appropriate local interface or next-hop Agent Gateway.
          If no entry is found, the Gateway may invoke a route-
          discovery procedure (outside the scope of this document)
          to locate the Gateway currently serving the target
          agent.

          The MFT is updated dynamically as agents attach, detach,
          or move, reflecting the evolving attachment state of the
          agentic overlay network.

  5. Agent Gateway Discovery and Attachment

     In a dynamic environment, an Agent cannot assume a static
     configuration for its messaging ingress. An Agent's network
     attachment may change over time due to mobility, multi-
     homing, policy decisions, or deployment constraints.
     Therefore, A2G-MTP defines a Gateway discovery and attachment
     procedure that allows an Agent to identify an appropriate
     Agent Gateway and establish a forwarding context.

     This document supports multiple mechanisms for discovering an
     Agent Gateway. These mechanisms are treated as bootstrap
     options and do not alter the attachment, authentication, or
     forwarding semantics defined in subsequent sections.

  5.1. Discovery Mechanisms

     An Agent MAY use one or more of the following mechanisms to
     discover a candidate Agent Gateway:

  5.1.1. Anycast-Based Discovery

     An Agent MAY discover a local ingress Gateway by sending a
     GW-DISCOVER message to a well-known routable anycast address.
     The discovery message includes the Agent's ID and a nonce.

     Any Agent Gateway reachable via the anycast address MAY
     respond with a GW-OFFER message. Anycast-based discovery
     enables topology-aware selection of a nearby Gateway without
     requiring pre-configuration.





  Dunbar, et al.           Expires Dec 2, 2026            [Page 9]


  Internet-Draft             Agent-Attachment


  5.1.2. DHCP-Based Bootstrapping

     In managed access networks, the Agent Gateway MAY be co-
     located with, or designated by, the IP gateway for the
     Agent's access network. In such environments, DHCP MAY be
     used to provide the Agent with unicast bootstrap information
     for an Agent Gateway, such as an IP address, FQDN, or service
     endpoint.

     DHCP-based information MUST be treated as advisory. The Agent
     MUST still perform the authentication and registration
     procedures defined in Section 4.3 before establishing an
     attachment.

  5.1.3. DNS-Based Discovery via Directory Service

     The Directory Service MAY return a stable Agent Gateway
     service identifier (e.g., URL or FQDN) to the Agent as part
     of the capability discovery process. The Agent MAY use DNS
     resolution (including anycast or load-balanced DNS) to obtain
     a reachable Agent Gateway unicast address.

     DNS-based discovery provides scalable, multi-hop reachability
     but does not replace the explicit attachment and
     authentication procedures defined by A2G-MTP.

  5.2. Offer and Selection

     For discovery mechanisms that involve Gateway responses
     (e.g., anycast-based discovery), an Agent Gateway responds
     with a GW-OFFER message containing:

          o Gateway identifier
          o Transport endpoint (e.g., gRPC URI)
          o Supported transport features

     The Agent selects one Gateway based on local policy and
     proceeds with the attachment procedure.

  5.3. Handshake and Registration

     The Agent initiates a mutual authentication handshake with
     the selected Agent Gateway, providing its Agent ID and
     cryptographic proof of identity. Upon successful validation,
     the Agent Gateway establishes an attachment context and
     assigns a Session Context, analogous to a DHCP lease.


  Dunbar, et al.           Expires Dec 2, 2026           [Page 10]


  Internet-Draft             Agent-Attachment


     The Agent Gateway then registers the Agent in its local
     Message Forwarding Table (MFT), enabling message forwarding
     for the duration of the attachment.

     Regardless of the discovery mechanism used, the handshake,
     authentication, registration, and forwarding behavior defined
     by A2G-MTP remain identical.

  6. Messaging Forwarding and Routing

       The Agent GW serves as the switching and forwarding engine
       for the agentic overlay network. Each Agent Gateway
       maintains a MFT that maps Agent IDs (or Agent ID prefixes)
       to local attachment or next-hop Agent Gateways. The MFT
       reflects the dynamic attachment state of agents and is
       updated as agents attach, detach, or move.

  6.1. Transport Header

     Each message sent by an Agent carries a cleartext A2G
     transport header that enables forwarding without exposing
     application semantics. The transport header includes the
     following fields:

       o Target Agent ID (or prefix)
       o Message Identifier
       o TTL
       o End-to-End Security Context Identifier

     In most deployments, application data and higher-layer
     semantics are encrypted end-to-end between agents and are
     opaque to Agent Gateways.

  6.2. MFT Lookup and Forwarding

       Ingress Processing: When an Agent sends a message, it
       includes a clear-text A2G Header containing the Target
       Agent ID, which was obtained earlier from the capability
       discovery. The encrypted payload is encapsulated without
       modification by the Agent.

       Forwarding Logic: Upon receiving a message, the Agent
       Gateway performs an exact-match (or prefix-match, if
       supported) lookup on the Target Agent ID in its MFT.





  Dunbar, et al.           Expires Dec 2, 2026           [Page 11]


  Internet-Draft             Agent-Attachment


         o If the target is attached to the same Gateway, the
            Gateway forwards the encrypted payload to the
            corresponding local attachment.
         o If the target is attached to a remote Gateway, the
            Gateway forwards the encrypted payload to the next-hop
            Agent GW.

       If no matching MFT entry exists, the Gateway MAY invoke a
       route-discovery or resolution procedure to locate the
       Gateway currently serving the target Agent; such procedures
       are outside the scope of this document.

       Payload Confidentiality: Agent GW does not inspect,
       decrypt, or interpret the message body. The GW only
       forwards messages solely based on the information contained
       in the cleartext transport header.

  7. Session Maintenance and Teardown

     The relationship between the Agent and the GW may be stateful
     or stateless (soft state), depending on deployment
     requirements and implementation choices. In both cases, the
     attachment is ephemeral and reflects the Agent's current
     network presence.

  7.1. Stateful Attachment Model

     In a stateful attachment model, the Agent Gateway maintains
     explicit session state for each attached Agent.

     Keep-Alives: An attached Agent periodically sends "Heartbeat"
     messages to the GW to indicate continued presence. If
     heartbeats are not received within a configured interval, the
     GW marks the corresponding MFT entry as Stale and eventually
     remove it.

     Explicit Release: When an Agent finishes its task or intends
     to detach, it sends a Session-End signal to the Gateway. Upon
     receipt, the Gateway removes the Agent's entry from its MFT
     and MAY notify Gateways to tear down the corresponding
     forwarding state.







  Dunbar, et al.           Expires Dec 2, 2026           [Page 12]


  Internet-Draft             Agent-Attachment


  7.2. Stateless (Soft-State) Attachment Model

     In a soft-state attachment model, the Gateway does not rely
     on explicit session teardown and instead treats attachment
     state as time-bounded.

       o MFT entries are created with a lifetime and expire
          automatically unless refreshed.
       o Periodic data traffic or lightweight refresh messages
          MAY implicitly renew the attachment.
       o Absence of traffic or refreshes results in automatic
          removal of stale MFT entries without requiring explicit
          Session-End signaling.


     The soft-state model reduces signaling overhead and is well
     suited for large-scale or highly dynamic environments where
     explicit session management may be impractical.

  7.3. Interoperability Considerations

     Regardless of whether a stateful or soft-state model is used,
     the forwarding behavior defined in Section 5 remains
     unchanged. Gateways forward messages based on current MFT
     entries and do not depend on application-layer semantics.

     Implementations MAY support one or both attachment models,
     provided that stale attachment state is removed in a timely
     manner to prevent mis-delivery.

  8. End-to-End Security

     A2G-MTP is agnostic to the application-layer messaging
     protocol used between Agents (e.g., A2A, MCP) and does not
     mandate whether Agent-to-Agent communications are encrypted.
     In most practical deployments, such communications are
     expected to be protected using end-to-end encryption.

     When end-to-end security is employed, the selected mechanism
     is responsible for providing confidentiality, integrity
     protection, replay protection, and sender authentication
     between communicating Agents.

     Agent Gateways operate solely on the cleartext A2G transport
     header for forwarding decisions. Agent Gateways MUST NOT


  Dunbar, et al.           Expires Dec 2, 2026           [Page 13]


  Internet-Draft             Agent-Attachment


     decrypt, inspect, or modify application layer payloads and
     are not participants in application-layer security contexts.

     The specific end-to-end security protocol used between Agents
     is outside the scope of this document. Any selected mechanism
     SHOULD provide mutual authentication and cryptographic
     binding between the Agent identity and the protected message
     content.

  9. Security Considerations

     TBD.

  10. Manageability Considerations

          TBD

  11. IANA Considerations

     TBD


  12. References


  12.1. Normative References

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


  12.2. Informative References

     .

  13. Acknowledgments

     Acknowledgements to xxx for their extensive review and
     suggestions.

     This document was prepared using 2-Word-v2.0.template.dot.




  Dunbar, et al.           Expires Dec 2, 2026           [Page 14]


  Internet-Draft             Agent-Attachment



  Appendix A:

  Authors' Addresses

     Linda Dunbar
     Futurewei
     Email: ldunbar@futurewei.com

     Kausik Majumdar
     Oracle
     Email: kausik.majumdar@oracle.com



  Contributors' Addresses































  Dunbar, et al.           Expires Dec 2, 2026           [Page 15]



name: draft-jaju-httpbis-zstd-window-size
rev: 01
title: Window Sizing for Zstandard Content Encoding
time: 2024-06-11T02:15:07Z
group: httpbis
group_uri: /api/v1/group/group/1718/
expires: 2024-11-21T09:43:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.001501+00:00
source: ietf
abstract:
  Deployments of Zstandard, or "zstd", can use different window sizes
     to limit memory usage during compression and decompression.  Some
     browsers and user agents limit window sizes to mitigate memory usage
     concerns, causing interoperability issues.  This document updates the
     window size limit in RFC8878 from a recommendation to a requirement
     in HTTP contexts.

full_text:
  HTTPBIS                                                          N. Jaju
  Internet-Draft                                                    Google
  Intended status: Informational                           W. F. P. Handte
  Expires: 21 November 2024                           Meta Platforms, Inc.
                                                               20 May 2024


                Window Sizing for Zstandard Content Encoding
                   draft-jaju-httpbis-zstd-window-size-01

  Abstract

     Deployments of Zstandard, or "zstd", can use different window sizes
     to limit memory usage during compression and decompression.  Some
     browsers and user agents limit window sizes to mitigate memory usage
     concerns, causing interoperability issues.  This document updates the
     window size limit in RFC8878 from a recommendation to a requirement
     in HTTP contexts.

  About This Document

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

     The latest revision of this draft can be found at
     https://nidhijaju.github.io/draft-zstd-window-size/draft-jaju-
     httpbis-zstd-window-size.html.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-jaju-httpbis-
     zstd-window-size/.

     Discussion of this document takes place on the HTTPBIS 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/nidhijaju/draft-zstd-window-size.

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






  Jaju & Handte           Expires 21 November 2024                [Page 1]


  Internet-Draft              Zstd Window Size                    May 2024


     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 21 November 2024.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Window Size . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
       5.1.  Content Encoding  . . . . . . . . . . . . . . . . . . . .   3
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   4
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

  1.  Introduction

     Zstandard, or "zstd", specified in [RFC8878], is a lossless data
     compression mechanism similar to gzip.  When used with HTTP, the
     "zstd" Content Coding token signals to the decoder that the content
     is Zstandard-compressed.

     An important property of Zstandard-compressed content is its
     Window_Size ([RFC8878], Section 3.1.1.1.2), which describes the
     maximum distance for back-references and therefore how much of the
     content must be kept in memory during decompression.







  Jaju & Handte           Expires 21 November 2024                [Page 2]


  Internet-Draft              Zstd Window Size                    May 2024


     The minimum Window_Size is 1 KB.  The maximum Window_Size is (1<<41)
     + 7*(1<<38) bytes, which is 3.75 TB.  Larger Window_Size values tend
     to improve the compression ratio, but at the cost of increased memory
     usage.

     To protect against unreasonable memory usage, some browsers and user
     agents limit the maximum Window_Size they will handle.  This causes
     failures to decode responses when the content is compressed with a
     larger Window_Size than the recipient allows, leading to decreased
     interoperability.

     [RFC8878], Section 3.1.1.1.2 recommends that decoders support a
     Window_Size of up to 8 MB, and that encoders not generate frames
     using a Window_Size larger than 8 MB.  However, it imposes no
     requirements.

     This document updates [RFC8878] to enforce Window_Size limits on the
     encoder and decoder for the "zstd" Content Coding.

  2.  Conventions and Definitions

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

  3.  Window Size

     To ensure interoperability of the "zstd" Content Coding, decoders
     MUST support a Window_Size of up to and including 8 MB and encoders
     MUST NOT generate frames requiring a Window_Size larger than 8 MB,
     when using the "zstd" Content Coding (see Section 5.1).

  4.  Security Considerations

     This document introduces no new security considerations beyond those
     discussed in [RFC8878].

  5.  IANA Considerations

  5.1.  Content Encoding

     This document updates the entry added in [RFC8878] to the "HTTP
     Content Coding Registry" within the "Hypertext Transfer Protocol
     (HTTP) Parameters" registry:

     Name:  zstd



  Jaju & Handte           Expires 21 November 2024                [Page 3]


  Internet-Draft              Zstd Window Size                    May 2024


     Description:  A stream of bytes compressed using the Zstandard
        protocol with a Window_Size of not more than 8 MB.

     Reference:  This document

  6.  Normative References

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

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

     [RFC8878]  Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
                and the 'application/zstd' Media Type", RFC 8878,
                DOI 10.17487/RFC8878, February 2021,
                <https://www.rfc-editor.org/rfc/rfc8878>.

  Acknowledgments

     Zstandard was developed by Yann Collet.

     The authors would like to thank Yann Collet, Klaus Post, Adam Rice,
     and members of the Web Performance Working Group in the W3C for
     collaborating on the window size issue and helping to formulate a
     solution.  Also, thank you to Nick Terrell for providing feedback
     that went into RFC 8478 and RFC 8878.

  Authors' Addresses

     Nidhi Jaju
     Google
     Shibuya Stream, 3 Chome-21-3 Shibuya, Shibuya City, Tokyo
     150-0002
     Japan
     Email: nidhijaju@google.com


     W. Felix P. Handte
     Meta Platforms, Inc.
     380 W 33rd St
     New York, NY 10001,
     United States of America
     Email: felixh@meta.com




  Jaju & Handte           Expires 21 November 2024                [Page 4]


name: draft-bernardos-anima-fog-monitoring
rev: 07
title: Autonomic setup of fog monitoring agents
time: 2024-01-05T14:12:04Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2024-01-05T10:47:11Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Agent discovery/reg"]
tags: []
fetched_at: 2026-03-04T00:00:05.004433+00:00
source: ietf
abstract:
  The concept of fog computing has emerged driven by the Internet of
     Things (IoT) due to the need of handling the data generated from the
     end-user devices.  The term fog is referred to any networked
     computational resource in the continuum between things and cloud.  In
     fog computing, functions can be stiched together composing a service
     function chain.  These functions might be hosted on resources that
     are inherently heterogeneous, volatile and mobile.  This means that
     resources might appear and disappear, and the connectivity
     characteristics between these resources may also change dynamically.
     This calls for new orchestration solutions able to cope with dynamic
     changes to the resources in runtime or ahead of time (in anticipation
     through prediction) as opposed to today’s solutions which are
     inherently reactive and static or semi-static.

     A fog monitoring solution can be used to help predicting events so an
     action can be taken before an event actually takes place.  This
     solution is composed of agents running on the fog nodes plus a
     controller hosted at another device (running in the infrastructure or
     in another fog node).  Since fog environments are inherently volatile
     and extremely dynamic, it is convenient to enable the use of
     autonomic technologies to autonomously set-up the fog monitoring
     platform.  This document aims at presenting this use case as well as
     specifying how to use GRASP as needed in this scenario.

full_text:
  ANIMA WG                                              CJ. Bernardos, Ed.
  Internet-Draft                                                      UC3M
  Intended status: Experimental                                  A. Mourad
  Expires: 5 January 2024                                     InterDigital
                                                         P. Martinez-Julia
                                                                      NICT
                                                               4 July 2023


                  Autonomic setup of fog monitoring agents
                  draft-bernardos-anima-fog-monitoring-07

  Abstract

     The concept of fog computing has emerged driven by the Internet of
     Things (IoT) due to the need of handling the data generated from the
     end-user devices.  The term fog is referred to any networked
     computational resource in the continuum between things and cloud.  In
     fog computing, functions can be stiched together composing a service
     function chain.  These functions might be hosted on resources that
     are inherently heterogeneous, volatile and mobile.  This means that
     resources might appear and disappear, and the connectivity
     characteristics between these resources may also change dynamically.
     This calls for new orchestration solutions able to cope with dynamic
     changes to the resources in runtime or ahead of time (in anticipation
     through prediction) as opposed to today’s solutions which are
     inherently reactive and static or semi-static.

     A fog monitoring solution can be used to help predicting events so an
     action can be taken before an event actually takes place.  This
     solution is composed of agents running on the fog nodes plus a
     controller hosted at another device (running in the infrastructure or
     in another fog node).  Since fog environments are inherently volatile
     and extremely dynamic, it is convenient to enable the use of
     autonomic technologies to autonomously set-up the fog monitoring
     platform.  This document aims at presenting this use case as well as
     specifying how to use GRASP as needed in this scenario.

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




  Bernardos, et al.        Expires 5 January 2024                 [Page 1]


  Internet-Draft          GRASP for fog monitoring               July 2023


     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 January 2024.

  Copyright Notice

     Copyright (c) 2023 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
       1.1.  Problem statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Fog monitoring framework  . . . . . . . . . . . . . . . .   4
       1.3.  Supporting simple and complex monitoring metrics  . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Autonomic setup of fog monitoring framework . . . . . . . . .   7
     4.  Discovery Notification and Telemetry Publication  . . . . . .  11
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
     8.  Informative References  . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     The concept of fog computing has emerged driven by the Internet of
     Things (IoT) due to the need of handling the data generated from the
     end-user devices.  The term fog is referred to any networked
     computational resource in the continuum between things and cloud.  A
     fog node may therefore be an infrastructure network node such as an
     eNodeB or gNodeB, an edge server, a customer premises equipment
     (CPE), or even a user equipment (UE) terminal node such as a laptop,
     a smartphone, or a computing unit on-board a vehicle, robot or drone.





  Bernardos, et al.        Expires 5 January 2024                 [Page 2]


  Internet-Draft          GRASP for fog monitoring               July 2023


     In fog computing, functions might be organized in service function
     chains (SFCs), hosted on resources that are inherently heterogeneous,
     volatile and mobile.  This means that resources might appear and
     disappear, and the connectivity characteristics between these
     resources may also change dynamically.  This calls for new
     orchestration solutions able to cope with dynamic changes to the
     resources in runtime or ahead of time (in anticipation through
     prediction) as opposed to today’s solutions which are inherently
     reactive and static or semi-static.

  1.1.  Problem statement

     Figure 1 shows an exemplary scenario of a (robot) network service.  A
     robot device has its (navigation) control application running in the
     fog away from the robot, as a network service in the form of an SFC
     "F1-F2" (e.g., F1 might be in charge of identifying obstacles and F2
     takes decisions on the robot navigation).  Initially the function F1
     is assumed to be hosted at a fog node A and F2 at fog node B.  At a
     given point of time, fog node A becomes unavailable (e.g., due to low
     battery issues or the fog node A moving away from the coverage of the
     robot).  There is therefore a need to predict the need of migrating/
     moving the function F1 to another node (e.g., fog node C in the
     figure), and this needs to be done prior to the fog/edge node
     becoming no longer capable/available.  Such dynamic migration cannot
     be dealt with in today's orchestration solutions, which are rather
     reactive and static or semi-static (e.g., resources may fail, but
     this is an exceptional event, happening with low frequency, and only
     scaling actions are supported to react to SLA-related events).

                --------------
                |    ====    |
               ------+F1+----------
              / |  | ==== |  |     \
             /  |  +------+  |      \
             |  | fog node C |       \
             |  --------------        \
             |                         \
             |       --------------  ---\----------
             |       |    ====    |  |   \====    |
             | -----------+F1+------------+F2|    |
             |/      |  | ==== |  |  |  | ==== |  |
             o       |  +------+  |  |  +------+  |
             |       | fog node A |  | fog node B |
     --------+-      --------------  --------------
     |        |
     --0----0--

                           Figure 1: Example scenario



  Bernardos, et al.        Expires 5 January 2024                 [Page 3]


  Internet-Draft          GRASP for fog monitoring               July 2023


     Existing frameworks rely on monitoring platforms that react to
     resource failure events and ensure that negotiated SLAs are met.
     However these are not designed to predict events likely to happen in
     a volatile fog environment, such as resources moving away, resources
     becoming unavailable due to battery issues or just changes in
     availability of the resources because of variations of the use of the
     local resources on the nodes.  Besides, it is not feasible in this
     kind of volatile and extremely mobile environment to perform a
     continuous monitoring and reporting of every possible variable or
     parameter from all the nodes hosting resources, as this would not
     scale and would consume many resources and generate extra overhead.

     In volatile and mobile environments, prediction (make-before-break)
     is needed, as pure reaction (break-before-make) is not enough.  This
     prediction is not generic, and depends on the nature of the network
     service/SFC: the functions of the SFC, the connectivity between them,
     the service-specific requirements, etc.  Monitoring has to be setup
     differently on the nodes, depending on the specifics of the network
     service.  Besides, in order to act proactively and predict what might
     need to be done, monitoring in such a volatile and mobile
     environments does not only involve the nodes currently hosting the
     resources running the network service/service function chain (i.e.,
     hosting a function), but also other nodes which are potential
     candidates to join either in addition or in substitution to current
     nodes for running the network service in accordance with the
     orchestration decisions.

     In the example of Figure 1, the fog node initially hosting function
     F1 (fog node A) might be running out of battery and this should be
     detected before the node A actually becomes unavailable, so the
     function F1 can be effectively migrated in a time to a different fog
     node C, capable of meeting the requirements of F1 (compute,
     networking, location, expected availability, etc.).  In order to be
     able to predict the need for such a migration and have already
     identified a target fog node where to move the function, it is needed
     to have a monitoring solution in place that instructs each node
     involved in the service (A and B), and also neighboring node
     candidate (C) to host function (F1), to monitor and report on metrics
     that are relevant for the specific network service "F1-F2" that is
     currently running.

  1.2.  Fog monitoring framework

     Fog environments differ from data-center ones on three key aspects:
     heterogeneity, volatility and mobility.  The fog monitoring framework
     is used to predict events triggering and orchestration event (e.g.,
     migrating a function to a different resource).




  Bernardos, et al.        Expires 5 January 2024                 [Page 4]


  Internet-Draft          GRASP for fog monitoring               July 2023


     The monitoring framework we propose for fog environments is composed
     of 2 logical components:

     *  Fog agents running on each fog node.  An agent is responsible for
        sending the value of a variable or parameter to a fog monitoring
        controller and to other fog agents.  What variable or parameter
        will be monitored and what data will be sent (including frequency)
        is configured per agent considering the specifics of the network
        service or SFC.  A fog agent might also take some autonomous
        actions (such as request migration of a function to a neighbor
        node) in certain situations where connectivity with the fog
        monitoring controller is temporarily unavailable.

     *  A fog monitoring controller (e.g., running at the edge or at a fog
        node).  This node obtains input from the orchestration logic (MANO
        stack) and autonomously decides what variables or parameters will
        be monitored, where will the data be collected, and how it will be
        done, based on the requirements provided by the orchestration
        logic managing the network services instantiated in the fog.  This
        configuration is specific to a network service, a function, or an
        SFC as whole.

        -  It interacts with the orchestration logic to coordinate and
           trigger orchestration events, such as function migration,
           connectivity updates, etc.  In some deployments, this entity
           might be co-located with the orchestration logic (e.g., the
           NFVO).

        -  It interacts with the fog agents to instruct what variables
           and/or parameters need to be monitored.  It also interacts to
           get the resulting monitoring data.  This interaction is not
           limited to fog agents at nodes currently involved in a given
           network service or SFC, but also includes other nodes that are
           suitable for hosting a function that needs to be migrated.
           This allows to provide the orchestration logic with candidate
           nodes in a pro-active way.

        -  It is capable of autonomously discover and set up fog agents.













  Bernardos, et al.        Expires 5 January 2024                 [Page 5]


  Internet-Draft          GRASP for fog monitoring               July 2023


  1.3.  Supporting simple and complex monitoring metrics

     Fog monitoring nodes will be capable of providing raw monitoring data
     as well as processed data.  The former are obtained directly from the
     measured variables or parameters.  The latter are obtained by
     applying some processing function to several monitoring data items.
     The fog monitoring controllers will specify the function to be
     executed, which data will be collected and processed by the
     functions, and the additional parameters that will control the
     processing and will determine the particularities of the output of
     each function.

     The complexity of the functions that can be executed is arbitrary.
     They can be either pre-instructed in the fog agents or dynamically
     instructed by the requester (the fog monitoring controller) by
     providing the sequence to execute the functions and their input
     parameters.

     Complex monitoring metrics, the processed data, can also be used as
     part of the condition that determines the distributed and autonomic
     actions.  Thus, the logic that defines those actions is simplified
     and the actuation components can be concentrated on their task
     without requiring extra effort to process the raw monitoring data.

     Adding support for complex monitoring metrics enables the fog
     monitoring framework to avoid the transmission of unneeded data and
     thus optimize its overall operation.  For example, if the controller
     is interested in the average of the CPU load of a fog agent for the
     last 5 minutes, it can just request it, providing the period to
     average as input parameter and specifying the source from which
     measuring the CPU load variable.

  2.  Terminology

     The following terms are using in ths document:

     fog:          Fog goes to the Extreme Edge, that is the closest
                   possible to the user including on the user device
                   itself.

     fog node:     Any device that is capable of participating in the Fog.
                   A Fog node might be volatile, mobile and constrained
                   (in terms of computing resources).  Fog nodes may be
                   heterogeneous and may belong to different owners.

     orchestrator:  In this document we use orchestrator and NFVO terms
                   interchangeably.




  Bernardos, et al.        Expires 5 January 2024                 [Page 6]


  Internet-Draft          GRASP for fog monitoring               July 2023


  3.  Autonomic setup of fog monitoring framework

     Fog nodes autonomously start fog agents at the bootstrapping, then
     start looking for other agents and the fog monitoring controller.
     This autonomic setup can be performed using GRASP.  The procedure is
     represented in Figure 2.  The different steps are described next:













































  Bernardos, et al.        Expires 5 January 2024                 [Page 7]


  Internet-Draft          GRASP for fog monitoring               July 2023


     +--------+    +--------+    +--------+
     |  fog   |    |  fog   |    |  fog   |
     | node C |    | node A |    | node B |                       +------+
     |        |    |        |    |        |                       | fog  |
     | |    | |    | |    | |    | |    | |        +------+       | mon. |
     | +----+ |    | +----+ |    | +----+ |        | NFVO |       | ctrl |
     +--------+    +--------+    +--------+        +------+       +------+
                        |             |                |              |
                 (fog nodes A & B bootstrap)           |              |
                        |             |                |              |
                        |             |   periodic mcast advertisement|
                        |             |               (ID, fog_scope) |
                        |             |  <----------------------------+
                        | Mcast discovery (fog_node_ID, scope)        |
                        +-------------------------------------------->|
                        +------------>|                |              |
                        |    Mcast discovery (fog_node_ID, scope)     |
                        |             +------------------------------>|
                        |<------------+                |              |
                        |             |                |              |
                        |       Unicast advertisement (ID, fog_scope) |
                        |             |<------------------------------+
                        |<--------------------------------------------+
                        |             |                |              |
                        |    Unicast registration (ID, fog_node_ID    |
                        |             |            fog_scope, capab.) |
                        |             +------------------------------>|
                        +-------------------------------------------->|
                        |             |                |              |
                 (fog nodes A & B registered)          |              |
                        |             |                |              |
     (fog node C bootstraps)          |                |              |
          |             |             |                |              |
          | Mcast discovery (fog_node_ID, scope)       |              |
          +---------------------------------------------------------->|
          +-------------------------->|                |              |
          +------------>|       Unicast advertisement (ID, fog_scope) |
          |<----------------------------------------------------------+
          |<--------------------------+                |              |
          |<------------+    Unicast registration (ID, fog_node_ID    |
          |             |             |            fog_scope, capab.) |
          +---------------------------------------------------------->|
     (fog node C registered)          |                |              |
          |             |             |                |              |

                    Figure 2: Autonomic setup of fog agents





  Bernardos, et al.        Expires 5 January 2024                 [Page 8]


  Internet-Draft          GRASP for fog monitoring               July 2023


     *  The fog monitoring controller is regularly sending periodic
        multicast advertisement messages, which include its ID as well as
        the scope for the advertisement messages (i.e., the scope of where
        the messages have to be flooded).

        M_DISCOVERY messages are used, with new objectives and objective
        options.  GRASP specifies that "an objective option is used to
        identify objectives for the purposes of discovery, negotiation or
        synchronization".  New objective options are defined for the
        purposes of discovering potential fog agents with certain
        characteristics.  Non-limiting examples of these options are
        listed below (note that the names are just examples, and the ones
        used have to be registered by the IANA):

        -  FOGNODERADIO: used to specify a given type of radio technology,
           e.g.,: WiFi (version), D2D, LTE, 5G, Bluetooth (version), etc.

        -  FOGNODECONNECTIVITY: used to specify a given type of
           connectivity, e.g., layer-2, IPv4, IPv6.

        -  FOGNODEVIRTUALIZATION: used to specify a given type of
           virtualization supported by the node where the agent runs.
           Examples are: hypervisor (type), container, micro-kernel, bare-
           metal, etc.

        -  FOGNODEDOMAIN: used to specify the domain/owner of the node.
           This is useful to support operation of multiple domains/
           operators simultaneously on the same fog network.

        An example of discovery message using GRASP would be the following
        (in this example, the fog monitoring controller is identified by
        its IPv6 address: 2001:DB8:1111:2222:3333:4444:5555:6666):

        [M_DISCOVERY, 13948745, h'20010db8111122223333444455556666',
        ["FOGDOMAIN", F_SYNCH_bits, 2, “operator1”]]

        GRASP is used to allow the fog agents and the controller discovery
        in an autonomic way.  The extensions defined above, together with
        the use of properly scoped multicast addresses (as explained
        below), allow to precisely define which nodes participate in the
        monitoring and to gather their principal characteristics.

     *  When a fog node bootstraps, such as nodes A and B in the figure,
        they start sending multicast discovery messages within a given
        scope, that is, the intended area that composes the fog.  The
        definition of the scope depends on the scenario, and examples of
        possible scopes are:




  Bernardos, et al.        Expires 5 January 2024                 [Page 9]


  Internet-Draft          GRASP for fog monitoring               July 2023


        -  All-resources of a given manufacturer.

        -  All-resources of a given type.

        -  All-resources of a given administrative domain.

        -  All-resources of a given user.

        -  All-resources within a topological network distance (e.g.,
           number of hops).

        -  All-resources within a geographical location.

        -  Etc.

        Combination of previous scopes are also possible.

        The discovery messages are multicast within the scope, reaching
        all the nodes that compose the specified fog resources.  This can
        be done for example using well defined IPv6 multicast addresses,
        specified for each of the different scopes.  This signaling is
        based on GRASP.  Different IPv6 multicast addresses need to be
        defined to reach each different scope, using scopes equal or
        larger than Admin-Local according to [RFC7346].

     *  In response to multicast fog discovery messages, the fog
        monitoring controller replies with unicast messages providing its
        information.

     *  Fog agents can then register with a controller.  The registration
        message is unicast, and includes information on the capabilities
        of the fog node, such as:

        -  Type of node.

        -  Vendor.

        -  Energy source: battery-powered or not.

        -  Connectivity (number of network interfaces and information
           associated to them, such as radio technology type, layer-2 and
           layer-3 addresses, etc.).

        -  Etc.

        Note that registration to multiple fog monitoring controller
        instances could also be possible if a fog node wants to belong to
        several fog domains at the same time (but note that how the



  Bernardos, et al.        Expires 5 January 2024                [Page 10]


  Internet-Draft          GRASP for fog monitoring               July 2023


        orchestration of the same resource is done by multiple
        orchestrators is not covered by this invention).  The defined
        mechanisms support this via the use of fog IDs and FOGNODEDOMAIN
        options.

     *  A fog node C bootstraps after nodes A and B are already
        registered.  The same discovery process is followed by fog node C,
        but in addition to the regular advertisement, registration
        procedures described before, existing neighboring fog agents (such
        as A and B in this example), might also respond to discovery
        messages sent by bootstrapping nodes to provide required
        information.  This makes the procedure faster, more efficient and
        reliable.  In addition to helping the fog monitoring controller in
        the fog agent discovery process, fog agents learn themselves about
        the existence and associated capabilities of other fog agents.
        This can be used to allow autonomous monitoring by the fog agents
        without the involvement of the central controller.

  4.  Discovery Notification and Telemetry Publication

     Once a fog node has been discovered, the fog monitoring controller
     notifies the management and operation system — MANO system — that the
     node has been discovered and provides its identifier.  The MANO
     system will record it and, when needed, require the provision of
     telemetry data.  It will be provided by the fog monitoring controller
     by direct notification or publication, depending on the environment
     that the fog monitoring controller and MANO system are deployed.  The
     procedure is represented in Figure 3.























  Bernardos, et al.        Expires 5 January 2024                [Page 11]


  Internet-Draft          GRASP for fog monitoring               July 2023


     +--------+
     |  fog   |
     | node X |                +------+
     |        |                | fog  |               +--------+
     | |    | |                | mon. |               |  MANO  |
     | +----+ |                | ctrl |               | System |
     +--------+                +------+               +--------+
          |                        |                      |
      (fog node X                  |                      |
       bootstrap)                  |                      |
          |         periodic mcast |                      |
          |          advertisement |                      |
          |        (ID, fog_scope) |                      |
          |<-----------------------+                      |
          |                        |                      |
          | Mcast discovery        |                      |
          | (fog_node_ID, scope)   |                      |
          +----------------------->|                      |
          |                        |                      |
          |  Unicast advertisement |                      |
          |        (ID, fog_scope) |                      |
          |<-----------------------+                      |
          |                        |                      |
          | Uniast registration    |                      |
          | (ID, fog_node_ID       |                      |
          |  fog_scope, capab.)    |                      |
          +----------------------->|                      |
          |                        |                      |
      (fog node X                  |                      |
       registered)                 |                      |
          |                        | Fog node discovered  |
          |                        | (ID, fog_node_ID     |
          |                        |  fog_scope, capab.)  |
          |                        +--------------------->|
          |                        |                      |
          |                        |              Get TKO |
          |                        |        (fog_node_ID) |
          |                        |<---------------------+
          |                        |                      |
          |                        | TKO                  |
          |                        | (fog_node_ID, data)  |
          |                        +--------------------->|
          |                        |                      |
          |                        |        ...           |
          |                        |                      |

           Figure 3: Discovery notification and telemetry publication




  Bernardos, et al.        Expires 5 January 2024                [Page 12]


  Internet-Draft          GRASP for fog monitoring               July 2023


     The fog monitoring controller is able to provide either raw telemetry
     data or processed telemetry data.  They will be encoded as a
     telemetry knowledge object (TKO).  This contains the data and
     necessary meta-data to describe the data, the function that has been
     applied to the data (if any), and other context information that is
     set by the requester of the TKO, as enabled by the fog monitoring
     controller.

     The fog monitoring controller will offer a way for MANO system to
     discover the functions it can apply to telemetry data.  Nevertheless,
     the specification of the available functions that the fog monitoring
     controller supports is out of the scope of this document.

  5.  IANA Considerations

     TBD.

  6.  Security Considerations

     TBD.

  7.  Acknowledgments

     The work in this draft will be further developed and explored under
     the framework of the H2020 5G-DIVE project (Grant 859881).

  8.  Informative References

     [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
                DOI 10.17487/RFC7346, August 2014,
                <https://www.rfc-editor.org/info/rfc7346>.

  Authors' Addresses

     Carlos J. Bernardos (editor)
     Universidad Carlos III de Madrid
     Av. Universidad, 30
     28911 Leganes, Madrid
     Spain
     Phone: +34 91624 6236
     Email: cjbc@it.uc3m.es
     URI:   http://www.it.uc3m.es/cjbc/


     Alain Mourad
     InterDigital Europe
     Email: Alain.Mourad@InterDigital.com
     URI:   http://www.InterDigital.com/



  Bernardos, et al.        Expires 5 January 2024                [Page 13]


  Internet-Draft          GRASP for fog monitoring               July 2023


     Pedro Martinez-Julia
     NICT
     4-2-1, Nukui-Kitamachi, Koganei, Tokyo
     184-8795
     Japan
     Phone: +81 42 327 7293
     Email: pedro@nict.go.jp












































  Bernardos, et al.        Expires 5 January 2024                [Page 14]


