Independent Submission A. Sogomonian
Internet-Draft AIIF
Intended status: Informational 9 June 2026
Expires: 9 December 2026
AIID: An Identifier Namespace for Autonomous Systems
draft-sogomonian-aiid-namespace-00
Abstract
Autonomous systems operate today without stable, globally unique
identities. When an AI agent executes an action, there is no
universally recognized identifier for that agent, no delegation
record, and no accountability chain back to a human principal.
This document defines the Autonomous System Identifier (AIID)
namespace. An AIID is a structured, hierarchical identifier
assigned to an autonomous system, execution environment, or agent
operating within the Artificial Intelligence Internet Protocol
(AIIP) architecture [I-D.sogomonian-aiip-architecture].
This document specifies the AIID syntax, hierarchical structure,
registration model, operational states including safe mode, and
revocation mechanisms. The governance model for the namespace,
including selection of a root registry operator, is explicitly
left open for community determination.
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 9 December 2026.
Copyright Notice
Copyright (c) 2026 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
2. The Accountability Gap
3. AIID Syntax
4. Hierarchical Structure
5. Registration Model
6. Operational States and Safe Mode
7. Revocation
8. Namespace Governance
9. Security Considerations
10. IANA Considerations
11. Informative References
1. Introduction
The AIIP architecture [I-D.sogomonian-aiip-architecture] defines a
common execution model for autonomous systems based on a
resolve-invoke-execute-receipt pattern. For this model to function
across independently developed implementations, each participating
system must be uniquely and stably identifiable.
Existing identifier systems were not designed for autonomous
execution contexts. Domain names identify information resources.
IP addresses identify network endpoints. Neither provides the
identifier structure required for accountable autonomous execution
across organizational boundaries.
This document defines the AIID namespace to address this gap.
AIIDs are intended to be:
* Globally unique
* Hierarchically structured
* Revocable
* Bound to a verifiable root of trust
* Subject to human operational control
This document deliberately does not specify who operates the root
of the namespace. Governance questions, including the selection
of a root registry operator and the policy framework under which
it operates, are addressed in Section 8 and are explicitly left
open for community determination.
2. The Accountability Gap
Today autonomous systems — AI agents, robots, automated services,
and execution environments — operate without stable, globally
unique identities.
When an autonomous system executes an action today:
* There is no universally recognized identifier for that system
* There is no delegation record linking the action to a human
principal
* There is no verifiable receipt proving what occurred
* There is no mechanism to trace responsibility back to an
accountable human or organizational actor
* Nobody is formally responsible for what the system did
This situation is tolerable today because most autonomous actions
are low-stakes and easily reversible. It will not be tolerable
as autonomous systems increasingly operate in financial, medical,
industrial, physical, and safety-critical environments.
Consider what happens when an unidentified autonomous system:
* Executes a financial transaction
* Controls physical infrastructure
* Makes a decision with legal consequences
* Causes harm in a physical environment
* Acts outside its intended boundaries
Without identity, there is no accountability. Without
accountability, there is no basis for governance, liability,
or trust.
AIID proposes to close this gap before it becomes a crisis.
Every autonomous system that participates in AIIP execution
carries a stable, traceable identity. Every action can be
attributed. Every delegation chain traces back to a human
principal who bears responsibility.
Identity is therefore not a convenience feature of AIIP.
It is the foundation on which accountability, delegation,
policy enforcement, and human control are built.
3. AIID Syntax
An AIID is a dot-separated hierarchical identifier of the
following general form:
Figure 1: AIID Syntax
aiid ::= "aiid" "." organization "." identifier
Examples:
aiid.acme.robot-01
aiid.acme.agents.scheduler-7
aiid.example.agent-42
The components are defined as follows:
aiid:
The root label. Fixed as "aiid" for all identifiers in
this namespace.
organization:
A label assigned to a registrant by the root registry.
This label is unique within the root namespace.
identifier:
One or more labels assigned by the registrant to identify
a specific autonomous system, agent, robot, or execution
environment. Registrants may define sub-hierarchies within
their assigned namespace.
AIID labels consist of alphanumeric characters and hyphens.
Labels may not begin or end with a hyphen. Labels are
case-insensitive. The maximum total length of an AIID is
253 characters.
4. Hierarchical Structure
The AIID namespace is organized as a hierarchy beneath a single
root.
Figure 2: AIID Namespace Hierarchy
Root Registry
|
v
aiid.* (root namespace)
|
+-- aiid.acme.* (organization namespace)
| |
| +-- aiid.acme.robot-01 (leaf identifier)
| +-- aiid.acme.agents.* (sub-namespace)
|
+-- aiid.example.* (organization namespace)
The root registry is responsible for:
* Assigning organization-level namespace labels
* Maintaining the root registry database
* Publishing root trust material
* Operating under the governance framework described in
Section 8
Registrants are responsible for:
* Managing identifiers within their assigned namespace
* Maintaining accurate registration records
* Ensuring AIIDs within their namespace are not misused
* Managing operational states of agents under their namespace
5. Registration Model
Registration of an organization-level AIID namespace requires:
* Identification of the registrant (organization or individual)
* Contact information
* Intended use description
* Acceptance of the applicable registration policy
* Submission of a public key for namespace trust binding
Registration is intended to be open to all autonomous system
operators, vendors, and developers worldwide, with no restriction
on the type of autonomous system, the implementing organization,
or the geographic location of the registrant.
Registration details, policy documents, and the root registry
should be publicly accessible and machine-readable.
6. Operational States and Safe Mode
Every AIID carries an operational state. The operational state
determines whether an autonomous system may participate in AIIP
execution flows. Human principals and registrants may set and
change the operational state of any AIID within their authority.
The defined operational states are:
Active:
The autonomous system is operating normally. It may
participate in AIIP invocations, receive delegation grants,
and produce execution receipts.
Safe Mode:
The autonomous system is operating in a restricted state.
Safe mode is set by a human principal or authorized operator
to limit the system's execution capabilities without
suspending or revoking its identity.
In safe mode an autonomous system:
* Retains its AIID and registration
* May be queried for status
* May not accept new invocations unless explicitly permitted
* May complete in-progress executions at the operator's
discretion
* Returns a safe-mode indicator in any execution response
Safe mode is reversible. A human principal or authorized
operator may restore an autonomous system to Active state
at any time.
Safe mode is the primary mechanism for human override of
autonomous execution without permanent identity consequences.
It allows operators to pause, investigate, and resume
autonomous systems in a controlled manner.
Suspended:
The autonomous system is administratively offline. It may
not participate in any AIIP execution flows. Its identity
is preserved. Suspension is reversible.
Revoked:
The AIID has been permanently cancelled. The identifier
may not be reactivated. See Section 7.
Figure 3: Operational State Transitions
Active <---------> Safe Mode
| |
v v
Suspended <-------> Suspended
|
v
Revoked (terminal)
Human control over operational state is an architectural
requirement of AIIP. The ability to place any autonomous
system into safe mode at any time, from any point in the
delegation chain, is a fundamental safety property of the
AIID namespace.
The mechanism by which operational state changes are
communicated to execution environments is out of scope for
this document and will be addressed in future AIIP
specifications.
7. Revocation
An AIID may be revoked by the root registry or by the registrant
that issued it. Revocation renders the identifier permanently
invalid for use in AIIP invocations and execution contexts.
Revocation is distinct from Safe Mode and Suspension.
Revocation is permanent and irreversible. It is appropriate
when an autonomous system has been decommissioned, compromised,
or has violated registration policy.
A revocation record should include:
* The revoked AIID
* A timestamp of revocation
* The revoking authority
* A reason code (optional)
Implementations should treat a revoked AIID as unauthorized.
Execution environments should check revocation status prior
to accepting an invocation.
Revocation distribution mechanisms are out of scope for this
document and will be addressed in future AIIP specifications.
8. Namespace Governance
This document deliberately does not name a root registry
operator. The author believes that the question of who
operates and governs an identifier namespace for autonomous
systems is at least as important as the technical design of
the namespace itself, and that this question should be
answered by the community rather than asserted by a
specification author.
Open governance questions include:
* Should the root registry be operated by a single
organization, a consortium, or a decentralized mechanism?
* What accountability framework should govern the root
registry operator?
* How should registration policy be set and amended?
* What fee structures, if any, are appropriate?
* How should disputes over namespace labels be resolved?
* What relationship, if any, should the AIID namespace have
to existing identifier governance bodies?
Possible governance models include operation by an existing
Internet governance institution, creation of a new purpose-
built body, a multi-stakeholder consortium of implementers,
or a decentralized registry mechanism. Each model carries
different tradeoffs in accountability, neutrality, cost,
and operational reliability.
The author's intent is that governance of the AIID namespace,
if this work proceeds, should be determined through open
community processes.
9. Security Considerations
The AIID namespace is a trust anchor for the AIIP execution
architecture. Threats to consider include:
* Unauthorized registration of namespace labels
* Impersonation of registered autonomous systems
* Replay of revoked or suspended identifiers
* Compromise of root registry trust material
* Namespace squatting or abuse
* Unauthorized modification of operational state
* Circumvention of safe mode by autonomous systems
The root registry should use hardware security modules or
equivalent mechanisms to protect root signing keys. Root
trust material should be published through multiple
independent channels.
Registrants should rotate signing keys periodically and revoke
compromised keys immediately.
Implementations must enforce safe mode and suspension states.
An autonomous system must not be permitted to override or
bypass its own operational state. Human override capability
must be preserved at all times.
10. IANA Considerations
This document has no IANA actions.
Future revisions may define registries, namespace parameters,
delegation formats, operational state codes, or discovery
mechanisms if such actions are determined to be necessary.
11. Informative References
[I-D.sogomonian-aiip-architecture]
Sogomonian, A., "Architecture for the Artificial
Intelligence Internet Protocol", Work in Progress,
Internet-Draft, draft-sogomonian-aiip-architecture,
March 2026,
.
[I-D.sogomonian-aiip-native-access-architecture]
Sogomonian, A., "AIIP: Native Access Architecture for
Autonomous Systems", Work in Progress, Internet-Draft,
draft-sogomonian-aiip-native-access-architecture,
June 2026,
.
Author's Address
Aram Sogomonian (editor)
Artificial Intelligence Internet Foundation (AIIF)
Email: aiinternetfoundation@icloud.com