Architecture for the Artificial Intelligence Internet Protocol (AIIP)

Status of This Memo

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 17 June 2026.¶

Copyright Notice

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

Table of Contents

1. Introduction

AIIP provides a uniform address space and invocation model for AI resources with verifiable outcomes. The architecture follows a resolve-invoke-receipt pattern.¶

Autonomous systems communicate natively using AIIP envelopes over authenticated transports. Human operators and supervisory systems can access AIIP resources via HTTPS gateways for compatibility with Web-based tools.¶

This revision adds discovery metadata (DNS bootstrap plus HTTPS well-known) and an autonomous delegation use case.¶

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 [RFC2119] and [RFC8174].¶

2. Architectural Overview

AIIP separates addressing, invocation, and verification into distinct steps: (1) discovery and resolution provide invocation metadata; (2) invocation is carried in a native AIIP envelope; (3) the response includes an execution receipt that can be verified independently.¶

3. Native Autonomous Access Model

Autonomous systems, including robots, industrial controllers, agents, and embedded devices, use AIIP natively. In native mode, AIIP envelopes are exchanged directly between client and resource over an authenticated transport such as mutual TLS or QUIC.¶

Native AIIP invocation does not depend on HTTP semantics, cookies, or browser-originated state. Authorization, policy enforcement, and result verification are defined by AIIP.¶

Human operators and management interfaces typically interact with AIIP resources through HTTPS gateways. These gateways provide compatibility with Web-based clients but are not required for autonomous operation.¶

4. Discovery and Delegation Metadata

AIIP supports decentralized discovery using two complementary mechanisms: DNS-based bootstrap discovery and HTTPS-based detailed metadata retrieval. This design avoids reliance on any single global resolver by allowing each administrative domain to publish its own resolution parameters and delegation information.¶

_aiip.service.example.  IN TXT  "v=aiip1; endpoint=https://service.example/.well-known/aiip"

5. Native Envelope Framing

AIIP invocations are carried in a byte-framed envelope suitable for native machine-to-machine transports. The wire format defined here is transport-agnostic: authenticated transports provide confidentiality and channel security, while the AIIP envelope provides a stable framing and replay-resistant metadata.¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |          Magic "AIIP"         | VerMaj|VerMin|   Flags (16)    |
 +-------------------------------+-------------------------------+
 |          PayloadLen (32)      |           SigLen (16)         |
 +-------------------------------+-------------------------------+
 |                         Nonce (64)                            |
 +---------------------------------------------------------------+
 |                      TimestampMs (64)                         |
 +---------------------------------------------------------------+
Bytes:  0..3   Magic (0x41 49 49 50)
        4      VerMaj (this document: 1)
        5      VerMin (this document: 0)
        6..7   Flags
        8..11  PayloadLen
        12..13 SigLen
        14..15 Rsv16 (MUST be 0)
        16..23 Nonce
        24..31 TimestampMs

41 49 49 50  01 00  00 01  00 00 00 9C  00 40  00 00
2F 7A 13 44  9B 02 5D 8A  00 00 01 93  8F 4C 3A 10

6. Execution Receipts

Each successful invocation produces an execution receipt that can be verified independently of transport intermediaries. Receipts bind the invocation identifier, relevant policy context, and execution outcome.¶

This document illustrates a JWS-based receipt container ([RFC7515]). The specific receipt schema is expected to evolve with implementation experience.¶

Illustrative receipt container:¶

{
  "protected": "base64url(jws-protected-header)",
  "payload": {
    "txid": "b7f7cfd2-6c38-4d7a-8e5a-6f1e1d9e0a10",
    "ts": 1734149100000,
    "result": { "status": 200, "data_commitment": "base64url(hash)" },
    "policy": { "max_speed_mps": 0.5, "forbidden_zones": ["Z1", "Z2"] },
    "attestation": { "tee": "base64url(attestation-evidence)" }
  },
  "signature": "base64url(jws-signature)"
}

Receipt structure sketch (informative, ASN.1-like):¶

AIIP-Receipt ::= SEQUENCE {
  txid            UUID,
  ts              INTEGER,            -- milliseconds since epoch
  resultCommit    OCTET STRING,       -- hash/commitment
  policy          SEQUENCE OF UTF8String OPTIONAL,
  attestation     OCTET STRING OPTIONAL,
  sigAlg          OBJECT IDENTIFIER,
  signature       OCTET STRING
}

7. Use Case: Autonomous Delegation

AIIP enables explicit delegation of real-world actions to autonomous agents without disclosure of user credentials and without interactive authorization at execution time. A user may delegate a capability (for example, aiip://user.phone/call) to an AI agent once, under defined policy constraints.¶

After delegation, any authorized AI agent may invoke the delegated capability directly using AIIP. Invocation does not require access to passwords, OAuth tokens, or user sessions. Each execution produces a verifiable receipt binding the user’s authorization, the invoked action, and the execution outcome.¶

Example invocation:¶

aiip://user.phone/call?to=+15551234567&text=I'm+late

The resulting execution receipt provides non-repudiable evidence that the user authorized the action and that it was executed as requested. This delegation model enables autonomous agents to perform actions such as calls, messages, device control, or payments without exposing credentials or requiring repeated user interaction.¶

8. HTTPS Gateway Profile

An HTTPS gateway translates Web-based requests into AIIP invocations and returns results with receipts to human-facing clients.¶

The HTTPS gateway is a compatibility layer for human operators and MUST NOT be required for autonomous or machine-to-machine AIIP invocation.¶

9. Security Considerations

AIIP implementations MUST authenticate peers via the selected transport binding, prevent replay, and ensure integrity of invocation and receipt data.¶

Execution receipts provide non-repudiable evidence of authorization and execution, suitable for audit, dispute resolution, and legal review.¶

10. Privacy Considerations

Implementations SHOULD minimize retained metadata and avoid correlating invocations beyond what is required for verification. Delegations SHOULD be scoped minimally to avoid over-exposure of capabilities or metadata.¶

11. IANA Considerations

This document makes no IANA requests. Future revisions may request registration of well-known resources used for AIIP discovery.¶

Author's Address