| Internet-Draft | AAP | July 2026 |
| Fane | Expires 7 January 2027 | [Page] |
This document defines the OpenA2A Agent Authorization Protocol (AAP), a protocol for authorization in AI agent systems. AAP provides mechanisms for agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation, and revocation propagation. AAP is the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, in the same way that OAuth 2.0 complements HTTP for web applications.¶
AAP has two layers. The token model, defined in this document, specifies the AAP credentials and assertions: what they contain, how they are signed, and how they are verified. A companion broker and resolution layer specifies how an agent obtains and exercises a grant without the credential value ever entering the agent's reasoning context. This confinement property, that no secret, temporary credential, or backend identifier reaches the agent or the model behind it, is the primary design goal of the protocol.¶
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 7 January 2027.¶
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.¶
AI agent systems present authorization challenges that existing protocols such as OAuth 2.0 [RFC6749], SAML, and OpenID Connect were not designed to address. Agents are non-deterministic: the same agent with identical permissions can behave differently depending on its inputs, conversation history, and model state. Static authorization grants cannot account for this behavioral variability.¶
A second, agent-specific hazard is credential exposure. An autonomous agent that holds a secret in its reasoning context can be induced, through prompt injection or tool-output poisoning, to disclose or misuse it. AAP therefore treats the confinement of credentials away from the agent's reasoning context as a first-class requirement rather than a deployment detail.¶
AAP introduces six protocol components that together provide authorization coverage for agent-to-agent, agent-to-service, and human-to-agent interactions:¶
Agent Identity Token (AIT): a cryptographic identity assertion.¶
Capability Grant Token (CGT): a scoped, short-lived authorization.¶
Delegation Assertion (DA): cross-agent capability delegation.¶
Behavioral Attestation Claim (BAC): a real-time behavioral state proof.¶
Cross-Organizational Trust Federation: mutual trust between issuing authorities.¶
Revocation Propagation: federated revocation within a bounded interval.¶
AAP is positioned as the authorization complement to agent communication protocols such as A2A [A2A] and the Model Context Protocol [MCP], which convey messages and tool invocations but do not themselves define scoped, attested authorization.¶
A governing constraint applies to every choice in AAP: the protocol and its vocabulary are open, and nothing in AAP requires a vendor, cloud provider, or government to surrender control of its own trust root. The topology is a trust program of federated, conformant Root Authorities, not a single root, the same property that let DNS, TLS, OAuth, and OpenID Connect achieve broad deployment.¶
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.¶
The AIT is a cryptographic assertion of agent identity, analogous to an OpenID Connect ID Token. It is presented by an agent to identify itself to other agents, services, and infrastructure. An AIT is an identity assertion only; it conveys no authorization (see Section 8.5).¶
An AIT carries an agent identifier, a decentralized identifier for the agent, a hash reference to the agent's current ATX, a declared purpose, a trust level, issuance and expiry timestamps, a hybrid signature, and the issuer's decentralized identifier:¶
{
"agentId": "uuid",
"agentDid": "did:opena2a:agent:org/agent-name",
"atxReference": "sha256-hash-of-current-atx",
"declaredPurpose": "natural language description",
"trustLevel": 0,
"issuedAt": "ISO 8601",
"expiresAt": "ISO 8601",
"signature": "Ed25519 + ML-DSA-65 hybrid",
"issuerDid": "did:opena2a:authority:issuing-registry"
}
¶
AIT verification MUST be local. The verifier checks the signature against the issuer's public key, distributed via the trust anchor mechanism. No network call to a Registry is required at verification time.¶
The CGT is a short-lived, scoped authorization token, analogous to an OAuth 2.0 access token [RFC6749]. It authorizes a specific capability exercise under fine-grained authorization constraints. In a broker deployment [AAP-BROKER-PROFILE], the CGT is what the broker mints from a verified ATX before exchanging it for a downstream credential.¶
{
"tokenId": "unique-id",
"agentId": "uuid",
"capability": "db:read",
"scope": {
"resources": ["customers"],
"actions": ["read"],
"attributes": ["name", "email"],
"maxUses": 100,
"contextRequired": true
},
"fgaConstraints": "json-encoded FGA policy",
"intentVerified": true,
"issuedAt": "ISO 8601",
"expiresAt": "ISO 8601",
"signature": "Ed25519"
}
¶
A CGT has a bounded time-to-live. This document defines three tiers; profiles MAY define others:¶
The DA enables cross-agent capability delegation, analogous to OAuth 2.0 Token Exchange [RFC8693]. A delegatee's capability scope MUST NOT exceed the delegator's scope. The exchange mode of the broker profile is a realization of the DA over [RFC8693].¶
A DA is subject to the following constraints:¶
The BAC is a short-lived signed assertion of an agent's current behavioral state, with a time-to-live on the order of 60 seconds. It has no direct parallel in existing web protocols; it exists because agents are non-deterministic.¶
A BAC is issued at one of three levels:¶
BAC verification is local. The receiver verifies the ML-DSA-65 signature [FIPS204] against the issuing authority's public key.¶
Federation follows a PKI-style hierarchy: subordinate Registry nodes (Root Authorities) issue ATXs that are trusted by their peers according to published trust lists. Any federated node can verify any other node's ATXs without direct contact. No participant joins a central operator; each operates a conformant Root Authority and cross-trusts its peers.¶
When any node revokes an ATX, the revocation MUST propagate to all federation members within 60 seconds via signed push. No member is required to poll. Authorization revocation in the broker profile is bound entirely to this mechanism; the profile defines no separate revocation system.¶
Where AAP is deployed via a broker, no credential value, temporary token, or backend identifier may enter an agent's reasoning context. This requirement is normative in the broker profile [AAP-BROKER-PROFILE] and is the property that defends against the credential-harvest and exfiltration attack classes catalogued in [THREATMATRIX]. An agent emits an abstract grant reference; the broker verifies the agent's ATX, evaluates resource policy, obtains a scoped credential, performs the operation, and returns only the result.¶
All tokens include a unique identifier ("jti"). Receivers MUST track used identifiers for the token's time-to-live window and MUST reject a repeated identifier.¶
All signatures use a hybrid of Ed25519 and ML-DSA-65 [FIPS204]. Key exchange uses a hybrid of X25519 and ML-KEM-768 [FIPS203]. The signature suite is a named, negotiable field, so suites can be added or retired by negotiation rather than by a new credential format.¶
Semantic intent classification can express constraints that static policies cannot. Intent classification is probabilistic; systems MUST NOT rely on it alone to authorize irreversible actions.¶
A valid AIT or ATX is an identity and posture assertion, not permission to act on a resource, and trust is not transitive. Authorization exists only where a local policy grants it. Brokers MUST default-deny.¶
This document requests registration of the "aap" URI scheme in the Uniform Resource Identifier (URI) Schemes registry, and, via the broker profile [AAP-BROKER-PROFILE], the "grant" URI scheme. It further anticipates registries for AAP protocol versions, credential-provider mode identifiers, and signature suite identifiers, to be coordinated with the ATX signature suite registry [ATX]. The concrete registration templates will be provided in a future revision of this document.¶
This specification was authored in the open and benefits from review of its authorization and delegation model by the OpenA2A community.¶