| 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¶