Architecture for the Artificial Intelligence Internet Protocol (AIIP)

AIIP enables interoperable addressing and invocation of AI resources, including autonomous systems and human-facing services that delegate tasks to such systems. AIIP identifiers use the companion aiip URI scheme . Interoperation with the existing Web is provided via an HTTPS gateway profile. 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 RFC 2119 and RFC 8174 when, and only when, they appear in all capitals, as shown here.

Modern networks were designed for document delivery and passive data exchange over HTTP and HTTPS. Today, however, many connected systems perform physical actions with safety critical consequences. These systems require reliable control, safety enforcement, and verifiable execution guarantees beyond what HTTPS alone can provide. AIIP introduces a trust layer for autonomy. It ensures that each invocation is performed under an authenticated and authorized identity, is governed by declared safety policies, and results in a signed execution receipt that can be audited. A core requirement for autonomy is continuity. Network outages are inevitable, yet autonomous systems must remain operable and safe during disconnection. AIIP establishes the AIID namespace, enabling the following properties:

AIID identity for each AI resource or autonomous agent.
Cryptographic verification of origin and trust level.
Portability across networks and mobility domains.

With these properties, AIIP supports globally interoperable autonomy that is addressable, controllable, verifiable, and safe across both connected and disconnected conditions.

AI Resource: An addressable agent, model, tool, task endpoint, or robot controller.
AIIP Resolver: Software that dereferences an aiip:// URI to an actionable endpoint.
Gateway: An HTTPS service that accepts client HTTP requests, resolves embedded aiip:// URIs, and translates results back into HTTP semantics.
AIID: The AIIF Identifier Authority operating the root namespace and allocation policy.
Invocation Descriptor (IDesc): A JSON object returned by resolution that describes how to reach and authenticate to a resource, and which proofs and policies apply.
Autonomous Identity (AID): A cryptographic identity for an AI resource or agent whose trust level may evolve based on attested execution history.

AIIP follows a resolve-invoke pattern. Given an aiip:// identifier, the client or gateway performs Resolution to obtain an Invocation Descriptor and then performs a Message Exchange with the resource.

Resolver --(B)--> Resource | | +-- via HTTPS --Gateway+ (A) Resolve aiip://... (B) Invoke per descriptor ]]>

AIIP supports a dual namespace model to serve Web integrated services and autonomous objects:

Domain Based Names (service oriented): authority is a DNS name. Example: aiip://bank.example/service/payments.
Object Based Names (entity oriented): authority is an AIID allocated object namespace (for example aiid:org:1234) serialized into the authority or path. Example: aiip://id/aiid.org.1234/robot/forklift-42.

The AIIF Identifier Authority (AIID) MUST ensure global uniqueness for object based allocations and SHOULD publish delegation metadata usable by resolvers.

The normative URI syntax is defined in and follows the generic URI conventions of . HTTPS discovery uses any of the following mechanisms:

HTTP Link headers ()
HTML link rel="aiip"
/.well-known/aiip ()

Internationalization: non ASCII characters appearing in path or query components MUST be encoded in UTF-8 and the resulting octets MUST be percent encoded as per .

Resolution maps an aiip:// URI to an Invocation Descriptor (IDesc). An IDesc is a small JSON object describing how to reach and authenticate to the resource. Resolvers MUST validate the IDesc provenance and MUST reject conflicting or unverifiable data.

AIIP defines a simple request and response envelope that can be carried over different transports (HTTPS, mTLS TCP, QUIC). The envelope is JSON; binary payloads are carried via base64url fields. Results SHOULD be authenticity protected (for example detached JWS ) and include a monotonic timestamp and policy flags.

AIIP supports execution endpoints that do not retain caller data beyond the lifetime of a single invocation unless explicitly stated. Endpoints that do not persist data MUST advertise persistence equals none in their Invocation Descriptor. Implementations SHOULD make determinism explicit. If execution is non deterministic, responses MUST include transcript or seed commitments sufficient for external verification.

AIIP resources MAY advertise policy claims in their IDesc indicating operational constraints that the endpoint enforces. During network partition or degraded trust, endpoints MUST apply stricter safety defaults unless an explicit offline envelope authorizes otherwise.

Each successful invocation response MUST include a signed execution receipt proving that execution occurred under the advertised identity and policy. AIIP makes use of TEE based attestation evidence as defined by the RATS architecture . Endpoints MAY additionally include zero knowledge proofs for enhanced trust minimization. A receipt SHOULD contain a result commitment, execution transcript hash or equivalent, timestamp, algorithm identifiers, and the attestation evidence or ZKP object. Receipts MUST be JWS protected and verifiable using a JWKS referenced from the Invocation Descriptor.

AIIP supports disruption tolerant operation. When connectivity to external services is unavailable, endpoints MAY continue to operate within pre authorized offline envelopes. Receipts generated offline MUST remain verifiable using local keys and SHOULD be synchronized when connectivity is restored.

Compute receipts MAY be anchored to external settlement systems to provide independent auditability and economic finality. Settlement anchoring is optional and MUST NOT expose plaintext inputs.

A conforming gateway accepts HTTPS requests, validates embedded aiip:// URIs, performs Resolution, invokes the resource, and translates results into HTTP status codes and bodies.

Transport security MUST be at least TLS 1.3 .
Authorization context from the Web session MUST be enforced. Tokens SHOULD be bound using DPoP or mTLS.
Result provenance MUST be verified. Unverifiable results MUST be rejected.
Downgrade prevention: the gateway MUST NOT weaken authentication versus native AIIP.

AIIP operations can trigger physical actions or financial effects. Implementations MUST authenticate peers, enforce authorization, and apply safety policy.

Resolvers and gateways may expose metadata. Operators SHOULD minimize logging, apply retention limits, and prefer unlinkable proofs where feasible.

This document makes no IANA requests beyond referencing the provisional registration of the aiip URI scheme in .