Artificial Intelligence Internet Foundation (AIIF)

USA waterbottling@icloud.com

This document describes a non-normative architecture for the AI Internet Protocol (AIIP), centered on the "ai" URI scheme. It focuses on a direct connection model for robots, devices, and software agents to communicate natively over AIIP.

This document introduces the architecture for the AI Internet Protocol (AIIP), which defines mechanisms and naming structures for AI-centric communication using the "ai" URI scheme. It outlines the motivation, scope, and structure of the protocol and provides a foundation for discussion and refinement within the IETF. The AIIP aims to enable standardized AI-native addressing and interaction models on top of existing Internet infrastructure. AI-enabled systems such as robots, devices, and intelligent software agents connect to and interact with Internet resources by initiating interactions using "ai://" identifiers. Resources and capabilities are identified and resolved using the AIIP model, allowing a consistent, verifiable invocation flow across heterogeneous networks and deployments. This work aligns with the URI framework defined in and follows the URI scheme registration procedures in . 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

AIIP: The AI Internet Protocol described in this document. AI System: A robot, device, or software agent that produces or consumes AI capabilities. Manifest: Signed metadata describing identity, capabilities, and endpoints for invocation.

AI systems (robots, devices, agents) SHOULD initiate interactions using "ai://" identifiers. Implementations treat the identifier as the primary handle for discovery and invocation and avoid embedding deployment-specific hostnames in application logic. This improves portability and enables consistent policy enforcement and auditing. AIIP operates at the application or protocol layer and is transport-agnostic. Implementations MAY use any suitable underlying network transport, including wired broadband, 4G or 5G cellular, satellite constellations, or private networks, provided the chosen transport satisfies deployment requirements for latency, throughput, and security. Devices SHOULD embed a resolver client, maintain trust anchors for verifying manifest signatures, and implement local policy for consent when capabilities imply risk (for example, payments, physical actuation, or signing). Implementations SHOULD define canonicalization and percent-encoding rules to avoid confusion during signature verification and policy checks.

The following illustrative flow shows direct connection and resolution:

Signed Manifest 3) Invoke per manifest ]]>

Example identifier (non-normative):

Resolution yields a signed manifest describing publisher identity, verification keys, capabilities (for example, "actuate", "inspect"), and one or more endpoints (for example, HTTPS URL or MQTT topic). The client verifies the manifest, selects an endpoint, and proceeds with invocation according to local policy.

Manifests SHOULD be integrity-protected and attributable (for example, JOSE or COSE signatures). Clients maintain trust anchors, perform expiry and revocation checks, and log resolutions and invocations for audit where appropriate. User interfaces for human-in-the-loop scenarios SHOULD present verified publisher identity and capability prompts when risk is material. Implementers SHOULD avoid embedding personal data in clear-text identifier components and prefer passing sensitive attributes within protected session channels. Canonicalization rules SHOULD be defined to mitigate spoofing and confusion attacks.

This document makes no requests of IANA.