AI URI Scheme

The ai URI scheme identifies AI-addressable resources such as agents, models, tools, and tasks. Deployments MAY resolve ai: identifiers natively within AI systems and robots, or via HTTPS gateways for compatibility with existing web stacks. For clarity, this document uses the term AIIP to denote the Artificial Intelligence Internet Protocol, the operational protocol by which ai:// resources are addressed, resolved, and invoked. While ai:// is the URI scheme, AIIP defines resolution and interaction semantics. 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.

The scheme follows . An informal summary is shown: Examples (illustrative only):

Many user agents will not natively implement the ai scheme or the Artificial Intelligence Internet Protocol (AIIP). To enable immediate interoperability, deployments MAY expose ai:// resources via HTTPS gateways so that end users remain on conventional websites while backends or trusted intermediaries invoke AIIP. In this model, a relying party (for example, an online bank) advertises an ai:// endpoint and resolves it server-side or through a gateway; the user continues to interact over HTTPS without needing to understand ai://.

HTTPS origins that rely on AIIP SHOULD advertise their ai:// endpoints using one or more of:

HTTP Link header on responses: ; rel="aiip" ]]>
HTML link relation for progressive enhancement: ]]>
Well-known resource at /.well-known/aiip:
DNS bootstrap (optional), for example, SRV or TXT records:

A conforming HTTPS to AIIP gateway MUST map an embedded ai:// URI to an HTTPS URL under its control, perform AIIP resolution, and translate the result back into HTTPS semantics for the client. For example: Gateways MUST:

Parse and normalize the ai:// URI; reject malformed or ambiguous inputs.
Authenticate to the AI endpoint and verify provenance of responses (for example, JWS with a key discoverable via the origin's JWKS).
Enforce authorization consistent with the user's web session (for example, token exchange, DPoP, or mTLS constraints).
Preserve confidentiality and integrity at least equivalent to TLS 1.3 and obey HTTP semantics .
Prevent downgrades; do not weaken authentication or authorization versus native AIIP.

Web user agents NEED NOT implement AIIP. Sites may perform all AI resolution server-side or via a trusted gateway. This enables gradual deployment: users remain on HTTPS while services invoke ai:// under the hood to complete actions (for example, initiating a payment).

Responses returned from AIIP resolution MUST include verifiable provenance (for example, a detached or embedded signature). Gateways and relying parties MUST reject unverifiable or policy-incompatible results. Implementations SHOULD publish a JWKS for verification and rotate keys per operational policy.

To support global uniqueness and safe operation of autonomous systems, namespace administration for ai: identifiers is expected to be coordinated by the Artificial Intelligence Internet Foundation (AIIF), which serves as the umbrella governance body. The AIIF Registry Authority for Identifiers (AIID) operates the AI Root Registry and administers identifier allocation and operational policy for ai:// namespaces. This administrative role is separate from the technical specification of the scheme and protocol.

Implementations that dereference ai: identifiers MUST authenticate endpoints and apply authorization and safety policies, especially when actions may control physical devices or financial operations. Gateways translating ai: to HTTPS MUST preserve provenance and provide transport security per and semantics conforming to .

Accessing ai:// resources through HTTPS gateways may expose metadata such as target identifiers, origin site, and timing information to intermediaries. Gateways SHOULD minimize logging, apply strict data retention limits, and avoid retaining identifiers longer than operationally necessary. Provenance and result signatures may contain linkable identifiers; deployments SHOULD apply least-privilege scopes and anonymization where appropriate.

Identifiers in ai:// URIs follow . Non-ASCII characters appearing in the path or query components MUST be percent-encoded. Any authority components mapped from DNS MUST follow IDNA processing where applicable. No additional internationalization mechanisms are defined by this document.

This document requests Provisional registration of the ai URI scheme per .

This section provides the registration template for the ai URI scheme in accordance with Section 3.4. Change controller: The author of this document (or a designated successor) References: This document; RFC 3986; RFC 7595; RFC 8446; RFC 9110 Security considerations: See "Security Considerations" of this document ]]>