Gateway Capability Directory and Synchronization for Internet of Agents
draft-zhang-dmsc-gateway-directory-sync-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lianhua Zhang , Huiling Yang , Yun Li , Shoufeng Wang | ||
| Last updated | 2026-04-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-dmsc-gateway-directory-sync-01
Network Working Group L. Zhang
Internet-Draft H. Yang
Intended status: Informational Y. Li
Expires: 31 October 2026 S. Wang
AsiaInfo Technologies (China) Inc.
29 April 2026
Gateway Capability Directory and Synchronization for Internet of Agents
draft-zhang-dmsc-gateway-directory-sync-01
Abstract
This document describes a gateway capability-directory framework for
the Internet of Agents (IoA) in deployments that use Agent Gateways.
In such deployments, a gateway-managed capability directory is a
necessary control-plane function for maintaining validated capability
information beyond transient advertisements, static endpoint
bindings, or external descriptions alone. This document defines
requirements and a common object model for gateway-managed capability
information, including the Agent Capability Specification (ACS),
Capability Digest, and directory entry lifecycle. It also specifies
synchronization, freshness, provenance, and validation requirements
for capability information exchanged across gateways.
This document clarifies the relationship between gateway-managed ACS
objects and externally published descriptions such as the A2A Agent
Card, and briefly compares this framework with broader distributed
directory-service approaches. It does not define a discovery query
protocol, ranking algorithm, storage substrate, distributed lookup
algorithm, task orchestration protocol, or agent-to-agent session
protocol. It can inform subsequent DMSC protocol work, including
capability digest synchronization and related gateway procedures.
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."
Zhang, et al. Expires 31 October 2026 [Page 1]
Internet-Draft Gateway Capability Directory for IoA April 2026
This Internet-Draft will expire on 31 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
5. Directory Object Model . . . . . . . . . . . . . . . . . . . 5
5.1. Agent Capability Specification . . . . . . . . . . . . . 5
5.2. Capability Digest . . . . . . . . . . . . . . . . . . . . 6
5.3. Directory Entry States . . . . . . . . . . . . . . . . . 6
6. Lifecycle Requirements . . . . . . . . . . . . . . . . . . . 7
7. Synchronization Requirements . . . . . . . . . . . . . . . . 7
8. Freshness, Validation, and Provenance . . . . . . . . . . . . 8
9. DMSC Integration . . . . . . . . . . . . . . . . . . . . . . 9
10. Relationship to External Descriptions . . . . . . . . . . . . 10
11. Relationship to Other Directory Approaches . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
14. Normative References . . . . . . . . . . . . . . . . . . . . 11
15. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
As agent systems become increasingly distributed across heterogeneous
networks and administrative domains, a gateway-based deployment needs
a gateway-managed capability directory as a stable control-plane view
of capability information. A gateway cannot rely only on transient
advertisements, static endpoint bindings, or external descriptions if
it is expected to support capability visibility, semantic resolution,
policy enforcement, routing input, and interconnection across
gateways.
Zhang, et al. Expires 31 October 2026 [Page 2]
Internet-Draft Gateway Capability Directory for IoA April 2026
This document therefore describes a framework for gateway capability
directories and synchronization in IoA. It focuses on what
information a gateway-managed directory entry needs to contain, how
that information is derived and maintained, how much of it can be
synchronized across gateways, and what validation and provenance
guarantees are required before the information can be used by
routing, task invocation, or other collaboration functions.
Adjacent work is separating discovery from other interoperability
layers. DAWN is focusing on discovery problem statements,
terminology, and requirements, while explicitly excluding
registration processes, capability negotiation, task orchestration,
and agent-to-agent communication protocols [DAWN-PS] [DAWN-REQ].
This leaves DMSC-specific work on the gateway-side capability
directory that supports registration, synchronization, validation,
and handoff to collaboration protocols.
2. Conventions 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] and
[RFC8174].
The following terms are used in this document:
Agent Capability Specification (ACS): A gateway-managed, structured
capability description associated with an Agent Identity Code (AIC)
and constrained by local authorization and policy.
Capability Digest: A gateway-generated summary derived from one or
more ACS objects, intended for inter-gateway visibility and
synchronization rather than full capability disclosure.
Directory Entry: A versioned object stored or managed by a gateway
capability directory. A directory entry MAY contain a full ACS, a
derived digest, or related validation metadata.
Handoff Reference: Information returned by a gateway that enables a
subsequent interaction, invocation, or session establishment step.
Source Description: An externally or internally supplied capability
description that a gateway can ingest, normalize, or constrain.
Examples include an A2A Agent Card, a local registration payload, or
an operator-managed descriptor.
Freshness: The degree to which synchronized or cached information is
still valid for operational use.
Zhang, et al. Expires 31 October 2026 [Page 3]
Internet-Draft Gateway Capability Directory for IoA April 2026
Provenance: Evidence indicating where a directory entry originated,
how it was transformed, and what authority or gateway asserted it.
3. Scope and Non-Goals
This document specifies:
- A common framework for gateway capability directory objects in IoA
deployments.
- Requirements for ACS objects, capability digests, and directory
entry lifecycle.
- Requirements for synchronization, freshness, provenance, and
validation across gateways.
- The relationship between gateway-managed ACS objects and externally
published descriptions such as the A2A Agent Card.
This document does not specify:
- A discovery query protocol, query syntax, ranking algorithm, or
candidate selection policy.
- A naming system, global identifier resolution protocol, or generic
registry architecture for all entities.
- Agent-to-gateway advertisement messages, intent submission
messages, candidate-list response messages, routing-feedback
messages, or other wire-format exchanges of an intent-routing
protocol.
- Task orchestration, session establishment, or agent-to-agent
message exchange procedures.
- A domain-specific ontology or a full semantic negotiation protocol,
although semantic hooks MAY be carried by directory objects.
- A complete identity framework, trust framework, or credential
issuance system.
Zhang, et al. Expires 31 October 2026 [Page 4]
Internet-Draft Gateway Capability Directory for IoA April 2026
4. Architecture Overview
Within a gateway-based IoA deployment, the capability directory is a
gateway-side control-plane function. It receives or derives
capability descriptions during onboarding, associates them with an
AIC and authorized operational scope, maintains local directory
entries, and exposes suitable information to later functions such as
semantic resolution, task-based invocation, and inter-gateway
visibility.
The capability directory sits between registration/authorization and
collaboration/runtime procedures, as illustrated in Figure 1.
+----------------------------------+
| Registration / Authorization |
+----------------------------------+
| Gateway Capability Directory |
| - ACS |
| - Digest |
| - Validation Metadata |
+----------------------------------+
| Resolution / Handoff / TIP / A2A |
+----------------------------------+
Figure 1
Figure 1: Capability Directory Position
A gateway capability directory manages directory entries. A
directory entry may carry a full ACS, a derived Capability Digest, or
related validation metadata, depending on local use and disclosure
scope.
5. Directory Object Model
5.1. Agent Capability Specification
An ACS is the primary full directory object. An ACS MUST be bound to
a single AIC or equivalent local agent identity reference. An ACS
SHOULD be sufficient for local directory use, semantic resolution
input, handoff preparation, and policy evaluation.
An ACS SHOULD contain at least:
- a stable local identifier for the ACS entry;
- the bound AIC or equivalent identity reference;
Zhang, et al. Expires 31 October 2026 [Page 5]
Internet-Draft Gateway Capability Directory for IoA April 2026
- one or more capability references;
- input/output or modality references relevant to invocation and
compatibility;
- interface binding references and handoff references, if available;
- local status and version information;
- provenance and integrity metadata; and
- optional semantic hooks such as ontology identifier, ontology
version, or semantic-profile reference.
An ACS MAY additionally carry local policy constraints, region or
domain scope, deployment visibility, or runtime limitations. Such
information SHOULD be clearly distinguished from core capability
assertions.
5.2. Capability Digest
A Capability Digest is a derived object intended for synchronization
and visibility across gateways. A digest MUST be smaller in
disclosure scope than the corresponding ACS. It SHOULD reveal enough
information for coarse-grained matching, routing preparation, or
further query forwarding, while minimizing unnecessary internal
detail.
A Capability Digest SHOULD contain:
- a digest identifier and version;
- the asserting gateway or administrative domain identifier;
- one or more abstracted capability references or categories;
- visibility scope and freshness metadata; and
- provenance and integrity metadata.
A digest MAY contain handoff hints, interface categories, trust
indicators, or semantic summary references, provided these do not
disclose more information than permitted by local policy.
5.3. Directory Entry States
Directory entries SHOULD support an explicit lifecycle. The
following states are RECOMMENDED:
Zhang, et al. Expires 31 October 2026 [Page 6]
Internet-Draft Gateway Capability Directory for IoA April 2026
- active: entry is valid for operational use;
- suspended: entry is temporarily not usable but retained;
- deprecated: entry remains visible for compatibility but SHOULD be
replaced; and
- revoked: entry MUST NOT be used for new operational decisions.
Implementations MAY define equivalent states, but the effect on
visibility and use MUST be clear.
6. Lifecycle Requirements
A gateway MUST be able to create, update, deprecate, suspend, revoke,
and remove directory entries under local lifecycle control.
Registration and credential issuance themselves are out of scope, but
this document defines what the directory layer requires after
onboarding has completed.
At a minimum:
- a new ACS entry MUST be versioned at creation time;
- changes to bound identity, capability references, interface binding
references, semantic hooks, or integrity metadata SHOULD create a new
version or equivalent version transition;
- state changes MUST be auditable;
- revoked entries MUST be excluded from new handoff or resolution
results; and
- deprecated entries SHOULD indicate replacement or migration
information if available.
If an ACS is derived from an external source description such as an
A2A Agent Card, the gateway SHOULD distinguish source changes from
gateway-local changes. A source refresh that does not alter accepted
operational semantics MAY update freshness metadata without changing
the ACS semantic version.
7. Synchronization Requirements
Gateways in the same collaboration environment or across federated
domains MAY synchronize capability visibility information.
Synchronization MUST be policy-aware and SHOULD default to Capability
Digest exchange rather than full ACS replication.
Zhang, et al. Expires 31 October 2026 [Page 7]
Internet-Draft Gateway Capability Directory for IoA April 2026
A synchronization mechanism for directory information SHOULD support:
- initial establishment of baseline visibility;
- incremental updates for entry creation, modification, withdrawal,
and state transitions;
- version comparison or ordering sufficient to detect stale updates;
- explicit acknowledgement or equivalent delivery confirmation;
- conflict detection and local conflict resolution policy; and
- recovery after disconnection or partial state loss.
When multiple gateways provide conflicting information about the same
effective capability or identity reference, the receiving gateway
SHOULD consider provenance, signature status, administrative trust
policy, lifecycle state, and update freshness before accepting the
new information.
Synchronization procedures SHOULD be able to carry, or reference, the
following metadata:
- source gateway identifier;
- entry identifier and version;
- operation type;
- effective time or update time;
- optional replacement or revocation information; and
- integrity and provenance evidence.
8. Freshness, Validation, and Provenance
A gateway MUST evaluate whether directory information is still
suitable for operational use before returning it to semantic
resolution, handoff preparation, or task-routing logic.
Directory validation SHOULD include:
- integrity validation of the entry or synchronized update;
- freshness validation against local policy or advertised validity
information;
Zhang, et al. Expires 31 October 2026 [Page 8]
Internet-Draft Gateway Capability Directory for IoA April 2026
- lifecycle-state validation, including revocation awareness;
- provenance validation indicating which gateway or source asserted
the information; and
- semantic or profile reference validation when semantic hooks are
present.
Validation failure handling SHOULD distinguish between:
- invalid entry content;
- unverifiable provenance;
- stale information;
- revoked information; and
- locally disallowed disclosure or use.
An implementation MAY retain invalid or stale entries for audit or
troubleshooting purposes, but such entries MUST NOT be used for new
operational decisions unless explicitly allowed by local policy.
9. DMSC Integration
Within DMSC architecture, the capability directory is a gateway-side
control-plane function that supports other DMSC functions such as
semantic resolution, task-based invocation, and inter-gateway
visibility [MACP-02] [ACPS-ARC] [IOA-TASK].
This document is intended to be complementary to other DMSC work. It
refines the control-plane objects and requirements needed by
protocol-suite elements such as ACS/CDSP in MACP, by capability-
management and discovery functions in ACPs Architecture, and by
gateway functions such as delegated discovery, ID-based resolution,
and task-based searching [MACP-02] [ACPS-ARC] [GW-REQ].
It also provides a substrate that can be used by task-level
procedures and semantic-interoperability work, while remaining below
gateway-facing intent-routing behavior such as IAIP [IOA-TASK]
[IOA-SEM] [IAIP-00]. Accordingly, this document does not define
discovery query syntax or routing algorithms. Instead, the
capability directory defined here is intended to support other DMSC
functions as follows:
- semantic resolution procedures MAY use ACS or digest content as
inputs to capability matching and route preparation;
Zhang, et al. Expires 31 October 2026 [Page 9]
Internet-Draft Gateway Capability Directory for IoA April 2026
- task-based invocation procedures MAY use handoff references and
capability constraints derived from ACS content;
- gateway policy enforcement MAY use lifecycle state, provenance, and
local constraints stored with the directory entry; and
- semantic interoperability procedures MAY use optional ontology or
semantic-profile hooks carried by ACS content without redefining the
semantic layer itself.
10. Relationship to External Descriptions
A gateway capability directory can ingest or reference externally
supplied descriptions. Such external descriptions MAY be published
by an agent endpoint, a management system, or another authoritative
source. They are treated by this document as source descriptions
rather than as gateway-native directory objects.
A2A defines the Agent Card as one example of such an external
description. The Agent Card is a self-describing object published by
an agent endpoint for discovery and interaction setup, and includes
information such as identity, skills, supported interfaces, security
requirements, and other public metadata [A2A-SPEC].
An ACS is not the same object as an external description such as an
A2A Agent Card. An external description states what an agent claims
or offers for publication or exchange, while an ACS is a gateway-
managed, normalized, and policy-constrained directory object used by
DMSC infrastructure. A Capability Digest is a further abstraction
derived from ACS content for inter-gateway visibility.
A gateway MAY ingest an A2A Agent Card as one source description when
constructing an ACS. However, externally supplied description
content is not automatically suitable for directory synchronization
or operational use; it remains subject to local validation,
normalization, provenance tracking, and policy application.
11. Relationship to Other Directory Approaches
Other proposals are considering broader directory-service mechanisms
for agents. For example, the ADS draft discusses a distributed agent
directory service with content-addressed storage, taxonomy-based
discovery, content-routing, and peer-to-peer synchronization
[ADS-01].
Zhang, et al. Expires 31 October 2026 [Page 10]
Internet-Draft Gateway Capability Directory for IoA April 2026
This document has a narrower focus. It defines the gateway-managed
control-plane directory objects and requirements that a DMSC Gateway
needs in order to maintain validated capability information for local
use and inter-gateway visibility.
Accordingly, this document does not define a storage substrate,
content-addressed artifact model, distributed lookup algorithm,
taxonomy design, or generic search architecture. Such mechanisms
could be complementary if they are used as one backend, one exchange
environment, or one visibility mechanism for gateway-managed
directory information.
12. Security Considerations
Capability directories and synchronization channels are attractive
targets for poisoning, replay, downgrade, and unauthorized disclosure
attacks. Implementations SHOULD consider:
- integrity protection for ACS entries and synchronized digests;
- provenance continuity for derived objects, especially when
ingesting external descriptions such as A2A Agent Cards;
- freshness enforcement to prevent stale or replayed capability
visibility;
- access control over which entries may be disclosed, synchronized,
or returned for operational use; and
- auditability of lifecycle changes and synchronization decisions.
If semantic hooks are carried, implementations SHOULD also consider
risks related to ontology substitution, invalid alignment references,
or use of inconsistent semantic-profile versions.
13. IANA Considerations
This document makes no request for IANA action.
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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, 2017,
<https://www.rfc-editor.org/info/rfc8174>.
Zhang, et al. Expires 31 October 2026 [Page 11]
Internet-Draft Gateway Capability Directory for IoA April 2026
15. Informative References
[A2A-SPEC] Foundation, L., "A2A Protocol Specification", 2026,
<https://a2a-protocol.org/latest/specification/>.
[ACPS-ARC] Liu, J., Yu, K., Li, K., and K. Chen, "Agent Collaboration
Protocols Architecture for Internet of Agents", Work in
Progress, Internet-Draft, draft-liu-dmsc-acps-arc-03,
2026, <https://datatracker.ietf.org/doc/draft-liu-dmsc-
acps-arc/03/>.
[ADS-01] Muscariello, L. and R. Polic, "Agent Directory Service",
Work in Progress, Internet-Draft, draft-mp-agntcy-ads-01,
2026, <https://datatracker.ietf.org/doc/draft-mp-agntcy-
ads/01/>.
[DAWN-PS] Akhavain, A., Moussa, H., and D. King, "Problem Statement
for the Discovery of Agents, Workloads, and Named Entities
(DAWN)", Work in Progress, Internet-Draft, draft-akhavain-
moussa-dawn-problem-statement-00, 2026,
<https://datatracker.ietf.org/doc/draft-akhavain-moussa-
dawn-problem-statement/00/>.
[DAWN-REQ] King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-00,
2026, <https://datatracker.ietf.org/doc/draft-king-dawn-
requirements/00/>.
[GW-REQ] Liu, B., "Gateway Requirements for Dynamic Multi-agents
Secured Collaboration", Work in Progress, Internet-Draft,
draft-liu-dmsc-gw-requirements-00, 2026,
<https://datatracker.ietf.org/doc/draft-liu-dmsc-gw-
requirements/00/>.
[IAIP-00] Sun, S. and X. Zhang, "Intent-based Agent Interconnection
Protocol at Agent Gateway", Work in Progress, Internet-
Draft, draft-sz-dmsc-iaip-00, 2026,
<https://www.ietf.org/archive/id/draft-sz-dmsc-iaip-
00.txt>.
[IOA-SEM] Zhang, L., Yang, H., Li, Y., and S. Wang, "Ontology-based
Semantic Interaction for Internet of Agents", Work in
Progress, Internet-Draft, draft-zhang-dmsc-ioa-semantic-
interaction-02, 2026, <https://datatracker.ietf.org/doc/
draft-zhang-dmsc-ioa-semantic-interaction/02/>.
Zhang, et al. Expires 31 October 2026 [Page 12]
Internet-Draft Gateway Capability Directory for IoA April 2026
[IOA-TASK] Yang, C., Wang, P., Wu, J., and T. Huang, "Internet of
Agents Task Protocol for Heterogeneous Agent Teaming and
Cross-domain Collaboration", Work in Progress, Internet-
Draft, draft-yang-dmsc-ioa-task-protocol-01, 2026,
<https://datatracker.ietf.org/doc/draft-yang-dmsc-ioa-
task-protocol/01/>.
[MACP-02] Li, X., Liu, J., Du, C., and L. Zhang, "Multi-agent
Collaboration Protocol Suite", Work in Progress, Internet-
Draft, draft-li-dmsc-macp-02, 2026,
<https://datatracker.ietf.org/doc/draft-li-dmsc-macp/02/>.
Authors' Addresses
Lianhua Zhang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: zhanglh2@asiainfo.com
Huiling Yang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: yanghl10@asiainfo.com
Yun Li
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: liyun9@asiainfo.com
Shoufeng Wang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: wangsf11@asiainfo.com
Zhang, et al. Expires 31 October 2026 [Page 13]