Artificial Intelligence Internet Foundation (AIIF)

US aiinternetfoundation@icloud.com

Internet Independent Submission This document defines the architectural model for the Artificial Intelligence Internet Protocol (AIIP), including decentralized discovery and a byte-precise native envelope. AIIP enables stateless, verifiable invocation of autonomous systems using a resolve-invoke-receipt pattern over authenticated transports. Native AIIP is the default for machine-to-machine operation; HTTPS gateways are optional for human-facing access. Each invocation produces a cryptographically verifiable execution receipt, optionally including attestation evidence. Note Work in Progress.

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

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.

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.

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.

DNS Bootstrap Discovery For an AIIP identifier whose authority is a DNS name (for example, aiip://service.example/...), an implementation MAY perform bootstrap discovery by querying a DNS TXT record under _aiip.service.example. The TXT record value is a semicolon-separated set of key/value parameters. At a minimum, it SHOULD include an endpoint parameter indicating where detailed metadata can be retrieved. Example: The DNS record is intended for bootstrap only. Implementations SHOULD treat HTTPS metadata (Section ) as authoritative when available.

HTTPS Metadata Discovery An implementation MAY retrieve detailed AIIP metadata from the HTTPS well-known resource /.well-known/aiip on the authority host (see ). The retrieved document can provide resolver endpoints, verification keys or key references, and policy signals required to validate invocation metadata. The well-known document MUST be fetched over HTTPS and its authenticity and integrity MUST be validated using standard HTTPS server authentication. If both DNS bootstrap discovery and HTTPS metadata discovery are available, implementations SHOULD use the DNS record only to locate the HTTPS metadata.

Delegation Statements Discovery metadata MAY include delegation statements allowing an administrative domain to delegate subsets of its AIIP namespace or specific capabilities to other parties. Clients and resolvers MUST validate delegation chains prior to accepting invocation metadata derived from delegated authority.

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.

Byte Order All multi-octet integer fields are encoded in network byte order (big-endian). Unless otherwise specified, fields are unsigned.

32-Byte Header An AIIP message is encoded as: Wire = Header(32) || Payload(PayloadLen) || Signature(SigLen). The header is exactly 32 octets.

AIIP Header Layout (32 bytes)

No reserved fields exist beyond the fixed 32-byte header; the signature bytes follow the payload. Flags is a 16-bit bitmask. Bit 0 (0x0001) indicates that the requester requires a receipt in the response. Other bits are reserved for future use. Example header bytes (illustrative only): Payload is UTF-8 JSON. Binary fields (when needed) are represented using base64url strings.

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 (). The specific receipt schema is expected to evolve with implementation experience. Illustrative receipt container: Receipt structure sketch (informative, ASN.1-like):

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.

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.

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.

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.

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

Normative References

Author's Address Aram Sogomonian
Artificial Intelligence Internet Foundation (AIIF)
United States of America
Email: aiinternetfoundation@icloud.com