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:///.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [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, . [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, . [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, . [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, . [I-D.hood-independent-agtp] Hood, C., "Agent Gateway Transport Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp, 2026, . Author's Address Leonard Gebauer Independent Germany Email: leonard.gebauer.ha@gmail.com Gebauer Expires 29 January 2027 [Page 9]