AgentID: An Identity Protocol for Autonomous AI Agents
draft-gudlab-agentid-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tim Uzua | ||
| Last updated | 2026-03-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gudlab-agentid-protocol-00
Web Authorization Protocol T. Uzua
Internet-Draft GudLab
Intended status: Standards Track 14 March 2026
Expires: 15 September 2026
AgentID: An Identity Protocol for Autonomous AI Agents
draft-gudlab-agentid-protocol-00
Abstract
This document defines the AgentID Protocol, an open standard for
establishing, verifying, and managing the identity of autonomous AI
agents operating across the Internet. As AI agents increasingly
interact with web services, APIs, and each other on behalf of humans
and organisations, the industry lacks a universal mechanism to
determine which agent is making a request, who is accountable for it,
and what it is permitted to do.
AgentID introduces the Agent Identity Token (AIT), a signed JWT
carrying agent identity, owner verification, capability, and
delegation chain claims. The protocol defines agent registration,
owner verification levels, service-side access tiers, and transparent
delegation chains with scope attenuation. It builds on existing
standards including OAuth 2.0, OpenID Connect, JSON Web Token (JWT),
and JSON Web Key (JWK), adapting them to the unique requirements of
non-human autonomous actors.
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 15 September 2026.
Uzua Expires 15 September 2026 [Page 1]
Internet-Draft AgentID Protocol March 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
4. Agent Identity Token (AIT) . . . . . . . . . . . . . . . . . 5
4.1. Token Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Token Claims . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Identity Claims . . . . . . . . . . . . . . . . . . . 6
4.2.2. Owner Claims . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Capability Claims . . . . . . . . . . . . . . . . . . 6
4.2.4. Delegation Claims . . . . . . . . . . . . . . . . . . 7
4.2.5. Standard JWT Claims . . . . . . . . . . . . . . . . . 7
4.3. AIT Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Cryptographic Requirements . . . . . . . . . . . . . . . 8
4.5. Token Lifetime . . . . . . . . . . . . . . . . . . . . . 8
5. Owner Verification Levels . . . . . . . . . . . . . . . . . . 9
6. Agent Registration . . . . . . . . . . . . . . . . . . . . . 9
6.1. Phase 1: Owner Registration . . . . . . . . . . . . . . . 9
6.2. Phase 2: Agent Creation . . . . . . . . . . . . . . . . . 9
7. Service-Side Access Control . . . . . . . . . . . . . . . . . 10
7.1. Policy Expression . . . . . . . . . . . . . . . . . . . . 10
8. Delegation Chain . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Delegation Chain Structure . . . . . . . . . . . . . . . 11
8.2. Scope Attenuation . . . . . . . . . . . . . . . . . . . . 12
9. Agent Registry . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Registry API . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Revocation . . . . . . . . . . . . . . . . . . . . . . . 13
10. Relationship to OAuth 2.0 . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11.1. Key Management . . . . . . . . . . . . . . . . . . . . . 14
11.2. Replay Prevention . . . . . . . . . . . . . . . . . . . 14
11.3. Abuse Mitigation . . . . . . . . . . . . . . . . . . . . 14
Uzua Expires 15 September 2026 [Page 2]
Internet-Draft AgentID Protocol March 2026
11.4. Privacy Considerations . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12.1. Media Type Registration . . . . . . . . . . . . . . . . 15
12.2. JWT Claims Registration . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Capability Namespace Convention . . . . . . . . . . 16
Appendix B. Error Codes . . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Today's Internet authentication infrastructure was designed for
humans interacting with services through browsers. OAuth 2.0
[RFC6749] enables a user to grant an application limited access to
their resources. OpenID Connect [OpenID.Core] enables a user to
prove their identity across services. Neither protocol was designed
for autonomous software agents that:
* Operate independently without a human in the loop
* Chain together in multi-step workflows where Agent A dispatches
tasks to Agent B
* Make decisions and take actions at machine speed on behalf of
principals who may not be present
The result is a proliferation of ad-hoc solutions: raw API keys with
no ownership tracing, OAuth tokens repurposed beyond their design
intent, workload identity frameworks such as [SPIFFE] that address
service-to-service authentication but not agent-specific concerns
like owner accountability and delegation chains, and proprietary
agent authentication schemes that fragment the ecosystem.
AgentID addresses this gap by providing a lightweight,
cryptographically secure identity layer purpose-built for autonomous
AI agents. It answers three questions that no existing standard
addresses comprehensively:
1. Which agent is this?
2. Who is accountable for it?
3. What is it permitted to do?
Uzua Expires 15 September 2026 [Page 3]
Internet-Draft AgentID Protocol March 2026
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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.
Agent An autonomous software system that interacts with services on
behalf of a principal (human user or another agent).
Agent Identity Token (AIT) A signed JWT that an agent presents to
authenticate itself to a service.
Owner The human or organisation legally accountable for an agent's
actions.
Principal The entity on whose behalf an agent acts. May be a user,
an organisation, or another agent.
Delegation Chain The ordered sequence of principals and agents
through which authority was delegated, from the original
authoriser to the acting agent.
Registry A service that stores agent identities, public keys, and
owner verification records.
Scope Attenuation The principle that each link in a delegation chain
can only have equal or fewer permissions than the previous link.
Verification Level A numeric indicator (0-3) of the rigour of
identity verification performed on an agent's owner.
2. Threat Model
Without a standardised agent identity layer, services face the
following threats:
Unattributable Abuse An anonymous agent submits large volumes of
spam, books fake appointments, or scrapes content. The service
has no way to trace the actor or hold anyone accountable.
Impersonation A malicious agent claims to act on behalf of a
reputable organisation without any verifiable proof.
Privilege Escalation An agent granted read access to a resource
exploits loose controls to perform write or delete operations.
Uzua Expires 15 September 2026 [Page 4]
Internet-Draft AgentID Protocol March 2026
Delegation Opacity Agent A spawns Agent B which spawns Agent C. A
service receiving a request from Agent C has no visibility into
the delegation chain or the original authorising principal.
Rate-Limit Evasion Without stable agent identity, rate limiting
falls back to IP addresses, which agents trivially rotate.
3. Protocol Requirements
The protocol MUST satisfy the following requirements:
1. *Verifiable Identity:* A service MUST be able to
cryptographically verify an agent's identity without a
synchronous call to a central authority.
2. *Owner Accountability:* Every agent identity MUST be traceable to
a verified human or organisational owner.
3. *Granular Access Control:* Services MUST be able to define
policies based on agent identity, owner identity, verification
level, and declared capabilities.
4. *Delegation Transparency:* When an agent acts on behalf of
another agent or a human, the full chain of delegation MUST be
inspectable.
5. *Revocability:* Compromised or abusive agent identities MUST be
revocable in real time.
6. *Interoperability:* The protocol MUST work across agent
frameworks, programming languages, and deployment models.
7. *Performance:* Token verification MUST be possible offline using
cached public keys, with registry lookups reserved for enhanced
checks.
4. Agent Identity Token (AIT)
The Agent Identity Token is a signed JSON Web Token (JWT) conforming
to [RFC7519], with a custom claim set designed for agent
identification. The token is self-contained: any service with access
to the issuer's public key can verify the token without contacting
the registry.
4.1. Token Header
The AIT JOSE header MUST contain the following parameters:
Uzua Expires 15 September 2026 [Page 5]
Internet-Draft AgentID Protocol March 2026
alg REQUIRED. MUST be "ES256" (ECDSA using P-256 and SHA-256, per
[RFC7518] Section 3.4).
typ REQUIRED. MUST be "AIT+jwt".
kid REQUIRED. Key identifier for key rotation, corresponding to a
key in the registry's JWKS [RFC7517].
{
"alg": "ES256",
"typ": "AIT+jwt",
"kid": "agentidp-2026-03-01"
}
Figure 1: AIT Header Example
4.2. Token Claims
The AIT payload contains the following claims organised into four
groups:
4.2.1. Identity Claims
agent_id REQUIRED. String. Globally unique agent identifier
assigned by the registry.
agent_name REQUIRED. String. Human-readable name of the agent.
agent_version RECOMMENDED. String. Semantic version of the agent
software.
agent_description OPTIONAL. String. Brief description of the
agent's purpose.
4.2.2. Owner Claims
owner_id REQUIRED. String. Unique identifier for the agent's owner
in the registry.
owner_type REQUIRED. String. Either "person" or "org".
owner_name REQUIRED. String. Display name of the owner.
verification_level REQUIRED. Integer (0-3). See Section 5.
4.2.3. Capability Claims
capabilities OPTIONAL. Array of strings. Declared capabilities
Uzua Expires 15 September 2026 [Page 6]
Internet-Draft AgentID Protocol March 2026
using the namespace convention defined in Appendix A.
4.2.4. Delegation Claims
delegation_chain OPTIONAL. Array of delegation objects. See
Section 8.
4.2.5. Standard JWT Claims
iss REQUIRED. String. The registry URL that issued the agent
identity.
sub REQUIRED. String. Same value as agent_id.
aud RECOMMENDED. String. The target service URL.
iat REQUIRED. NumericDate. Time at which the token was issued.
exp REQUIRED. NumericDate. Expiration time. MUST NOT exceed 24
hours after iat. A lifetime of 1 hour or less is RECOMMENDED for
high-security contexts.
jti REQUIRED. String. Unique token identifier for replay
prevention.
4.3. AIT Example
The following is an example AIT payload:
Uzua Expires 15 September 2026 [Page 7]
Internet-Draft AgentID Protocol March 2026
{
"agent_id": "ag_7xK9m2nP4qRtL8",
"agent_name": "AcmeBookingAgent",
"agent_version": "1.2.0",
"owner_id": "own_T1mR4xBq9",
"owner_type": "org",
"owner_name": "Acme Inc",
"verification_level": 2,
"capabilities": ["calendar:read", "calendar:write"],
"delegation_chain": [{
"principal_type": "user",
"principal_id": "usr_abc123",
"granted_at": "2026-03-01T10:00:00Z",
"scopes": ["calendar:read"]
}],
"iss": "https://registry.agentidp.dev",
"sub": "ag_7xK9m2nP4qRtL8",
"aud": "https://api.example.com",
"iat": 1740000000,
"exp": 1740003600,
"jti": "tok_unique_nonce_123"
}
Figure 2: AIT Payload Example
4.4. Cryptographic Requirements
All Agent Identity Tokens MUST be signed using ES256 (ECDSA with the
P-256 curve and SHA-256) as defined in [RFC7518] Section 3.4. This
algorithm provides strong security with compact signatures suitable
for high-frequency agent-to-service communication.
Agent key pairs are generated during registration and the public key
is published via the registry's JWKS endpoint [RFC7517]. Services
verify tokens by fetching the public key from the JWKS endpoint, with
aggressive caching (RECOMMENDED TTL: 24 hours).
4.5. Token Lifetime
AIT tokens MUST have a maximum lifetime of 24 hours (the difference
between exp and iat MUST NOT exceed 86400 seconds). For high-
security contexts, a lifetime of 1 hour or less is RECOMMENDED.
Short-lived tokens limit the blast radius of key compromise. Agents
MUST implement automatic token refresh using their private key.
Uzua Expires 15 September 2026 [Page 8]
Internet-Draft AgentID Protocol March 2026
5. Owner Verification Levels
The protocol defines four verification levels providing increasing
assurance about the agent owner's identity. Services can set minimum
verification requirements per endpoint.
Level 0 - Unverified Email address confirmed only. Suitable for
testing, development, and open-access services.
Level 1 - Email Email and phone verification. Suitable for low-risk
public services.
Level 2 - Domain DNS TXT record or well-known file verification at
the owner's domain. Suitable for business APIs and partner
integrations.
Level 3 - Organisation Know Your Business (KYB) verification
including company registration and legal entity verification.
Suitable for financial services, healthcare, and regulated
industries.
6. Agent Registration
Agent registration is a two-phase process: owner verification
(performed once) followed by agent creation (performed per agent). A
single verified owner MAY register multiple agents.
6.1. Phase 1: Owner Registration
1. Owner registers at an AgentID-compliant registry with email and
authenticating credentials.
2. Owner completes verification to their desired level (email,
domain DNS, or KYB document submission).
3. Registry issues an owner_id and management credentials.
6.2. Phase 2: Agent Creation
1. Owner calls POST /v1/agents with agent name, description, and
declared capabilities.
2. Registry generates an ES256 key pair, stores the public key, and
returns the agent_id, private key (in JWK format per [RFC7517]),
and the kid.
Uzua Expires 15 September 2026 [Page 9]
Internet-Draft AgentID Protocol March 2026
3. Agent uses the private key to self-sign AIT tokens. The private
key MUST NOT be retained by the registry after delivery to the
owner.
Owners MUST immediately store the agent private key in a secure
secrets manager. If the private key is lost, the agent MUST be re-
registered with a new key pair.
7. Service-Side Access Control
Services consuming AgentID tokens implement access policies based on
the claims present in the AIT. The protocol defines three standard
access tiers:
Open Any agent may access. No AIT required. Rate limiting is IP-
based only. Suitable for public read-only endpoints.
Authenticated A valid AIT from any registered agent is required.
Token signature and revocation status are verified. Rate limiting
is per agent_id. Suitable for general-purpose APIs.
Permissioned A valid AIT is required AND the agent_id or owner_id
MUST be on an explicit allowlist maintained by the service. Rate
limiting is per agent_id. Suitable for partner integrations and
sensitive data.
7.1. Policy Expression
Services define policies as a set of rules evaluated against AIT
claims. The protocol RECOMMENDS the following policy structure:
{
"resource": "/api/bookings",
"access_tier": "authenticated",
"min_verification_level": 2,
"required_capabilities": ["calendar:write"],
"rate_limit": {
"requests_per_hour": 100,
"scope": "agent_id"
},
"allowlist": null,
"denylist": ["ag_known_bad_actor"]
}
Figure 3: Access Policy Example
Uzua Expires 15 September 2026 [Page 10]
Internet-Draft AgentID Protocol March 2026
8. Delegation Chain
When Agent A instructs Agent B to perform an action, or when a human
user authorises an agent to act on their behalf, the delegation chain
is encoded in the AIT so that the receiving service can inspect the
full provenance of the request.
8.1. Delegation Chain Structure
The delegation_chain claim is an ordered array of delegation objects,
from the original principal (index 0) to the most recent delegator.
Each entry records who delegated, when, and with what scope
restrictions.
{
"delegation_chain": [
{
"principal_type": "user",
"principal_id": "usr_john_abc",
"granted_at": "2026-03-01T10:00:00Z",
"scopes": ["calendar:read", "calendar:write"],
"evidence": "oauth2:token_exchange"
},
{
"principal_type": "agent",
"principal_id": "ag_orchestrator_1",
"granted_at": "2026-03-01T10:00:05Z",
"scopes": ["calendar:read"],
"evidence": "ait:delegation"
}
]
}
Figure 4: Delegation Chain Example
Each delegation object contains:
principal_type REQUIRED. String. Either "user" or "agent".
principal_id REQUIRED. String. Identifier of the delegating
principal.
granted_at REQUIRED. String (datetime). When the delegation was
granted.
scopes REQUIRED. Array of strings. The scopes granted in this
delegation step.
Uzua Expires 15 September 2026 [Page 11]
Internet-Draft AgentID Protocol March 2026
evidence OPTIONAL. String. Reference to the mechanism used to
establish the delegation (e.g., "oauth2:token_exchange" per
[RFC8693], "ait:delegation").
8.2. Scope Attenuation
Each link in the delegation chain MUST have scopes that are equal to
or a strict subset of the previous link's scopes. A delegate MUST
NOT grant more permissions than it received. This is enforced by
both the issuing agent (when constructing the token) and the
verifying service (when validating claims).
If a verifying service detects a scope attenuation violation, it MUST
reject the token with error code AID-009 (DELEGATION_INVALID).
9. Agent Registry
The Agent Registry is the trust anchor of the AgentID ecosystem. It
stores agent public keys, owner verification records, and revocation
status.
9.1. Registry API
A compliant registry MUST implement the following endpoints:
Uzua Expires 15 September 2026 [Page 12]
Internet-Draft AgentID Protocol March 2026
+========+==============================+======================+
| Method | Endpoint | Description |
+========+==============================+======================+
| POST | /v1/owners | Register a new owner |
+--------+------------------------------+----------------------+
| POST | /v1/owners/{id}/verify | Submit verification |
| | | evidence |
+--------+------------------------------+----------------------+
| POST | /v1/agents | Register a new agent |
+--------+------------------------------+----------------------+
| GET | /v1/agents/{agent_id} | Public agent lookup |
+--------+------------------------------+----------------------+
| GET | /v1/ | Fetch agent public |
| | agents/{agent_id}/public-key | key (JWK) |
+--------+------------------------------+----------------------+
| DELETE | /v1/agents/{agent_id} | Revoke an agent |
+--------+------------------------------+----------------------+
| GET | /.well-known/jwks.json | Registry JWKS |
| | | endpoint |
+--------+------------------------------+----------------------+
| GET | /v1/agents/{agent_id}/status | Real-time revocation |
| | | check |
+--------+------------------------------+----------------------+
Table 1
9.2. Revocation
Agent revocation MUST be immediate. When an owner revokes an agent
or the registry suspends one, the agent status is set to "revoked".
* Services implementing real-time checks SHOULD call the status
endpoint.
* Services relying on cached public keys SHOULD implement a maximum
cache TTL of 1 hour and MUST honour Cache-Control headers returned
by the registry.
10. Relationship to OAuth 2.0
AgentID is designed to complement, not replace, OAuth 2.0 [RFC6749].
For services that already use OAuth for user authentication, AgentID
adds the agent identity layer. A typical integration pattern is:
1. The user grants an OAuth token to the agent (user delegation).
Uzua Expires 15 September 2026 [Page 13]
Internet-Draft AgentID Protocol March 2026
2. The agent includes the OAuth grant reference in the AIT
delegation chain via the "evidence" field (e.g.,
"oauth2:token_exchange").
3. The service verifies both the agent's identity (AgentID) and the
user's authorisation (OAuth).
This layered approach allows services to answer "which agent is
this?" (AgentID) independently from "what is this user allowing?"
(OAuth), providing complete request provenance.
11. Security Considerations
11.1. Key Management
Agent private keys MUST be stored in hardware security modules (HSMs)
or cloud secret managers in production. Key rotation is supported
via key versioning: owners can generate a new key pair without
changing the agent_id. Both old and new keys are valid during a
configurable overlap period (default: 72 hours).
11.2. Replay Prevention
Every AIT includes a unique jti claim. Services SHOULD maintain a
jti cache (e.g., with TTL matching token expiry) and reject tokens
with previously seen jti values. For stateless verification, the
short token lifetime provides an acceptable trade-off.
11.3. Abuse Mitigation
Registries SHOULD implement automated abuse detection monitoring for
anomalous patterns. Services can report abusive agent_ids to the
registry. A graduated response model is RECOMMENDED: warning,
temporary suspension, permanent revocation, owner-level ban.
11.4. Privacy Considerations
Registries store owner identity information subject to applicable
data protection regulations (GDPR, etc.). Owner personal data MUST
NOT be exposed via the public agent lookup API unless the owner
explicitly opts in. The minimum public disclosure is: owner_type,
verification_level, and (for Level 2+) verified_domain.
12. IANA Considerations
Uzua Expires 15 September 2026 [Page 14]
Internet-Draft AgentID Protocol March 2026
12.1. Media Type Registration
This document requests registration of the "AIT+jwt" media type
subtype in the "JSON Web Token Types" sub-registry of the "JSON Web
Token (JWT)" registry.
Type name: AIT+jwt
Subtype name: N/A
Required parameters: N/A
Optional parameters: N/A
Reference: This document
12.2. JWT Claims Registration
This document requests registration of the following claims in the
"JSON Web Token Claims" registry:
* agent_id - Globally unique agent identifier
* agent_name - Human-readable agent name
* agent_version - Agent software version
* agent_description - Agent purpose description
* owner_id - Agent owner identifier
* owner_type - Owner type (person or org)
* owner_name - Owner display name
* verification_level - Owner verification level (0-3)
* delegation_chain - Delegation provenance chain
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Uzua Expires 15 September 2026 [Page 15]
Internet-Draft AgentID Protocol March 2026
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January
2020, <https://www.rfc-editor.org/info/rfc8693>.
[SPIFFE] CNCF, "SPIFFE: Secure Production Identity Framework for
Everyone", 2024,
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
Appendix A. Capability Namespace Convention
Capabilities follow a resource:action format:
form:submit Submit form data
form:read Read form structure/schema
calendar:read Read calendar events
calendar:write Create/update events
calendar:delete Delete events
email:send Send emails
email:read Read inbox
storage:read Read files
storage:write Upload/modify files
payment:initiate Start a payment
payment:confirm Confirm a payment
Uzua Expires 15 September 2026 [Page 16]
Internet-Draft AgentID Protocol March 2026
Service providers MAY define custom capabilities using reverse-domain
notation (e.g., "com.example.booking:create").
Appendix B. Error Codes
+=========+===========================+======================+
| Code | Name | Description |
+=========+===========================+======================+
| AID-001 | INVALID_TOKEN | AIT signature |
| | | verification failed |
+---------+---------------------------+----------------------+
| AID-002 | TOKEN_EXPIRED | AIT has exceeded its |
| | | exp claim |
+---------+---------------------------+----------------------+
| AID-003 | AGENT_REVOKED | Agent has been |
| | | revoked |
+---------+---------------------------+----------------------+
| AID-004 | AGENT_SUSPENDED | Agent is temporarily |
| | | suspended |
+---------+---------------------------+----------------------+
| AID-005 | INSUFFICIENT_VERIFICATION | Owner verification |
| | | level below minimum |
+---------+---------------------------+----------------------+
| AID-006 | CAPABILITY_DENIED | Agent lacks required |
| | | capability |
+---------+---------------------------+----------------------+
| AID-007 | RATE_LIMIT_EXCEEDED | Per-agent rate limit |
| | | exceeded |
+---------+---------------------------+----------------------+
| AID-008 | NOT_ON_ALLOWLIST | Agent not on service |
| | | allowlist |
+---------+---------------------------+----------------------+
| AID-009 | DELEGATION_INVALID | Scope attenuation |
| | | violated |
+---------+---------------------------+----------------------+
| AID-010 | REPLAY_DETECTED | Token jti previously |
| | | used |
+---------+---------------------------+----------------------+
Table 2
Acknowledgements
The authors wish to thank the contributors to the AgentID Protocol
specification on GitHub, and the broader community working on AI
agent identity and authentication standards.
Uzua Expires 15 September 2026 [Page 17]
Internet-Draft AgentID Protocol March 2026
Author's Address
Tim Uzua
GudLab
Email: tim@gudlab.org
URI: https://gudlab.org
Uzua Expires 15 September 2026 [Page 18]