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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

The deployment of autonomous AI agents at scale creates an authorization gap that existing Internet protocols do not address. When a human user initiates a request, the authorization question is well-understood: who is the user, what are they permitted to do, and has their session expired? Protocols such as OAuth 2.0 [RFC6749] answer these questions for human-delegated access.¶

When an autonomous agent initiates a request — potentially on behalf of another agent, under a delegated mandate, with specific constraints on permissible actions — the question requires a different answer. The agent may be acting under a mandate issued hours earlier; its actions may be bounded by value caps, action allowlists, or domain restrictions; and the authorization may expire on a schedule that the receiving system must be able to verify without contacting the issuing party.¶

No current IETF standard addresses this combination of requirements for autonomous agents. OAuth 2.0 scopes are issuer-defined strings without machine-evaluable semantics for agent mandates. SPIFFE/SVID addresses workload identity but not authorization semantics. JWT claims are flexible but unstructured for agent-specific use cases.¶

This document specifies the Agent Authorization Envelope (AAE) to fill this gap. AAE is derived from a production deployment operational since March 2026 [ARXIV-AAE] and is aligned with regulatory requirements from Singapore IMDA [IMDA-MGF], NIST [NIST-CAISI], and the EU AI Act (Regulation 2024/1689).¶

2. The Agent Authorization Envelope

An AAE is a W3C Verifiable Credential [W3C-VC] whose credentialSubject carries an aae object. The aae object has three mandatory members — mandate, constraints, and validity — defined in the following subsections.¶

An AAE MUST be secured using JOSE. The Verifiable Credential is the payload of a JSON Web Signature (JWS) [RFC7515] in compact serialization, signed by the issuer using the Edwards-curve Digital Signature Algorithm (EdDSA) with the Ed25519 curve, as specified for JOSE in [RFC8037] and for the signature algorithm itself in [RFC8032]. The issuer's signing key is a JSON Web Key (JWK) [RFC7517] bound to the issuer's W3C DID [W3C-DID]: the JWS protected-header kid parameter MUST be a DID URL that dereferences, via the issuer DID document, to the corresponding verification method.¶

This document distinguishes two media types. An unsecured AAE — the Verifiable Credential before JWS encapsulation — is a JSON object with media type application/aae+json (Section 8). A secured AAE — the JWS in compact serialization — is not a JSON document; it is transported with media type application/jose [RFC7515], and the media type of its JWS payload is indicated by the cty protected-header parameter, "aae+json".¶

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

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

{
  "@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": { ... }
    }
  }
}

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

"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
  }
}

"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
}

3. Delegation Chains

An agent may act under a mandate delegated from another agent. An AAE issued directly by a principal, and not itself delegated, is a root AAE: it has no delegation member, and its effective delegation depth is 0. A root AAE that authorizes onward delegation MUST include a delegation_policy object in its MANDATE block with a non-negative integer max_depth member; this value is the parent's effective maximum depth for the first delegation link.¶

"mandate": {
  "actions": ["read", "book"],
  "delegation_policy": { "max_depth": 2 }
}

A delegated AAE carries a delegation object in its MANDATE block:¶

"mandate": {
  "actions": ["read"],
  "delegation": {
    "delegator_did": "did:example:parent-agent",
    "delegator_aae_id": "urn:uuid:parent-aae-123",
    "delegator_aae_uri": "https://aae.example/p/parent-aae-123",
    "delegator_aae_hash": "sha-256:5b7e2c...",
    "depth": 1,
    "max_depth": 2
  }
}

delegator_did: REQUIRED in delegation context. The DID of the delegating agent.¶

delegator_aae_id: REQUIRED in delegation context. The id of the parent AAE.¶

delegator_aae_uri: REQUIRED in delegation context, unless the parent AAE is embedded in the request by the transport binding. A URI from which the relying party can retrieve the parent AAE.¶

delegator_aae_hash: OPTIONAL. A hash of the parent secured AAE. If present, the value MUST have the form sha-256:<base64url-encoded-digest>. The digest input MUST be the exact ASCII octet sequence of the parent AAE JWS compact serialization as retrieved, without additional whitespace, decoding, re-encoding, or JSON canonicalization. SHA-256 is as defined in [RFC6234]. If the computed digest does not match the value in delegator_aae_hash, the relying party MUST reject the delegated AAE.¶

depth: REQUIRED in delegation context. Integer. The delegation depth of this AAE. It MUST equal the parent AAE's effective delegation depth plus 1. The effective delegation depth of a root AAE is 0; the effective delegation depth of a delegated AAE is its delegation.depth.¶

max_depth: REQUIRED in delegation context. Integer. The maximum delegation depth permitted for this branch of the chain. It MUST be less than or equal to the parent AAE's effective maximum depth — the parent's delegation.max_depth if the parent is a delegated AAE, or the root AAE's mandate.delegation_policy.max_depth if the parent is a root AAE. A relying party MUST reject a delegated AAE whose depth exceeds its max_depth, and MUST reject any delegation whose parent is a root AAE that has no delegation_policy.¶

A relying party MUST be able to retrieve the parent AAE in order to verify a delegation chain. The parent AAE's credentialSubject.id MUST equal the delegated AAE's delegation.delegator_did. Which DID is permitted to sign a delegated AAE — the signing-authority rule — is specified in the Verification Algorithm (Section 5).¶

Delegated AAEs MUST NOT grant actions not present in the parent AAE. Delegated AAEs MUST be strictly subordinate to their parent AAE. For the purposes of this document, "equal to or more restrictive" is defined per element as follows:¶

• Actions: The delegated mandate.actions MUST be a subset of the parent mandate.actions. If the delegated MANDATE contains the delegate action, the parent MANDATE MUST also contain it.¶

• Numeric upper-bound constraints (for example, max_transaction_value): The delegated value MUST be less than or equal to the parent value.¶

• Rate-limit constraints (rate_limit): A delegated rate_limit constraint is equal to or more restrictive than the parent only if the relying party can prove that no execution pattern permitted by the delegated rate limit would violate the parent rate limit. In the absence of a profile defining such comparison semantics, the delegated rate_limit MUST use the same window value as the parent constraint, and the delegated value MUST be less than or equal to the parent value; if the windows differ and no such profile applies, the delegated AAE MUST be rejected.¶

• Allowlist constraints (for example, allowed_domains): The delegated value MUST be a subset of the parent value.¶

• Validity: The delegated validity.not_before MUST be greater than or equal to the parent validity.not_before, and the delegated validity.not_after MUST be less than or equal to the parent validity.not_after.¶

• Delegation depth: The delegated delegation.depth MUST equal the parent AAE's effective delegation depth plus 1; the delegated delegation.max_depth MUST be less than or equal to the parent AAE's effective maximum depth; and delegation.depth MUST NOT exceed delegation.max_depth.¶

Every constraint present in the parent AAE that is marked required: true, or for which the required member is absent and is therefore treated as required: true (Section 2.3), MUST also be present in the delegated AAE and MUST either be marked required: true or omit the required member. A delegated AAE MUST NOT omit, downgrade, or change to required: false any parent constraint that is required by this rule. A delegated AAE MAY introduce additional constraints, provided they do not contradict the parent constraints. For currency-valued constraints (for example, max_transaction_value), the delegated constraint MUST use the same currency as the parent constraint, unless the relying party has an explicitly configured and auditable currency-conversion policy; if the currencies differ and no such policy exists, the delegated AAE MUST be rejected.¶

If a relying party cannot determine whether a delegated element is equal to or more restrictive than the corresponding parent element, the delegated AAE MUST be rejected.¶

4. Action Vocabulary Schemas

Interoperability across relying parties requires shared action vocabularies. This document defines a minimal common vocabulary:¶

Vertical-specific vocabularies (travel, finance, healthcare) SHOULD be published as extensions to this base vocabulary, as stable and versioned schemas at publicly accessible URIs. This document does not create an IANA registry for action vocabularies.¶

5. Verification Algorithm

A relying party receiving an agent request with an attached AAE MUST perform the following checks in order:¶

1. Signature verification: Parse the JWS in compact serialization and read the protected header. The signing DID is the DID portion of the kid parameter. Resolve the signing DID, dereference the referenced verification method, and confirm that (a) the verification method is present in that DID document, (b) it is authorized for the assertionMethod proof purpose, (c) it contains or resolves to a JWK with kty: "OKP" and crv: "Ed25519", and (d) the JWS signature validates under that key. Reject the AAE if the signing DID cannot be resolved, the verification method is absent or not authorized for assertionMethod, the key is not Ed25519, the alg is not "EdDSA", or the signature is invalid.¶

   The relying party MUST then verify signing authority. For a non-delegated AAE (no mandate.delegation member), the signing DID MUST be identical to the Verifiable Credential issuer. For a delegated AAE, the signing DID MUST satisfy one of the following: (a) it is identical to mandate.delegation.delegator_did, and the Verifiable Credential issuer is also identical to that DID; or (b) it is explicitly authorized by mandate.delegation.delegator_did to issue delegated AAEs on that delegator's behalf, where the authorization is represented by a verification method or service entry in the delegator's DID document. If signing authority cannot be established under the applicable rule — or, for case (b), the relying party does not understand the authorization mechanism — the AAE MUST be rejected.¶

2. Payload and schema validation: Parse the JWS payload as UTF-8-encoded JSON. The payload MUST be a W3C Verifiable Credential containing id, issuer, credentialSubject.id, and credentialSubject.aae. The aae object MUST contain mandate, constraints, and validity. The protected-header cty parameter MUST equal "aae+json". Reject the AAE if any required member is absent, has the wrong JSON type, or otherwise violates the structural requirements of this document.¶

3. Temporal validity: Confirm current time is within not_before and not_after. Reject if outside bounds.¶

4. Subject binding: Confirm the agent presenting the AAE controls credentialSubject.id. The relying party MUST generate a fresh, unpredictable nonce with at least 128 bits of entropy and send it to the agent together with a relying-party audience identifier. The agent MUST return a JWS in compact serialization whose payload is the UTF-8 encoding of a JSON object with exactly these members:¶

   {
     "nonce":  "<relying-party nonce>",
     "aud":    "<relying-party audience identifier>",
     "iat":    "<RFC 3339 UTC timestamp>",
     "aae_id": "<Verifiable Credential id>"
   }
   

   ¶

   The challenge-response JWS protected header MUST contain "alg": "EdDSA" and a kid DID URL whose DID portion equals credentialSubject.id. The referenced verification method MUST be authorized under the authentication relationship in the resolved DID document. The relying party MUST reject the AAE unless all of the following hold: (a) the challenge-response signature is valid under a key controlled by credentialSubject.id; (b) the verification method is authorized for authentication; (c) the nonce was generated by this relying party and has not been used before; (d) aud identifies this relying party; (e) aae_id equals the Verifiable Credential id; and (f) iat is within the relying party's accepted clock-skew window.¶

5. Single-use check: If validity.single_use is true, the relying party MUST perform an atomic check-and-record operation keyed by the Verifiable Credential id. An id that has already been recorded MUST be rejected. Where the relying party is deployed across multiple nodes, this state MUST be shared across all nodes; concurrent presentations of the same id MUST NOT both succeed.¶

6. Action check: Confirm the requested action is present in mandate.actions. Reject if absent.¶

7. Constraint evaluation: For each constraint in the CONSTRAINTS block, the relying party MUST enforce every constraint it recognizes. If a recognized constraint marked required: true (or with required absent) cannot be evaluated, the relying party MUST reject the AAE. If a recognized constraint marked required: false cannot be evaluated, the relying party MAY ignore that constraint. If a constraint is unrecognized, the relying party MUST reject the AAE unless that constraint is explicitly marked required: false. The relying party MUST reject the AAE if any enforced constraint is violated.¶

8. Revocation check (if applicable): If validity.revocation_check is present, the relying party MUST query the endpoint over HTTPS and evaluate the result as specified for revocation_check in Section 2.4, including the limited fail-open exception defined there.¶

9. Delegation chain (if applicable): If the AAE contains a delegation field, the relying party MUST verify every ancestor AAE in the chain. The signature, payload-and-schema, temporal-validity, and revocation checks above apply to each ancestor AAE. The subject-binding and single-use checks MUST NOT be performed for ancestor AAEs: ancestor agents are not required to be online to answer a challenge, and single-use state applies only to the presented AAE. For each delegation link, the relying party MUST verify that the parent AAE's credentialSubject.id equals the child's delegation.delegator_did; that the signing authority of each AAE in the chain holds as specified in step 1; and that constraint monotonicity and depth limits hold as defined in Section 3. To detect cycles, the relying party MUST maintain the set of AAE id values already visited in the current verification path and MUST reject the chain immediately if any id appears more than once. The relying party MUST enforce an implementation-defined maximum recursion limit no greater than the smallest max_depth value observed in the chain.¶

Steps 1–7 are REQUIRED. Steps 8–9 are conditional on presence of the relevant fields.¶

6. Security Considerations

7. Privacy Considerations

AAEs contain the agent's DID and may contain the principal's DID. Relying parties SHOULD NOT log full AAE payloads unless required for regulatory audit purposes. Where audit logs are required, implementations SHOULD apply data minimization: log the AAE identifier, action taken, timestamp, and outcome — not the full MANDATE or CONSTRAINTS payload.¶

Even when only hashes of AAEs are anchored on a public ledger, timestamps, issuer DIDs, subject DIDs, and repeated hash-publication patterns can leak metadata and enable linkability across an agent's activity. Implementations SHOULD assess linkability risk before anchoring AAEs on a public ledger and SHOULD avoid publishing stable identifiers on-chain unless required.¶

8. IANA Considerations

9. References

Appendix A. Example: Travel Booking Agent

A travel booking agent operating under an 8-hour mandate with a $500 transaction cap. The example shows the JWS protected header and the JWS payload (the unsecured Verifiable Credential); on the wire these are BASE64URL-encoded and concatenated with the signature as a JWS in compact serialization (Section 2.1).¶

JWS protected header:¶

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

JWS payload:¶

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://moltrust.ch/contexts/aae/v1"
  ],
  "type": ["VerifiableCredential", "AgentAuthorizationEnvelope"],
  "id": "urn:uuid:9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
  "issuer": "did:moltrust:registry",
  "validFrom": "2026-05-20T08:00:00Z",
  "credentialSubject": {
    "id": "did:example:travel-agent-001",
    "aae": {
      "mandate": {
        "actions": ["read", "book", "pay"],
        "purpose": "Business travel booking",
        "scope": "travel-vertical",
        "principal_did": "did:example:enterprise-corp"
      },
      "constraints": {
        "max_transaction_value": {
          "value": 500, "currency": "USD", "required": true
        },
        "allowed_domains": {
          "value": ["flights.example.com", "hotels.example.com"],
          "required": true
        }
      },
      "validity": {
        "not_before": "2026-05-20T08:00:00Z",
        "not_after": "2026-05-20T16:00:00Z",
        "single_use": false
      }
    }
  }
}

Appendix B. Relationship to Existing Standards

AAE is designed as a complement to, not a replacement for, existing authorization standards:¶

• OAuth 2.0 / GNAP ([RFC6749], [RFC9635]): Handle human-delegated access tokens. AAE handles machine-to-machine agent authorization with richer semantics.¶

• SPIFFE/SVID ([SPIFFE]): Handles workload identity in service meshes. AAE handles authorization semantics layered above identity.¶

• W3C Verifiable Credentials: AAE is issued as a VC, leveraging the existing VC ecosystem for issuance, verification, and revocation.¶

• W3C DIDs: AAE subjects and issuers are identified by DIDs, enabling decentralized, portable agent identity.¶

Appendix C. Acknowledgements

The AAE specification is derived from the MolTrust production deployment documented in [ARXIV-AAE]. The author thanks Harald Rössler (DSNCON GmbH) for infrastructure and security review.¶

Author's Address