Internet-Draft | AI URI | October 2025 |
Sogomonian | Expires 5 April 2026 | [Page] |
This document specifies the experimental ai
Uniform
Resource Identifier (URI) scheme. The scheme provides a
dedicated access point for Artificial Intelligence (AI)
resources, enabling autonomous systems and robots to connect
natively while allowing human-facing applications to
interoperate via HTTPS gateways.¶
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 5 April 2026.¶
Copyright (c) 2025 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The scheme follows [RFC3986]. An informal summary is shown:¶
ai-uri = "ai:" hier-part [ "?" query ] [ "#" fragment ] ; hier-part, query, fragment per RFC 3986¶
Examples (illustrative only):¶
ai:/agent/forklift-42?task=load&zone=A3 ai://factory.example/pay?amount=10¤cy=USD¶
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:¶
Link: <ai://bank/service/payments>; rel="aiip"¶
HTML link relation for progressive enhancement:¶
<link rel="aiip" href="ai://bank/service/payments">¶
Well-known resource at
/.well-known/aiip
:¶
{ "endpoint": "ai://bank/service/payments", "jwks": "https://www.bank.example/.well-known/aiip.jwks.json", "scopes": [ "initiate-payment", "check-balance" ], "policy": { "auth": "oauth2", "mtls": true, "requireSignedResults": true } }¶
DNS bootstrap (optional), for example,
SRV
or TXT
records:¶
_aiip._tcp.bank.example. 300 IN SRV 0 0 443 aiip.bank.example. _aiip.bank.example. 300 IN TXT "endpoint=ai://bank/service/payments"¶
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:¶
Original: ai://bank/service/payments?amount=10¤cy=USD Gateway : https://ai.example/gateway/bank/service/payments ?amount=10¤cy=USD¶
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 [RFC8446] and obey HTTP semantics [RFC9110].¶
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
[RFC8446] and semantics conforming to
[RFC9110].¶
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
[RFC3986]. 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 [RFC7595].¶
This section provides the registration template for the
ai
URI scheme in accordance with
[RFC7595] Section 3.4.¶
Scheme name: ai Status: Provisional Applications/protocols that use this scheme: AIIP (Artificial Intelligence Internet Protocol) Contact: Aram Sogomonian <waterbottling@icloud.com> 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¶