OpenA2A Agent Authorization Protocol (AAP)

4.1. Authorization Details

The "authorization_details" claim is the claim of that name defined in [RFC9396]: an array of objects, each with a REQUIRED "type" member naming an entry type from the registry below, plus the members that type defines. It is the structured, fine-grained form of the grant. It is mandatory to understand: whenever it is present it MUST be named in "aap_crit" (Section 4.2), and a verifier that does not implement it MUST reject the token.¶

The "scope" and "trust_class" claims stay REQUIRED so that verifiers built on [RFC8693] and OpenID Connect, which understand only the scope string, keep working. Within one token, "authorization_details" MUST fall inside what "scope" and "trust_class" permit: every entry's locations and actions MUST be ones the scope string already allows, and no entry may name a capability outside the trust class. A verifier that understands "authorization_details" enforces the intersection; a verifier that understands only "scope" enforces "scope"; neither ever grants more than "scope" alone would. A producer MUST NOT emit "authorization_details" toward a verifier that has not advertised support for every entry type the token carries, because a verifier without "aap_crit" support would treat the token as an unconstrained baseline token. The advertisement is the set of entry types the counterparty understands, with the semantics of the "authorization_details_types_supported" metadata of [RFC9396], not a boolean. Both aap-conformance [AAP-CONFORMANCE] reference verifiers ("verifiers/python/verify.py", "verifiers/node/verify.mjs") implement "aap_crit"; that repository's "conformance.json" is the record of what they verify.¶

The initial entry type registry has seven types. The wire value of "type" is a URI, "https://specs.opena2a.org/aap/types/" followed by the short name below; the short name is the registry key and the name used in prose. Member names inside an entry are camelCase; "type", "locations", "actions", "datatypes", "identifier", and "privileges" are the common members of [RFC9396] and keep their registered spelling. Every type that can carry data out of a session ("mcp_tool", "peer_agent", "model", "network", and "data" with a write action) carries an "egressCeiling" member, a set of labels; when absent it is the empty set. Every type MAY carry "requiresApproval", a boolean; when true, the broker admits the entry only through its escalation hook and denies it where no hook exists. Unless a member says otherwise, an absent set member means unbounded and an absent identity member is not permitted.¶

mcp_tool

"serverId" (a decentralized identifier or a "sha256:" key fingerprint), OPTIONAL "serverAtx" (a "sha256:" ATX reference), "tools" (an array of tool names), OPTIONAL "argumentConstraints" (an object keyed by tool name whose values map argument names to constraints), OPTIONAL "schemaHash" (a "sha256:" digest of the pinned tool schema), OPTIONAL "egressCeiling". The tool servers and tools the agent may call; connecting to a server outside the grant is drift.¶

skill

"identifier", "version", "contentHash" (a "sha256:" digest). A skill the agent may load, pinned to a version and content.¶

peer_agent

"peerDid", "direction" (an array holding one or both of "outbound" and "inbound"), "subDelegationDepth" (an integer greater than or equal to 0), OPTIONAL "egressCeiling". A peer the agent may delegate to or accept delegation from.¶

model

"endpoint" (the URI or decentralized identifier of the model endpoint), OPTIONAL "models" (an array of model identifiers), OPTIONAL "egressCeiling". The model endpoints the agent may send context to.¶

network

"destinations" (an array of host or host:port values; a leading "*." matches subdomains), "tlsRequired" (a boolean), OPTIONAL "egressCeiling". The network destinations the agent may reach.¶

data

"locations", "actions" (where "read" and "list" are read actions and every other action is a write action), OPTIONAL "fieldsAllowed" and "fieldsDenied" (arrays of field paths), OPTIONAL "labelCeiling" (a set of labels; absent means the empty set), OPTIONAL "egressCeiling" (applies when "actions" contains a write action). The data the agent may read or write, down to the field, and the labels it is cleared for.¶

budget

At least one of "spend" (an object with a decimal string "amount" and an ISO 4217 "currency"), "rate" (an object with an integer "max" and an integer "windowSeconds"), "maxUses", "concurrency", and "tokenCap" (an object with integer "input" and "output" members, either of which MAY be omitted). The resource budget of the grant; a budget entry carries no data and has no egress ceiling.¶

A verifier that encounters an entry type it does not implement MUST reject the token. New types are added by a revision of this document until the registry of Section 10 exists.¶

The label terms used by this document are defined here; these definitions are normative. A label is an opaque string naming a sensitivity class. A label set is a set of labels; labels are sets, not levels, because two fields can carry incomparable labels and a session that has read both must be treated as carrying both. A field with label set L is admissible under a ceiling C only if L is a subset of C. The session is the agent's context at a broker. The session label is the union of the label sets of every field admitted into that context so far; it only grows within a session, is keyed by the subject in the agent security context, carries across every CGT and DA minted for that subject, and is reset only by a deployment-defined context reset that is recorded there; a deployment that issues data grants MUST define that reset. A CGT lifetime is the minimum session, not its bound. An entry with an egress ceiling E admits the session's data out only if the session label is a subset of E; the default E is the empty set. Residency is a label family, so the rules that govern a health record class also govern data that may not leave a region.¶

4.2. Mandatory-to-Understand Claims

JWT defines a "crit" header parameter for header members but no equivalent for claims. The "aap_crit" claim is an array of claim names the verifier MUST understand in order to accept the token. A verifier that encounters a name in "aap_crit" that it does not implement MUST reject the token. A verifier MUST also reject a token whose "aap_crit" names a claim that is not present in the token, and a token whose "aap_crit" is present but empty. "aap_crit" MUST NOT name the baseline claims listed above. "authorization_details" MUST be listed whenever it is present. "cnf" MUST be listed whenever it is present, because a verifier that ignores "cnf" accepts the token as a bearer token. Every other claim is optional to ignore.¶

4.3. Proof of Possession

The "cnf" claim [RFC7800] binds a CGT or DA to the presenter's key, so that a token seen in transit is not a credential. "cnf" carries exactly one of "jwk" (the public key itself, per [RFC7800]) or "jkt" (the base64url SHA-256 JWK thumbprint of [RFC7638], as registered as a confirmation method by [RFC9449]). The bound key is the key the presentation binding step of the broker profile [AAP-BROKER-PROFILE] verified: the ATX subject key where the credential carries one (a later revision of the ATX format; the current ATX 1.1 format carries no subject key), otherwise the key registered for the agent's decentralized identifier. The presentation proof formats per binding are defined in the broker profile: operating system peer credentials on a local socket, an HTTP message signature [RFC9421] on HTTP, and a signed challenge on the A2A and MCP bindings. The presenter is the agent that presents the token to a broker: the "sub" of a CGT, the delegatee of a DA. A CGT the minting broker uses as its own assertion toward a downstream (the Assume and Exchange modes of the broker profile) is not presented in this sense; "cnf" on such a token is not verified by the downstream.¶

"cnf" is REQUIRED on every CGT or DA that is presented by an agent to any party other than the broker that minted it. On a local socket binding, where the token never leaves the minting broker and the presenter is bound by operating system peer credentials, "cnf" MAY be omitted. A verifier that receives a token with "cnf" MUST verify the presenter's proof against the bound key and MUST reject the token otherwise. As of the date of this revision no known implementation mints "cnf", and the reference broker binds no presentation.¶

4.4. Example With Authorization Details

The following generated claim set carries one "data" entry, one "budget" entry, "aap_crit", and "cnf" bound by thumbprint to a published presenter test key.¶

{
  "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,
  "authorization_details": [
    {
      "type": "https://specs.opena2a.org/aap/types/data",
      "locations": ["https://api.orders.internal/orders"],
      "actions": ["read"],
      "fieldsAllowed": ["id", "status", "total"],
      "fieldsDenied": ["customer.email"],
      "labelCeiling": ["internal"]
    },
    {
      "type": "https://specs.opena2a.org/aap/types/budget",
      "maxUses": 100,
      "rate": {"max": 60, "windowSeconds": 60}
    }
  ],
  "aap_crit": ["authorization_details", "cnf"],
  "cnf": {"jkt": "HlHgCcjrhbeyw80VMef51yPwhyRqjiwLdwSLRqo7hSI"},
  "iat": 1780315200,
  "exp": 1780315500,
  "jti": "c3d4e5f6a7b8091a2b3c4d5e6f708192"
}

5.1. Attenuation

Delegation attenuates: a DA can only carry less than the delegator's grant. For "authorization_details" this is made mechanical by a "narrower than or equal to" relation defined per entry type. An entry of the delegatee is narrower than or equal to an entry of the delegator of the same "type" when every member of the delegatee's entry is narrower than or equal to the corresponding member under the member kind: identity members ("serverId", "serverAtx", "identifier", "version", "contentHash", "schemaHash", "peerDid", "endpoint") are equal, and a hash the delegator left open MAY be pinned by the delegatee; allow-set members ("locations", "actions", "datatypes", "privileges", "tools", "models", "destinations", "direction", "fieldsAllowed", "labelCeiling", "egressCeiling") are a subset, where an absent allow set in the delegator means unbounded except for "labelCeiling" and "egressCeiling", where absent means the empty set, and an absent allow set in the delegatee inherits the delegator's value, and where the subset of "destinations" is evaluated by pattern coverage (each delegatee element equals a delegator element or matches a delegator "*." pattern, and a delegatee pattern is covered only by an equal or broader delegator pattern); deny-set members ("fieldsDenied") are a superset; bound members ("subDelegationDepth", "maxUses", "concurrency", the "max" of "rate", the "amount" of "spend" in the same currency, and the members of "tokenCap") are less than or equal, with the "windowSeconds" of "rate" greater than or equal for the same or a smaller "max", with "subDelegationDepth" strictly less because the delegatee is one delegation deeper, and with a "spend" in a currency the delegator does not carry not comparable, which makes the entry an orphan; restriction flags ("tlsRequired", "requiresApproval") stay true when the delegator's is true; and constraint objects ("argumentConstraints") carry every constraint the delegator states, JSON-equal, and MAY add constraints for arguments the delegator leaves unconstrained (the constraint grammar is deferred to the revision that lands broker enforcement).¶

A DA is valid only if every entry in its "authorization_details" is narrower than or equal to some entry of the same type in the delegator's "authorization_details", and no entry lacks such a parent. An orphan entry makes the DA invalid. The delegatee's array MAY hold fewer entries than the delegator's. When a chain is present, the relation is checked link by link. The minting broker MUST check the relation at mint time; a verifier that can resolve the delegator's grant MUST re-check it; a verifier that cannot MUST NOT treat the DA as carrying more than its own entries state. A DA's "max_depth" MUST NOT exceed the "subDelegationDepth" of the delegator's "peer_agent" entry whose "peerDid" is the DA's "sub", when such an entry exists; a "max_depth" of 0 is a terminal delegation. The "cnf" claim of a DA is bound to the delegatee's key, since the delegatee is the presenter.¶

The following generated claim set delegates the grant of Section 4.4 with fewer fields and a smaller budget.¶

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,
  "authorization_details": [
    {
      "type": "https://specs.opena2a.org/aap/types/data",
      "locations": ["https://api.orders.internal/orders"],
      "actions": ["read"],
      "fieldsAllowed": ["id", "status"],
      "fieldsDenied": ["customer.email"],
      "labelCeiling": ["internal"]
    },
    {
      "type": "https://specs.opena2a.org/aap/types/budget",
      "maxUses": 10,
      "rate": {"max": 10, "windowSeconds": 60}
    }
  ],
  "aap_crit": ["authorization_details", "cnf"],
  "cnf": {"jkt": "qI__BOccgAhhH9wob_G7gFVHLKIkS4CutvoSx0bMCY8"},
  "act": { "sub": "did:opena2a:agent:acme/orders-reader" },
  "max_depth": 1,
  "delegator_atx":
    "sha256:2052879dda15b1ca5e60319e3477a400\
      8412bffdaf3c3566c658795a48cab8fd",
  "iat": 1780315200,
  "exp": 1780315500,
  "jti": "d4e5f6a7b8c9012b3c4d5e6f70819203"
}

7.1. Revocation Propagation

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. Revoking an agent's ATX revokes every grant minted for it within the propagation window.¶

Revoking a single grant without revoking the agent is a local mechanism. A broker MUST maintain a grant revocation list, local to the operator, keyed by "jti" (one CGT or DA) and by "sub" (every CGT and DA minted for an agent by that broker, current and future). A revocation cascades through delegation chains by the delegator's "jti": listing a token's "jti" also revokes every DA whose "act" chain leads back to it. The list MUST be checked at every resolution, after the ATX and revocation list checks and before policy evaluation, and a listed token MUST be denied. The list never leaves the operator and is never fetched from a hosted service. As of the date of this revision no known implementation maintains such a list.¶

8.1. Replay Prevention

All tokens include a unique identifier ("jti"): 16 random bytes, lowercase hex (32 characters), as minted by the reference implementation. Receivers MUST track used identifiers for the token's TTL window and MUST reject a repeated identifier. The reference verifiers enforce this (conformance category "REPLAYED_JTI"): a jti is remembered from first acceptance until the token's "exp", and a second presentation inside that window rejects, after all other checks pass.¶

The aap-conformance suite [AAP-CONFORMANCE] exercises this rule with the fixture:¶

• cgt-compact-replayed.json¶

8.2. Cryptographic Agility and Post-Quantum Readiness

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, never 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 (broker profile Section 8.1).¶

The v1 suite registry (Section 9.5) contains two active entries: "EdDSA" (Ed25519, [RFC8037]) and "ML-DSA-65" (FIPS 204 [FIPS204]; JOSE "alg" identifier and "AKP" key type registered by [RFC9964], May 2026). The post-quantum profile is hybrid Ed25519 + ML-DSA-65, carried as two "signatures[]" entries of the multi-signature form (Section 9.4), one per suite, matching ATX's per-signature "algorithm" model: 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 (Section 9.4). Hybrid is the RECOMMENDED form wherever both ends implement AAP; single-suite compact tokens remain the interoperability baseline (Section 9.3). ML-DSA-65 signing uses the empty context string and no pre-hash variant, as [RFC9964] requires. Key exchange, where AAP deployments negotiate transport keys, targets hybrid X25519 + ML-KEM-768 (FIPS 203 [FIPS203]); ML-KEM has no final JOSE registration yet, so that row remains reserved on the same adoption path this section previously applied to ML-DSA-65.¶

The aap-conformance suite [AAP-CONFORMANCE] exercises the hybrid profile with the fixtures:¶

• cgt-hybrid-general-valid.json¶
• cgt-hybrid-missing-ed25519.json¶
• cgt-hybrid-missing-mldsa65.json¶
• cgt-hybrid-ed25519-bad-signature.json¶
• cgt-hybrid-mldsa-bad-signature.json¶

8.3. Intent Verification

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

8.4. Trust Is Not Authorization

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

8.5. Credential Confinement

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

8.6. Presentation Is Not Possession

An ATX proves what was attested about a build, not that the presenter is that agent, and a CGT or DA without "cnf" proves only that someone holds the bytes. Before this revision every presentation in AAP was bearer. The presentation binding step of the broker profile [AAP-BROKER-PROFILE] and the "cnf" claim (Section 4.3) close that gap. A deployment that accepts an ATX or a CGT over a network binding without the binding step accepts a badge and MUST NOT claim conformance to the broker profile.¶

8.7. A Constraint a Verifier May Ignore Is Not a Constraint

Previous revisions reserved "fga_constraints" as optional to ignore. A downstream that does not understand it treats the grant as unconstrained, so the claim could never be relied on. This revision deprecates it and moves the constraint into "authorization_details", which "aap_crit" makes mandatory to understand. The residual hazard is a legacy verifier that ignores "aap_crit" itself; the producer rule of Section 4.1 is the only control until every verifier on a path implements this revision, and deployments MUST treat a path with a legacy verifier as a bearer, unconstrained path.¶

9.1. Canonical Form

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].¶

9.2. Protected Header

The protected header carries "alg" (a suite identifier from the registry in Section 9.5), "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]).¶

9.3. Compact Serialization

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.2): "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.¶

9.4. Multi-Signature Form

This section is the one home of the family signature gate: every declared signature entry MUST verify, and an artifact that declares an ML-DSA-65 entry MUST also carry a verifying Ed25519 (EdDSA) entry, otherwise it is rejected as "HYBRID_INCOMPLETE". ATX, ATP and AIP cite this rule for their own signature arrays rather than restate it.¶

Where more than one signature is required, the hybrid post-quantum profile of Section 8.2, the token is carried as JWS General JSON Serialization ([RFC7515], Section 7.2.1), pinned by "schemas/jws-general-v1.schema.json": one "signatures[]" entry per suite, each with its own protected header ("alg", "kid") over the same payload. This is the family's named, swappable per-signature suite model, an entry's {protected.alg, protected.kid, signature} corresponds one-to-one to the ATX/ATP {algorithm, keyId, value}, expressed in the JOSE-standard container. 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 of Section 8.2 and MUST carry at least one "EdDSA" entry and at least one "ML-DSA-65" entry; a verifier MUST reject a general-form token missing either family (conformance category "HYBRID_INCOMPLETE"). Together with the subset rule above, this means 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, published as "examples/tokens/cgt-v1.general.json".¶

The aap-conformance suite [AAP-CONFORMANCE] exercises this rule with the fixtures:¶

• cgt-hybrid-missing-ed25519.json¶
• cgt-hybrid-missing-mldsa65.json¶

9.5. Suite Registry

The v1 suite registry contains two entries:¶

EdDSA

Ed25519 [RFC8037]. Active; the interoperability baseline.¶

ML-DSA-65

FIPS 204 [FIPS204], JOSE registration [RFC9964]. Active. Hybrid with EdDSA via the multi-signature form, or single-suite compact on post-quantum-capable interoperability paths. ML-DSA-44 and ML-DSA-87, though registered for JOSE, are not in this registry and are rejected as unknown suites.¶

Adding or retiring a suite is a change to this registry plus version negotiation, never a change of format.¶

9.6. Claim Conventions

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. Claims registered by another specification keep their registered spelling ("authorization_details", "cnf", "act"); members inside an "authorization_details" entry that this document defines are camelCase, and the common members of [RFC9396] keep their registered spelling. The claims added by this revision are additive: a token that omits them is byte-identical to a token of the previous revision, so the claim schema version is unchanged.¶