Internet Agent Communication Protocol - INTEROP
draft-gebauer-iacp-interop-00
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) | |
|---|---|---|---|
| Author | Leonard Gebauer | ||
| Last updated | 2026-07-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-gebauer-iacp-interop-00
Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 28 July 2026
Expires: 29 January 2027
Internet Agent Communication Protocol - INTEROP
draft-gebauer-iacp-interop-00
Abstract
Ever since 1969 and the ARPANET, the internet has repeatedly been
faced with challenges that it has had to overcome—and has overcome.
Year after year, the number of users has grown, and year after year,
the complexity and range of ways in which the internet can be used
have expanded. With the advent of AI, we not only have a new type of
user, we have a different form of communication; the internet itself
is being attributed a completely different significance. If they are
not already, AIs will make up the majority of internet users in the
foreseeable future. The question of an ‘AgentNet,’ is not merely a
question concerning the internet; it is a question of how AIs will
interact within a global network in the future.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 January 2027.
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.
Gebauer Expires 29 January 2027 [Page 1]
Internet-Draft IACP - INTEROP July 2026
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 . . . . . . . . . . . . . . . . . . 2
2. Interoperability with other Protocols . . . . . . . . . . . . 2
2.1. Interoperability with WIMSE . . . . . . . . . . . . . . . 3
2.1.1. Trust Domain and Workload Identifier Mapping . . . . 3
2.1.2. Transport of WIMSE Credentials . . . . . . . . . . . 3
2.1.3. PSS as Transport for WIMSE Authentication . . . . . . 3
2.1.4. Gateway Integration . . . . . . . . . . . . . . . . . 4
2.1.5. Trust Domain Discovery . . . . . . . . . . . . . . . 4
2.2. Interoperability with AGTP . . . . . . . . . . . . . . . 5
2.2.1. IACP as Transport for AGTP Methods . . . . . . . . . 5
2.2.2. AGTP Identity Document as Discovery Resource . . . . 6
2.2.3. AGTP as the Method Layer over IACP . . . . . . . . . 6
2.2.4. Deployment Considerations . . . . . . . . . . . . . . 7
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Normative References . . . . . . . . . . . . . . . . . . 8
3.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document is merely a sub-I-D of the main I-D. For appendices,
acknowledgments, Security Considerations, IANA Considerations and
other information, please refer to the main I-D. This sub-I-D
contains only a 1:1 copy of the chapter it covers, to provide a
better basis for discussion.
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. Interoperability with other Protocols
Gebauer Expires 29 January 2027 [Page 2]
Internet-Draft IACP - INTEROP July 2026
2.1. Interoperability with WIMSE
IACP and the WIMSE architecture [I-D.ietf-wimse-arch] address
different layers of the workload communication stack. WIMSE defines
the architecture for workload identity and authentication, consisting
of three building blocks: trust domain, workload identifier, and
identity credentials [I-D.ietf-wimse-arch]. IACP provides the
routing and transport layer for agent-to-agent communication.
2.1.1. Trust Domain and Workload Identifier Mapping
A WIMSE trust domain SHOULD be identified by a fully qualified domain
name and maps to trust anchors for validating X.509 certificates and
JWK Sets for validating Workload Identity Tokens (WITs)
[I-D.ietf-wimse-arch].
An IACP EID (Ephemeral Agent Identity) MAY be mapped to a WIMSE
Workload Identifier [I-D.ietf-wimse-identifier]. The mapping is
deployment-defined and MAY be published in the IACP DHT under KEY =
SHA-256("wimse-map:" || Namespace).
2.1.2. Transport of WIMSE Credentials
IACP's Opaque Authorization Envelope (Section 5.7.2) MAY carry WIMSE
credentials (Workload Identity Tokens or Workload Identity
Certificates) as opaque byte arrays. IACP does not interpret the
internal structure of these credentials; it only guarantees
authenticated delivery and cryptographic integrity of the envelope.
For WIT validation, the verifier MUST validate the JWS signature and
the cnf.jwk claim as defined in Section 5.1 of
[I-D.ietf-wimse-workload-creds]. For WIC validation, the verifier
MUST validate the X.509 certificate chain and verify that the
certificate contains exactly one SubjectAltName extension of type URI
as defined in Section 6.1 of [I-D.ietf-wimse-workload-creds].
An IACP implementation that wishes to verify a carried WIT MAY call a
WIMSE verifier on the envelope bytes, following the verification
rules defined in [I-D.ietf-wimse-workload-creds].
2.1.3. PSS as Transport for WIMSE Authentication
IACP's Persistent State Sessions (PSS) MAY be used as the transport
layer for WIMSE authentication mechanisms (WPT, HTTP Signatures, or
mutual TLS). The WIMSE authentication establishes the workload
identity of the communicating parties; the IACP PSS provides the
reliable, secure channel.
Gebauer Expires 29 January 2027 [Page 3]
Internet-Draft IACP - INTEROP July 2026
In this deployment model: - IACP handles session establishment,
mobility, and fault tolerance - WIMSE handles workload identity
authentication and credential validation
For application-layer authentication, IACP MAY carry a WIT in the
Workload-Identity-Token header for use with HTTP Message Signatures
[I-D.ietf-wimse-http-signature]. For transport-layer authentication,
IACP MAY carry a WIC for use with mTLS [I-D.ietf-wimse-mutual-tls].
These bindings are deployment- specific and do not require changes to
the core IACP specification.
The combination provides both identity assurance and reliable
communication.
2.1.4. Gateway Integration
WIMSE defines gateway services that MAY implement identity proxy
functionality, including authentication, token exchange, and token
transformation [I-D.ietf-wimse-arch]. IACP's Layer 7 Application
Gateway (Section 5.7.2) MAY serve as such an identity proxy for WIMSE
credentials, forwarding opaque authorization envelopes containing
WITs or other WIMSE credentials without interpreting their internal
structure.
2.1.5. Trust Domain Discovery
A WIMSE trust domain MAY publish its trust anchors for discovery
using the mechanism defined in [I-D.schwenkschuster-wimse-trust-
domain-discovery]. The mechanism defines a WIMSE Trust Bundle, a JWK
Set document containing the trust anchors for both JWT-based (wimse-
jwt) and X.509-based (wimse-x509) credentials, and a discovery
endpoint at the well-known URI:
https://<trust-domain>/.well-known/wimse-trust-domain
An IACP relying party that receives a WIMSE credential from an
unknown trust domain MAY perform discovery to obtain the trust
anchors needed to validate the credential. The discovery procedure
follows Section 5.3 of [I-D.schwenkschuster-wimse-trust-domain-
discovery]. Discovered trust anchors MUST NOT override locally
provisioned trust anchors for the same trust domain.
Gebauer Expires 29 January 2027 [Page 4]
Internet-Draft IACP - INTEROP July 2026
2.2. Interoperability with AGTP
AGTP [I-D.hood-independent-agtp] and IACP address different layers
and concerns of the agent communication stack. AGTP provides a
dedicated application-layer protocol for AI agent traffic with native
intent-based methods, a cryptographic identity model, and protocol-
level observability and governance primitives. IACP provides
identity-locator separation, routing, mobility, and persistent
sessions for agent-to-agent communication.
The two protocols are complementary and MAY be composed in
deployments that require both agent-native methods and robust routing
and mobility support.
2.2.1. IACP as Transport for AGTP Methods
IACP's Persistent State Sessions (PSS) MAY be used as the transport
layer for AGTP method invocations. In this deployment model:
* The IACP PSS provides session continuity, mobility, and fault
tolerance across network transitions (generation counting,
MIGRATION_VECTOR, degraded multi-path routing). AGTP uses port
4480 by default [I-D.hood-independent-agtp].
* AGTP method invocations (QUERY, DISCOVER, DESCRIBE, EXECUTE,
DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY, and the Lifecycle
methods ACTIVATE, DEACTIVATE, REINSTATE, REVOKE, and DEPRECATE)
are carried as opaque payloads within IACP PSS_DATA_STREAM frames.
* The AGTP identity (Agent-ID) is a 256-bit value derived as SHA-256
of the Agent Genesis in its canonical-form serialization (with the
signature field excluded) [I-D.hood-independent-agtp,
Section 7.5.2]. It is independent of the IACP EID (Ephemeral
Agent Identity).
* A deployment MAY choose to map an IACP EID to an AGTP Agent-ID
through a deployment-specific mapping. Such mapping is out of
scope for this document.
The AGTP core method set consists of eighteen methods: cognitive
methods (QUERY, DISCOVER, DESCRIBE, INSPECT, SUMMARIZE, PLAN,
PROPOSE), mechanics methods (EXECUTE, DELEGATE, ESCALATE, CONFIRM,
SUSPEND, NOTIFY), and lifecycle methods (ACTIVATE, DEACTIVATE,
REINSTATE, REVOKE, DEPRECATE) [I-D.hood-independent- agtp,
Section 8.1.1].
Gebauer Expires 29 January 2027 [Page 5]
Internet-Draft IACP - INTEROP July 2026
2.2.2. AGTP Identity Document as Discovery Resource
AGTP defines an Agent Identity Document (application/vnd.agtp
.identity+json) that is returned when an agtp:// URI is resolved
[I-D.hood-independent-agtp]. An IACP agent that wishes to discover
an AGTP-speaking agent MAY resolve the AGTP URI and retrieve the
Agent Identity Document to learn the agent's capabilities, supported
methods, verification tier, and authority scopes.
The AGTP Agent Identity Document contains: - agent_id: the canonical
AGTP Agent-ID (256-bit hex-encoded) - methods: the set of supported
AGTP methods (from the eighteen- method floor or extended set) -
verification_tier: the verification tier (1, 2, or 3) per [I-D.hood-
independent-agtp, Section 7.1.9] - verification_path: the
verification path used at activation (dns-anchored, log-anchored,
hybrid, or org-asserted) - scopes_accepted: the authority scopes the
agent accepts (domain:action format) - capabilities: higher-level
service descriptors - trust_score: behavioral trust score on [0.0,
1.0]
IACP does not interpret the AGTP Identity Document; it is carried as
an opaque resource. The AGTP Identity Document MAY be retrieved via
the IACP DHT if a deployment chooses to store it there, or it MAY be
retrieved directly via AGTP URI resolution.
AGTP defines three verification tiers for identity anchoring [I-
D.hood-independent-agtp, Section 7.1.9]: - Tier 1 (Verified):
identity anchored via one of three paths: dns-anchored (DNS TXT
record), log-anchored (transparency log inclusion proof per RFC 9162/
RFC 9943), or hybrid (DNS + blockchain signature combination) - Tier
2 (Org-Asserted): organizational affiliation declared without
cryptographic verification - Tier 3 (Experimental): development-only,
not production-eligible
2.2.3. AGTP as the Method Layer over IACP
In a composed deployment, the following operational pattern applies:
1. The IACP EID Routing Protocol (ERP) establishes the agent's
identity and network location.
2. An IACP Persistent State Session (PSS) is established between
peers.
3. AGTP methods are invoked over the PSS channel. The AGTP Agent-ID
and Authority-Scope headers are carried alongside the IACP
headers.
Gebauer Expires 29 January 2027 [Page 6]
Internet-Draft IACP - INTEROP July 2026
4. IACP handles mobility and fault tolerance; AGTP handles the
semantic method vocabulary and governance (Attribution-Record,
Audit-ID, verification tiers).
This composition allows agents to benefit from both IACP's routing
and mobility capabilities and AGTP's intent-native method vocabulary
and observability primitives.
AGTP's Authority-Scope header uses the domain:action format (e.g.,
documents:query, payments:confirm) [I-D.hood-independent- agtp,
Appendix D]. When AGTP is composed over IACP, the Authority- Scope
header is carried as part of the AGTP payload within the IACP
PSS_DATA_STREAM frame. IACP does not enforce AGTP authority scopes;
enforcement remains at the AGTP layer.
2.2.4. Deployment Considerations
Deployments that compose IACP and AGTP SHOULD consider the following:
* Identity Mapping: If a deployment requires mapping between IACP
EIDs and AGTP Agent-IDs, a deployment-specific mapping mechanism
is required. Such mapping is out of scope for both
specifications. The mapping MAY be published in the IACP DHT
under KEY = SHA-256("agtp-map:" || Namespace) for discoverability.
* Session Continuity**: IACP PSS provides session continuity across
network transitions. AGTP method invocations carried over PSS
benefit from this continuity without AGTP-level mobility
mechanisms.
* Authority Scope: AGTP Authority-Scope headers are independent of
IACP's authorization model. A deployment MAY enforce both
independently or define a mapping between them. AGTP's Authority-
Scope uses the domain:action format; IACP's authorization model is
based on EID reputation and PoM.
* Governance: AGTP provides protocol-level observability and
governance (Attribution-Record, Audit-ID, verification tiers,
lifecycle methods ACTIVATE/DEACTIVATE/REVOKE/DEPRECATE). IACP
provides routing-level governance (EID reputation, PoM, 2PSE).
The two governance models are complementary and MAY be used
together in a composed deployment.
* Port and Transport: AGTP uses IANA-assigned port 4480 for both
TCP/TLS and QUIC [I-D.hood-independent-agtp, Section 12.1]. When
AGTP is composed over IACP, the AGTP messages are carried within
IACP PSS_DATA_STREAM frames, and the underlying port is determined
by the IACP transport configuration, not the AGTP port assignment.
Gebauer Expires 29 January 2027 [Page 7]
Internet-Draft IACP - INTEROP July 2026
* Trust Tiers: AGTP's verification tiers (1, 2, 3) are independent
of IACP's EID reputation system. A deployment MAY use AGTP's
verification_tier as an input to IACP's reputation calculations,
but such integration is deployment-specific and out of scope for
both specifications.
* Verification Paths: AGTP's verification_path field (dns-anchored,
log-anchored, hybrid, org-asserted) provides evidence of how the
agent's identity was anchored at activation time [I-D.hood-
independent-agtp, Section 7.1.9]. This information MAY be used by
IACP deployments to inform routing or policy decisions, but such
use is deployment-specific.
Interoperability with AGTP is OPTIONAL; IACP agents that do not
support AGTP composition operate as specified in the core IACP
specification.
3. References
3.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
3.2. Informative References
[I-D.ietf-wimse-arch]
Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload
Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
[I-D.ietf-wimse-identifier]
Rosomakho, Y. and J. Salowey, "Workload Identifier", Work
in Progress, Internet-Draft, draft-ietf-wimse-identifier-
03, 6 July 2026, <https://datatracker.ietf.org/doc/draft-
ietf-wimse-identifier/>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J., Schwenkschuster, A., Sheffer,
Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work
Gebauer Expires 29 January 2027 [Page 8]
Internet-Draft IACP - INTEROP July 2026
in Progress, Internet-Draft, draft-ietf-wimse-workload-
creds-02, 2 July 2026, <https://datatracker.ietf.org/doc/
draft-ietf-wimse-workload-creds/>.
[I-D.ietf-wimse-http-signature]
Salowey, J. and Y. Sheffer, "WIMSE Workload-to-Workload
Authentication with HTTP Signatures", Work in Progress,
Internet-Draft, draft-ietf-wimse-http-signature-04, 6 July
2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-
http-signature/>.
[I-D.ietf-wimse-mutual-tls]
Salowey, J. and Y. Rosomakho, "Workload Authentication
Using Mutual TLS", Work in Progress, Internet-Draft,
draft-ietf-wimse-mutual-tls-02, 6 July 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-
tls/>.
[I-D.schwenkschuster-wimse-trust-domain-discovery]
Schwenkschuster, A. and Y. Rosomakho, "WIMSE Trust Domain
Discovery", Work in Progress, Internet-Draft, draft-
schwenkschuster-wimse-trust-domain-discovery-00, 3 July
2026, <https://datatracker.ietf.org/doc/draft-
schwenkschuster-wimse-trust-domain-discovery/>.
[I-D.hood-independent-agtp]
Hood, C., "Agent Gateway Transport Protocol (AGTP)", Work
in Progress, Internet-Draft, draft-hood-independent-agtp,
2026, <https://datatracker.ietf.org/doc/draft-hood-
independent-agtp/>.
Author's Address
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 29 January 2027 [Page 9]