| Internet-Draft | AAP | July 2026 |
| Fane | Expires 23 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 23 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.¶
Some JSON examples in this document carry digest values longer than the 72-character line limit; those lines are folded using the single backslash strategy of [RFC8792]. The backslash fold marker and the leading whitespace of a continuation line are display artifacts, not part of the example content.¶
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 is an AAP token in the serialized form of Section 9: a JWT [RFC7519] whose claims follow the JWT registry naming convention. The required claims are "iss" (the issuing Registry decentralized identifier), "sub" (the agent decentralized identifier), "atx_reference" (the SHA-256 of the agent's current ATX), "trust_level" (the Registry trust level, an integer from 0 to 4), "iat" and "exp" (the validity window as NumericDate values, that is, seconds since the epoch), and "jti" (a unique token identifier). The optional "agent_id", "declared_purpose", and "aap_ver" claims MAY also appear.¶
NOTE: '\' line wrapping per RFC 8792
{
"iss": "did:opena2a:authority:opena2a.org",
"sub": "did:opena2a:agent:acme/orders-reader",
"agent_id": "aim_orders_reader",
"atx_reference":
"sha256:2052879dda15b1ca5e60319e3477a400\
8412bffdaf3c3566c658795a48cab8fd",
"declared_purpose": "Reads order records for reporting",
"trust_level": 4,
"iat": 1780315200,
"exp": 1780318800,
"jti": "1c9f2e8a7b6d5c4e3f2a1b0c9d8e7f6a"
}
¶
No reference implementation mints AITs yet; the claim schema and this generated example pin the form for implementers.¶
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.¶
The CGT claim set is ratified byte-for-byte from the reference broker implementation. The required claims are "iss" (the minting broker's issuer identifier), "sub" (the agent decentralized identifier, taken from the verified ATX and never from agent input), "aud" (the downstream audience or resource), "scope" (the downstream authorization scope as a string, for example "orders.read"), "trust_class" (the abstract ATX capability exercised for this grant, in "class:action" form), "issuer_chain" (the ATX issuer chain), "trust_level" (an integer from 0 to 4), "iat" and "exp" (the validity window, where "exp" minus "iat" is the policy time-to-live), and "jti". The "fga_constraints", "intent_verified", "max_uses", and "context_required" claims are OPTIONAL and are not minted by the v1 reference.¶
{
"iss": "https://broker.acme.example",
"sub": "did:opena2a:agent:acme/orders-reader",
"aud": "https://api.orders.internal",
"scope": "orders.read",
"trust_class": "orders:read",
"issuer_chain": ["did:opena2a:authority:opena2a.org"],
"trust_level": 4,
"iat": 1780315200,
"exp": 1780315500,
"jti": "9f8e7d6c5b4a39281706f5e4d3c2b1a0"
}
¶
In a broker deployment the CGT is used as the OAuth 2.0 Token Exchange [RFC8693] "subject_token" with a "subject_token_type" of "urn:ietf:params:oauth:token-type:jwt", so the downstream authorization server verifies it as a standard JWT against the broker's published key material.¶
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:¶
A DA is an AAP token in the form of Section 9: the CGT claim set plus the delegation members of [RFC8693]. Here "sub" is the delegatee; "act" carries the delegating agent as {"sub": delegator}, with nested "act" objects expressing a chain, innermost actor first; "max_depth" bounds further delegation; and "delegator_atx" embeds the delegator's ATX hash for the audit trail. The delegatee's "scope" and "trust_class" MUST be equal to or a subset of the delegator's.¶
NOTE: '\' line wrapping per RFC 8792
{
"iss": "https://broker.acme.example",
"sub": "did:opena2a:agent:acme/reporting-bot",
"aud": "https://api.orders.internal",
"scope": "orders.read",
"trust_class": "orders:read",
"issuer_chain": ["did:opena2a:authority:opena2a.org"],
"trust_level": 4,
"act": { "sub": "did:opena2a:agent:acme/orders-reader" },
"max_depth": 1,
"delegator_atx":
"sha256:2052879dda15b1ca5e60319e3477a400\
8412bffdaf3c3566c658795a48cab8fd",
"iat": 1780315200,
"exp": 1780315500,
"jti": "4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d"
}
¶
The v1 reference realizes delegation through the broker profile's Exchange mode, where the broker assertion is the subject token of the [RFC8693] exchange; it does not yet mint standalone DAs with an "act" chain.¶
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 declares its level in the "bac_level" claim, an integer 1, 2, or 3. The levels are cumulative: an L2 claim carries the L1 members, and an L3 claim carries all of them.¶
NOTE: '\' line wrapping per RFC 8792
{
"iss": "did:opena2a:authority:opena2a.org",
"sub": "did:opena2a:agent:acme/orders-reader",
"bac_level": 3,
"atx_reference":
"sha256:2052879dda15b1ca5e60319e3477a400\
8412bffdaf3c3566c658795a48cab8fd",
"binary_hash":
"sha256:479bd28a55e3a3eb20b9f5b48202318d\
5de9d0dbea9e6df20b2ee7ff95a4c135",
"drift_score": 0.04,
"anomaly_state": "nominal",
"intent_verified": true,
"iat": 1780315200,
"exp": 1780315260,
"jti": "7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b"
}
¶
The validity window MUST satisfy "exp" minus "iat" less than or equal to 60 seconds. BAC verification is local: the receiver verifies the signature against the issuing Registry instance's published public key, under the suite model of Section 8.3. The post-quantum profile, an ML-DSA-65 [FIPS204] signature alongside Ed25519 via the multi-signature form of Section 9, is shipped for CGTs (the reference broker mints it and the conformance suite carries generated hybrid fixtures); for BACs it remains a target: no implementation mints BACs yet, and the v1 BAC fixtures carry a single Ed25519 signature.¶
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 in the "jti" claim: 16 random bytes encoded as 32 lowercase hexadecimal characters, as minted by the reference implementation. Receivers MUST track used identifiers for the token's time-to-live window and MUST reject a repeated identifier. The reference verifiers enforce this: an identifier is remembered from first acceptance until the token's "exp", and a second presentation inside that window is rejected after all other checks pass.¶
The signature suite is a named, swappable field, the JOSE "alg" of each signature's protected header (Section 9), so suites can be added or retired by negotiation rather than by a new credential format. A verifier MUST reject a token whose declared suite it does not support rather than silently downgrade. Suite acceptance is pinned by verifier policy per path, never selected by the token; a producer configured for the hybrid profile on a path MUST NOT fall back to a classical-only token on that path except through explicit version negotiation.¶
The v1 suite registry (Section 9) contains two active entries: "EdDSA" (Ed25519 [RFC8037]) and "ML-DSA-65" (FIPS 204 [FIPS204], whose JOSE "alg" identifier and AKP key type are registered by [RFC9964]). The post-quantum profile is a hybrid of Ed25519 and ML-DSA-65, carried as two signature entries of the multi-signature form (Section 9), one per suite: a hybrid token verifies only if at least one ML-DSA-65 signature and at least one Ed25519 signature verify, with every declared entry verifying. The hybrid form is RECOMMENDED wherever both ends implement AAP; single-suite compact tokens remain the interoperability baseline. ML-DSA-65 signing uses the empty context string and no pre-hash variant, as [RFC9964] requires, and ML-DSA-65 verification keys publish as AKP JSON Web Keys. The reference implementation mints all three forms, and the conformance suite carries generated hybrid and ML-DSA-65 fixtures, including rejection fixtures in which one of a hybrid token's two signatures is invalid. Key exchange, where AAP deployments negotiate transport keys, targets a hybrid of X25519 and ML-KEM-768 [FIPS203]; ML-KEM has no final JOSE registration, so that row remains reserved on the adoption path this section previously applied to ML-DSA-65.¶
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 section pins the byte-level form of every AAP token: the AIT, CGT, DA, and BAC. AAP tokens are JOSE objects, that is, JWTs [RFC7519] over JWS [RFC7515]. The form is ratified from the reference implementation: what the reference broker actually signs is normative, byte for byte.¶
The signed bytes are the JWS Signing Input:¶
ASCII( BASE64URL(UTF8(protected header)) || "." ||
BASE64URL(payload) )
¶
AAP defines no other canonical form: serialization is canonicalization. The producer serializes the header and claim set once, as compact JSON with no insignificant whitespace, and signs those exact bytes; a verifier operates on the transmitted base64url segments and never re-serializes. There is no separate canonicalization step and no field projection. This is a deliberate difference from ATX and ATP, and it exists because AAP tokens, uniquely in the family, are verified by foreign systems: OAuth 2.0 Token Exchange [RFC8693] authorization servers and OpenID Connect-style verifiers that understand exactly one thing, a standard JWT. Base64url is unpadded, per [RFC7515].¶
The protected header carries "alg" (a suite identifier from the registry below), "typ" (the value "JWT"), and "kid" (the key identifier of the signing key in the issuer's published key material; Ed25519 keys publish as OKP JSON Web Keys and ML-DSA-65 keys as AKP JSON Web Keys per [RFC9964]).¶
The compact serialization "header.payload.signature" is the v1 baseline and is REQUIRED on every interoperability path where a foreign system verifies the token; in particular a CGT or DA presented as an [RFC8693] "subject_token" MUST be compact. A compact token carries exactly one signature, and therefore exactly one suite. The suite of a compact token is pinned per path by verifier policy (Section 8.3): "EdDSA" is the interoperability baseline, and an "ML-DSA-65" compact token serves counterparties that support the [RFC9964] suites. During the current adoption window the RECOMMENDED default on foreign-interoperability paths remains "EdDSA", because deployed token-exchange and OpenID Connect-style verifiers do not yet verify the [RFC9964] suites. Where more than one signature is required, the hybrid post-quantum profile of Section 8.3, the token is carried as JWS General JSON Serialization ([RFC7515]), with one signature entry per suite, each with its own protected header over the same payload. Every declared entry MUST verify; a verifier MUST NOT accept a token on a subset of its declared signatures. A general-form token that declares any ML-DSA-65 entry is on the hybrid profile and MUST carry at least one Ed25519 entry and at least one ML-DSA-65 entry; a verifier MUST reject a general-form token missing either family, so a stripped hybrid token can never degrade to single-family acceptance. Multiple entries of one suite with no ML-DSA-65 entry remain a legal multi-signature (co-signature) form.¶
The v1 suite registry contains two entries:¶
Adding or retiring a suite is a change to this registry plus version negotiation, never a change of format.¶
Claim names use the JWT registry convention, lowercase with snake_case for compound names such as "trust_class" and "issuer_chain". This is a deliberate exception to the OpenA2A camelCase JSON convention, which governs API responses rather than IETF-track token claims. The "iat" and "exp" claims are NumericDate values (seconds since the epoch), not date strings. The optional "aap_ver" claim carries the claim-schema version; it is OPTIONAL in v1 and REQUIRED from the first federated version, where a peer broker must select a claim schema without a shared channel.¶
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]. Until those registries exist, the signature suite registry of Section 9 is managed within this specification. 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.¶