AIIP Core: Agent Access Plane, AIID, Resolve, Invoke, and Receipt

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 13 March 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. 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

AIIP is a native agent access plane peer to HTTPS for the human web. Agents are named by AIID, addressed with the aiip: URI scheme, and exchange Resolve, Invoke, and Receipt messages over a secure underlay (TLS in the lab profile). Identity is AIID; IP addresses, hostnames, ports, and tunnel tips are locators only.¶

The Artificial Intelligence Internet Foundation (AIIF) may prepare documentation and optional underlay hosting. AIIF is not a wire identity and is not a runtime dependency of Invoke or Receipt.¶

This -00 package stays lean: plane split, AIID, URI, Resolve/Invoke/ Receipt, disposable underlay, independence (pipes never authority), mesh tip attest, and Experimental Access Fabric punch. World services (mailbox, channels, market, jobs, presence) remain informative companions and are not elevated to core MUSTs here.¶

2. Conventions and 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.¶

AIID: Agent identity string beginning with "aiid.". AIIP: AI Internet Protocol - agent access plane messages. Grant: Signed delegation binding subject, executor, and action. Locator: Underlay host and port (or equivalent) returned by Resolve. Receipt: Signed proof of execution returned by an access point. Tip: Disposable underlay locator advertisement (mesh / seeds). Punch: Experimental hole-punch coordination (Access Fabric).¶

3. Planes

Conforming deployments MUST preserve separation of:¶

(1) Agent access plane - AI agents named by AIID; aiip: + AIIP messages (Resolve, Invoke, Receipt) over a secure underlay.¶

(2) Human web plane - people and browsers; DNS / www; https: (and http: where applicable).¶

(3) Human control plane (optional) - HTTP(S) interfaces for humans to govern AIID state and inspect receipts. Control-plane HTTP(S) MUST NOT be the agent Invoke path.¶

Agents MUST use AIIP for Invoke. Agents MUST NOT use HTTP or HTTPS as their Invoke path. Agents MUST likewise use AIIP (not HTTP/HTTPS) for Resolve. AIIP clients MUST reject http: and https: URIs as addressing the wrong plane.¶

4. Transport and Framing

Access points and registries listen on TLS. Application messages are length-prefixed JSON frames:¶

frame = uint32_be(length) || utf8_json_bytes length = number of bytes in utf8_json_bytes max = 16 MiB¶

Receivers MUST accept standard JSON. Underlay assists (NAT reverse tunnels, disposable public tips) MUST remain replaceable locators and MUST keep AIIP TLS end-to-end when used as byte-transparent assists (lab profile name: aiip-tunnel-0).¶

Optional future carriers (QUIC, Noise with post-quantum hybrid, MLS long sessions) are out of scope for this document and MUST NOT be treated as normative for aiip-wire-0. See lab companion [TRANSPORT-ROADMAP-v0] (informative / Future).¶

5. Cryptography

Signatures: Ed25519. Public keys on the wire: raw 32-byte key, standard Base64 (not PEM). Signatures on the wire: Base64 of the 64-byte Ed25519 signature. Bytes signed = canonical JSON of the signed field object:¶

JSON serialization(obj, sort_keys=True, separators=(",", ":"), ensure_ascii=False).encode("utf-8")¶

result_hash = SHA-256 hex (lowercase) of canonical JSON of the result object (or wrapped non-dict values as defined by the implementation profile).¶

6. AIID

6.1. Syntax¶

An AIID MUST begin with the label prefix "aiid.".¶

Lab-aligned syntax (profile aiip-wire-0):¶

aiid = "aiid" "." org-label *( "." label )¶

Labels are alphanumeric plus hyphen, with no leading or trailing hyphen. Example: aiid.agent-1.example-1.¶

Production documents SHOULD align label rules with the AIID namespace Internet-Draft when available.¶

6.2. Operational States¶

An AIID has an operational state. For this core profile, states include at least: active, safe_mode, suspended, revoked.¶

An AIID in state revoked, suspended, or safe_mode MUST NOT participate in new Invokes as invoker or as executor. Only an AIID in state active MAY appear as invoker_aiid or executor_aiid on a new Invoke. revoked is terminal for participation purposes unless an explicit re-issuance procedure is defined by the registry authority.¶

7. URI Scheme aiip:

The aiip: URI scheme identifies resources and actions on the AIIP agent access plane. It is peer to https: on the human web plane.¶

Valid forms in profile aiip-wire-0:¶

aiip:<aiid> aiip:<aiid>?action=<action> aiip://<aiid>/<action> aiip://<aiid>/<action>?action=<ignored-if-path-set>¶

If action is omitted, a profile default MAY apply (aiip-wire-0 lab default: demo.example).¶

Client algorithm for an aiip: target:¶

1. Parse the URI into AIID and action. 2. Resolve the AIID at the registry. 3. Require success, state == active, and a non-null access_point locator with host and port (or equivalent). 4. Open a secure connection to that locator. 5. Send Invoke (including a valid grant where required). 6. Receive and verify Receipt; treat execution as done only if verification succeeds and status indicates success.¶

8. Resolve

Before sending an Invoke to an executor, an AIIP client MUST Resolve the executor AIID at the registry (or an equivalent authoritative resolution service). The client MUST proceed with Invoke only if Resolve succeeds, the AIID state is active, and an access-point locator is present.¶

Underlay addresses returned by Resolve are locators only. They MUST NOT be treated as identity. Identity is the AIID.¶

Request (lab profile):¶

{ "op": "resolve", "aiid": "aiid.agent-1.example-1" }¶

Success includes at least: ok, aiid, state, public_key, and optional access_point { host, port, transport }. Pure agents MAY return a null access_point. Multiple access points are allowed across the system: distinct executor AIIDs MAY advertise distinct locators.¶

9. Grants

A grant is signed by a principal Ed25519 key. Signed fields:¶

principal_aiid, subject_aiid, executor_aiid, action, exp¶

Full grant object = signed fields + signature (Base64). Verifiers MUST check the signature with the principal's public key and exp >= now. Humans MAY issue grants offline via a control interface. Agents attach the grant JSON to Invoke over AIIP. Issuing a grant over HTTP is not an Invoke.¶

10. Invoke

Every participant in an AIIP Invoke MUST be identified by an AIID.¶

Invoke is sent by the invoker to the executor's access point:¶

{ "type": "invoke", "invoker_aiid": "<aiid>", "executor_aiid": "<aiid>", "invocation_id": "<string>", "action": "<string>", "params": {}, "grant": {} }¶

The access point MUST: match executor_aiid to itself; require both invoker and executor active; verify the grant; execute the action; return a Receipt.¶

11. Receipt

Every participant in the corresponding Receipt MUST be identified by an AIID. A Receipt MUST include at least: receipt_id, executor_aiid, invoker_aiid, invocation_id.¶

Receipts that omit any of these fields MUST be treated as invalid. Absence of a valid, verified Receipt means the invocation MUST NOT be treated as executed for AIIP purposes.¶

Signed fields (lab profile): receipt_id, executor_aiid, invoker_aiid, invocation_id, status, result_hash, timestamp. Full receipt = signed fields + signature + optional result object (outside the signature payload). Success status value in aiip-wire-0: "ok".¶

12. Underlay Locators

Underlay IP addresses, hostnames, and ports are locators only. They MUST NOT be used as agent identity. Optional underlay assists (NAT reverse tunnels, disposable public tips such as free TCP relays) MUST remain replaceable. A tunnel tip MUST NOT become identity. Seeds carry genesis registry tips for join; private keys MUST NOT appear in seeds or join packs.¶

For genesis resilience, deployments SHOULD advertise and consume tips from multiple independent operators (multi-operator tips). Clients SHOULD NOT treat a single vendor door (one cloud host, one relay product) as the sole join path. Tip gossip and failover remain locator mechanics; they do not mint AIID authority.¶

13. Independence Doctrine

Companion document: [INDEPENDENCE].¶

Authority on the agent plane is AIID, grants, receipts, and (where used) mesh tip attestation. Underlay pipes and external platforms are never authority.¶

Implementations MUST NOT treat any of the following as identity or as Invoke authorization: HTTP(S) control UIs, vendor cloud accounts, disposable TCP relays, tunnel tips, DNS names alone, or optional bridges to third-party APIs.¶

Pipes (seeds tips, reverse tunnels, VPS roads, human on-ramps) MAY provide reachability. They MUST remain optional and replaceable. Local-sovereign operation (loopback registry and access tips only) MUST remain possible without a public relay.¶

AIIF prepares documentation and optional hosting; AIIF MUST NOT appear as a wire identity or as a required runtime dependency of Resolve, Invoke, or Receipt.¶

14. Mesh Tip Attestation

Mesh tip advertisements MAY carry a signed attestation binding an operator AIID to a tip locator for a limited TTL. Clients MAY prefer attested tips from operators in a local trust store.¶

Tip attestation is a trust layer for locator selection. It is NOT a blockchain ledger and MUST NOT move Invoke onto a chain. Unsigned or unknown tips MAY be accepted as untrusted locators unless a local policy requires attestation. Clients MUST NOT treat mesh tips as identity or as immortal.¶

Lab ops (informative): tip_announce, tip_list, tip_fetch, and related peer-find stubs. Profile remains aiip-wire-0. See lab companions MESH-SPEC-v0 and MESH.¶

15. Access Fabric Punch (Experimental)

Design freeze: [ACCESS-FABRIC].¶

Access Fabric punch coordination is Experimental lab wire for dual- NAT style connectivity assist. It is inspired by relay-first then coordinated hole-punch ideas; it does not claim IETF adoption.¶

Experimental registry ops (lab profile aiip-wire-0):¶

punch_offer - advertise underlay candidate locators via rendezvous punch_ready - signal readiness for simultaneous open punch_result - outcome: direct | fallback_relay (+ path metadata) punch_coord - umbrella create / status / attempt / nest¶

Rendezvous MUST be a mesh tip or registry peer identified in the agent plane - not a vendor STUN/TURN account as authority, and not an overlay that becomes the Invoke path.¶

Implementations MUST NOT treat punch success as identity. Punch establishes or selects a disposable underlay path only. Fallback to a relay path MUST remain allowed. Future transport profiles (QUIC / Noise-PQ / MLS) are informative only ([TRANSPORT-ROADMAP-v0]). Real dual-NAT measurement bars and guaranteed punch rates are out of scope for this -00 core; see lab companions [ACCESS-FABRIC] (and any dual-NAT lab notes when present).¶

Optional future transports (QUIC, Noise-PQ, MLS) are informative only; see [TRANSPORT-ROADMAP-v0]. They are not required for aiip-wire-0 interoperability.¶

16. Informative World Services

Lab profile aiip-wire-0 also exposes registry operations for discovery, receipt query, world map / presence, mailbox, channels, market listings, and jobs. Those services are informative companions for implementers and MUST NOT be treated as core MUSTs of this document ([AIIP-WORLD-v0]). See the companion index [AIIP-WORLD-v0] in the reference implementation tree. Market price fields, if present, are non- normative lab metadata only (no real-money settlement).¶

This core draft intentionally does not expand into a kitchen-sink catalogue of every lab service.¶

17. Security Considerations

Agents that accept HTTP(S) as an Invoke path collapse the plane split and enable confused-deputy and phishing risks against AIID holders. Grants are bearer delegations within their bind and expiry; principals MUST minimize scope and lifetime. Self-signed lab TLS is for lab interoperability only; production deployments need an explicit trust story. Underlay operators can observe connection metadata; they MUST NOT be treated as identity authorities. Treating punch success or a tip hostname as AIID identity undermines the independence doctrine.¶

18. IANA Considerations

This document makes no immediate IANA requests. Future revisions may request registration of the aiip: URI scheme and related registries.¶

Appendix A. Lab Profile aiip-wire-0

Interoperability with the reference MVP at the time of writing uses profile identifier aiip-wire-0. Breaking wire changes require a new profile identifier or a document that explicitly obsoletes this freeze. This appendix is informative.¶

Appendix B. Revision Note (2026-09-08)

Wire-harden refresh for IETF paste readiness (local file only; not uploaded to datatracker by this lab):¶

* Independence doctrine (Section 13): pipes != authority; AIIF not on wire. * Mesh tip attestation (Section 14): trust layer, not ledger; multi-operator tips SHOULD (Section 12). * Access Fabric punch ops (Section 15): Experimental punch_offer / punch_ready / punch_result / punch_coord; punch success MUST NOT be identity. * Transport roadmap (QUIC / Noise-PQ / MLS): Future / non-normative pointer only (Section 4). * World services remain informative (Section 16); core stays lean.¶

Filename draft-sogomonian-aiip-core-00 is an author draft name for later human upload. No RFC number is assigned. No Working Group adoption is claimed.¶

Author's Address