Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents

1.1. Regulatory Convergence

Independent regulatory work has converged on the same authorization structure that AAE implements. Two requirements from the Singapore IMDA Model AI Governance Framework for Agentic AI, Version 1.5 [IMDA-MGF], published 20 May 2026, are directly relevant.¶

First, on agent identity (§2.1.2, "Agent identity — Identification"), the framework states:¶

• An agent should have its own unique, cryptographically verifiable identity, such that it can identify itself to the organisation, its human user, or other agents.¶

The framework further recommends that agent identities be catalogued and centrally managed, issued from and tracked by a centralised system — the operational model that a DID-based trust registry implements.¶

Second, on authorization scope (§2.1.2, "Authorisation"), the framework recommends that authorisations be scoped, time- or session-bound, non-transferable, and follow the principle of least privilege by default with explicit escalation paths; that they be bounded by the authorising human's permissions; and that delegations of authority be clearly recorded.¶

This maps directly to the three AAE blocks: MANDATE defines the scope and action allowlist, CONSTRAINTS implement least-privilege and value bounds, VALIDITY enforces time-bound non-transferable authorization, and the delegation chain structure records authority provenance (Section 3).¶

A case study in the same framework (§2.3, "Terminal 3 case study") describes an independent implementation of the same pattern: a "Verifiable Credential of Intent" issued by a human principal to an agent before each cycle, defining accessible records, applicable constraints, and a declared ceiling amount. This is a real-world deployment of pre-transaction scoped authorization that is structurally equivalent to AAE.¶

1.2. 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 entity that takes actions on behalf of a principal, potentially without per-action human approval.¶

Principal: The human or organization that deploys and is ultimately accountable for an agent's actions.¶

Issuer: The entity that issues the AAE, typically a trust registry or the principal directly.¶

Relying Party: The system or service that receives a request from an agent and evaluates the AAE to determine whether to process it.¶

AAE: Agent Authorization Envelope — the structured authorization container defined in this document.¶

2.1. Structure

On the wire, a secured AAE is a JWS in compact serialization:¶

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)

The JWS Protected Header MUST contain:¶

{
  "alg": "EdDSA",
  "cty": "aae+json",
  "kid": "did:moltrust:registry#key-1"
}

alg: REQUIRED. MUST be "EdDSA"; the curve MUST be Ed25519, as specified for JOSE in [RFC8037].¶

cty: REQUIRED. The media type of the JWS payload; MUST be "aae+json" (Section 11). The "application/" prefix is omitted as permitted by [RFC7515]. Per [RFC7515], cty (content type) identifies the secured payload; the typ parameter, if present, identifies the JWS object itself and MUST NOT carry the payload media type.¶

kid: REQUIRED. A DID URL identifying the issuer verification method. It MUST dereference, via the issuer DID document, to an Ed25519 verification method authorized for the assertionMethod proof purpose.¶

The JWS Payload is the unsecured AAE: a W3C Verifiable Credential whose media type is application/aae+json (Section 11).¶

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://moltrust.ch/contexts/aae/v1"
  ],
  "type": ["VerifiableCredential", "AgentAuthorizationEnvelope"],
  "id": "urn:uuid:3f2b8c10-7c2e-4f1a-9b6d-1e2a3c4d5e6f",
  "issuer": "did:moltrust:registry",
  "validFrom": "2026-05-20T10:00:00Z",
  "credentialSubject": {
    "id": "did:example:agent-abc123",
    "aae": {
      "mandate": { ... },
      "constraints": { ... },
      "validity": { ... }
    }
  }
}

The Verifiable Credential MUST contain an id member whose value is a URI [RFC3986] that is globally unique across all AAEs issued by the issuer (for example, a UUID URN [RFC9562]). The Verifiable Credential MUST NOT contain an embedded proof member; integrity and authenticity are provided solely by the enclosing JWS.¶

2.2. The MANDATE Block

The MANDATE block specifies what the agent is authorized to do. It MUST contain an actions array of permitted action identifiers and SHOULD contain a purpose string describing the authorization context.¶

"mandate": {
  "actions": ["read", "book", "pay"],
  "purpose": "Travel booking on behalf of principal",
  "scope": "travel-vertical",
  "principal_did": "did:example:principal-xyz"
}

actions: REQUIRED. Array of strings. Each string is a permitted action identifier. Relying parties define their own action vocabularies; interoperability is achieved through shared vertical schemas (see Section 4).¶

purpose: RECOMMENDED. Human-readable description of the authorization context. Used for audit logs.¶

scope: OPTIONAL. Restricts the MANDATE to a specific vertical or service domain.¶

principal_did: RECOMMENDED. The DID of the human or organization ultimately accountable for the agent's actions.¶

The MANDATE block MAY also contain a delegation object or a delegation_policy object; both are defined in Section 3.¶

The same principal may also be named in another identifier space — one defined outside this document, whether by a further specification or by a relying party's own enrolment records. Nothing in AAE requires two such identifiers to agree, or even to be comparable, and no rule in this document derives one from the other. Where a deployment needs the question answered, it answers it with data: a table mapping both identifier forms onto one canonical space, published as part of the deployment. An identifier with no entry is unresolved, which is a missing input rather than a conflict. Such a table is supplied, not derived; a rule that only reads a table is not a rule this document can state. See Section 9.¶

"grants": [
  {
    "action_binding": "sha256:<64 lowercase hex characters>",
    "type_fields": ["verb", "asset", "chain"],
    "disposition": "allow",
    "constraints": [
      { "type": "exact", "field": "to", "value": "0xABCDEF01" },
      { "type": "range", "field": "amount", "lo": 0, "hi": 1000 }
    ]
  }
]

action_binding = "sha256:" || LOWERHEX( SHA-256( TAG || JCS(A) ) )

TAG = the 21 octets "aae:enforce-action:v1" followed by a single
      0x00 octet

2.3. The CONSTRAINTS Block

The CONSTRAINTS block specifies limits that bound the agent's actions within the MANDATE.¶

Relying parties MUST enforce all constraints they recognize. A relying party MUST reject an AAE if any constraint marked required: true is unrecognized or cannot be evaluated. A relying party MAY ignore an unrecognized constraint only if that constraint is explicitly marked required: false. If the required member is absent, the constraint MUST be treated as required: true.¶

"constraints": {
  "max_transaction_value": {
    "value": 500,
    "currency": "USD",
    "required": true
  },
  "allowed_domains": {
    "value": ["booking.example.com", "flights.example.com"],
    "required": true
  },
  "rate_limit": {
    "value": 10,
    "window": "PT1H",
    "required": false
  }
}

Constraint keys are extensible. This document defines three RECOMMENDED constraint types:¶

• max_transaction_value: Maximum value of any single transaction. MUST include value (number) and currency (ISO 4217).¶

• allowed_domains: Allowlist of domains the agent may contact.¶

• rate_limit: Maximum number of actions per time window. MUST include value (integer) and window (an ISO 8601 duration, e.g., "PT1H").¶

A relying party that enforces a rate_limit constraint marked required: true MUST maintain sufficient state to count accepted actions within the specified window. A relying party that cannot maintain such state MUST reject an AAE containing a required rate_limit constraint.¶

2.4. The VALIDITY Block

The VALIDITY block specifies the temporal bounds of the authorization.¶

"validity": {
  "not_before": "2026-05-20T10:00:00Z",
  "not_after": "2026-05-20T18:00:00Z",
  "revocation_check": "https://api.moltrust.ch/aae/revocation/{id}",
  "single_use": false
}

not_before: REQUIRED. An RFC 3339 [RFC3339] date-time, expressed in UTC with the "Z" offset. The AAE MUST NOT be accepted before this time.¶

not_after: REQUIRED. An RFC 3339 [RFC3339] date-time, expressed in UTC with the "Z" offset. The AAE MUST NOT be accepted after this time. Relying parties MUST reject expired AAEs.¶

revocation_check: OPTIONAL. An HTTPS URI Template [RFC6570] for checking AAE revocation status. The template MUST support the {id} variable, expanding (with URI encoding) to the Verifiable Credential id, and SHOULD support the {did} variable, expanding to credentialSubject.id. If revocation_check is present, the relying party MUST query the endpoint over HTTPS; the response MUST be a JSON object containing at least an id member and a boolean revoked member. The relying party MUST reject the AAE if the endpoint indicates revoked: true or if the response cannot be parsed. If revocation status cannot be determined — for example, on network failure or an HTTP 5xx response — the relying party MUST reject the AAE. A relying party MAY apply an explicit, locally configured, auditable fail-open policy only for AAEs whose risk classification permits such behaviour; such a policy SHOULD NOT be used for high-risk actions and MUST be subject to explicit governance and audit logging.¶

single_use: OPTIONAL. Boolean. Default: false. If true, the relying party MUST maintain state keyed by the Verifiable Credential id (Section 2.1) and MUST reject any subsequent presentation of an AAE bearing the same id after the first successful authorization. A relying party that cannot maintain such state MUST reject any AAE with single_use: true. Where a relying party is deployed across multiple nodes, the single-use state MUST be shared across all nodes that can accept the AAE; otherwise the AAE could be replayed against a different node. In this document, "invalidation" denotes relying-party-local state; it does not invalidate the AAE globally.¶

If the Verifiable Credential contains a validFrom member, the relying party MUST NOT accept the AAE before the later of validFrom and validity.not_before. Issuers SHOULD set validFrom equal to or earlier than validity.not_before.¶

A verdict under Section 2.5 is a function of the mandate and the transaction. It says nothing about whether a condition that held when the mandate was issued still holds at the moment the action is attempted. Answering that requires state carried across presentations — a counter that advanced, an identifier already spent, an attestation of recency — and the runtime core of Section 2.5.3 holds none by construction, since carrying such state would break the recompute determinism that section requires. The members defined above bound the authorization in time; they do not make it fresh. See Section 9.¶

2.5. Enforcement Constraint Language

This section defines a constraint language used by grants (Section 2.2.1). It is separate from the CONSTRAINTS block of Section 2.3 and does not modify it. Section 2.3 defines an open, extensible set of named constraint keys evaluated by a relying party that may consult stored state; the language here is closed and evaluates a single transaction with no state at all. The two coexist: an AAE MAY carry a Section 2.3 CONSTRAINTS block and Section 2.2.1 grants, and a relying party evaluates each on its own terms.¶

Recompute determinism is the reason for the separation. Two independent verifiers MUST reach an identical result from identical inputs, and that holds only if the constraint language is not a program.¶

{
  "predicate": "range",
  "field": "amount",
  "value": 500,
  "bound": { "lo": 0, "hi": 1000 },
  "result": "PASS"
}

{
  "enforce_version":    "<string>",
  "mandate_digest":     "sha256:<64 lowercase hex characters>",
  "transaction_digest": "sha256:<64 lowercase hex characters>",
  "action_digest":      "sha256:<64 lowercase hex characters>",
  "verdict":            "PERMIT | DENY | PENDING",
  "grant_index":        0,
  "trace":              [],
  "prev_core_digest":   "sha256:<64 lowercase hex characters>"
}

core_digest = "sha256:" || LOWERHEX( SHA-256( TAG || JCS(core) ) )

TAG = the 19 octets "aae:enforce-core:v1" followed by a single
      0x00 octet

5.1. Verification Dependencies

The checks above are evaluated by the relying party against the presented AAE and its ancestors. This document defines no step in which the relying party contacts the organization that originated the authorization in order to obtain an authorization decision: the AAE carries the authorization and the relying party evaluates it.¶

The algorithm does depend on data the relying party may have to retrieve:¶

• the DID documents needed to resolve the signing DID in step 1 and, where step 4 is performed, credentialSubject.id;¶

• each ancestor AAE of a delegation chain in step 9, obtained from delegation.delegator_aae_uri unless the transport binding conveys the ancestor inline as described in Section 3;¶

• the endpoint named in validity.revocation_check, queried over HTTPS, where that member is present (step 8).¶

These are retrieval dependencies, not authorization callbacks. This document does not constrain how a relying party obtains them, and Section 3 already contemplates an ancestor conveyed inline rather than fetched. Verification therefore requires no synchronous call to the originating organization, but characterising it as offline without qualification is inaccurate for any AAE that carries a delegation chain or a revocation_check member.¶

5.2. Deferred Verification Capabilities

Four capabilities named elsewhere in this document are not available in this revision, and all four wait on the same thing: a relying party can only make them safe once it can perform outbound requests through a proxy that constrains where those requests may go. Until such a proxy exists, a conforming implementation refuses rather than pretends.¶

• Ancestor retrieval by delegator_aae_uri. Step 9 verifies ancestors supplied inline. A relying party MUST NOT dereference delegator_aae_uri in this revision.¶

• DID methods requiring outbound resolution. This affects the subject in step 4 and the delegator in step 9 alike: where the DID cannot be resolved locally, the relying party rejects rather than fetches.¶

• Revocation checking (step 8). A relying party that cannot perform the lookup rejects an AAE carrying revocation_check fail-closed, rather than reporting a check it did not perform. What rests on this limitation is the discovery half of Section 7.5 — establishing that a parent has been revoked. The consequence half of that section is not deferred: a relying party that already knows of the revocation MUST treat the descendants as invalid, and no egress path is needed to obey a rule about what it already holds.¶

• Case (b) delegated signing authority. Establishing that a delegator's DID document authorizes another DID requires resolving that document, which is the second item above.¶

The condition for a future revision is an egress path that constrains outbound requests and is available to the relying party. All four become specifiable together, because one capability unlocks all of them. Section 9 lists the relying-party revocation lookup under the same condition; it is this list's third item seen from the roadmap side.¶

6.1. Verdict Vocabulary

Evaluating a transaction against a mandate yields exactly one of three verdicts.¶

• PERMIT — a grant bound the action, all of that grant's constraints held, and its disposition is allow. PERMIT is reachable in no other way.¶

• PENDING — a grant bound the action, all of its constraints held, and its disposition is hold. PENDING states that the mandate defers this action to a decision that has not been made. It MUST NOT be produced for an action no grant addresses.¶

• DENY — every other outcome. A missing or structurally invalid mandate, a missing transaction, an action that cannot be canonicalized, an unaddressed action, a matched forbid grant, an unknown constraint type, an unparseable value, and a matched grant whose constraints do not hold all produce DENY.¶

DENY is the default. A relying party that cannot evaluate MUST deny; absence of a mandate is never a route to PERMIT.¶

6.2. Verdict Records and Chaining

A verdict record consists of the core of Section 2.5.3 and its digest. A record is immutable. A relying party MUST NOT edit a record after it is produced.¶

Verdict records MAY be chained. A record's prev_core_digest carries the core digest of the record it follows, or null at the start of a chain. The caller holds the chain; this document does not require a chain to be published, stored, or anchored to any ledger.¶

A ratification record is the exception. Its prev_core_digest MUST be present and MUST equal the core digest of the record it ratifies. A ratification is a statement about one specific prior record, and a chaining field pointing anywhere else would describe a different history than the one the ratification asserts. A verifier MUST reject a ratification record whose prev_core_digest is absent or does not equal the digest it claims to ratify.¶

6.3. Ratification

A verdict may need a status it did not have when it was produced — an action held under PENDING that the mandating party later authorizes, or a denial that party subsequently confirms. This document corrects such history by appending, never by editing.¶

A ratification is a second signed record referencing a prior verdict record by its core digest. It carries a decision, which is either APPROVED or DISAPPROVED, and it reports a status, which is either RATIFIED or REJECTED. The decision is what the ratifying party asserts; the status is what the verifier established about that assertion. A decision takes effect for the prior record only when the status is RATIFIED. When the status is REJECTED, the prior record keeps the verdict it had, and the ratification records why the assertion did not hold.¶

What the decision is about. APPROVED and DISAPPROVED are statements about the action, not about the verdict record. APPROVED says the authority authorizes the action the prior record describes; DISAPPROVED says it does not. Reading them the other way — as an endorsement or a rejection of the verdict — would make APPROVED mean "the denial was right" in one row of the matrix below and "the action may proceed" in another, and a party signing a statement would not know which it had signed. One reading, fixed here: the decision is about the action.¶

The four combinations of a ratifiable prior verdict and a decision therefore resolve as follows, in every case only where status is RATIFIED:¶

Where status is REJECTED, none of the four rows takes effect: the assertion did not hold, and the action's authorization is whatever the prior verdict already made it.¶

Two consequences of the table are normative. A relying party MUST NOT edit or re-issue the prior record in any row — the effective authorization is read from the pair (prior verdict, decision) carried in the ratification, and no fourth verdict value is produced. And the third row, DENY with APPROVED, is an authorization the mandate itself did not give: a relying party MUST NOT treat the resulting record as a PERMIT of Section 6.1, MUST record that the authorization derives from a ratification rather than from a grant, and MUST bound it to the one transaction the prior record's transaction_digest names. A ratification authorizes one transaction, never a class of them.¶

The signed statement binds three things together:¶

{
  "ratify_version": "3.0",
  "ratifies": "sha256:<64 lowercase hex characters>",
  "decision": "APPROVED",
  "authority": "<DID>"
}

It is signed over the domain tag aae:enforce-ratify-statement:v1 followed by a 0x00 octet and the [RFC8785] canonicalization of that object. Binding all three means an APPROVED signature cannot be moved to another record, cannot be reread as DISAPPROVED, and cannot be attributed to a different authority.¶

ratify_version is inside the signed bytes, so it is not decoration: a party that builds the statement with a different value produces a different signature over the same decision.¶

A ratification record carries its own core, with its own structure. It is not a verdict core with different values: it has no verdict, no action_digest and no grant_index, and it carries members a verdict core does not. Stating it by reference to Section 2.5.3 would leave a third-party verifier guessing which of those members survive, so it is written out here.¶

{
  "ratify_version":   "<string>",
  "ratifies":         "sha256:<64 lowercase hex characters>",
  "prior_verdict":    "DENY | PENDING",
  "decision":         "APPROVED | DISAPPROVED",
  "status":           "RATIFIED | REJECTED",
  "authority":        "<DID string or null>",
  "mandate_digest":   "sha256:<64 lowercase hex characters>",
  "trace":            [],
  "prev_core_digest": "sha256:<64 lowercase hex characters>"
}

ratifies is the core digest of the record being ratified, and prior_verdict is that record's verdict — only DENY and PENDING are ratifiable, so no other value appears here. status is what the verifier established and decision is what the authority asserted; a decision takes effect for the prior record only where status is RATIFIED. authority is null exactly where status is REJECTED and no authority was established. mandate_digest is copied from the prior record's core, which is what binds the ratification to the same mandate the verdict was reached under. prev_core_digest equals ratifies, as Section 6.2 requires; it is carried explicitly so that the chaining member has the same name and meaning in both record types. trace entries are the structured five members of Section 2.5.2; as in Section 2.5.3, the human-readable reason — on the record and on each entry — is diagnostic and is not digested.¶

The digest is computed as everywhere else in this document, under its own tag:¶

core_digest = "sha256:" || LOWERHEX( SHA-256( TAG || JCS(core) ) )

TAG = the 26 octets "aae:enforce-ratify-core:v1" followed by a
      single 0x00 octet

The separate tag keeps a ratification core from ever colliding with a verdict core: the two structures could otherwise be confused by a verifier that only compared digests. A later record that chains onto a ratification points at this digest.¶

Like a verdict record, a ratification record is deterministic. Its inputs are exactly three: the prior verdict record, the decision, and the authority proof of Section 6.4. The mandate is the fourth thing a recomputation needs — without it the authority cannot be derived and the mandate digest cannot be bound — and it is not a fourth input, because it travels as a member of the authority proof. Stating it that way matters: a third party holding a prior record, a decision and a proof holds the mandate too, and recomputes the record without contacting the verifier or fetching anything. A proof without its mandate member is not a proof, and Section 6.4 gives it no other route in.¶

6.4. Authority (Witness, not Ruler)

The authority ratifying a record MUST derive from the mandate the prior record refers to. Two sources are permitted, both inside the mandate: the issuing principal, and a role the mandate names. A verifier MUST NOT accept a ratification from any other party, and in particular MUST NOT recognize the operator of the verification service, a registry, or any central supervising role as an authority by virtue of its position.¶

The public key against which the signature is checked MUST be taken from the mandate and MUST NOT be taken from the proof. A proof that carries its own key establishes nothing.¶

Where the authorities are named. The two sources are two named members of the mandate, and a third party checking a ratification reads exactly these:¶

"principal": {
  "did": "<DID>",
  "public_key": "<32 octets, hexadecimal>"
},
"ratification_authorities": [
  {
    "did": "<DID>",
    "public_key": "<32 octets, hexadecimal>",
    "role": "<string>"
  }
]

mandate.principal is the issuing principal and contributes one authority. mandate.ratification_authorities is an OPTIONAL array; a relying party MUST support at least 64 entries and MAY ignore entries beyond a limit of its own, and ignoring an entry can only make a ratification harder to establish, never easier, so the limit is fail-closed by construction.¶

An entry contributes an authority only where it carries both a did string and a public_key string. An entry with a DID and no key names a party whose signature cannot be checked, which is not an authority; a relying party MUST NOT treat it as one and MUST NOT fall back to any other key for it.¶

role is a label, not a permission. A relying party MUST NOT interpret it, MUST NOT derive any capability from its value, and MUST NOT require it: what is checked is that the claimed authority's DID appears in one of the two members above, and that the signature verifies under the key given there. The role is reported alongside the result so a reader can see which of the two sources applied. This is what makes "a role the mandate names" checkable by a third party: there is no role vocabulary to agree on, only two member names and a DID.¶

An issuer MUST NOT name the same DID twice across the two members. Two entries for one DID with different keys make the mandate ambiguous about which key is authoritative, and a verifier resolving that ambiguity by position would make the outcome depend on document order.¶

The authority proof. The proof is an object with three REQUIRED members:¶

{
  "mandate": {},
  "authority": "<DID>",
  "signature": "<64 octets, hexadecimal>"
}

mandate is the full mandate, supplied because the prior record carries only its digest. The paragraph below binds it by recomputing its digest against the prior record's mandate_digest; it is never trusted as supplied.¶

authority is the DID the signer claims. It is compared against the DIDs of the two members above as an exact octet sequence, in constant time. A relying party MUST NOT normalize, percent-decode, case-fold, or otherwise transform either side before comparing, and MUST NOT accept a DID URL carrying a fragment or a path in this member: the value is a DID, not a verification-method reference.¶

signature is the raw Ed25519 signature over the statement bytes of Section 6.3 — the domain tag, a 0x00 octet, and the [RFC8785] canonicalization of the statement object — encoded as hexadecimal.¶

The cryptographic profile is fixed: EdDSA over Ed25519 [RFC8032], a 32-octet public key and a 64-octet signature, both hexadecimal. There is no JOSE container here and no algorithm agility: the signature is over the statement bytes directly, so there is no header a party could vary and nothing to negotiate. A relying party MUST reject a key or a signature of any other length, and MUST treat every decoding failure as a failed signature predicate rather than as an error — a malformed proof is a rejected ratification, not a crash.¶

Because a verdict record carries only the mandate's digest, the ratifying party supplies the mandate alongside the proof. The verifier MUST bind it by recomputing the mandate digest per Section 2.5.3 and comparing it against the prior record's mandate_digest. A mandate that does not match makes the proof worthless and the status MUST be REJECTED.¶

A verifier MUST set the status to REJECTED, and MUST leave the prior record's verdict standing, when any of the following holds: the authority proof is absent or malformed; the supplied mandate does not match the prior record's mandate digest; the claimed authority is neither the issuing principal nor a role named in the mandate; or the signature does not verify under the mandate-held key. Each of these MUST appear as a failed predicate in the ratification's trace.¶

Only DENY and PENDING may be ratified. A PERMIT has no status to change, and an attempt to ratify one is a caller error rather than a rejected ratification.¶

The line between the two outcomes is worth stating, because both refuse the request and only one of them produces a record. A rejected ratification is a result: the question was well posed and the answer is that the authority did not hold, so there is a record with a status of REJECTED and a trace saying which predicate failed. A caller error is not a result: the question itself does not line up, so there is nothing to record. A relying party MUST treat as a caller error, and MUST NOT produce a ratification record for: a decision that is neither APPROVED nor DISAPPROVED; a prior record whose core_digest does not match its own core; a prior record carrying no mandate_digest; a prior verdict that is not DENY or PENDING; and a supplied prev_core_digest that names a record other than the one being ratified (Section 6.2). Everything else — a missing proof, a mandate that does not bind, an authority the mandate does not name, a signature that does not verify — is a REJECTED record with a trace.¶

7.1. Replay Attacks

AAEs with broad temporal validity windows are susceptible to replay attacks. Implementations SHOULD use short not_after windows (minutes to hours for high-value actions) and SHOULD implement nonce-based replay protection at the transport layer.¶

The verdict of Section 2.5.3 is a function of the mandate and the transaction and of nothing else. It carries no server time, no counter, and no record of what has been presented before. That is deliberate — it is what makes a verdict recomputable by a third party who was not present when it was reached — and it is also a limit that has to be read as one.¶

A PERMIT is not a single-use authorization. The same mandate and the same transaction produce the same PERMIT every time they are evaluated, at this relying party and at any other. Section 2.5 provides no replay protection, no cumulative budget across presentations, and no rate limit. An agent holding a mandate whose range constraint bounds a transfer at 1000 can obtain a PERMIT for a transfer of 1000, and then obtain it again: the constraint bounds each transfer, never their sum. A relying party that reads a PERMIT as "this action has not yet been authorized" reads something the verdict does not say.¶

Where replay protection matters, it MUST come from the protocol around the verdict rather than from the verdict. A relying party acting on a PERMIT MUST establish freshness and consumption by its own means — a nonce it minted for this presentation, an identifier it records as spent before acting, or an idempotency key on the action it is about to perform. A relying party that does none of these MUST NOT rely on the verdict for either property.¶

Step 4 of Section 5 provides exactly this for the envelope: a challenge bound to a nonce this relying party minted, and a used-nonce store that refuses the second presentation. Nothing equivalent exists at the enforcement layer in this revision. Section 9 names the condition under which it could — state carried across presentations, together with a resolution of what such state does to the recompute guarantee of Section 2.5.3, since a verdict that depends on a counter is no longer a function of the mandate and the transaction alone. Until that is resolved, the absence is a property of this document and not an omission from it.¶

7.2. Constraint Bypass

Relying parties that silently ignore unrecognized constraints create a security gap. Relying parties MUST treat unrecognized constraints with required: true as grounds for rejection.¶

7.3. Key Compromise

If an issuer's signing key is compromised, all AAEs signed by that key are potentially invalid. Issuers MUST have an operational key-rotation procedure and SHOULD publish revocation endpoints. Issuers SHOULD retain verification material for retired signing keys for at least as long as AAEs signed by those keys can remain valid, unless a key was retired because of compromise. Issuers SHOULD provide a mechanism for real-time revocation signaling to relying parties; continuous access evaluation profiles defined by other standards bodies are one such mechanism.¶

7.4. Delegation Amplification

Delegation chains that do not enforce constraint monotonicity allow sub-agents to acquire permissions exceeding those of their parent. Implementations MUST enforce that delegated AAEs are strictly subordinate to their parent AAEs in actions, constraints, and validity.¶

7.5. Delegation Revocation

The previous revision carried two SHOULD statements here. They do not stand on the same ground, and this revision separates them.¶

Issuer. If a parent AAE or a delegator agent is compromised, the issuer MUST revoke the parent, and MUST treat all downstream delegated AAEs as revoked. The revocation MUST propagate along the delegation chain to every descendant reachable from the revoked node.¶

Revocation of the parent MUST NOT be withheld because the cascade could not be completed. Of the two ways this can fail, a compromised parent still reported as valid is the worse one, and withholding its revocation is the only way this rule could fail open. An issuer that cannot propagate to every descendant MUST therefore report two things at once: the parent as revoked, and the cascade as incomplete. A descendant of a revoked parent whose own status could not be set is unknown, and a relying party MUST treat unknown as invalid here — the same outcome as an explicit revocation, reached without claiming a status the issuer never established.¶

The rule places no depth limit on the cascade, because depth is a property of a deployment and not of this format. An implementation that bounds its propagation has an incomplete cascade in the sense above and reports it as such; it does not report a complete one.¶

Relying party. Two statements, and only one of them waits on a capability this revision defers.¶

A relying party that has determined that a parent AAE in a delegation chain is revoked MUST treat every descendant AAE in that chain as invalid. This is unconditional, and it costs nothing to satisfy: the sentence applies only once the revocation is already known — from a status list the relying party already holds, from material presented alongside the envelope, or from a check it performed earlier. No lookup follows from it. A SHOULD here would permit a relying party to accept a descendant of a parent it already knows to be revoked, which is not a limitation of any deployment but a decision to disregard what it knows.¶

What stays deferred is the discovery of revocation, not the consequence of it. A relying party SHOULD NOT dereference a revocation endpoint at evaluation time in this revision: doing so safely requires an egress path that constrains outbound requests, and until one exists, a conforming implementation rejects an AAE carrying revocation_check fail-closed rather than reporting a check it did not perform (Section 5.2). Section 9 names the condition under which the discovery half becomes normative too.¶

7.6. Clock Skew and Time Synchronization

AAE validity depends on relying-party evaluation of not_before, not_after, and challenge-response timestamps. Relying parties SHOULD use authenticated time synchronization and SHOULD define a maximum accepted clock-skew window. For high-value actions, relying parties SHOULD keep the accepted skew to the minimum operationally feasible value. Excessive clock-skew windows can allow premature use of an AAE or its continued use after expiration.¶

7.7. On-Chain Anchoring

When AAEs are anchored to a public ledger for tamper-evident audit trails, implementations MUST ensure that no personally identifiable information (PII) is written on-chain. AAE content SHOULD be hashed before anchoring; the hash, timestamp, and issuer DID are sufficient for audit purposes.¶

Where a verdict record is anchored for audit, committing to a sensitive argument value rather than writing it in the clear would let an auditor confirm that an agent stayed inside a bound without the value itself becoming public. Any such commitment has to bind to anchored reality rather than to caller-supplied input, since a commitment over a claim is not a commitment over anything checkable. This document defines no such mechanism; see Section 9.¶

7.8. Predicate Trace Disclosure

Section 2.5.2 requires every verdict to carry a predicate trace, and every entry of that trace carries value — what the transaction held at the constrained field — and bound — what the constraint required. A conforming verdict therefore discloses the transaction values that were tested and the limits they were tested against, in the clear, to everyone who holds the record. A recipient address compared under exact, an amount compared under range, a jurisdiction compared under enum: all three appear verbatim in the trace, and the trace is inside the digested core of Section 2.5.3.¶

This is not incidental and it is not minimized. The trace is what makes a verdict checkable predicate by predicate rather than merely signed, and a trace with the values removed would not support the recompute guarantee: a second implementation could no longer derive the same core, only accept the first one's word for it. The property that makes the verdict verifiable is the same property that makes it disclosing, and this revision does not offer both.¶

Three consequences are normative. A relying party MUST treat a verdict record as carrying transaction content, with the same care it applies to the transaction itself. A relying party MUST NOT forward, publish, transmit to a third party, or anchor a verdict record whose trace carries values it is obliged to protect, unless the recipient is already entitled to those values; Section 7.7 requires that no personally identifiable information be written on-chain when a record is anchored for audit, the trace is precisely the member of a verdict record that can carry it, and an anchoring pipeline that hashes the record without inspecting the trace has satisfied Section 7.7 only by accident. And where a relying party retains verdict records, it MUST apply to them the retention limit it applies to the transactions they describe: a record kept after the transaction has been deleted keeps the deleted values.¶

An issuer has one mitigation available inside this revision, and it is a blunt one: not to constrain a sensitive value in a grant at all, and to bound it outside the enforced path instead. That trades away the enforcement the grant would have provided, which is why it is a mitigation and not a solution.¶

Section 9 names selective hash commitments as the intended remedy — a commitment to a value rather than the value itself, so that an auditor can confirm an agent stayed inside a bound without the bound or the value becoming public. Section 7.7 describes what such a mechanism would have to bind to. Neither defines one, and until one exists, the disclosure above is the behaviour a conforming implementation exhibits.¶

7.9. Resource Exhaustion and Input Limits

The minimum capabilities of Sections 2.2.1 and 2.5.1 — 256 grants, 64 constraints per grant, 512 enum members, 32 type-field names, paths of 8 segments — are floors a conforming verifier has to reach, not sizes it has to accept without limit (Section 2.2.1). Read together with the comparison rules they describe a worst case, and the worst case is caller-supplied: a mandate at every floor, evaluated against one transaction where every matched grant fails on its last constraint, reaches 256 x 64 x 512 = 8 388 608 string comparisons, over values the caller chose the length of. The predicate trace grows with it, entry by entry, and the trace is digested.¶

The comparison rules themselves are not where to economize. The constant-time exact comparison and the non-short-circuiting enum comparison exist so that timing does not reveal how close a value came or where in an enumeration it matched, and an implementation that abandons either to save work has traded a denial-of-service surface for a side channel. Both remain MUST without qualification.¶

The input is where to economize. A relying party MAY set hard limits of its own, applied before evaluation begins, on the length of any string in the mandate or in the transaction; on the total serialized size of the mandate and of the transaction; on the depth and the member count of the transaction object; and on the number of entries a predicate trace may reach. Such limits are local policy and this document fixes no value for any of them, for the same reason it states capabilities as floors: an issuer needs to know what any conforming verifier will accept, and a verifier needs to remain free to protect itself above that.¶

Where an input exceeds a limit, the relying party MUST reject fail-closed. Rejection here is the DENY verdict of Section 6.1, decided before evaluation rather than during it. A relying party MUST NOT truncate the input, MUST NOT evaluate a prefix of it, and MUST NOT return PERMIT on a mandate it evaluated only in part — a partial evaluation that stops at a limit has not established that the remaining grants were absent, only that it did not read them.¶

Two points follow specifically for the trace. A value or a bound read from a caller-supplied transaction enters the trace and therefore the digested core, so a limit on input string length is also the only limit on how large a verdict record can grow. And a relying party that refuses an oversized input MUST report the refusal as a DENY with its reason recorded rather than as a transport error, so that the caller can distinguish a refusal to evaluate from a failure to reach the verifier — the two call for different responses, and conflating them makes an overload look like an outage.¶

11.1. Media Type Registration

IANA is requested to register the following media type in the "Media Types" registry, following the procedures of [RFC6838] and the structured syntax suffix rules of [RFC6839]:¶

Type name:

application¶

Subtype name:

aae+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

Same as for application/json [RFC8259]; UTF-8.¶

Security considerations:

See Section 7 of this document.¶

Interoperability considerations:

This media type uses the "+json" structured syntax suffix [RFC6839]. Processors that do not understand application/aae+json MAY process it as application/json.¶

Published specification:

This document.¶

Applications that use this media type:

Autonomous AI agent frameworks, authorization servers, policy engines, and relying parties that issue or evaluate Agent Authorization Envelopes.¶

Fragment identifier considerations:

As specified for the "+json" structured syntax suffix in [RFC6839].¶

Additional information:

Deprecated alias names for this type: N/A. Magic number(s): N/A. File extension(s): .aae.json. Macintosh file type code(s): N/A.¶

Person & email address to contact for further information:

Lars Kersten Kroehl lars@moltrust.ch¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Lars Kersten Kroehl¶

Change controller:

Lars Kersten Kroehl, CryptoKRI GmbH¶

This registration applies to the unsecured JSON AAE payload. A secured AAE in JWS compact serialization is not a JSON document and is transported using the application/jose media type defined in [RFC7515]; this document does not register a separate media type for the secured form.¶

11.2. No Further IANA Actions

This document requests no other IANA actions.¶

This revision introduces several closed vocabularies and several domain tags, and none of them is offered for registration. The disposition values of Section 2.2.1, the constraint types of Section 2.5.1, the verdict vocabulary of Section 6.1, the decision and status values of Section 6.3, and the domain tags used by the digests of Sections 2.2.2, 2.5.3 and 6.3 are closed sets defined by this document. A value outside one of these sets is not an extension; it is an input a conforming verifier rejects. Extension therefore happens by a new revision of this document, not by an addition to a registry.¶

The reason is stated in Section 2.5.1 and is a security property rather than an editorial preference: what a verifier cannot evaluate, it does not permit. A registry would make these sets open at exactly the point where that section requires them to be closed, and two verifiers reading different registry snapshots could then reach different verdicts on the same input — which Section 2.5.3 forbids.¶

12.1. Normative References

[W3C-DID]

W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July 2022, <https://www.w3.org/TR/did-core/>.

[W3C-VC]

W3C, "Verifiable Credentials Data Model v2.0", 8 May 2024, <https://www.w3.org/TR/vc-data-model-2.0/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/info/rfc8037>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC6570]

Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC7797]

Jones, M., "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, <https://www.rfc-editor.org/info/rfc7797>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC6839]

Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/info/rfc6839>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

12.2. Informative References

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/info/rfc9635>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/info/rfc9562>.

[SPIFFE]

"SPIFFE: Secure Production Identity Framework for Everyone", n.d., <https://spiffe.io/>.

[ARXIV-AAE]

Kroehl, L. K., "From Specification to Deployment: Empirical Evidence from a W3C VC + DID Trust Infrastructure for Autonomous Agents", May 2026, <https://arxiv.org/abs/2605.06738>.

[IMDA-MGF]

Singapore IMDA, "Model AI Governance Framework for Agentic AI, Version 1.5", 20 May 2026, <https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf>.

[NIST-CAISI]

NIST, "NIST AI 100-1: Artificial Intelligence Risk Management Framework", January 2023.

[PEDIGREE]

Rampalli, K., "PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems", Work in Progress, Internet-Draft, draft-rampalli-pedigree-00, 25 April 2026, <https://datatracker.ietf.org/doc/draft-rampalli-pedigree-00/>.