Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents

1.1. Motivation

The absence of an identity standard creates concrete operational problems. Services cannot implement fine-grained agent access control. Humans have no auditable record of what their agents did. Compromised agents cannot be reliably stopped. Agent-to-agent systems have no basis for trust.¶

Existing deployments typically operate in one of two modes: no access, or full access. AIP introduces fine-grained capability declarations. A principal can grant email.read without email.send, or transactions with a max_daily_total constraint.¶

1.2. Design Philosophy

AIP is built on the following design principles and relationships:¶

Neutral and open. This document is submitted under BCP 78, BCP 79, and the IETF Trust Legal Provisions. Code Components extracted from this document are licensed under the Revised BSD License as described in those Legal Provisions. This document defines the did:aip DID method and requests its registration with the W3C DID Method Registry.¶

Build on existing standards. AIP builds on W3C DID, JWT [RFC7519], JWK [RFC7517], DPoP [RFC9449], and CRL patterns from [RFC5280].¶

Human sovereignty. Every agent action must trace to a human or authorised organisational principal.¶

Security proportional to risk. AIP defines three security tiers matching overhead to risk level.¶

Deterministic verification. The Validation Algorithm (Section 9) is fully deterministic: two independent implementations executing the same steps on the same token will reach the same result.¶

Zero Trust Architecture. AIP is designed to support the zero trust principles defined in [SP-800-207] and to provide protocol controls that can be used by deployments seeking alignment with NIST SP 800-63-4 [SP-800-63-4] AAL2 for agent-to-service interactions. This specification does not by itself assert SP 800-63-4 conformance, certification, or audit sufficiency. Any implementation claiming SP 800-63-4 or AAL2 conformance MUST maintain a separate conformance mapping covering its concrete authenticators, identity proofing process, verifier behavior, key management, logging, and operational controls. No agent is implicitly trusted by virtue of its origin, network location, or prior successful interaction. Every interaction MUST execute the validation algorithm in Section 9; Registry-dependent checks are performed according to the token's Tier, revocation-checking mode, and cache rules. Short-lived Credential Tokens bound by a mandatory TTL limit the blast radius of any credential compromise. Revocation is checked in real time for Tier 2 sensitive operations as specified in Section 11.4. DPoP proof-of-possession (Section 21.3) ensures that possession of a valid Credential Token is insufficient for impersonation without the corresponding private key material, supporting the anti-replay objectives of [SP-800-207] Section 3.¶

Least Privilege. Agents are granted only the specific capabilities required for their declared purpose, expressed as signed Capability Manifests (Section 5.3). Capability grants are always additive from principal to agent and never exceed the principal-approved capability set or, for delegated agents, the delegating parent's effective Capability Manifest. A child agent must not be granted capabilities that the delegating parent does not itself hold (Rule D-1, Section 5.10). The max_delegation_depth field (Section 10) bounds the depth of sub-agent hierarchies, limiting transitive capability propagation. Capability constraints allow fine-grained least-privilege expression within each capability category, consistent with [SP-800-207] Section 3 (Tenets 5 and 6).¶

Relationship to SPIFFE/SPIRE. SPIFFE is designed for workload identity within enumerable, infrastructure-managed environments. AIP is designed for autonomous agents that are created dynamically, operate across organisational boundaries, and act on behalf of named human principals whose authority must be cryptographically traceable. An enterprise may deploy SPIFFE for its internal service mesh and AIP for its agent fleet without conflict. The two mechanisms are complementary and operate at distinct layers of the identity stack.¶

Relationship to MCP. The Model Context Protocol [MCP] defines how AI agents discover and invoke tools and data sources. AIP is the agent identity layer that sits beneath MCP's authorisation flow: AIP establishes that an agent is who it claims to be (identification via Credential Token), that it was authorised by a named human principal (delegation chain in the Principal Token), and that it holds specific capabilities (Capability Manifest). AIP does not replace MCP's tool-access OAuth flow - it provides the agent identity that OAuth's "sub" claim cannot supply when the subject is an autonomous agent rather than a human user. An AIP-authenticated agent can obtain scoped access tokens for MCP servers via the token exchange mechanism defined in Section 8.4 and the OAuth 2.1 Authorization Server profile in Section 17.15.¶

Out of scope - Prompt injection prevention. AIP is an identity and authorisation protocol. Whether the content an agent processes contains adversarial instructions is an application-layer and model-layer concern outside this specification's scope. AIP mitigates the persistence window of a successful prompt injection attack: a compromised agent may be revoked via full_revoke (Section 11.1). Tier 2 and Tier 3 revocation checks fail closed against live Registry state; Tier 1 rejection is bounded by the CRL freshness SLA, while child materialisation and replica convergence are bounded by the revocation propagation requirements in Section 11. AIP does not prevent the initial injection - it limits the attacker's persistence.¶

1.3. Architecture Layers

AIP is structured as six ordered layers:¶

 +------------------------------------------------------+
 | Layer 6 - Reputation Trust over time                 |
 +------------------------------------------------------+
 | Layer 5 - Revocation Standard kill switch            |
 +------------------------------------------------------+
 | Layer 4 - Credential Token & Verification            |
 |           Cryptographic proof                        |
 +------------------------------------------------------+
 | Layer 3 - Capabilities What the agent can do         |
 +------------------------------------------------------+
 | Layer 2 - Principal Chain Who authorised it          |
 |           incl. AIP-GRANT and Approval Envelopes     |
 +------------------------------------------------------+
 | Layer 1 - Core Identity Who the agent IS             |
 +------------------------------------------------------+

2.1. Canonical JSON Serialization

Several objects in this specification are signed outside the JWT framework. For those objects, AIP first constructs the object-specific signing input described below, then serializes that signing input with the JSON Canonicalization Scheme (JCS) defined in [RFC8785]. The following procedure MUST be used when computing or verifying signatures, and when computing Action Hashes:¶

1

Represent the object as a JSON value per [RFC8259].¶

2

Before computing any signature, set the object's "signature" field to the empty string "". The "signature" field MUST be included in the serialisation at its lexicographically correct position with value "".¶

3

Serialize the resulting signing-input JSON value using JCS [RFC8785]. Array element order MUST be preserved; arrays MUST NOT be sorted.¶

4

Encode the JCS result as a UTF-8 byte sequence with no BOM.¶

Every object type signed with this procedure MUST define a top-level signature member in its schema or in the object-specific signing profile. If an unsigned object instance is being prepared for signing and the top-level signature member is absent, the signer MUST inject that member with value "" before canonicalization. Verifiers MUST reconstruct the same signing input by replacing the received signature value with "". Object types that do not define a signature member MUST NOT be signed with this procedure unless a later profile explicitly defines the signature member name and signing input.¶

The serialization step is JCS. The preceding signature-field replacement or injection is AIP-specific signing-input normalization and is not part of RFC 8785 itself. Implementations SHOULD use an RFC8785-conformant library to ensure serialization correctness. When this procedure is used to compute Action Hashes, implementations MUST use an RFC8785-conformant library; custom serializer implementations MUST NOT be used for that purpose.¶

EXAMPLE (informative):¶

 {"z": 1, "a": 2, "m": [3,1,2]}  →  {"a":2,"m":[3,1,2],"z":1}

This canonical serialization procedure applies to Capability Manifests, Agent Identity Objects, Revocation Objects, Endorsement Objects, GrantRequest Objects when signed, and Approval Envelopes. It MUST NOT be used for JWT-format objects, including Credential Tokens, Principal Tokens, Step Execution Tokens, and RPNP push notifications. JWT-format objects MUST use standard JWS compact serialization per [RFC7515].¶

3.1. Abbreviations

The following common abbreviations are used with their ordinary industry meanings or with the referenced external specifications:¶

ABAC

Attribute-Based Access Control.¶

BOM

Byte Order Mark. AIP canonical JSON signing input uses UTF-8 without a leading BOM.¶

CDN

Content Delivery Network.¶

DAG

Directed Acyclic Graph.¶

FIDO2/WebAuthn

FIDO2 and Web Authentication.¶

HSM

Hardware Security Module.¶

HMAC

Hash-based Message Authentication Code.¶

JCS

JSON Canonicalization Scheme, defined by [RFC8785].¶

JWKS

JSON Web Key Set, the JWK container format used by OAuth and OIDC providers to publish signing keys.¶

MITM

Man-in-the-Middle.¶

mTLS

Mutual TLS.¶

OCSP

Online Certificate Status Protocol, defined by [RFC6960].¶

PII

Personally Identifiable Information.¶

PKCE

Proof Key for Code Exchange, defined by [RFC7636].¶

SAGA

Distributed-workflow compensation pattern.¶

SLA

Service-Level Agreement.¶

TTL

Time To Live.¶

3.2. Architecture Tiers

AIP defines three security Tiers that map synced AIP Scope Catalog metadata to mandatory protocol behaviors. Tiers are NOT performance classes and are not locally chosen labels; they are derived from the highest-risk requested scope.¶

• Tier 1 (Bounded-staleness): Optimized for high availability and low latency. Revocation is checked against a Registry-published CRL with a mandatory 15-minute update SLA. Principals MAY use did:key for Tier 1 operations.¶
• Tier 2 (Real-time): The default Tier for sensitive operations. Revocation status MUST be checked in real-time against the Registry on every interaction. DPoP proof-of-possession (RFC 9449) is REQUIRED. Principals MUST use did:web to enable Registry trust anchoring.¶
• Tier 3 (Regulated/Enterprise): The highest security level for regulated or high-value environments. Tier 3 supplements Tier 2 with mandatory mutual TLS (mTLS) and certificate revocation checking using OCSP or an equivalent deployment-profile mechanism defined in Section 21.6.¶

The complete mapping of Tiers to normative protocol requirements is defined in the Tier Conformance Table in Section 20.1.¶

4.1. AID Syntax

An Agent Identity Descriptor (AID) conforms to the following ABNF:¶

        AID        = "did:aip:" namespace ":" agent-id
        namespace  = LOALPHA *( LOALPHA / DIGIT )
                     *( "-" 1*( LOALPHA / DIGIT ) )
        agent-id   = 32LOHEXDIG
        LOALPHA    = %x61-7A        ; a-z only, lowercase
        DIGIT      = %x30-39
        LOHEXDIG   = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
                                    ; lowercase hex digit only

Example: did:aip:personal:9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3¶

The namespace MUST begin with a lowercase alpha character, MUST NOT end with a hyphen, and MUST NOT contain consecutive hyphens. Implementations MUST reject AIDs containing uppercase hex digits or uppercase namespace characters.¶

• namespace: A lowercase alphanumeric string with optional single-hyphen-separated segments identifying the agent type. Each hyphen MUST be followed by one or more lowercase alphanumeric characters. Concrete namespace registrations are maintained in the AIP Namespace Catalog (Section 17.16).¶
• agent-id: A 32-character hexadecimal string (lowercase) computed as the leftmost 128 bits (first 16 octets) of the SHA-256 hash of the agent's public Ed25519 key material (the JWK x value base64url-decoded).¶

4.2. AID Derivation

An AID is derived deterministically from the agent's Ed25519 public key:¶

1. Generate an Ed25519 keypair per [RFC8032].¶
2. Encode the public key as a JWK with kty="OKP", crv="Ed25519", and the public key value in the x field (base64url-encoded).¶
3. Compute SHA-256(base64url_decode(x)) to obtain a 32-byte digest.¶
4. Take the leftmost 16 octets of that digest and hex-encode them (lowercase) to form the 32-character agent-id.¶
5. Combine with the chosen namespace to form the complete AID: did:aip:<namespace>:<agent-id>.¶

This derivation is deterministic and cryptographically self-verifying: possession of the private key corresponding to the registered public key is both necessary and sufficient to prove control of the AID.¶

4.3. AIP Namespace Catalog

Standard and community AID namespace registrations are defined by the immutable AIP Catalog Snapshot identified in Section 17.16 and exposed by conformant Registries through the Namespace Catalog endpoint defined there. The Draft-02 Catalog Snapshot contains the standard namespace entries for personal, enterprise, service, orchestrator, ephemeral, and registry agents.¶

Namespace registration metadata is normative for namespace-level lifecycle rules. If a namespace entry sets requires_task_id: true, Principal Tokens for agents in that namespace MUST contain a non-empty task_id. If a namespace entry sets reserved: true, the namespace MUST NOT be registered through the normal POST /v1/agents flow.¶

Namespaces are immutable once registered. Custom or community namespaces MUST be registered in the AIP Namespace Catalog before they are treated as interoperable AIP namespaces.¶

4.4. Agent Identity Object Schema

The Agent Identity Object is the base document for an agent. It includes the AID, public key material, and metadata. The schema is defined in Section 5.2 (see also agent-identity.schema.json in the schemas directory).¶

Key fields:¶

• aid: The agent's AID (REQUIRED)¶
• name: Human-readable agent name (REQUIRED)¶
• type: The namespace component of the AID (REQUIRED, MUST match)¶
• model: AI model information including provider and model_id (REQUIRED)¶
• public_key: JWK format Ed25519 public key (REQUIRED)¶
• created_at: ISO 8601 timestamp (REQUIRED)¶
• version: Identity version number for key rotation (REQUIRED, minimum 1)¶
• previous_key_signature: EdDSA signature by previous key when rotating (REQUIRED if version > 1)¶

4.5. Uniqueness and Immutability

An AID MUST be unique within the authoritative Registry namespace and is cryptographically derived from the agent public key. Once an agent is registered in a Registry, its AID is immutable. An AID cannot be reused or transferred within that Registry. Two agents with identical public keys will derive identical AIDs, so the cryptographic relationship is deterministic. If two different public keys derive the same AID, the Registry MUST treat the later registration as an AID collision and reject it as a duplicate AID. If a registration attempt presents a public key that is already associated with a registered, non-revoked AID in that Registry, the Registry MUST reject the attempt with aid_already_registered.¶

5.1. Resource Naming

Agent Identities (AIDs) are W3C Decentralized Identifiers [W3C-DID] using the did:aip method. AID syntax is normatively defined by the AID, namespace, and agent-id ABNF productions in Section 4.1. This section does not define a second AID grammar. JSON Schemas and implementations MUST use grammar equivalent to Section 4.1.¶

The namespace MUST begin with a lowercase alpha character, MUST NOT end with a hyphen, and MUST NOT contain consecutive hyphens. Implementations MUST reject AIDs containing uppercase hex digits or uppercase namespace characters.¶

Concrete namespace values are maintained in the AIP Namespace Catalog (Section 17.16), not in this prose table. The namespace grammar from Section 4.1 remains the wire-format constraint; catalog membership supplies the interoperability and lifecycle metadata for each namespace.¶

Any namespace marked reserved: true in the AIP Namespace Catalog MUST NOT be registered via the standard POST /v1/agents endpoint. The standard registry namespace is reserved and MUST be created exclusively via the Registry Genesis procedure.¶

Compound typed identifiers use prefixed UUID v4 values:¶

5.2. Agent Identity Object

The Agent Identity Object is the canonical signed JSON document that establishes an agent's identity. The key-continuity signing target for key rotation is defined by the previous_key_signature requirements below.¶

aid

Type: string. Required: REQUIRED. Constraints: MUST match did:aip ABNF; pattern is lowercase namespace plus a 32-character lowercase hexadecimal agent-id derived from the leftmost 128 bits of the SHA-256 digest of the agent public key.¶

name

Type: string. Required: REQUIRED. Constraints: minLength: 1, maxLength: 64.¶

type

Type: string. Required: REQUIRED. Constraints: MUST exactly match namespace component of aid; pattern is lowercase alphanumeric with optional hyphen-separated segments.¶

model

Type: object. Required: REQUIRED. Constraints: See sub-fields below.¶

model.provider

Type: string. Required: REQUIRED. Constraints: minLength: 1, maxLength: 64.¶

model.model_id

Type: string. Required: REQUIRED. Constraints: minLength: 1, maxLength: 128.¶

model.attestation_hash

Type: string. Required: OPTIONAL for Tier 1, SHOULD be present for Tier 2, REQUIRED for Tier 3. Constraints: pattern sha256:<64 lowercase hex characters>.¶

created_at

Type: string. Required: REQUIRED. Constraints: ISO 8601 UTC; format: date-time; immutable after registration.¶

version

Type: integer. Required: REQUIRED. Constraints: minimum: 1; MUST increment by exactly 1 on key rotation.¶

public_key

Type: object. Required: REQUIRED. Constraints: JWK per [RFC7517]; Ed25519 (kty=OKP, crv=Ed25519) per [RFC8037].¶

public_key.kty

Type: string. Required: REQUIRED. Constraints: const: "OKP".¶

public_key.crv

Type: string. Required: REQUIRED. Constraints: const: "Ed25519".¶

public_key.x

Type: string. Required: REQUIRED. Constraints: pattern ^[A-Za-z0-9_-]{43}$ (32 bytes base64url, no padding).¶

public_key.kid

Type: string. Required: REQUIRED. Constraints: DID URL using the agent AID followed by #key-N where N is a positive integer.¶

fallback_public_key_x

Type: string. Required: OPTIONAL. Constraints: pattern ^[A-Za-z0-9_-]{43}$ (32 bytes base64url, no padding, same encoding as public_key.x). The x value of an Ed25519 fallback public key recorded for disaster recovery. When present, the Registry persists it and uses it to authenticate Emergency Key Rotation (Section 17.6) if the active private key is lost. MUST NOT equal public_key.x. MUST be accompanied by fallback_key_proof. Set at initial registration (version=1); immutable during ordinary key rotation; MAY be replaced or removed only as part of Emergency Key Rotation.¶

fallback_key_proof

Type: string. Required: REQUIRED when fallback_public_key_x is present; MUST be absent otherwise. Constraints: pattern ^[A-Za-z0-9_-]+$. A base64url-encoded EdDSA signature proving possession of the fallback private key. The signing input is the UTF-8 byte sequence of the string "aip:fallback-key-proof:v1:" + aid + ":" + fallback_public_key_x (literal colon separators, no whitespace, no trailing newline), signed with the fallback private key. Because the signing input binds only the immutable aid and the fallback key value itself, the proof remains valid across ordinary key rotations and the fallback private key never needs to leave cold storage except during Emergency Key Rotation. The Registry verifies this proof whenever the fallback key is introduced or replaced; Relying Parties MUST NOT evaluate this field.¶

previous_key_signature

Type: string. Required: OPTIONAL (version=1); REQUIRED (version>=2). Constraints: base64url EdDSA signature computed by the retiring previous private key over the new full Agent Identity Object, serialized using the Section 2.1 canonical JSON procedure with previous_key_signature set to ""; pattern ^[A-Za-z0-9_-]+$.¶

Normative requirements:¶

• The aid, type, and created_at fields MUST NOT change after initial registration.¶
• The type field MUST exactly match the namespace component of the aid field.¶
• The version field MUST start at 1 and MUST increment by exactly 1 on each key rotation.¶
• The public_key.kid MUST use format <aid>#key-<n> where <n> starts at 1.¶
• When fallback_public_key_x is present, it MUST differ from public_key.x and MUST be accompanied by a valid fallback_key_proof. It MUST NOT already be associated with any other registered AID (including as a primary or fallback key).¶
• The fallback_public_key_x and fallback_key_proof fields are recorded at initial registration and MUST NOT change during ordinary key rotation. They MAY be replaced (with a fresh proof for the new fallback key) or removed only as part of Emergency Key Rotation (Section 17.6). A fallback key is single-use: once it has authenticated an Emergency Key Rotation, the Registry MUST NOT accept it again for any AID.¶
• The model.attestation_hash field is the protocol binding between the registered agent identity and a model binary or version manifest. It SHOULD be present for Tier 2 deployments and MUST be present for Tier 3 deployments. A missing hash means the AID is not cryptographically pinned to a specific model artifact.¶
• When version is 2 or greater, previous_key_signature MUST be present and MUST be a non-empty base64url string.¶
• For key rotation, the previous_key_signature value MUST be generated with the retiring previous private key, not the new private key. The signing target is the complete new Agent Identity Object after applying the new version and public_key, serialized per Section 2.1 with previous_key_signature temporarily set to "". The computed signature then replaces that empty string in the stored Agent Identity Object. A Registry MUST verify this signature with the public key from the immediately previous Agent Identity Object version before accepting the rotation.¶

5.3. Capability Manifest

The Capability Manifest is a versioned, signed JSON document that declares the specific permissions granted to an agent. The signature field is computed using the Section 2.1 canonical JSON procedure with signature set to "". The signature_kid field identifies the Ed25519 verification method used for the signature.¶

A new manifest_id MUST be generated on every update, including scope_revoke operations. Relying Parties MUST verify the manifest signature field using the public key identified by signature_kid before trusting any capability declared within it. The DID portion of signature_kid MUST be byte-for-byte equal to granted_by.¶

5.4. Credential Token

An AIP Credential Token is a compact JWT with the following format:¶

  aip-token = JWT-header "." JWT-payload "." JWT-signature

The token MUST be a valid JWT as defined by [RFC7519]. Credential Tokens conforming to this specification MUST be signed with EdDSA using the registered Ed25519 key identified by the JOSE kid. Credential Tokens signed with ES256, RS256, symmetric algorithms, none, or non-Ed25519 key material MUST be rejected.¶

JWT Header fields:¶

Credential Token Payload fields:¶

aip_version

string, REQUIRED. AIP protocol compatibility version. MUST be "0.3" for tokens conforming to this specification. See Section 20 for version semantics and Section 9.6.6 for validation.¶

iss

string, REQUIRED. MUST match the did:aip ABNF; MUST equal the AID identified by the JWT header kid; MUST equal sub; MUST equal sub of the last aip_chain element.¶

sub

string, REQUIRED. MUST match the did:aip ABNF; MUST equal iss. For an agent-issued Credential Token, this is the acting leaf agent's AID. This specification does not define an on-behalf-of subject distinct from the signing agent.¶

aud

string or array, REQUIRED. Single string or array; MUST include the Relying Party's identifier.¶

iat

integer, REQUIRED. Unix timestamp; MUST NOT be in the future, with a 30-second clock skew tolerance.¶

exp

integer, REQUIRED. Unix timestamp; MUST be strictly greater than iat; TTL limits per Section 8.2.¶

jti

string, REQUIRED. UUID v4 canonical lowercase; unique per issuer AID across all delegation chains.¶

aip_scope

array, REQUIRED. minItems: 1; uniqueItems: true; each item matches <dot-separated-scope-name>.¶

aip_chain

array, REQUIRED. minItems: 1; maxItems: 11; each element is a compact-serialised signed Principal Token JWT. Elements are ordered root-to-leaf, and the last element's sub is the acting agent AID. The maximum length corresponds to delegation depths 0 through 10.¶

aip_principal_assertion

string, OPTIONAL for Tier 1 and Tier 2; REQUIRED for Tier 3. A compact-serialised signed JWT issued by an enterprise Identity Provider, such as an OIDC ID Token or equivalent JWT-formatted assertion. The assertion MUST contain a sub claim identifying the human principal. When present, the Relying Party MUST verify the assertion's signature against the IdP's JWKS endpoint before treating the human identity context as valid. The sub claim in aip_principal_assertion MUST match the root Principal Token's principal.id value in aip_chain[0]. The issuer (iss) of this JWT MUST NOT be the AIP Registry. See Section 9.19 Steps 11a, 11b, and 11c for normative validation.¶

aip_originator_aid

string, OPTIONAL; MUST be present when the agent is acting in a delegated agent-to-agent (A2A) workflow as specified in Section 10.4. The value is the AID of the originating agent that initiated the A2A workflow. When present, it MUST be a valid did:aip AID conforming to the ABNF in Section 4.1 and MUST NOT equal the sub claim of this Credential Token.¶

aip_registry

string, OPTIONAL. Advisory URI of the AIP Registry; if present, Step 6a trust anchoring is REQUIRED.¶

aip_engagement_id

string, OPTIONAL. Pattern: eng:<UUIDv4-lowerhex>; present when the token is scoped to an Engagement Object.¶

5.5. Principal Token

A Principal Token is a JWT payload encoding one delegation link in the AIP principal chain. Principal Tokens are embedded as compact- serialised JWTs in the aip_chain array of a Credential Token or Step Execution Token.¶

A Principal Token MUST be a compact-serialised JWT signed using EdDSA. Its JOSE header is outside the payload schema but is normative: typ MUST be "JWT", alg MUST be "EdDSA", and kid MUST be a DID URL identifying an Ed25519 verification method controlled by the token issuer identified by iss. For the root Principal Token (delegation_depth 0), the issuer is the root principal.id. For delegated Principal Tokens, the issuer is the parent agent AID in delegated_by, and that parent AID MUST be registered in the authoritative AIP Registry. Relying Parties resolve delegated Principal Token signing keys through the Registry historical public-key endpoint and verify that the returned key was valid at the Principal Token's issued_at instant. Principal Tokens signed with ES256, RS256, symmetric algorithms, none, or non-Ed25519 key material MUST be rejected. X25519 verification methods MUST NOT be used for Principal Token signing.¶

The principal.id field MUST be byte-for-byte identical across every Principal Token in the same aip_chain array. The principal.id MUST NOT begin with did:aip:.¶

For a root Principal Token produced by AIP-GRANT, issued_at is the issuer's current UTC signing time and expires_at equals issued_at plus the GrantResponse approved_delegation_valid_for_seconds value. The detailed derivation rule is defined in Section 12.3.¶

The purpose field, when present, is a signed human-readable consent and audit claim. It is not a machine-enforced authorization constraint. Relying Parties MAY display or log purpose for operator context, but MUST NOT use it to grant capabilities, satisfy scope checks, or override Capability Manifest, Capability Overlay, Approval Envelope, or policy evaluation.¶

5.6. Registration Envelope

The Registration Envelope is the request body submitted to POST /v1/agents to register a new AIP agent.¶

A Registration Envelope registers exactly one agent: the AID in identity.aid. The submitted principal_token payload sub MUST equal that AID. Direct principal-to-agent registrations use a root Principal Token with delegation_depth: 0 and delegated_by: null. Sub-agent registrations use a delegated Principal Token signed by the registered parent agent identified in delegated_by; the Registry reconstructs the complete principal chain from the parent's stored registration chain and the submitted token during Registration Check 9.¶

5.7. Revocation Object

Revocation is performed by submitting a signed Revocation Object to POST /v1/revocations. The signature field is computed using the Section 2.1 canonical JSON procedure with signature set to "". The signing input order is revocation_id, target_id, type, issued_by, kid, reason, timestamp, propagate_to_children, scopes_revoked, and signature.¶

Revocation Types:¶

• full_revoke - Permanently revokes the AID.¶
• scope_revoke - Invalidates specific scopes for the agent. For Tier 1 and 2, this MUST cause Relying Parties to reject Credential Tokens containing the revoked scopes (Step 7, Section 9).¶
• delegation_revoke - Invalidates delegation chains rooted at the target. Child agents lose authority; the target AID remains valid for direct principal interactions.¶
• principal_revoke - Issued by the root principal to revoke their authorisation of a target agent (via AID) or all agents under their authority (via Principal DID). Existing Credential Tokens and Step Execution Tokens depending on that authorisation become invalid immediately. This validity effect is independent of propagate_to_children; that flag controls only whether descendant Revocation Objects are materialised.¶

Revocation Reason Codes: The reason field MUST be one of the following values:¶

Externally submitted Revocation Objects MUST NOT use parent_revoked, heartbeat_timeout, or lifecycle_expired; those values are reserved for Registry-generated Revocation Objects.¶

5.8. Endorsement Object

Any Relying Party or agent MAY submit a signed Endorsement Object to the Registry after a completed interaction. The signature field is computed using the Section 2.1 canonical JSON procedure with signature set to "".¶

endorsement_id

string, REQUIRED. Pattern: end:<UUIDv4-lowerhex>.¶

from_aid

string, REQUIRED. MUST NOT equal to_aid.¶

to_aid

string, REQUIRED. MUST NOT equal from_aid.¶

task_id

string, REQUIRED. minLength: 1; maxLength: 256.¶

outcome

string, REQUIRED. One of success, partial, or failure.¶

score

number, REQUIRED. Endorsement score in the range 1 through 5 inclusive. Values outside this range MUST be rejected with endorsement_invalid.¶

notes

string or null, OPTIONAL. Maximum length 512. Signed audit context only; MUST NOT affect reputation scoring or validation.¶

timestamp

string, REQUIRED. ISO 8601 UTC timestamp.¶

signature_kid

string, REQUIRED. DID URL identifying an Ed25519 verification method controlled by from_aid.¶

signature

string, REQUIRED. Base64url EdDSA signature by from_aid.¶

The Registry MUST verify every submitted Endorsement Object signature. The DID portion of signature_kid MUST equal from_aid. Only success and partial outcomes increment endorsement_count. failure increments incident_count.¶

The notes field, when present, is signed human-readable audit context about the observed task outcome. The Registry MUST preserve it as part of the Endorsement Object, but MUST NOT parse, classify, or use notes to compute reputation scores, increment counters, validate capability authorization, or alter endorsement acceptance. Reputation effects are determined by the structured fields defined in this section and Section 14.¶

5.9. Field Constraints and Catalog-Bound Scope Identifiers

The Capability Manifest capabilities object is a closed object: top-level capability families not listed below MUST NOT appear unless a Registry accepts them through an explicit private extension policy. The immutable machine-readable schema for this draft is https://provai.dev/schemas/aip/capability-manifest/draft-02, also listed as capability-manifest.schema.json in the JSON Schema Index.¶

email

Permitted sub-fields are boolean read, write, send, and delete, plus optional integer max_recipients_per_send in the range 1-100. Boolean fields default to false when absent. The recipient cap applies only when send is true.¶

calendar

Permitted sub-fields are boolean read, write, and delete. Boolean fields default to false when absent.¶

filesystem

Permitted sub-fields are read and write arrays of absolute path strings, plus boolean execute and delete. Each path string MUST be non-empty and no longer than 512 characters. Empty or absent path arrays mean deny-all for that operation. File deletion is permitted only for paths also permitted by write.¶

web

Permitted sub-fields are boolean browse, forms_submit, and download, plus optional integer max_requests_per_hour in the range 1-10000. Boolean fields default to false when absent.¶

transactions

The enabled boolean is REQUIRED when the transactions object is present. When enabled is true, max_single_transaction, max_daily_total, and currency are REQUIRED; transaction limits MUST be greater than zero; currency MUST be an ISO 4217 three-letter uppercase currency code. Optional require_confirmation_above MUST be less than or equal to max_single_transaction when both are present.¶

communicate

The enabled boolean is REQUIRED when the communicate object is present. Permitted channel fields are boolean whatsapp, telegram, sms, and voice. When enabled is true, at least one channel field MUST be explicitly set to true; when enabled is false, channel fields have no granting effect.¶

spawn_agents

The enabled boolean is REQUIRED when the spawn_agents object is present. When enabled is true, integer max_concurrent in the range 1-100 is REQUIRED. Optional types_allowed lists namespace labels the agent may spawn; each value MUST be an active, spawnable entry in the synced AIP Namespace Catalog unless a private namespace policy explicitly permits it.¶

registry

Permitted sub-fields are Registry control-plane grants. Draft-02 defines boolean heartbeat, which grants the registry.heartbeat scope for authenticated liveness submissions.¶

approvals

Permitted sub-fields are Approval Envelope control-plane grants. Draft-02 defines boolean create, which grants the approvals.create scope for submitting Approval Envelopes to POST /v1/approvals.¶

An absent top-level capability family grants no capability in that family. An empty capabilities object grants no capabilities. Implementations MUST NOT treat absent fields as allow-all.¶

Scope Identifier Grammar and Catalog Binding:¶

Scope identifiers are dot-separated lowercase ASCII strings. Each segment MUST begin with a-z or _, and subsequent characters in the same segment MAY be a-z, 0-9, or _. The normative pattern is <dot-separated-scope-name>. This permits versioned or tiered scope names such as transactions.v2 or filesystem.read.tier1 while preserving a non-numeric first character in every segment.¶

Concrete scope identifiers and their security metadata are defined by the immutable AIP Catalog Snapshot identified in Section 17.16 and exposed by conformant Registries through the Scope Map endpoint defined in Section 17.16. A scope is interoperable only when it is present with status: "active" or status: "experimental" in the synced AIP Scope Catalog, or when a Registry explicitly documents a private local extension policy.¶

Tokens containing a scope that is absent from the synced AIP Scope Catalog, marked reserved, marked removed, or outside an explicitly documented local extension policy MUST be rejected with invalid_scope.¶

Where this document references transactions.* or communicate.*, the wildcard is category notation rather than a literal scope string. The matching semantics for scope-family entries are defined by the AIP Scope Catalog. In the Draft-02 catalog, transactions.* includes the bare transactions scope, any active scope beginning with transactions., and capabilities.transactions.enabled: true in the Capability Manifest; communicate.* includes active scopes beginning with communicate. and capabilities.communicate.enabled: true in the Capability Manifest.¶

Empty arrays [] for filesystem.read or filesystem.write MUST be interpreted as deny-all. A require_confirmation_above value above max_single_transaction is vacuous and MUST be rejected. When communicate.enabled is true, at least one channel MUST be explicitly set to true.¶

5.10. Delegation Rules

Rule D-1. A delegated agent MUST NOT grant scopes or looser constraint values than its own Capability Manifest contains.¶

Rule D-2. A delegated agent MUST NOT issue a Principal Token with max_delegation_depth greater than its remaining depth (max_delegation_depth - delegation_depth).¶

Rule D-3. Implementations MUST reject any Credential Token where the delegation_depth of any chain token exceeds the root token's max_delegation_depth. The hard protocol maximum for max_delegation_depth is 10.¶

Rule D-4. The root Principal Token (index 0) MUST have delegation_depth = 0. Each subsequent token at index i MUST have delegation_depth = i. No gaps, skips, or repeated values are permitted. Because depths 0 through 10 are the complete allowed range, a valid aip_chain contains at most 11 elements.¶

Rule D-5. Each delegation chain token MUST be signed by the private key of the delegated_by AID (or root principal for depth 0). For non-root delegation tokens, the signing AID MUST be a registered AIP agent whose public key can be resolved from the Registry as specified by Credential Token validation Step 8d-2.¶

5.11. Capability Overlays

A Capability Overlay is a signed restriction document stored in the Registry. It narrows an agent's effective capability set for operations within a specific engagement or issuer context.¶

Rule CO-1 (Attenuation Only): An overlay MUST NOT expand any constraint value beyond what the base Capability Manifest permits. The effective capability set is always the intersection of the base manifest and all active overlays scoped to the engagement or issuer.¶

Overlay Rules:¶

1. CO-1 (Attenuation Only): For every field in constraints, the value MUST be equal to or more restrictive than the corresponding value in the base Capability Manifest. Constraint comparison is recursive for nested objects. An omitted overlay field inherits the effective base value and MUST NOT be interpreted as removing or relaxing the base constraint.¶
2. CO-2 (Issuer DID Method): The issued_by DID MUST use did:web or did:aip. Overlays signed by did:key MUST be rejected with overlay_issuer_invalid. The DID portion of signature_kid MUST be byte-for-byte equal to issued_by.¶
3. CO-3 (Version Monotonicity): A new overlay for the same (aid, engagement_id, issued_by) tuple MUST have a strictly higher version than the current active overlay. A submission whose version is less than or equal to the current active overlay version MUST be rejected with overlay_version_conflict.¶
4. CO-4 (Expiry Handling): Expired overlays MUST be treated as absent.¶
5. CO-5 (Engagement Termination): If an Engagement Object associated with an overlay's engagement_id is terminated, all overlays for that engagement MUST be invalidated atomically by the Registry.¶
6. CO-6 (Multiple Overlays): When multiple overlays apply to the same agent, the effective capability set is the intersection of ALL applicable overlays with the base manifest.¶

Effective Capability Computation:¶

  effective = base_manifest.capabilities
  for each active_overlay in applicable_overlays:
      effective = intersect(effective, active_overlay.constraints)

Where intersect applies per-field, the following type-specific rules are normative. Scope set to false removes that scope through the boolean rule below.¶

The intersect operation is defined recursively over JSON values:¶

Objects

For each object member present in the base value, if the overlay omits that member, the effective value is the base member unchanged. If the overlay supplies that member, apply intersect recursively. If the overlay supplies a member that is absent from the base value, the overlay is valid only when this specification or the synced AIP Scope Catalog defines absence of that member as an unrestricted allowance or default value that the overlay narrows. Otherwise, the overlay expands the manifest and MUST be rejected with overlay_exceeds_manifest.¶

Booleans

Boolean fields use logical AND. false is more restrictive than true.¶

Numbers

Numeric fields that represent maximum allowances, rate limits, budget caps, concurrency caps, or confirmation thresholds use min(base, overlay). In the Draft-02 standard Capability Manifest schema, this rule applies to email.max_recipients_per_send, web.max_requests_per_hour, transactions.max_single_transaction, transactions.max_daily_total, transactions.require_confirmation_above, and spawn_agents.max_concurrent. A lower require_confirmation_above value is more restrictive because it requires explicit confirmation for a larger set of transactions. If the base manifest omits an optional numeric cap whose absence is defined as "no cap" or "no confirmation threshold", an overlay MAY add that cap and the effective value is the overlay value. Numeric fields whose ordering semantics are not defined by the synced AIP Scope Catalog or this specification MUST NOT be narrowed by ordering; the overlay value MUST equal the base value or be rejected with overlay_exceeds_manifest.¶

Arrays

Arrays of allowed values, including filesystem path arrays and spawn_agents.types_allowed, use set intersection. The result MAY be an empty array, which means deny-all for that allowed-value list. If the base manifest omits an optional allowed-value array whose absence is defined as all catalog-valid values being allowed, an overlay MAY add the array and the effective value is the overlay array.¶

Strings and enums

String and enum fields are not ordered. If an overlay supplies a string or enum value, it MUST be byte-for-byte equal to the base value unless the synced AIP Scope Catalog defines explicit subset semantics for that field. Otherwise the overlay MUST be rejected with overlay_exceeds_manifest. For example, transactions.currency set to "GBP" cannot attenuate a base transactions.currency value of "USD". If the overlay omits transactions.currency, the base currency is inherited unchanged.¶

Null and unknown types

null and any value type not covered above MUST NOT be used to relax or erase a base constraint. A non-equal overlay value of an unknown type MUST be rejected with overlay_exceeds_manifest.¶

5.12. Engagement Objects

An Engagement Object is a mutable Registry resource that models a multi-party engagement. It is the parent container for Capability Overlays scoped via engagement_id, Approval Envelopes scoped via engagement_id, and participant roster and approval gate state.¶

Engagement Object Fields:¶

engagement_id (string; REQUIRED)

Pattern: eng:<UUIDv4-lowerhex>¶

title (string; REQUIRED)

maxLength: 256¶

hiring_operator (string; REQUIRED)

DID; MUST be did:web or did:aip¶

deploying_principal (string; REQUIRED)

DID of the deploying principal¶

created_at (string; REQUIRED)

ISO 8601 UTC¶

expires_at (string; REQUIRED)

ISO 8601 UTC; MUST be after created_at¶

status (string; REQUIRED)

One of: "proposed", "active", "suspended", "completed", "terminated"¶

participants (array; REQUIRED)

Array of Participant objects¶

approval_gates (array; OPTIONAL)

Array of Approval Gate objects¶

change_log (array; REQUIRED)

Append-only array of Change Log Entry objects¶

hiring_operator_signature (string; REQUIRED)

Base64url EdDSA signature by hiring_operator over the top-level engagement signing input defined below¶

hiring_operator_kid (string; REQUIRED)

DID URL identifying the Ed25519 verification method for hiring_operator_signature¶

deploying_principal_signature (string; COND.)

Base64url EdDSA countersignature by deploying_principal over the same top-level engagement signing input defined below; REQUIRED for active, suspended, completed, and terminated Engagement Objects¶

deploying_principal_kid (string; COND.)

DID URL identifying the Ed25519 verification method for deploying_principal_signature; REQUIRED whenever deploying_principal_signature is present¶

version (integer; REQUIRED)

Positive integer; MUST equal max(change_log.seq)¶

Participant object fields: aid (REQUIRED), role (REQUIRED, maxLength: 64), capability_overlay_id (OPTIONAL), added_at (REQUIRED, ISO 8601), added_by (REQUIRED, DID), removed_at (OPTIONAL, ISO 8601).¶

Approval Gate object fields: gate_id (REQUIRED, pattern: gate:<lowercase-token>), name (REQUIRED, maxLength: 128), required_approver (REQUIRED, DID), trigger (REQUIRED, scope:<scope-string> or action_type:<action-type>), status (REQUIRED, one of: "pending", "approved", "rejected"), approved_at (OPTIONAL, ISO 8601).¶

Top-level engagement signature input: Both hiring_operator_signature and, when present, deploying_principal_signature MUST be computed over the same JCS-canonical JSON serialization of the immutable engagement agreement object containing only engagement_id, title, hiring_operator, deploying_principal, created_at, and expires_at. The top-level signing input MUST NOT include mutable lifecycle or roster state (status, participants, approval_gates, change_log, or version) and MUST NOT include top-level signature or *_kid fields. Mutable state is authenticated by the signed append-only change_log entries. The countersignature does not sign the other party's signature value.¶

Change Log Entry fields: seq (REQUIRED, monotonically increasing from 1), timestamp (REQUIRED, ISO 8601), action (REQUIRED), actor (REQUIRED, DID), actor_kid (REQUIRED DID URL), payload (OPTIONAL, object), signature (REQUIRED, Base64url EdDSA by actor over the Section 2.1 signing input with the entry signature excluded).¶

Engagement signature verification profile: Each top-level signature and each change-log entry signature MUST identify its verification key with the corresponding *_kid field. The kid value MUST be a DID URL whose DID portion is byte-for-byte equal to the signer DID: hiring_operator for hiring_operator_signature, deploying_principal for deploying_principal_signature, and the change-log entry actor for an entry signature. For did:aip signer DIDs, the Registry MUST resolve the verification method through its registered public-key endpoint for that AID. For other DID methods, the Registry MUST use the signer's DID method resolution rules. The resolved verification method MUST be Ed25519 verification material controlled by the signer DID. Missing kid fields, malformed DID URLs, signer/key DID mismatches, unsupported key types, failed DID resolution, or failed EdDSA signature verification MUST cause rejection with engagement_signature_invalid.¶

Defined change log actions: engagement_created, engagement_countersigned, participant_added, participant_removed, participant_role_changed, gate_added, gate_approved, gate_rejected, engagement_suspended, engagement_resumed, engagement_completed, engagement_terminated.¶

The Registry MUST reject any request that modifies or deletes an existing change log entry. Only appends are permitted.¶

Engagement version semantics: The version field is the current change-log sequence number, not an independent counter. On creation, the Registry MUST create exactly one engagement_created entry with seq: 1 and set version: 1. Each accepted mutation after creation MUST append exactly one new change-log entry whose seq is previous version + 1, and the Registry MUST set version to that new seq in the same atomic update. Therefore, for every stored Engagement Object, version MUST equal max(change_log[*].seq). A mutation that changes status, participants, approval gates, countersignature state, or termination state without appending a matching change-log entry MUST be rejected.¶

Engagement Lifecycle:¶

  proposed --> active --> completed
                 |
                 +--> suspended --> active (resumed)
                 |
                 +--> terminated

Engagement Lifecycle Transitions:¶

• proposed to active: Requires both hiring_operator_signature and deploying_principal_signature. Missing deploying_principal_signature during activation MUST be rejected with engagement_countersign_required.¶
• active to suspended / completed: Hiring operator only.¶
• active/suspended to terminated: Either party.¶

Termination Cascade: When an Engagement is terminated:¶

1. The Registry MUST set status: "terminated" atomically.¶
2. All Capability Overlays linked to this engagement_id MUST be invalidated (per Rule CO-5).¶
3. All Approval Envelopes in pending_approval, approved, or executing status scoped to this engagement_id MUST be transitioned to cancelled using the Approval Envelope cancellation rules in Section 13.6.¶
4. Subsequent Credential Token validation for operations scoped to this engagement MUST fail with engagement_terminated.¶

This termination cascade applies only when an Engagement transitions to terminated. Transition to completed does not trigger any Capability Overlay invalidation or Approval Envelope cancellation cascade.¶

6.1. Envelope Submission

The Registration Envelope request body is defined only in Section 5.6. An agent is registered by submitting that object to POST /v1/agents. This section defines Registry processing and validation; it does not define a second Registration Envelope schema.¶

6.2. Registration Validation

The Registry MUST perform the following checks in order before accepting a Registration Envelope. The Registry MUST either accept all or reject all — partial registration MUST NOT be possible.¶

If any required condition in Checks 1 through 15, including their lettered subchecks, fails and that check does not explicitly name a more specific error code, the Registry MUST reject the Registration Envelope with registration_invalid. Because the checks are ordered, the Registry SHOULD report the error code associated with the first failed check.¶

1. Check 1. identity MUST be present and MUST be valid JSON conforming to the Agent Identity schema.¶
2. Check 2. identity.aid MUST match the did:aip ABNF grammar defined in Section 4.1.¶
3. Check 3. identity.type MUST equal the namespace component of identity.aid. The namespace MUST have an active, non-reserved entry in the Registry's synced AIP Namespace Catalog, unless the Registry explicitly documents a private local namespace policy. A mismatch, unknown namespace, removed namespace, or reserved namespace MUST be rejected with registration_invalid.¶
4. Check 4. identity.aid MUST NOT already exist in the Registry, and identity.public_key MUST NOT already be associated with a registered, non-revoked AID in the Registry, whether as that AID's active public key or as its stored fallback public key. If any condition fails, the Registry MUST reject with aid_already_registered.¶
5. Check 5. identity.public_key MUST be an Ed25519 JWK with kty="OKP", crv="Ed25519", and a 43-character base64url x value.¶
6. Check 5b. If identity.fallback_public_key_x is present, it MUST be a valid 43-character base64url string (same encoding as public_key.x), MUST NOT equal identity.public_key.x, MUST NOT already be associated with any other registered AID in the Registry (including as a primary public key or as a fallback key of another AID), and MUST NOT be a fallback key that has already been consumed by a prior Emergency Key Rotation for any AID. If any of these conditions fails, the Registry MUST reject with registration_invalid and MUST include the field name identity.fallback_public_key_x in the error details. The Registry MUST persist the fallback public key at initial registration and MUST NOT allow it to change except through Emergency Key Rotation (Section 17.6).¶
7. Check 5c. If identity.fallback_public_key_x is present, identity.fallback_key_proof MUST be present and MUST be a valid EdDSA signature, verifiable with the Ed25519 public key encoded by identity.fallback_public_key_x, over the UTF-8 byte sequence of the string "aip:fallback-key-proof:v1:" + identity.aid + ":" + identity.fallback_public_key_x as defined in Section 5. If identity.fallback_public_key_x is absent, identity.fallback_key_proof MUST be absent. If either condition fails, the Registry MUST reject with fallback_proof_invalid and MUST include the field name identity.fallback_key_proof in the error details. This check ensures the registrant possesses the fallback private key, preventing unrecoverable registrations and fallback-key squatting.¶
8. Check 6. capability_manifest MUST be present and MUST be valid JSON conforming to the Capability Manifest schema. It MUST include manifest_id, aid, granted_by, version, issued_at, expires_at, capabilities, and signature. The version field MUST equal 1 for initial registration; manifest_id MUST match the cm: UUID pattern; issued_at and expires_at MUST be valid date-time values; capabilities MUST be an object; and signature MUST be a non-empty base64url value. The capability_manifest.expires_at value MUST be in the future at the time of registration.¶
9. Check 7. capability_manifest.aid MUST equal identity.aid.¶
10. Check 8. The principal_token string MUST be decodable as a compact-serialised JWT, MUST conform to the Principal Token schema, and MUST carry a JOSE header with typ equal to "JWT", alg equal to "EdDSA", and kid identifying an Ed25519 verification method controlled by the decoded iss DID or AID. For a did:aip issuer, the Registry MUST resolve the key through its public-key endpoint for that registered AID. The Registry MUST verify the Principal Token signature using the resolved verification method. If any Check 8 condition fails, the Registry MUST reject with registration_invalid.¶
11. Check 9. The decoded principal_token payload sub MUST equal identity.aid. If delegation_depth is 0, delegated_by MUST be null and iss MUST equal principal.id. If delegation_depth is greater than 0, delegated_by MUST be a registered, non-revoked parent AID, iss MUST equal delegated_by, and the Registry MUST reconstruct the complete candidate chain by appending the submitted Principal Token to the parent's stored registration chain. The reconstructed chain MUST satisfy the delegation-chain rules in Section 9.11, including linkage, consistent root principal, scope inheritance, task binding, and maximum delegation depth. The submitted capability_manifest scopes MUST be a subset of both the submitted Principal Token scope array and the parent's effective Capability Manifest. If any Check 9 condition fails, the Registry MUST reject with registration_invalid or invalid_delegation_depth when the depth limit is exceeded.¶
12. Check 9a. max_delegation_depth Bounds: If the root Principal Token for the reconstructed registration chain contains a max_delegation_depth claim, the Registry MUST verify that its value is an integer in the range 0 through 10 inclusive. If max_delegation_depth is absent from the root Principal Token, the Registry MUST treat it as 3 for all subsequent registration processing. If the value exceeds 10 or is a negative integer, the Registry MUST reject the registration with registration_invalid and MUST include the detail string max_delegation_depth exceeds the hard cap of 10 in the error response.¶
13. Check 10. The decoded principal_token payload principal.id MUST NOT begin with did:aip:.¶
14. Check 11. If the synced AIP Namespace Catalog entry for identity.type has requires_task_id: true, the decoded principal_token payload task_id MUST be non-null and non-empty.¶
15. Check 12. capability_manifest.signature MUST be verifiable against the granted_by DID's public key.¶
16. Check 13. identity.version MUST equal 1 and identity.previous_key_signature MUST be absent. Registration Envelopes are initial-registration objects only; key rotation is processed through PUT /v1/agents/{aid}.¶
17. Check 14a. grant_tier MUST be present and MUST be one of "G1", "G2", or "G3". If grant_tier is absent or has any other value, the Registry MUST reject with registration_invalid.¶
18. Check 14b. The Registry MUST determine the requested security Tier as the highest AIP Scope Catalog tier among all active scopes in capability_manifest.capabilities.¶
19. Check 14c. The submitted grant_tier MUST satisfy the requested security Tier determined in Check 14b. Tier 1 permits "G1", "G2", or "G3". Tier 2 permits "G2" or "G3" unless the Registry's identity_proofing_required_for_tier2 metadata field is true, in which case Tier 2 permits only "G3". Tier 3 permits only "G3". If grant_tier is inconsistent with the requested security Tier or the Registry's Tier 2 identity-proofing policy, the Registry MUST reject with registration_invalid.¶
20. Check 14d. If the requested security Tier determined in Check 14b is 2 or 3, the decoded principal_token payload principal.id MUST use the did:web method. Otherwise, the Registry MUST reject with principal_did_method_forbidden.¶
21. Check 14e. If grant_tier is "G3", the decoded principal_token payload MUST include a non-empty acr string and a non-empty amr array. If either claim is absent or empty, the Registry MUST reject with identity_proofing_insufficient.¶
22. Check 15. If the requested security Tier determined in Check 14b is 2 and identity.model.attestation_hash is absent, the Registry SHOULD accept the Registration Envelope, but only if it creates a structured registration warning with code equal to "model_attestation_missing_tier2", severity equal to "warning", source_check equal to "registration_check_15", and issued_at set to the Registry's current time. The warning message MUST state that the Tier 2 agent is not cryptographically pinned to a model artifact. The Registry MUST persist this warning in Agent Registration Metadata, MUST include it in the successful POST /v1/agents response, and MUST return it in subsequent GET /v1/agents/{aid} metadata responses while the registered Agent Identity Object lacks model.attestation_hash. The persisted warning is the required audit artifact for this condition. If the requested security Tier is 3, identity.model.attestation_hash MUST be present and MUST match the sha256:<64 lowercase hex characters> pattern. If the requested security Tier is 3 and the field is absent or malformed, the Registry MUST reject with registration_invalid.¶

On acceptance, the Registry MUST store the reconstructed registration chain for the registered AID. For a direct registration, that chain contains the submitted root Principal Token. For a sub-agent registration, it contains the parent's stored registration chain followed by the submitted delegated Principal Token. The Registry MUST record the delegated_by field from the decoded principal_token payload (or the principal's DID if delegated_by is null) in the parent-child delegation index, for use in revocation propagation (Section 11.4).¶

If the synced AIP Namespace Catalog entry for identity.type defines an automatic lifecycle expiry rule, the Registry MUST persist the resulting lifecycle_expires_at value in its stored registration record before accepting the Registration Envelope. For the Draft-02 ephemeral namespace, lifecycle_expires_at MUST be no later than the earlier of the decoded root Principal Token expires_at value and capability_manifest.expires_at.¶

6.3. Error Responses

All AIP error responses MUST use the format defined in Section 18.1. Implementations MUST NOT return HTTP 200 for error conditions.¶

7.1. DID Resolution

Every registered AID MUST have a corresponding W3C DID Document resolvable by a DID resolver that implements the did:aip method defined in this section. The DID Document is derived deterministically from the Agent Identity, active Capability Manifest, and lifecycle state stored in the authoritative Registry.¶

The Registry MUST generate and serve DID Documents from GET /v1/agents/{aid} when the Accept: application/did+ld+json or Accept: application/did+json header is present. Without one of these DID-specific Accept values, the endpoint returns the default Agent Registration Metadata response defined in Section 17.4.¶

AIP implementations MUST support DID resolution for at minimum did:aip, did:key, and did:web DID methods. Resolved DID Documents MAY be cached for a maximum of 300 seconds.¶

DID resolution performed during token validation MUST use an explicit timeout. For any validation step that is REQUIRED because the token has security Tier 2 or Tier 3 or because the token contains aip_registry, each remote DID resolution attempt MUST time out no later than 2 seconds after it is started, and the aggregate wall-clock budget for DID resolution across a single token validation attempt MUST NOT exceed 5 seconds. Local non-network resolution, such as did:key, SHOULD complete without consuming this remote-resolution budget. Implementations MAY use shorter timeouts, but MUST NOT use a zero-duration timeout for a required remote DID resolution attempt.¶

If DID resolution fails or times out during a REQUIRED validation step, implementations MUST treat the result as registry_unavailable and MUST reject the operation. If a Tier 1-only operation performs Registry Trust Anchoring as a RECOMMENDED check and DID resolution times out, the Relying Party MAY either reject with registry_unavailable or skip that RECOMMENDED check according to local policy.¶

If the AID has been revoked, the Registry MUST return deactivated: true in didDocumentMetadata, per W3C-DID Section 7.1.2.¶

7.2. did:aip Method Resolution

A did:aip resolver MUST NOT infer the authoritative Registry from the namespace or agent-id components of the DID. The resolver MUST be invoked with an authoritative Registry base URI, or MUST obtain one from protocol context: the aip_registry claim in a Credential Token, the iss or aip_registry value in a Step Execution Token, the root principal DID Document's AIPRegistry service entry, or a local trust policy that binds the AID namespace to a Registry. If no authoritative Registry can be determined, resolution fails and protocol validation that requires the result MUST reject with registry_unavailable.¶

The resolver's input DID MUST match the did:aip syntax in Section 4.1. A resolver receiving a malformed AID MUST return a DID Core resolution result with didResolutionMetadata.error set to invalidDid and MUST NOT contact a Registry.¶

To resolve a valid AID, the resolver MUST perform the following steps:¶

1. Resolve and, when required by the validation context, pin the authoritative Registry trust state using the Registry Genesis procedure in Section 7.4.¶
2. Percent-encode the complete AID for use as the {aid} path parameter according to Section 17.2.¶
3. Send GET /v1/agents/{aid} to the authoritative Registry with Accept: application/did+json or Accept: application/did+ld+json.¶
4. If the Registry returns HTTP 404, return a DID resolution result with didResolutionMetadata.error set to notFound.¶
5. If the Registry cannot be reached or times out under the limits in Section 7.1, return a DID resolution result with didResolutionMetadata.error set to registry_unavailable.¶
6. If the requested representation is unsupported, return a DID resolution result with didResolutionMetadata.error set to representationNotSupported.¶
7. On success, return a DID Core resolution result whose didDocument.id equals the input AID, whose didResolutionMetadata.contentType matches the returned representation, and whose didDocumentMetadata contains versionId, updated, deactivated, and aip_registry.¶

A Registry constructs the did:aip DID Document from its stored registration record as follows. The DID Document id is the AID. The verificationMethod array contains the current active Ed25519 public key from the current Agent Identity Object. The verification method id MUST equal <aid>#key-<identity.version>, its controller MUST equal the AID, and its publicKeyJwk MUST contain only public JWK members. The authentication array MUST contain that verification method identifier. The DID Document controller value MUST equal the active Capability Manifest granted_by value. The didDocumentMetadata.versionId value MUST equal the decimal string form of identity.version.¶

DID URL dereferencing for did:aip supports only the empty fragment and key fragments of the form #key-<positive-integer>. The empty fragment dereferences to the DID Document. A key fragment dereferences to the corresponding verification method if the Registry retains the requested historical key version at GET /v1/agents/{aid}/public-key/{key-id}; otherwise dereferencing returns didResolutionMetadata.error set to notFound. Other fragments MUST return notFound.¶

The CRUD operations for the did:aip method are:¶

Deactivation is permanent for the affected AID. After full revocation, the Registry MUST return didDocumentMetadata.deactivated as true. The Registry MAY still return the last DID Document and MUST continue to serve retained historical public keys for audit and signature verification, but Relying Parties MUST reject new protocol operations for a deactivated AID during revocation and lifecycle validation.¶

7.3. DID Document Structure

A conformant did:aip DID Document MUST include @context, id, verificationMethod, authentication, and controller. See the canonical example in the repository at examples/did-document.json. Method operations and DID URL dereferencing rules are defined in Section 7.2.¶

A principal that authorises agents for Tier 2 or Tier 3 operations MUST use the did:web DID method, and that principal's DID Document MUST include an AIPRegistry service entry in its service array. Principals MUST NOT use the did:aip method anywhere in the protocol.¶

  {
    "id": "did:web:acme.com#aip-registry",
    "type": "AIPRegistry",
    "serviceEndpoint": "https://registry.acme.com"
  }

The serviceEndpoint MUST be an HTTPS URI pointing to the base URL of the authoritative AIP Registry for agents delegated by this principal. The type MUST be exactly "AIPRegistry" (case-sensitive).¶

For principals using did:key: an AIPRegistry service entry cannot be declared (DID Key documents have no service array). did:key principals MUST NOT authorise Tier 2 or Tier 3 operations.¶

For principals using any W3C DID method other than did:web or did:aip, authorisation is limited to Tier 1. Even if such a DID method supports service entries, this specification does not permit it for Tier 2 or Tier 3 principal authorisation. For did:web principals, the AIPRegistry service entry is REQUIRED when the principal authorises any agent with Tier 2 or Tier 3 scopes. It is OPTIONAL for principals authorising only Tier 1 agents.¶

7.4. Registry Genesis

Registry Genesis is the one-time initialisation procedure by which a new AIP Registry establishes its stable service identifier, generates its initial trust keys, and publishes discovery and trust metadata. It MUST be performed before the Registry serves any requests.¶

  https://registry.example.com

GET /v1/registry-metadata

7.5. AIP Gateway Protected Resource Metadata

Any MCP gateway that enforces AIP authentication for tool listing or tool execution MUST publish OAuth Protected Resource Metadata [RFC9728] using the registered oauth-protected-resource well-known URI suffix:¶

https://{gateway-host}/.well-known/oauth-protected-resource

AIP does not define or require an AIP-specific well-known URI suffix for gateway discovery. The response MUST be a JSON object conforming to RFC 9728 and containing the following fields:¶

{
  "resource": "https://gateway.example.com/",
  "authorization_servers": ["https://registry.example.com"],
  "scopes_supported": ["email.read", "calendar.read"],
  "bearer_methods_supported": ["header"],
  "dpop_signing_alg_values_supported": ["EdDSA"],
  "dpop_bound_access_tokens_required": true,
  "resource_name": "Example AIP MCP Gateway",
  "resource_documentation": "https://gateway.example.com/docs"
}

resource

REQUIRED. The gateway protected resource identifier. It MUST be an HTTPS URL with no fragment, as defined by [RFC9728].¶

authorization_servers

REQUIRED for AIP gateways. The array MUST contain at least one AIP Registry OAuth authorization-server issuer identifier acceptable for this protected resource.¶

scopes_supported

RECOMMENDED. When present, values MUST be AIP scope strings from the synced AIP Scope Catalog or accepted local extension policy.¶

bearer_methods_supported

REQUIRED for AIP gateways that accept non-DPoP Bearer tokens and MUST include "header" when present. AIP uses the registered Bearer authentication scheme for requests that do not require proof-of-possession and the registered DPoP authentication scheme for DPoP-bound tokens.¶

dpop_signing_alg_values_supported

REQUIRED when any advertised scope or endpoint requires DPoP, and MUST include "EdDSA".¶

dpop_bound_access_tokens_required

REQUIRED when the gateway requires DPoP-bound access tokens for all requests to the protected resource. If omitted or false, clients MUST still apply AIP DPoP requirements derived from the requested scope Tier, Scope Catalog metadata, and endpoint policy.¶

tls_client_certificate_bound_access_tokens

REQUIRED and set to true when the gateway enforces AIP Tier 3 mTLS-bound access tokens for the protected resource.¶

Endpoint Requirements:¶

1

The /.well-known/oauth-protected-resource endpoint MUST respond to unauthenticated HTTP GET requests. Authentication MUST NOT be required to retrieve the Protected Resource Metadata document.¶

2

The response MUST use HTTP status 200 and Content-Type: application/json.¶

3

The response SHOULD include a Cache-Control header with a max-age value between 60 and 300 seconds. Clients MUST NOT cache the Protected Resource Metadata document for longer than 300 seconds.¶

4

Consistency Constraint: If a gateway advertises Tier 2 or Tier 3 scopes in scopes_supported, or if local endpoint policy marks the protected resource as Tier 2 or Tier 3, the gateway MUST either set dpop_bound_access_tokens_required to true or document per-scope DPoP requirements through Registry policy. A client MUST treat contradictory metadata as gateway_config_invalid.¶

5

For stateless gateway deployments (Section 8.2.1), the gateway MUST NOT serve stale Protected Resource Metadata; the document MUST reflect the currently active resource configuration from the shared configuration store.¶

MCP clients that discover a gateway through OAuth Protected Resource Metadata SHOULD fetch this document before tool listing or tool execution. If the document is absent, malformed, or does not identify an acceptable AIP Registry authorization server, an AIP-aware MCP client MUST NOT assume that unauthenticated tool access is permitted.¶

8.1. Credential Token Transport and Version Header

The Credential Token JWT header and payload fields are defined in Section 5.4. This section defines only the HTTP transport profile, version-header requirements, issuance lifetime rules, and refresh behavior for those tokens.¶

An AIP Credential Token for a request that does not require proof-of-possession is transmitted as an HTTP Authorization header using the registered Bearer authentication scheme [RFC6750]:¶

EXAMPLE (informative):¶

 Authorization: Bearer <token>
 X-AIP-Version: 0.3

For interactions requiring Proof-of-Possession, the Credential Token is transmitted using the registered DPoP authentication scheme [RFC9449] and the request also carries a DPoP proof JWT:¶

EXAMPLE (informative):¶

 Authorization: DPoP <token>
 DPoP: <dpop-proof>
 X-AIP-Version: 0.3

The X-AIP-Version HTTP header MUST carry the full protocol version string, identical to the aip_version JWT claim. For this specification, the value MUST be "0.3". This value is the AIP protocol compatibility version defined in Section 20, not the Internet-Draft revision suffix. Implementations MUST reject requests with unsupported_version when the X-AIP-Version header is absent, carries an unsupported value, or does not match the token aip_version claim.¶

Every AIP-aware HTTP response to an AIP protocol request MUST include an X-AIP-Version response header containing the AIP protocol compatibility version used to interpret the request and generate the response. For responses conforming to this specification, the value MUST be "0.3". This requirement applies to successful responses and error responses, including responses that reject a request with unsupported_version. When a request is rejected because the requested version is unsupported, the responder MUST set X-AIP-Version to a protocol version it supports for that endpoint and SHOULD include X-AIP-Supported-Versions with a comma-separated list of supported AIP protocol versions.¶

8.2. Token Issuance

Implementations MUST enforce the following maximum Credential Token lifetimes. The effective TTL limit for a token is the lowest applicable limit from this table across all requested scopes.¶

When a token contains multiple scopes, the most restrictive TTL applies. Zero-duration and negative-duration tokens (where exp <= iat) MUST be rejected. A synced AIP Scope Catalog entry for a standard or extension scope MUST NOT advertise a ttl_max_seconds value greater than the ceiling for that scope's Tier. A token containing a scope whose active catalog entry is missing, inactive, or exceeds its Tier ceiling MUST be rejected with invalid_scope or invalid_token as applicable to the validation step.¶

A token's security Tier is determined by its highest-risk scope (Section 3.2). A token containing one Tier 2 scope and any number of Tier 1 scopes is a Tier 2 token in its entirety. Implementations MUST NOT derive Tier from the majority of scopes or from the first scope in the array.¶

8.3. Token Refresh and Long-Running Tasks

effective_ttl_seconds = exp - iat

refresh_lead_seconds =
  max(1, min(
    300,
    max(30, ceiling(effective_ttl_seconds * 0.10)),
    floor(effective_ttl_seconds / 2)
  ))

begin refresh when (exp - now) <= refresh_lead_seconds

8.4. Token Exchange for MCP

 POST /v1/oauth/token HTTP/1.1
 Content-Type: application/x-www-form-urlencoded
 DPoP: <DPoP proof JWT>

 grant_type=urn:ietf:params:oauth:grant-type:token-exchange
 &subject_token=<AIP Credential Token>
 &subject_token_type=urn:ietf:params:oauth:token-type:jwt
 &resource=https://mcp-server.example.com/
 &scope=email.read calendar.read

 {
   "access_token": "<JWT>",
   "token_type": "DPoP",
   "expires_in": 300,
   "scope": "email.read calendar.read",
"issued_token_type": "urn:ietf:params:oauth:token-type:access_token"
 }

9.1. Step 1: Parse

Parse the Authorization header value as a JWT per [RFC7519]. If parsing fails or the token is malformed, reject with invalid_token.¶

9.2. Step 2: Header Validation

Verify the JWT header contains:¶

• typ: MUST be "AIP+JWT"¶
• alg: MUST be "EdDSA"¶
• kid: MUST be present and MUST be a DID URL in the form did:aip:<namespace>:<32-hex>#key-<n>¶

If any check fails, reject with invalid_token.¶

9.3. Step 2a: Expiration Preflight

Before performing any Registry key lookup, the Relying Party MUST decode the JWT payload without using it for any acceptance decision. This preflight is only an error-ordering and lookup-amplification control. Signature verification in Step 4 and full claim validation in Step 5 remain mandatory before a token can be accepted.¶

The Relying Party MUST inspect only iat, exp, and aip_scope during this preflight. If iat or exp is absent, not an integer, or exp <= iat, reject with invalid_token. If exp is in the past, reject with token_expired. This rejection applies even if the token's kid references a historical key version that is no longer retained by the Registry.¶

If the unsigned payload's exp - iat exceeds the largest ttl_max_seconds value among active entries in the synced AIP Scope Catalog, the Relying Party MAY reject with invalid_token before key lookup. This check is conservative: it can reject tokens that no valid catalog entry could authorize, but it MUST NOT be used to accept a token.¶

9.4. Step 3: Identify Agent and Retrieve Public Key

Extract the kid header parameter. This is a full DID URL identifying the agent's public key. Contact the Registry to retrieve the historical public key matching this kid using GET /v1/agents/{aid}/public-key/{key-id}, where {aid} is the DID URL without the fragment and {key-id} is the fragment without the leading #. The Registry response MUST conform to public-key-response.schema.json and return the public key material along with its validity period (valid_from timestamp and valid_until timestamp or null).¶

If the Registry cannot be reached or the public key lookup cannot be completed because the Registry is unavailable, reject with registry_unavailable. If the Registry lookup succeeds but the kid is not found or the key is not valid at the time of the JWT's iat claim, reject with unknown_aid. Because Step 2a runs before this lookup, an already-expired token MUST surface as token_expired, not unknown_aid, even when its historical signing key has aged out of Registry retention.¶

9.5. Step 4: Verify Signature

Verify the JWT signature using the public key retrieved in Step 3. The signature verification MUST use constant-time comparison. If signature verification fails, reject with invalid_token.¶

9.6. Step 5: Validate Claims

Validate the following claims from the decoded JWT payload:¶

9.7. Step 6: TTL Validation

Verify that the token's lifetime does not exceed the maximum permitted by its scopes. Compute lifetime = exp - iat (in seconds). Compare against the ttl_max_seconds values in the synced AIP Scope Catalog and the Tier ceilings in Section 8.2:¶

effective_ttl_limit =
  min(
    scope.ttl_max_seconds,
    tier_ttl_ceiling(scope.tier)
    for scope in aip_scope
  )

When a token contains multiple scopes, the most
restrictive catalog TTL applies.

If lifetime exceeds the limit, reject with invalid_token.¶

For validation, a token's security Tier is determined by its highest-risk scope (Section 3.2). A token containing one Tier 2 scope and nine Tier 1 scopes is a Tier 2 token in its entirety. A Relying Party MUST NOT derive Tier from the majority of scopes or from the first scope in the array.¶

9.8. Step 6a: Registry Trust Anchoring (Conditional)

This step is REQUIRED for Tier 2 and Tier 3 operations and for any Credential Token that contains aip_registry. It is RECOMMENDED for Tier 1 operations when aip_registry is absent. It verifies that the Registry from which the Relying Party has been fetching data matches the Registry declared by the principal's DID Document.¶

1. Extract principal_id from aip_chain[0].iss (the root principal's DID). This is the authorising human or organisational principal.¶
2. If the operation's security Tier is 2 or 3, principal_id MUST use the did:web method. If it uses did:key, did:aip, or any other DID method, reject with principal_did_method_forbidden.¶
3. Resolve principal_id using the DID method's own resolution mechanism (e.g., did:web resolution per [W3C-DID], did:key per [W3C-DID]). The resolution MUST be independent of any agent-provided data. Use the DID method's canonical resolver.¶
4. Examine the resolved DID Document's service array. Locate an entry with type: "AIPRegistry".¶
5. Extract the serviceEndpoint URI from that service entry. This is the authoritative Registry URI for this principal.¶
6. Verify that the Registry from which the Relying Party has been fetching revocation status, Capability Manifests, and step data matches the declared serviceEndpoint URI. Perform origin comparison per [RFC6454] (scheme + host + port must match).¶
7. If aip_registry is present in the Credential Token, verify it matches the DID-Document-declared Registry endpoint. If mismatch, reject with registry_untrusted.¶
8. If the DID Document does not contain an AIPRegistry service entry and the operation's security Tier is 2 or 3 or the token contains aip_registry, reject with registry_untrusted.¶

For Tier 1 operations where aip_registry is absent, this step is RECOMMENDED. Registry trust anchoring prevents MitM Registry substitution but adds latency (additional DID resolution). Tier 1 operators MAY skip this step if they accept the risk that the Registry might be MitM'd with a loss of up to 15-minute revocation staleness.¶

If DID resolution fails and the operation's security Tier is 2 or 3 or the token contains aip_registry, reject with registry_unavailable.¶

DID resolution for this step MUST use the timeout requirements in Section 7.1. For Tier 2 or Tier 3 operations and tokens containing aip_registry, a DID resolution timeout is a validation failure and MUST be reported as registry_unavailable; implementations MUST NOT wait indefinitely for the principal DID resolver.¶

A Relying Party MUST NOT use aip_registry as an authoritative Registry locator unless this step has verified it against the DID-Document-declared Registry endpoint.¶

9.9. Step 6b: Engagement Validation (Conditional)

This step applies only if aip_engagement_id is present in the Credential Token payload.¶

1. Fetch the Engagement Object from the Registry via GET /v1/engagements/{aip_engagement_id}.¶
2. Verify the Engagement's status field. If "active", continue. If "completed" or "terminated", reject with engagement_terminated. If "suspended", reject with engagement_suspended.¶
3. Verify that the token's sub (agent AID) appears in the Engagement's participants array as an active participant. If sub is not in the participants array or has been marked as removed, reject with engagement_participant_removed.¶
4. If the Engagement defines approval_gates with pending gates that guard the current operation, evaluate each gate trigger using the trigger grammar in Section 5.12. A scope:<scope-string> trigger guards any operation whose requested aip_scope set contains that scope. An action_type:<action-type> trigger guards Approval Envelope steps whose action_type exactly equals that value. If a matching required gate is still pending, reject with engagement_gate_pending. If a matching required gate has status "rejected", reject with engagement_terminated.¶

9.10. Step 7: Revocation Check

Query the Registry for revocation status of the agent identified by iss (extracted from the kid). The revocation check method depends on the token's Tier. Chain-wide and principal-wide revocation effects are completed in Step 8 after aip_chain has been validated.¶

• Tier 1: Retrieve a verifiable CRL from the Registry cache. The CRL's next_update MUST be later than the Relying Party's current UTC validation time. If no fresh verifiable CRL is available, reject with registry_unavailable. If the agent appears on the CRL with revocation type full_revoke or principal_revoke, reject with agent_revoked. If the agent appears with scope_revoke, the Relying Party MUST verify that none of the scopes in the token's aip_scope are present in the scopes_revoked list. If any match, reject with agent_revoked. The same CRL MUST also be used in Step 8 to evaluate principal_revoke entries whose target_id is the root Principal DID or any AID in the validated aip_chain.¶
• Tier 2: Perform a live Registry lookup. Query GET /v1/agents/{iss}/revocation. A successful response MUST be HTTP 200 with a body conforming to revocation-status.schema.json (Section 17.9). If revoked is true, reject with agent_revoked. If any currently requested scope appears in scopes_revoked, reject with agent_revoked. If the token relies on delegation authority rooted at an AID whose response has delegation_revoked equal to true, reject with agent_revoked. If the Registry returns unknown_aid, reject with unknown_aid. If the Registry is unreachable, reject with registry_unavailable. A previously cached accepted token validation result MUST NOT be used to skip this lookup.¶

The Relying Party MUST verify the Registry trust state used for this revocation check using the Registry trust bootstrapping and Registry Trust Record procedures in Section 7.4.4 and Section 7.4.5, and the sequential trust-update procedure in Section 7.4.7.1 when updating pinned trust state, before treating Registry responses as authoritative.¶

9.11. Step 8: Delegation Chain Validation

Validate the Principal Token delegation chain in aip_chain. This array contains one or more compact-serialised JWTs, each conforming to the Principal Token schema.¶

For each Principal Token at index i (from 0 to n-1 where n is the length of aip_chain):¶

8a. Valid JWT:

The token at index i MUST be a valid, well-formed JWT conforming to the Principal Token schema. Its JOSE header MUST contain typ equal to "JWT", alg equal to "EdDSA", and a non-empty kid DID URL. If parsing, schema validation, or header validation fails, reject with delegation_chain_invalid.¶

8b. delegation_depth Matches Index:

The delegation_depth claim in token i MUST equal exactly i. The array is 0-indexed: aip_chain[0] has delegation_depth: 0, and aip_chain[1], when present, has delegation_depth: 1. If mismatch, reject with invalid_delegation_depth.¶

8c. Delegation Depth Does Not Exceed Maximum:

The delegation_depth of token i MUST NOT exceed the max_delegation_depth value declared in token 0 (the root token). If max_delegation_depth is absent from token 0, the default is 3. If i exceeds this limit, reject with invalid_delegation_depth.¶

8d. Issuer and kid Binding:

For token at index i, extract the iss claim. For i = 0, iss MUST equal principal.id. For i > 0, iss MUST equal delegated_by. The kid header MUST identify an Ed25519 verification method controlled by iss, and the DID portion of kid MUST equal iss. If any of these bindings fail, reject with delegation_chain_invalid.¶

8d-1. Root Principal Signature Verification:

For i = 0, resolve kid using the DID method of the root principal DID in principal.id. The AIP Registry MUST NOT be used as the authority for root-principal keys. If DID resolution fails, the key is not Ed25519 verification material, the verification method is not controlled by principal.id, or signature verification fails, reject with delegation_chain_invalid.¶

8d-2. Delegated Agent Key Lookup:

For i > 0, iss is the parent agent AID that signed this delegated Principal Token. The Relying Party MUST resolve the signing key through the authoritative AIP Registry using the percent-encoded issuer AID and the kid fragment: GET /v1/agents/{iss}/public-key/{key-id}. The key-id path component is the fragment portion of kid without the leading number-sign character. The Registry response MUST identify the same AID as iss and return Ed25519 public key material whose validity interval covers the Principal Token's issued_at instant. If the Registry cannot be reached or the key lookup cannot be completed because the Registry is unavailable, reject with registry_unavailable. If the Registry lookup succeeds but iss is not a registered AID, kid is not found, or the key is not valid at issued_at, reject with unknown_aid.¶

8d-3. Delegated Principal Token Signature Verification:

For i > 0, verify the Principal Token signature using the key resolved in Step 8d-2. If the resolved key is not Ed25519 verification material, identifies a key not controlled by iss, or signature verification fails, reject with delegation_chain_invalid.¶

8e. Delegation Chain Linkage:

For token at index i > 0, verify that delegated_by[i] equals sub[i-1] (the sub of the previous token). This ensures the chain is continuous: each agent is delegated by the previous agent in the chain. A delegated Principal Token MUST NOT be self-delegated: delegated_by[i] MUST NOT equal sub[i]. If linkage fails or the token is self-delegated, reject with delegation_chain_invalid.¶

8f. Agent Revocation:

For each sub AID in the chain (at all indices), verify it is not revoked using the same Tier-specific revocation check as Step 7. If the Registry returns unknown_aid for any chain sub AID, reject with unknown_aid. If any agent in the chain is revoked, reject with agent_revoked. A principal_revoke whose target_id equals any chain sub AID MUST be treated as revoked even when no descendant Revocation Object has been materialised for that AID.¶

8g. No Duplicate AIDs:

No AID may appear more than once in the chain (no cycles or duplicates). This rule includes direct self-delegation, where a Principal Token attempts to delegate from an AID back to the same AID. If an AID appears at indices i and j with i != j, reject with delegation_chain_invalid.¶

8h. Token Validity:

For token at index i, parse issued_at and expires_at as ISO 8601 UTC instants. Verify issued_at is not more than 30 seconds in the future relative to the Relying Party's current UTC clock. If it is, reject with delegation_chain_invalid. Verify expires_at > issued_at; if not, reject with delegation_chain_invalid. Verify expires_at is in the future; if expired, reject with chain_token_expired.¶

8i. Consistent Principal:

The principal.id field MUST be byte-for-byte identical across ALL elements in the chain (index 0 through n-1). This ensures the chain always traces to the same root principal. If any element has a different principal.id, reject with delegation_chain_invalid.¶

8j. Principal is Not an Agent:

The principal.id from aip_chain[0] MUST NOT begin with did:aip:. Principals are humans or organisations, never agents. If principal.id uses the did:aip method, reject with delegation_chain_invalid.¶

8k. Namespace Task Binding:

For every Principal Token whose sub namespace has requires_task_id: true in the synced AIP Namespace Catalog, the token payload MUST include a non-null, non-empty task_id. If such a chain element omits task_id, sets it to null, or sets it to an empty string, reject with delegation_chain_invalid.¶

8l. Root Principal Revocation:

Let root_principal_id be the principal.id value that Step 8i verified across the chain. Using the revocation source required for the token's Tier, verify that no active principal_revoke has target_id equal to root_principal_id. A match invalidates every Credential Token and Step Execution Token rooted at that Principal DID; reject with agent_revoked. This rejection is required regardless of the propagate_to_children value on the Revocation Object.¶

9.12. Step 9: Capability Validation

Verify that the agent's requested scopes are permitted by its Capability Manifest.¶

1. Fetch the Capability Manifest for the agent identified by iss from GET /v1/agents/{iss}/capabilities. The response MUST conform to capability-manifest.schema.json, and manifest.aid MUST equal iss. If unavailable, malformed, or not bound to iss, reject with manifest_invalid.¶
2. Verify the manifest signature using manifest.signature_kid. The DID portion of signature_kid MUST equal manifest.granted_by. If key resolution, key binding, or signature verification fails, reject with manifest_invalid.¶
3. Verify expires_at is in the future. If expired, reject with manifest_expired.¶
4. For each requested scope whose synced AIP Scope Catalog entry has a non-null constraint_schema, validate the corresponding Capability Manifest value against that schema. If validation fails, reject with manifest_invalid.¶

9.13. Step 9a: Scope Verification

For all agents: verify each scope in aip_scope is present with status: "active" or, when local policy allows experimental behavior, status: "experimental" in the synced AIP Scope Catalog. If any requested scope is unknown, reserved, removed, or not permitted by local extension policy, reject with invalid_scope. Then verify each requested scope is present in the Capability Manifest. If any requested scope is absent from the Capability Manifest, reject with insufficient_scope.¶

9.14. Step 9b: Capability Overlay (Conditional)

If a Capability Overlay exists, verify scope constraints permit the requested operation. For each overlay constraint whose synced AIP Scope Catalog entry has a non-null constraint_schema, validate the overlay constraint against that schema before applying attenuation. If schema validation fails, reject with overlay_exceeds_manifest.¶

9.15. Step 9c: Delegation Scope Inheritance

For delegated Credential Tokens, the Relying Party MUST verify that the requested scopes and the leaf agent's Capability Manifest are valid attenuations of every delegation in aip_chain.¶

Let chain[i] be the decoded Principal Token payload at aip_chain[i], and let manifest(chain[i].sub) be the current Capability Manifest for the agent identified by chain[i].sub. Let n be the length of aip_chain. The Relying Party MUST execute the inheritance validation in increasing index order, from the root delegated agent (i = 0) to the leaf acting agent (i = n-1).¶

1. For every i from 0 to n-1, obtain the current Capability Manifest M[i] for chain[i].sub. The leaf manifest M[n-1] MAY reuse the manifest already fetched in Step 9. All ancestor manifests MUST be fetched according to the caching rules in Section 10. If any required manifest is unavailable, reject with manifest_invalid.¶
2. For every obtained manifest M[i], verify M[i].aid == chain[i].sub, verify the manifest signature using M[i].signature_kid, verify the DID portion of M[i].signature_kid equals M[i].granted_by, and verify that M[i].expires_at is in the future. If the AID binding, key binding, or signature check fails, reject with manifest_invalid. If the manifest is expired, reject with manifest_expired.¶
3. For every requested scope in aip_scope, verify that the scope is present in the scope array of every Principal Token in aip_chain and is granted by the leaf manifest M[n-1]. If any requested scope is absent from any chain token or from the leaf manifest, reject with insufficient_scope.¶
4. For every adjacent pair (M[i-1], M[i]) where i ranges from 1 to n-1, verify that the child manifest M[i] is a valid attenuation of the parent manifest M[i-1]. Every scope granted by M[i] MUST be present in M[i-1], and every child constraint for that scope MUST be equal to or more restrictive than the corresponding parent constraint. If a child scope is absent from the parent manifest, or if a child constraint is more permissive than the parent constraint, reject with insufficient_scope.¶

Constraint comparison MUST use the recursive attenuation semantics from Rule CO-1, treating the parent manifest constraint as the base value and the child manifest constraint as the overlay value. When the synced AIP Scope Catalog provides a non-null constraint_schema, both parent and child constraints MUST first validate against that schema. If schema validation fails, reject with manifest_invalid. Any violation at any adjacent pair is fatal to the chain. For example, a chain where M[0].transactions.max_single_transaction = 250, M[1].transactions.max_single_transaction = 300, and M[2].transactions.max_single_transaction = 200 is invalid at pair (M[0], M[1]), even though M[2] is more restrictive than M[1].¶

9.16. Step 9d: Grant Tier Conformance

Determine the operation's security Tier as the highest tier value among all requested aip_scope entries in the synced AIP Scope Catalog. For every Principal Token payload in aip_chain, retrieve the registered grant_tier from the Registry registration metadata for the AID identified by that payload's sub. The Relying Party MUST reject the request with grant_tier_insufficient if any participating AID's registered grant_tier is absent, unrecognised, or not permitted for the operation's security Tier.¶

The permitted runtime mappings are: Tier 1 permits G1, G2, or G3; Tier 2 permits G2 or G3; Tier 3 permits only G3. For Tier 2 and Tier 3, the root principal DID MUST use the did:web method. A higher-assurance Grant Tier MAY satisfy a lower security Tier, but a lower-assurance Grant Tier MUST NOT satisfy a higher security Tier.¶

If the operation's security Tier is 2 and the Registry's identity_proofing_required_for_tier2 metadata field is true, Tier 2 permits only G3 for this Registry. In that case, a participating AID registered with G2 MUST be rejected with grant_tier_insufficient.¶

9.17. Step 10: DPoP Validation (Conditional)

For this step, the operation's security Tier is the highest Tier among all requested scopes. A token containing one Tier 2 scope is a Tier 2 token for DPoP validation.¶

DPoP (Demonstration of Proof-of-Possession) MUST be verified when the operation's security Tier is 2 or 3, when any requested scope has requires_dpop: true in the synced AIP Scope Catalog, or when the requested Registry endpoint requires DPoP independently of scope metadata. A Tier 2 or Tier 3 operation requires DPoP even if every requested scope has requires_dpop: false.¶

If DPoP is required, the HTTP request MUST include a DPoP header containing a Demonstration of Proof-of-Possession proof JWT per [RFC9449]. Verify:¶

1. The DPoP proof is a valid JWT.¶
2. The htm (HTTP method) claim matches the HTTP method of the request.¶
3. The htu (HTTP URI) claim matches the absolute target URI of the current request after removing query and fragment components, with URI normalization performed as specified for DPoP in [RFC9449]. Because htu includes the target origin and path, a DPoP proof captured at one Relying Party or Registry MUST NOT validate at another Relying Party or Registry unless the normalized target URI is identical.¶
4. The ath claim is present and equals BASE64URL(SHA-256(token)), where token is the exact compact Credential Token or Step Execution Token value from the Authorization header after removing the authorization scheme and surrounding whitespace. When DPoP is required, the authorization scheme MUST be DPoP. The hash input MUST NOT include the authorization scheme, whitespace, or the DPoP proof itself.¶
5. The iat claim is within the verifier's accepted DPoP proof window. Unless the verifier requires a server-provided DPoP nonce per [RFC9449], the verifier MUST reject proofs whose iat is more than 300 seconds before receipt time or more than 30 seconds after receipt time. When a server-provided nonce is required, the verifier MUST validate the nonce claim and the server-managed nonce lifetime instead of extending acceptance based on a client-chosen future iat.¶
6. The jti has not been seen before (DPoP-specific replay cache, separate from Credential Token jti cache, keyed by (kid, jti)). The replay cache is local to the verifier and MUST retain entries for at least the accepted DPoP proof window, or for the server-provided nonce lifetime when nonce validation is used, whichever is longer. AIP does not require cross-Relying Party or cross-Registry synchronization of DPoP replay caches; cross-target replay prevention relies on the mandatory htm, htu, and ath checks above.¶
7. The public key in the jwk claim matches the effective actor's key material. For an agent-issued Credential Token, this is the agent key that signed the Credential Token. For a Step Execution Token, this is public key material controlled by the actor AID in sub; it is not the Registry step-execution key that signed the SET.¶

If DPoP validation fails at any step, reject with dpop_proof_required (if proof is missing) or invalid_token (if proof is malformed or invalid).¶

9.18. Step 10a: Approval Envelope Step Verification (Conditional)

This step applies only to Step Execution Tokens that have already passed the SET validation profile defined in this section. Agent-issued Credential Tokens MUST NOT be accepted for Approval Envelope step execution merely because they contain approval-related claims.¶

The Relying Party MUST call the SET issuer Registry endpoint identified by aip_step_kind. For aip_step_kind: "forward", call GET /v1/approvals/{aip_approval_id}/steps/{n} where {n} is the value of aip_approval_step verbatim. For aip_step_kind: "compensation", call GET /v1/approvals/{aip_approval_id}/compensation-steps/{n} where {n} is the value of aip_compensation_step verbatim. In either case the index is an integer >= 1 and MUST NOT be decremented or adjusted. Both aip_approval_step and aip_compensation_step use 1-based indexing; the first forward step in an envelope is step 1. This is a change from deprecated 0-indexed drafts. Verify:¶

1. Cancellation Status: If the Registry response indicates the Approval Envelope or referenced step has status "cancelled", reject with engagement_cancelled.¶
2. Step Status: The step's status field MUST be "claimed". If status is "pending", the step has not been claimed and cannot execute; reject with approval_step_not_claimed. If status is "completed", "failed", "compensated", "skipped", or "cancelled", reject with approval_step_invalid. Prerequisite failures are reported at claim time by the Registry using approval_step_prerequisites_unmet; a Relying Party that sees an unclaimed step during Step Execution Token verification treats it as a state conflict rather than an authorization denial.¶
3. Actor Match: The returned forward or compensation step's actor field MUST equal the Step Execution Token's sub (the actor AID). Reject if mismatch with approval_step_invalid.¶
4. Relying Party Match: The returned step's relying_party_uri MUST match the host of the current HTTP request (origin comparison per [RFC6454]: scheme + host + port). Reject if mismatch with approval_step_invalid.¶
5. Action Hash: Compute the expected action hash for this step per Section 13.7. Compare against the returned step's action_hash field. If mismatch, reject with approval_step_action_mismatch. This ensures the approving principal authorised the exact action being executed.¶
6. Scope Match: The Step Execution Token aip_scope set MUST be identical to the returned step's scopes set. Order is not significant for this comparison, but duplicate scope strings are invalid under the SET schema. If the sets differ, reject with approval_step_invalid.¶

9.19. Step 11: Tier 3 Enterprise Checks (Conditional)

This step applies only to Tier 3 enterprise deployments, which are declared and documented in the Registry's /v1/registry-metadata endpoint.¶

For Tier 3 operations:¶

1. mTLS Client Certificate: The HTTP connection MUST use mutual TLS. Validate the client certificate using the Tier 3 mTLS Certificate Profile in Section 21.7. The effective actor AID is the Credential Token iss for agent-issued Credential Tokens, or the Step Execution Token sub for SETs. If the client certificate is absent, reject with mtls_required. If certificate path validation, key usage, EKU, SAN uniqueness, or SAN-to-actor matching fails, reject with invalid_token.¶
2. OCSP Revocation Check: Perform an OCSP check per [RFC6960] on the client certificate to verify it has not been revoked at the transport layer, or perform the equivalent deployment-profile revocation check allowed by Section 21.7. If the certificate is revoked, reject with agent_revoked. If revocation status is unavailable, stale, or indeterminate, reject with invalid_token.¶

Step 11a. Principal Assertion Presence Check:

For Tier 3 agent-issued Credential Tokens, the Credential Token MUST contain an aip_principal_assertion claim. Absence MUST result in rejection with enterprise_assertion_missing.¶

Step 11b. Principal Assertion Signature Verification:

The Relying Party MUST resolve the iss claim of the aip_principal_assertion JWT to an OIDC provider configuration document and retrieve the provider's JWKS. The assertion signature MUST be verified against the matching kid in the JWKS. Failure MUST result in rejection with enterprise_assertion_invalid.¶

Step 11c. Principal Binding Check:

The sub claim of the verified aip_principal_assertion MUST match the root Principal Token's principal.id value in aip_chain[0]. A mismatch indicates that the agent is presenting human context that does not match its registered delegation chain and MUST result in rejection with enterprise_assertion_principal_mismatch.¶

If any Tier 3 check fails, reject with the appropriate error code (mtls_required, invalid_token, agent_revoked, enterprise_assertion_missing, enterprise_assertion_invalid, or enterprise_assertion_principal_mismatch).¶

9.20. Step 12: Accept

If all preceding steps pass without rejection, the Relying Party MUST accept the token and grant the requested access.¶

9.21. Step Execution Token Validation Profile

A Step Execution Token (SET) is a Registry-issued JWT. It MUST NOT be validated by applying Credential Token Step 2 and Step 3 literally, because its iss is the Registry ID and its kid is a Registry step-execution key URI, not a did:aip agent key. A Relying Party that receives a token for Approval Envelope step execution MUST use this profile before applying Step 10a.¶

1. Parse the token as a JWT per Step 1.¶
2. Decode the JOSE header and payload without using either for acceptance. The payload MUST conform to step-execution-token.schema.json. The iss claim MUST be an HTTPS Registry ID URI, sub MUST be the actor AID, and aip_approval_id and aip_step_kind MUST both be present. When aip_step_kind is "forward", aip_approval_step MUST be present and aip_compensation_step MUST be absent. When aip_step_kind is "compensation", aip_compensation_step MUST be present and aip_approval_step MUST be absent. If aip_registry is present, it MUST equal iss. If any of these checks fail, reject with invalid_token.¶
3. Validate the SET header. typ MUST be "AIP-SET+JWT", alg MUST be "EdDSA", and kid MUST be an HTTPS URI whose origin matches the iss Registry ID origin. The protected header MUST also contain integer aip_trv. If any check fails, reject with invalid_token.¶
4. Apply the expiration preflight from Step 2a.¶
5. Resolve the issuing Registry trust state from local pinned trust records only. The Relying Party MUST have previously completed first-contact bootstrap or sequential trust update for the iss Registry ID under Section 7.4.4 and Section 7.4.7.1. It MUST select the locally retained Registry Trust Record whose signed.registry_id equals iss and whose signed.version equals the SET protected header aip_trv. The Relying Party MUST NOT fetch /v1/registry-metadata or a Registry Trust Record during SET validation to establish trust for the SET being validated. If no matching pinned trust record exists, or if the pinned trust record is expired and has not already been refreshed by a completed trust-update procedure, reject with registry_untrusted.¶
6. The SET header kid MUST exactly match the keyid of a JWK listed in active_verification_keys.step_execution of the accepted Registry Trust Record version. If no such key is listed, reject with invalid_token.¶
7. Verify the SET signature using the matched step-execution JWK. If signature verification fails, reject with invalid_token.¶
8. Apply Steps 5a through 5f and Step 6 to the SET common claims. Step 5g is replaced for SETs by the following SET-specific binding: the payload iss MUST be the HTTPS Registry ID whose pinned Registry Trust Record was selected by protected header aip_trv; the payload sub MUST match the did:aip ABNF and identify the actor AID; and the protected header kid MUST identify a Registry step-execution key listed in that selected Trust Record. The SET replay cache is keyed by (iss, jti), where iss is the Registry ID. A Registry MUST generate SET jti values that are unique within that Registry ID across all issued Step Execution Tokens. Registry complete/fail endpoints MAY return a stored idempotent response for an exact retry of a previously completed transition, but MUST NOT re-execute the transition or accept a replayed SET as fresh authority.¶
9. Apply Step 6a when required, treating the SET issuer Registry iss as the Registry whose trust anchor is being verified. For Tier 2 or Tier 3 operations, or whenever aip_registry is present, the root principal DID Document's AIPRegistry service endpoint MUST match the SET issuer Registry by origin comparison.¶
10. Apply Step 6b to any aip_engagement_id, using sub as the actor AID whose engagement participation is being checked.¶
11. Apply Step 7 to the actor AID in sub, not to the Registry ID in iss. Apply Step 8 to aip_chain, except that Step 8 Post-Check A and B are replaced by the rule that aip_chain[n-1].sub MUST equal the SET sub.¶
12. Apply Steps 9 through 9d using the actor AID in sub as the effective agent AID for manifest lookup, scope verification, delegation inheritance, and Grant Tier Conformance.¶
13. Apply Step 10 when DPoP is required. For SETs, the DPoP proof key MUST match public key material controlled by the actor AID in sub, not the Registry step-execution key that signed the SET.¶
14. Apply Step 10a, Step 11 using sub as the effective actor AID, and Step 12.¶

A token with typ: "AIP+JWT" MUST NOT be accepted as a Step Execution Token. A token with typ: "AIP-SET+JWT" MUST NOT be accepted as an agent-issued Credential Token. This type separation prevents substitution between agent-issued and Registry-issued authorisation artifacts.¶

10.1. Delegation Chain

Every Credential Token MUST include a verifiable principal chain linking the acting agent to its root principal via the aip_chain array. The root principal MUST be a human or organizational entity identified by a W3C Decentralized Identifier (DID) that does NOT use the did:aip method. Subject to the Tier-specific Principal DID Method requirements in Section 20, did:web, did:key, or proprietary DID methods can be acceptable for Tier 1.¶

The maximum delegation depth is a hard constraint of 10. Delegation depth is the zero-based delegation_depth value carried in each Principal Token and MUST equal that token's index in the aip_chain array. A valid chain therefore contains at most 11 Principal Tokens: indexes 0 through 10. An agent MUST NOT delegate to a sub-agent if doing so would create a token with delegation_depth greater than 10 or an aip_chain longer than 11 elements.¶

An agent MUST NOT delegate to itself. For every delegated Principal Token with delegation_depth greater than 0, the delegated_by AID MUST identify the immediate parent agent and MUST NOT equal the token's sub AID. Relying Parties enforce this prohibition during Step 8e and Step 8g of Credential Token validation.¶

The default value of max_delegation_depth MUST NOT exceed 3. When a Principal Token does not explicitly set max_delegation_depth, implementations MUST treat the default as 3. This conservative default prevents accidental authorization chains from becoming unmanageably deep; parties requiring deeper chains MUST explicitly opt in by setting max_delegation_depth to a value greater than 3 and no greater than 10.¶

10.2. Capability Scope Rules

Scope inheritance is the mechanism by which child agents are constrained to operate within the bounds of their parent's authorization. Five core rules (D-1 through D-5) govern this relationship; they are defined in Section 5.10 of the AIP specification.¶

Scope Inheritance Rule: For each scope s granted to a child agent, s MUST be present in the parent's Capability Manifest AND all constraint values for s in the child's manifest MUST be equal to or more restrictive than the corresponding values in the parent's manifest.¶

Constraint comparison uses the recursive attenuation semantics from Rule CO-1. Numeric caps and thresholds use the ordering defined for that field; booleans, arrays, strings, enums, omitted fields, and unknown types follow the type-specific CO-1 rules.¶

Implementations MUST enforce this rule at delegation time -- when a child agent is registered, the Registry MUST validate that all scopes in its Capability Manifest satisfy the inheritance rule relative to its immediate parent's manifest. Implementations MAY reject delegation requests that violate this rule before they are registered.¶

Relying Parties MUST independently verify this rule during validation using the ordered Step 9c algorithm in the Credential Token validation algorithm (see Section 9.15). This ensures that even if a Registry incorrectly permits a violating delegation, Relying Parties will catch it and reject the token.¶

10.3. Delegation Validation

When validating a delegated Credential Token, Relying Parties MUST fetch and verify the Capability Manifests of all agents in the delegation chain. This section specifies the performance and caching constraints for these operations.¶

Ancestor Manifest Fetch Limits: Implementations MUST NOT fetch more ancestor manifests than the max_delegation_depth value of the chain's root token (which defaults to 3 when absent). This limit prevents accidental O(n^2) fetch patterns in deep delegation chains and bounds the performance cost of validation.¶

Ancestor Manifest Caching for Tier 1: For Tier 1 operations (low-risk scopes with bounded-staleness threat model), ancestor manifests MAY be cached for a maximum of 60 seconds. This cache is per-agent and per-manifest, and MUST respect the 60-second TTL. After 60 seconds, the Relying Party MUST fetch a fresh manifest.¶

No-Cache Requirement for Tier 2: For Tier 2 operations (high-risk scopes with real-time threat model), the no-cache requirement in the Credential Token validation algorithm (see Section 9.15) applies to ALL manifests in the delegation chain -- including ancestor manifests -- not only the leaf agent's manifest. The 60-second ancestor cache MUST NOT be used for any manifest appearing in a Tier 2 validation. Every manifest MUST be fetched fresh from the Registry.¶

Unavailable Manifests: If an ancestor manifest is unavailable or cannot be fetched (due to network failure, Registry downtime, or the manifest having been deleted), the Relying Party MUST reject the token by returning the error code manifest_invalid. Partial delegation chains are not acceptable; either all manifests in the chain are available and valid, or the token is rejected.¶

10.4. Delegated Identity Chaining for A2A Workflows

Agent-to-agent asynchronous workflows require Relying Parties to distinguish the acting agent from the originating agent that delegated the work. When Agent B makes a tool call on behalf of Agent A, Agent B's Credential Token MUST carry both identities using the profile in this section.¶

1

Agent B's Credential Token aip_chain array MUST include Agent A's Principal Token as an additional chain element after Agent B's own root Principal Token.¶

2

The aip_scope in Agent B's Credential Token MUST be a strict subset of the scopes granted in Agent A's Capability Manifest. Rule D-1 enforces this at delegation time; this rule applies the same attenuation requirement to the presented Credential Token.¶

3

When Agent B is acting in a delegated A2A context, Agent B's Credential Token MUST include the aip_originator_aid claim. The value of aip_originator_aid MUST be Agent A's AID: the AID of the agent that initiated the workflow and delegated the task to Agent B. The aip_originator_aid value MUST conform to the did:aip ABNF defined in Section 4.1. The aip_originator_aid value MUST NOT equal the sub claim of Agent B's Credential Token. When aip_originator_aid is present but does not meet these constraints, the Relying Party MUST reject the request with a2a_originator_invalid.¶

4

Relying Parties MAY use aip_originator_aid to apply originator-level access policies and to index audit events by the originating agent. Full chain validation under Section 9.11 remains REQUIRED for every accepted Credential Token.¶

5

Relying Parties receiving a Credential Token that contains aip_originator_aid MUST perform the following validation:¶

1. Verify aip_originator_aid conforms to the did:aip ABNF in Section 4.1. If not, reject with a2a_originator_invalid.¶
2. Verify aip_originator_aid does not equal the Credential Token sub claim. If equal, reject with a2a_originator_invalid.¶
3. Verify aip_originator_aid appears as the sub of aip_chain[0] or as a registered AID in the validated delegation chain, so that Agent A is demonstrably the originator of the chain. If no such binding exists, reject with a2a_originator_invalid.¶
4. Relying Parties MAY use aip_originator_aid to apply originator-level access policies and audit classification for the already validated request context. Every new Credential Token or Step Execution Token presented on a downstream call MUST still pass the full validation algorithm, including Section 9.11.¶

This profile aligns with RFC 8693 actor-token semantics: the signing Credential Token identifies the current actor, while aip_originator_aid and the additional Principal Token context allow enterprise audit systems to attribute tool calls to the originating agent chain.¶

Relying Parties that support enterprise audit logging SHOULD record aip_originator_aid in their audit trail as the chain originator for all A2A tool calls.¶

11.1. Revocation Object

Revocation is performed by submitting a signed Revocation Object to POST /v1/revocations. The Revocation Object fields, required members, type enum, and signing input are defined only in Section 5.7. This section defines processing effects for accepted Revocation Objects; it does not define a second Revocation Object schema.¶

A principal_revoke with a Principal DID target invalidates every Credential Token and Step Execution Token whose aip_chain[0].principal.id equals that Principal DID. A principal_revoke with an AID target invalidates every token whose aip_chain depends on that AID's principal authorisation. This effect is independent of propagate_to_children. The propagate_to_children flag controls whether the Registry also materialises descendant Revocation Objects; it does not limit the validity effect of principal_revoke.¶

11.2. Revocation Submission Validation

A conformant Registry MUST implement POST /v1/revocations for externally submitted Revocation Objects. The request body MUST be a JSON object conforming to revocation-object.schema.json. Unless a check below specifies a more precise error code, failed validation MUST be rejected with revocation_invalid.¶

The Registry MUST perform the following checks in order:¶

1. The request MUST use Content-Type: application/json. The object MUST contain all required Revocation Object members, including kid. If propagate_to_children is absent, the Registry MUST process it as false.¶
2. If revocation_id was already accepted, the Registry MUST compare the Section 2.1 canonical JSON serialization of the submitted object to the stored object. If they are identical, the Registry MUST return HTTP 200 with the stored Revocation Object and MUST NOT apply side effects again. If they differ, the Registry MUST reject with revocation_conflict.¶
3. The timestamp value MUST be a valid UTC date-time and MUST NOT be more than 300 seconds in the future relative to the Registry's current clock. Registries MAY accept older timestamps, but the revocation_id uniqueness check remains mandatory.¶
4. The reason value MUST be one of the reason codes in the Revocation Object schema. Externally submitted Revocation Objects MUST NOT use parent_revoked, heartbeat_timeout, or lifecycle_expired; those reason codes are reserved for Registry-generated Revocation Objects.¶
5. For full_revoke, scope_revoke, and delegation_revoke, target_id MUST be a registered did:aip AID in the authoritative Registry. Unknown targets MUST be rejected with unknown_aid. For principal_revoke, target_id MUST be either a registered AID or a Principal DID associated with at least one stored registration in that Registry.¶
6. For scope_revoke, scopes_revoked MUST be present and non-empty, and every entry MUST be an active synced AIP Scope Catalog scope or an accepted local/private extension scope that is currently granted by the target's effective Capability Manifest. Invalid scope entries MUST be rejected with invalid_scope. For all other revocation types, scopes_revoked MUST be absent.¶
7. The Registry MUST construct the target authorization chain from its registration records. That chain consists of the target's root Principal DID and every ancestor AID recorded through the parent-child delegation index. For full_revoke, scope_revoke, and delegation_revoke, issued_by MUST equal either the target's root Principal DID or an ancestor AID in that chain. For principal_revoke targeting a Principal DID, issued_by MUST equal that Principal DID. For principal_revoke targeting an AID, issued_by MUST equal the target AID's root Principal DID. Unauthorized issuers MUST be rejected with revocation_unauthorized.¶
8. For a DID issuer, kid MUST be a DID URL whose DID portion equals issued_by. The Registry MUST resolve the DID, locate the Ed25519 verification method named by kid, and verify the Revocation Object signature over the Section 5.7 signing input. For a did:aip issuer, the key lookup MUST use the authoritative Registry public-key endpoint for the referenced AID and key version. If the key cannot be resolved, is not Ed25519, is not controlled by issued_by, or the signature fails, the Registry MUST reject with revocation_invalid.¶

Registry-generated Revocation Objects are not externally submitted through the public POST /v1/revocations endpoint. For parent_revoked, heartbeat_timeout, and lifecycle_expired, the Registry MUST set issued_by to its registry_id, set kid to a JWK listed in active_verification_keys.crl of the Registry Trust Record current at the Revocation Object timestamp, and sign the object with the corresponding private key.¶

Acceptance MUST be atomic. On success, the Registry MUST store the Revocation Object immutably, update live revocation status, schedule CRL publication within the 15-minute freshness window defined in Section 11.3, and return HTTP 201 with Content-Type: application/json and the stored Revocation Object. If propagate_to_children is true, the Registry MUST recursively materialise child Revocation Objects with reason parent_revoked within 15 seconds. For principal_revoke, token invalidation does not depend on materialised child objects; propagation only adds audit and index records.¶

11.3. Certificate Revocation List (CRL)

The Registry MUST expose a canonical origin CRL endpoint at GET /v1/crl and MUST publish the preferred CRL retrieval URI as endpoints.crl in both /v1/registry-metadata and the signed Registry Trust Record. The published endpoints.crl value MAY be /v1/crl or an absolute HTTPS URI for a CDN or distributed object store. Relying Parties MUST retrieve CRL documents from the accepted Registry Trust Record's signed.endpoints.crl value rather than assuming registry_id + "/v1/crl".¶

The CRL MUST be updated within 15 minutes of a new Revocation Object being accepted. The published CRL retrieval URI MUST be served from a CDN or distributed infrastructure. CDN and object-store distribution is not a trust anchor: CRL documents MUST be signed by a JWK listed in active_verification_keys.crl of the Registry Trust Record version current at issuance time.¶

The CRL is an AIP signed JSON document, not an X.509 CRL. A successful CRL response MUST use Content-Type: application/aip-crl+json and MUST conform to crl.schema.json. The top-level object MUST contain signed and signatures. The signed object MUST include registry_id, trust_record_version, crl_id, issued_at, next_update, sequence, publication_mode, revocation_count, and revocations. The publication_mode value MUST be "complete", "index", or "segment". In "complete" mode, the revocations array contains the full signed Revocation Objects active for bounded-staleness validation at issued_at. In "index" mode, the revocations array MUST be empty and the signed object MUST contain segments as defined in Section 17.11. In "segment" mode, the revocations array contains only the Revocation Objects assigned to that segment, and the signed object MUST contain segment_id.¶

The CRL signing input is the RFC 8785 JSON Canonicalization Scheme (JCS) serialization of the signed object only. Each signature entry MUST contain keyid and sig. The keyid MUST match a JWK keyid in active_verification_keys.crl for the Registry Trust Record whose signed.version equals the CRL signed.trust_record_version. The signature algorithm is EdDSA over Ed25519. A Relying Party MUST reject an unsigned, malformed, or unverifiable CRL and MUST NOT treat CDN integrity, TLS termination, or object-store metadata as a substitute for this signature verification.¶

CRL consumers MUST verify that signed.registry_id equals the accepted Registry Trust Record's signed.registry_id, that signed.trust_record_version identifies an accepted Registry Trust Record, and that at least one signature verifies under that trust record's active_verification_keys.crl. The next_update timestamp MUST be no later than 15 minutes after issued_at. Relying Parties MUST NOT use a CRL for new token validations after next_update; if no fresh verifiable CRL is available when one is required, validation MUST fail with registry_unavailable.¶

CRL documents MUST include active principal_revoke entries by target_id. For Tier 1 validation, Relying Parties MUST check principal_revoke entries whose target_id equals the token's root Principal DID and entries whose target_id equals any AID in the token's validated aip_chain. A matching principal_revoke is equivalent to agent_revoked for that token.¶

11.4. Revocation Checking

A token's Tier is determined by its highest-risk scope. A token with one Tier 2 scope and any number of Tier 1 scopes is a Tier 2 token.¶

Tier 1 - Bounded-staleness: The Credential Token TTL is the effective catalog-derived TTL defined in Section 8.2. Relying Parties validate revocation status at request validation time using a verifiable CRL whose next_update has not passed. A Relying Party MUST refresh its cached CRL before using it for new validations after next_update.¶

Tier 2 - Real-time revocation: Applies when the highest synced AIP Scope Catalog tier among requested scopes is 2. Real-time Registry check on EVERY request. MUST NOT cache revocation status. DPoP MUST be verified for the request regardless of per-scope requires_dpop metadata. If Registry unreachable: MUST deny and return registry_unavailable.¶

The live Tier 2 lookup uses GET /v1/agents/{aid}/revocation. A registered AID returns HTTP 200 whether or not it is revoked. The response body is the Revocation Status response defined in Section 17.9. Unknown AIDs return unknown_aid (HTTP 404).¶

Tier 3 - Enterprise: MUST use mTLS. MUST support OCSP per RFC 6960. Tier 3 supplements, not replaces, Tier 2.¶

Child Agent Propagation: When the Registry processes a Revocation Object with propagate_to_children: true, the Registry MUST recursively revoke descendants within 15 seconds. A principal_revoke invalidates dependent tokens regardless of this flag; propagation only controls whether descendant Revocation Objects are written for indexing, CRL compactness, and auditability.¶

Replica Registries MUST synchronise within 45 seconds. Combined end-to-end propagation MUST NOT exceed 60 seconds.¶

Approval Envelope interaction: When an agent AID is revoked, the Registry MUST transition all Approval Envelopes in pending_approval, approved, or executing status to failed. Unclaimed steps for that actor MUST be marked failed. In-progress claims MUST be treated as failed; the Registry MUST initiate compensation if applicable.¶

11.5. Registry Push Notification Protocol (RPNP)

RPNP is an OPTIONAL Registry capability for real-time revocation event delivery.¶

X-AIP-Signature: <sig-header>

sig-header = "v1;t=" timestamp ";kid=" subscription-id ";h=" hmac

12.1. Overview and Roles

The AIP-GRANT ceremony involves three actors:¶

Agent Deployer

The party that constructs the GrantRequest and submits the Registration Envelope to the Registry. The deployer generates the agent's Ed25519 keypair before initiating the grant and may be the principal themselves or a service acting on the principal's behalf.¶

Principal Wallet

Software that holds the principal's DID private key and executes the signing ceremony. The Principal Wallet MUST verify the deployer's signature and MUST obtain explicit human approval before signing.¶

AIP Registry

The service that accepts the Registration Envelope. The Registry's role is defined in Section 17; it is not modified by AIP-GRANT.¶

The basic flow:¶

   Agent Deployer      Principal Wallet      AIP Registry
         |                     |                  |
         |-- GrantRequest ---->|                  |
         | (agent_aid,         |                  |
         |  capabilities,      |                  |
         |  purpose, nonce)    |                  |
         |                     |                  |
         |             [Display consent UI]       |
         |           [Human reviews & signs]      |
         |                     |                  |
         |<-- GrantResponse ---|                  |
         | (signed             |                  |
         |  PrincipalToken)    |                  |
         |                     |                  |
         |-- Registration Envelope -------------->|
         | (identity + manifest +                 |
         |  principal_token)                      |
         |                                        |
         |<-- AID --------------------------------|

12.2. GrantRequest Object

The GrantRequest is a JSON object constructed by the Agent Deployer. It MUST be signed by the deployer's Ed25519 key when transmitted over the Web Redirect or QR Code bindings. For G2, the signed request MUST identify the deployer through the deployer_did field and the signature key MUST be bound to that DID. The nonce MUST be cryptographically random and MUST contain at least 128 bits of entropy.¶

The request MUST also include deployer_name for consent UI display. The deployer_name value is human-readable metadata only; it is not a trust anchor and MUST NOT replace verification of deployer_did and the signed GrantRequest envelope.¶

GrantRequest Fields:¶

grant_request_id (string; REQUIRED)

pattern: gr:<UUIDv4-lowerhex>¶

aip_version (string; REQUIRED)

AIP protocol compatibility version; MUST be "0.3"; not the Internet-Draft revision¶

agent_aid (string; REQUIRED)

MUST match did:aip ABNF; pre-derived AID of the agent being authorised; Principal Token sub MUST equal this value¶

agent_name (string; REQUIRED)

maxLength: 64; displayed in consent UI¶

agent_type (string; REQUIRED)

registered namespace value¶

model.provider (string; REQUIRED)

displayed in consent UI¶

model.model_id (string; REQUIRED)

displayed in consent UI¶

requested_capabilities (object; REQUIRED)

Capability Manifest capabilities sub-schema¶

purpose (string; REQUIRED)

minLength: 1; maxLength: 512¶

delegation_valid_for_seconds (integer; REQUIRED)

requested maximum delegation lifetime; min: 300; max: 31536000; approved value MUST NOT exceed this value¶

nonce (string; REQUIRED)

minLength: 22; cryptographically random¶

request_expires_at (string; REQUIRED)

ISO 8601 UTC¶

callback_uri (string; CONDITIONAL)

REQUIRED for Web Redirect and G3 OAuth authorization requests; MUST use HTTPS; for G3, MUST equal the OAuth redirect_uri¶

state (string; CONDITIONAL)

REQUIRED for G3 OAuth authorization requests; echoed unchanged and MUST equal the OAuth state parameter¶

deployer_did (string; REQUIRED)

W3C DID of the deployer; used to verify signed GrantRequests and displayed in consent UI¶

deployer_name (string; REQUIRED)

minLength: 1; maxLength: 128; displayed alongside deployer_did; display metadata only, not a trust anchor¶

deployer_public_key (object; OPTIONAL)

JWK key hint only; MUST match the verification method resolved from deployer_did and MUST NOT replace DID resolution¶

The deployer MUST generate the agent's AID before constructing the GrantRequest and MUST include that value as agent_aid. The Principal Token produced from this grant MUST use the original GrantRequest agent_aid as its sub claim.¶

Signed GrantRequest envelope: A GrantRequest sent directly to a Principal Wallet using the Web Redirect or QR Code binding MUST be carried as a compact JWS whose payload is the UTF-8 JSON serialization of the GrantRequest object. The protected JWS header MUST contain typ equal to "aip-grant+jws", alg equal to "EdDSA", and kid as a DID URL. The DID portion of kid MUST equal the GrantRequest deployer_did. The referenced verification method MUST resolve from the deployer_did DID Document, MUST be controlled by deployer_did, and MUST be an Ed25519 signing key. If deployer_public_key is present, it is a cache hint only; the Principal Wallet MUST verify that it is byte-for-byte equivalent to the resolved verification method before using it and MUST NOT trust a self-supplied key that is not present in the resolved DID Document.¶

The same signed GrantRequest envelope format is used by the G3 OAuth binding. In that case, the compact JWS is carried in the aip_grant_request authorization request parameter and is verified by the Registry acting as OAuth Authorization Server before any authentication or consent ceremony is started.¶

12.3. Principal Wallet Consent Requirements

The Principal Wallet MUST implement the following requirements before signing any grant.¶

Nonce and expiry checks: The Principal Wallet MUST check request_expires_at against the current clock. If expired, it MUST reject with grant_request_expired and MUST NOT show the consent UI. The Principal Wallet MUST maintain a record of seen grant_request_id values for at least 30 days and MUST reject replays with grant_request_replayed.¶

The Principal Wallet MUST use its own reliable UTC clock for request_expires_at checks and MAY allow a 30-second clock skew tolerance. If the Principal Wallet's current time is more than 30 seconds after request_expires_at, the request is expired. If the Principal Wallet cannot determine reliable current UTC time, it MUST reject with grant_request_invalid rather than issuing a back-dated or future-dated Principal Token.¶

Signed request checks: For a G2 GrantRequest, the Principal Wallet MUST verify the signed GrantRequest envelope before displaying the consent UI. The Principal Wallet MUST reject with grant_request_invalid and MUST NOT show the consent UI if the request is unsigned, if deployer_did is absent, if the JWS kid DID does not equal deployer_did, if the deployer DID cannot be resolved, if the referenced key is not an Ed25519 signing key controlled by deployer_did, or if the JWS signature verification fails.¶

Mandatory display elements: The consent UI MUST display ALL of the following before presenting the sign/decline choice:¶

1. Agent name (agent_name) and type (agent_type)¶
2. AI model - provider and model_id¶
3. Purpose - the purpose field verbatim¶
4. Deployer identity - deployer_name and deployer_did¶
5. All requested capabilities using trusted AIP Scope Catalog display metadata¶
6. Delegation validity - requested duration and the approximate expiry computed from delegation_valid_for_seconds using the Principal Wallet's current UTC clock¶
7. Destructive Operations: Any scope whose active AIP Scope Catalog entry has destructive: true MUST be highlighted in the UI using the mandatory two-step confirmation flow required for Principal Wallet conformance in Section 23.2.¶

Before displaying the consent UI, the Principal Wallet MUST resolve requested_capabilities to the concrete requested scope identifiers using the scope-to-capability rules in Section 5.9 and any explicit private extension policy accepted by the Principal Wallet. The Principal Wallet MUST use a trusted immutable AIP Scope Catalog Snapshot for this resolution. For each requested scope, the Principal Wallet MUST find an active or experimental scope entry and MUST find complete trusted display metadata for the Principal Wallet's selected locale or for the entry's display.default_locale. If no trusted catalog snapshot is available, if a requested capability cannot be resolved to a concrete scope identifier, if the scope entry is unknown, removed, reserved, or outside an accepted private extension policy, or if the required display metadata is absent or incomplete, the Principal Wallet MUST reject with grant_request_invalid and MUST NOT show the consent UI.¶

The Principal Wallet MUST NOT synthesize consent text from raw scope identifiers, capability field names, deployer-supplied display strings, generic family names, or untrusted catalog data. The title value in display.strings[locale].title is the canonical human-readable capability string for that locale. The Principal Wallet MAY also display display.strings[locale].summary, but it MUST NOT use the summary to replace or weaken required destructive-operation highlighting.¶

If an issued Principal Token includes a purpose claim, the claim value MUST be either the exact GrantRequest purpose value or a shorter summary that was displayed to and approved by the principal before signing. A Principal Token issuer MUST NOT include a deployer-supplied or issuer-generated purpose claim that was not presented during consent.¶

Principal Token signing profile: For a root Principal Token, the token issuer is always the root principal identified by principal.id. A Principal Wallet or other principal-controlled signing component that constructs a root Principal Token after consent MUST sign the JWT with EdDSA, MUST set iss to principal.id, and MUST use a JOSE header kid identifying an Ed25519 verification method controlled by principal.id. A Registry or authorization server MAY prepare the payload, mediate consent, collect high-assurance authentication context, store the GrantResponse, or deliver the signed token, but it MUST NOT sign a root Principal Token with a Registry-controlled or authorization-server-controlled key and MUST NOT set iss to the Registry or authorization server. The Principal Token payload sub claim MUST equal the agent_aid value from the original GrantRequest. A service that cannot obtain a principal-controlled Ed25519 signature MUST NOT issue a root Principal Token with that principal as iss.¶

Delegation expiry derivation: The Principal Token issuer MUST compute a single issuance timestamp from its current reliable UTC clock at the moment of signing. It MUST set the Principal Token issued_at claim and the GrantResponse signed_at field to that same instant. The approved delegation lifetime MUST be represented as approved_delegation_valid_for_seconds, MUST be at least 300 seconds, and MUST NOT exceed the original GrantRequest delegation_valid_for_seconds. The issuer MAY approve a shorter lifetime than requested.¶

The Principal Token expires_at claim MUST equal issued_at plus approved_delegation_valid_for_seconds seconds. No clock skew tolerance is applied to this calculation; clock skew tolerance applies only when validators compare timestamps to their local current time. The issuer MUST NOT use the deployer's clock, callback receipt time, or request_expires_at as the Principal Token issued_at value.¶

Draft-02 Catalog display metadata:¶

The AIP Scope Catalog is the normative source of capability display metadata. Each scope entry's display member is defined in Section 17.16. For standard Draft-02 scopes, display.strings["en-US"].title MUST equal the display string listed below. The corresponding summary value MUST be non-empty and MUST describe the same capability without broadening the authorization represented by the scope. Extension and private scopes MUST provide equivalent catalog display metadata through their catalog entry or accepted private extension policy before a Principal Wallet can present consent for them.¶

12.4. GrantResponse Object

The GrantResponse is constructed and signed by the Principal Wallet after the principal approves, partially approves, or declines the signing ceremony.¶

A GrantResponse with status "approved" or "partial" MUST also include approved_delegation_valid_for_seconds. The value MUST be an integer from 300 through the original GrantRequest delegation_valid_for_seconds, inclusive, and is used to derive the Principal Token expires_at claim.¶

Deployer validation of GrantResponse: Upon receipt the deployer MUST:¶

1. Verify grant_request_id matches the original request¶
2. Verify nonce matches. If mismatch, the deployer MUST reject the GrantResponse with grant_nonce_mismatch; the mismatch MUST be treated as a forgery attempt and no agent is registered.¶
3. If status is "rejected", the deployer MUST treat the grant as a terminal failure with grant_rejected_by_principal and no agent is registered.¶
4. Verify approved_delegation_valid_for_seconds is present for "approved" or "partial" responses, is at least 300 seconds, and does not exceed the original GrantRequest delegation_valid_for_seconds¶
5. Decode and verify the principal_token JWT signature¶
6. Verify the principal_token payload sub exactly matches agent_aid from the original GrantRequest¶
7. Verify the principal_token payload issued_at represents the same instant as the GrantResponse signed_at¶
8. Verify signed_at and issued_at are not more than 30 seconds in the future relative to the deployer's current UTC clock, and that signed_at is not more than 24 hours in the past¶
9. Verify the principal_token payload expires_at equals issued_at plus approved_delegation_valid_for_seconds seconds¶

If any GrantResponse validation check fails, the deployer MUST treat the GrantResponse as invalid and MUST NOT submit a Registration Envelope based on it.¶

When a deployer, Registry, Principal Wallet, or authorization server returns an AIP error response for a rejected grant, the error code MUST be grant_rejected_by_principal. When it returns an AIP error response for a GrantResponse whose nonce does not match the original GrantRequest, the error code MUST be grant_nonce_mismatch.¶

12.5. Transport Bindings

Implementations MUST support the Web Redirect Flow.¶

Web Redirect Flow:¶

https://wallet.example.com/aip-grant
  ?request=<compact-JWS-signed-GrantRequest>
  &aip_version=0.3

After the principal signs, the Principal Wallet delivers the GrantResponse:¶

POST <callback_uri>
Content-Type: application/json

{GrantResponse JSON}

The callback_uri MUST be pre-registered by the deployer. Principal Wallets MUST NOT deliver GrantResponses to unregistered URIs.¶

12.6. Sub-Agent Delegation Flow

When a parent agent delegates to a child agent, the parent acts as the delegation issuer for the child. No new human consent UI is required, because the parent can only delegate scopes and constraints that are already within its own accepted authority.¶

The child is registered with a delegated Principal Token, not a second root Principal Token. The delegated token's sub is the child AID, delegated_by is the parent AID, and delegation_depth is the parent's depth plus one. The Registry validates the submitted Registration Envelope using Registration Check 9 and stores the reconstructed parent-plus-child chain for later runtime validation.¶

The parent agent MUST:¶

1. Verify requested child capabilities are a strict subset of its own Capability Manifest (Rule D-1)¶
2. Generate a fresh Ed25519 keypair for the child agent¶
3. Construct and sign the child's Principal Token¶
4. Construct the Registration Envelope for the child¶
5. Submit the Registration Envelope to the Registry¶
6. Provision the child's private key through a secure channel¶

The parent MUST NOT retain the child's private key after successful provisioning. Retaining the child's private key enables the parent to forge Credential Tokens in the child's name and constitutes a violation of the principle of least privilege. This is a local implementation conformance and key-management requirement. The Registry and Relying Parties cannot determine from protocol messages whether the parent retained a copy of the child's private key, and MUST NOT treat private-key deletion as a Registry acceptance check or Credential Token validation precondition. Deployment profiles that audit this requirement MUST collect the sub-agent provisioning and deletion evidence defined in Section 21.4.¶

For sub-agent delegation, a parent agent MAY include a purpose claim in the child's Principal Token to describe the delegated work. That claim is signed audit metadata only. It MUST NOT expand the child agent's scopes or constraints and MUST NOT be treated by Relying Parties as a substitute for Capability Manifest or Approval Envelope validation.¶

12.7. AIP-GRANT Error Codes

12.8. G1: Registry-Mediated Grant Flow

The G1 (Registry-Mediated) grant profile is designed for consumer deployments where the agent deployer does not operate its own Principal Wallet integration. The AIP Registry brokers the consent ceremony on the deployer's behalf.¶

Actors: Agent Deployer, AIP Registry, Principal (via Registry-hosted or redirected Principal Wallet consent UI).¶

      Deployer               Registry              Principal
         |                      |                      |
         |-- POST /v1/grants -->|                      |
         |  (GrantRequest +     |                      |
         |   callback_uri)      |                      |
         |<-- 201 grant_id + ---|                      |
         |    wallet_redirect   |                      |
         |                      |                      |
         |-- [redirect principal to Principal Wallet URI] ------>|
         |                      |                      |
         |                      |<--- authenticates ---|
         |                      |<-- approve/decline --|
         |                      |                      |
         | [Principal-controlled signer signs token]   |
         |                      |                      |
         |<--- POST callback ---|                      |
         |    (GrantResponse)   |                      |
         |                      |                      |
         |-- GET /v1/grants/id->|                      |
         |<--- GrantResponse ---|                      |

Step-by-step definition:¶

1. The deployer generates the agent's Ed25519 keypair and constructs a GrantRequest. For G1, callback_uri is REQUIRED.¶
2. The deployer calls POST /v1/grants. See example response.¶
3. The deployer redirects the principal to wallet_redirect_uri. The Registry presents a consent UI.¶
4. On approval, the Registry MUST obtain a root Principal Token signed using the Principal Token signing profile above, with iss equal to the approving principal's DID and sub equal to the stored GrantRequest agent_aid. The Registry MAY construct the unsigned payload and present it to a principal-controlled Principal Wallet or signing component, but the final compact JWT MUST be signed by an Ed25519 verification method controlled by principal.id. The Registry MUST store the resulting GrantResponse without altering or re-signing the Principal Token.¶
5. The deployer receives the GrantResponse and submits the Registration Envelope to POST /v1/agents with grant_tier: "G1".¶

GET /v1/grants/{grant_id} authorisation: Only the deployer whose deployer_did appears in the original GrantRequest MUST be permitted to retrieve the GrantResponse.¶

If grant_id does not identify a stored G1 grant, or if the referenced grant is expired and no GrantResponse is retrievable, the Registry MUST reject the request with grant_not_found.¶

If grant_id identifies a stored, retrievable G1 grant but the authenticated requester does not match the deployer_did in the original GrantRequest, the Registry MUST reject the request with grant_deployer_mismatch.¶

If grant_id identifies a stored G1 grant whose principal outcome is "rejected", the Registry MUST reject the retrieval request with grant_rejected_by_principal. If the stored GrantResponse nonce does not match the original GrantRequest nonce, the Registry MUST reject the retrieval request with grant_nonce_mismatch and MUST NOT return the stored GrantResponse.¶

12.9. G2: Direct Deployer Grant Flow

The G2 (Direct Deployer) grant profile is the standard flow for applications that integrate directly with Principal Wallets. The deployer signs the GrantRequest directly and transmits it to the Principal Wallet via a front-channel binding (Web Redirect or QR Code).¶

Actors: Agent Deployer, Principal Wallet, Principal.¶

Step-by-step definition:¶

1. The deployer generates the agent's Ed25519 keypair, derives the agent AID, and constructs a GrantRequest that includes agent_aid and deployer_did.¶
2. The deployer signs the GrantRequest as a compact JWS using the Ed25519 key identified by a kid under deployer_did.¶
3. The deployer transmits the request to the Principal Wallet via a front-channel binding.¶
4. The Principal Wallet resolves deployer_did, verifies the signed GrantRequest envelope, and presents the consent UI to the principal only after successful verification.¶
5. On approval, the Principal Wallet signs the Principal Token using the Principal Token signing profile above and returns a GrantResponse to the deployer's callback_uri.¶
6. The deployer submits the Registration Envelope to the Registry with grant_tier: "G2".¶

12.10. G3: Full Ceremony Grant Flow (OAuth 2.1)

The G3 (Full Ceremony) grant profile is required for high-assurance Tier 3 operations and environments requiring identity proofing. It uses an OAuth 2.1 Authorization Server (AS) typically operated by the Registry.¶

Actors: Agent Deployer, AIP Registry (as OAuth AS), Principal Wallet, Principal.¶

OAuth binding of the GrantRequest: Before initiating the OAuth authorization request, the deployer MUST construct and sign a GrantRequest using the signed GrantRequest envelope defined in Section 12.2. The G3 OAuth authorization request MUST carry that compact JWS in an aip_grant_request form parameter. The authorization request MUST also include response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256, acr_values, and aip_version=0.3.¶

POST /v1/oauth/authorize
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=did:web:assistant.example.com
&redirect_uri=https://assistant.example.com/aip/grant-callback
&scope=email.read%20calendar.read
&state=sess_abc123_csrf_xyz789
&code_challenge=<S256-code-challenge>
&code_challenge_method=S256
&acr_values=<requested-acr>
&aip_version=0.3
&aip_grant_request=<compact-JWS-signed-GrantRequest>

The Registry Authorization Server MUST verify the signed GrantRequest envelope before redirecting the principal to a Principal Wallet or displaying any consent UI. Verification MUST include the signed GrantRequest checks in Section 12.2 and the following G3 binding checks:¶

1

The aip_grant_request parameter is present and contains a compact JWS whose payload is a GrantRequest object.¶

2

The OAuth client_id either equals the GrantRequest deployer_did or identifies a pre-registered OAuth client whose Registry metadata maps to that same deployer_did.¶

3

The OAuth redirect_uri exactly matches the GrantRequest callback_uri.¶

4

The OAuth state exactly matches the GrantRequest state.¶

5

The GrantRequest request_expires_at has not passed, allowing at most 30 seconds of clock skew.¶

6

The OAuth scope parameter does not request authority outside the GrantRequest requested_capabilities. If the Authorization Server cannot map a requested scope string to the GrantRequest capabilities under the synced AIP Scope Catalog, it MUST treat the authorization request as invalid.¶

If any binding check fails, the Authorization Server MUST reject the authorization request with grant_request_invalid and MUST NOT issue an authorization code. After successful verification, the Authorization Server MUST store an immutable authorization-code binding that includes the JCS hash of the GrantRequest payload, the compact JWS signature value, grant_request_id, agent_aid, deployer_did, nonce, state, callback_uri, requested_capabilities, and delegation_valid_for_seconds. The token endpoint MUST use this stored binding when redeeming the authorization code and MUST reject any code that lacks such a binding with grant_request_invalid.¶

G3 token endpoint response mapping: A successful POST /v1/oauth/token response for a G3 grant ceremony is an OAuth token response that transports, but does not replace, an AIP GrantResponse. The response body MUST be a JSON object with the following fields:¶

• token_type: REQUIRED. MUST be "AIP+JWT".¶
• access_token: REQUIRED. The compact Principal Token JWT. This value is an OAuth transport alias only.¶
• expires_in: REQUIRED. Integer seconds until the Principal Token expires; MUST equal grant_response.approved_delegation_valid_for_seconds.¶
• state: REQUIRED. MUST equal the OAuth state value stored in the authorization-code binding.¶
• grant_response: REQUIRED. A JSON object conforming to the GrantResponse schema in Section 12.4 with status equal to "approved" or "partial".¶

The access_token value MUST be byte-for-byte identical to grant_response.principal_token. The deployer MUST validate the nested grant_response using the GrantResponse validation rules in Section 12.4 and MUST use grant_response.principal_token when constructing the Registration Envelope. The access_token field exists only for OAuth client interoperability and MUST NOT be interpreted as replacing the principal_token field. The Principal Token payload MUST include the acr and amr claims from the completed G3 ceremony. If the principal rejects the grant or the ceremony fails before approval, the Authorization Server MUST return an OAuth error response and MUST NOT return a successful token response.¶

Step-by-step definition:¶

1. The deployer constructs and signs a GrantRequest, then initiates an OAuth 2.1 Authorization Code Flow with PKCE at the Registry's authorization endpoint using the G3 OAuth binding above.¶
2. The Registry redirects the principal to their configured Principal Wallet for authentication and consent.¶
3. The Principal Wallet performs high-assurance authentication (e.g., FIDO2/WebAuthn) and obtains consent.¶
4. The Principal Wallet returns an authorization code or equivalent signed ceremony result to the Registry.¶
5. The Registry MUST obtain a root Principal Token signed using the Principal Token signing profile above by a principal-controlled Ed25519 verification method. The Registry MAY prepare the token payload and include the high-assurance acr and amr values from the OAuth ceremony, but it MUST NOT sign the root Principal Token with the Registry's authorization-server key and MUST NOT change iss away from principal.id. The token sub MUST equal the agent_aid value from the stored authorization-code binding, and the token MUST include acr and amr claims from the completed ceremony.¶
6. The token endpoint returns the G3 token endpoint response defined above. Its grant_response member is the AIP GrantResponse used by the deployer for Registration Envelope construction.¶
7. The deployer submits the Registration Envelope to the Registry with grant_tier: "G3".¶

13.1. Motivation

The Cascading Approval Problem: Without Approval Envelopes, multi-step agent workflows require the human to approve each step independently, eliminating the benefit of autonomous agents. For example, an agent places an order with an e-commerce platform (step 1), which triggers a payment processor (step 2). Without Approval Envelopes, each step would require independent approval.¶

13.2. The Token-Expiry-While-Pending Problem

A Credential Token with a catalog-derived TTL may expire while approval is pending. Approval Envelopes decouple the approval phase from execution: the envelope waits in pending_approval state without requiring a valid token, and step-claim tokens are issued at execution time.¶

13.3. Approval Envelope Schema

Approval Envelopes have two wire profiles. An ApprovalEnvelopeSubmission is submitted by the orchestrating agent to POST /v1/approvals. A StoredApprovalEnvelope is returned by Registry read and mutation endpoints and includes Registry-managed lifecycle fields. A Registry MUST validate POST /v1/approvals request bodies against the submission profile and MUST NOT accept read-only stored fields in the submission body.¶

An ApprovalEnvelopeSubmission MUST NOT contain top-level status, principal_signature, or approved_at. Its forward steps MUST NOT contain read-only status, claimed_at, or completed_at fields. Its compensation steps MUST NOT contain read-only status fields. If any read-only field is present in the submission body, the Registry MUST reject with approval_envelope_invalid.¶

total_value and currency MUST both be present or both absent. When present, total_value MUST equal the sum of value fields across ALL steps. A step that omits value contributes 0 to this sum. Required and optional steps are both included in the sum when they carry a value field. This value is the maximum approved financial exposure of the envelope, not a prediction that every optional step will execute.¶

When present, engagement_id scopes the Approval Envelope to the parent Engagement Object. The field is part of the Approval Envelope body and MUST NOT be supplied only as external Registry metadata. Both creator_signature and principal_signature signing inputs MUST include engagement_id whenever it is present.¶

The creator_signature signing input is the Section 2.1 canonical JSON serialization of the ApprovalEnvelopeSubmission object with creator_signature set to "". The principal_signature signing input is the same immutable submission object after successful submission, including creator_signature, principal_kid, and a principal_signature member set to "". Both signing inputs include creator_kid, notification_uri, and engagement_id when present. The DID portion of creator_kid MUST equal created_by; the DID portion of principal_kid MUST equal principal_id. Neither signing input includes Registry-managed top-level lifecycle fields (status or approved_at) or Registry-managed step fields (status, claimed_at, or completed_at).¶

13.4. Step Schema

Each element in the steps array represents one atomic action at one Relying Party.¶

The triggered_by field implements the SAGA DAG. A step with triggered_by: null is a root step. A step with triggered_by: N MUST NOT be claimed before step N reaches completed status. Circular dependencies MUST be rejected.¶

Multiple steps MAY share the same triggered_by value, enabling parallel execution paths.¶

The compensation_index field, when present on a forward step, identifies the single compensation step that rolls back that forward step. The value is a 1-based identifier that MUST equal the compensation_index field of exactly one entry in compensation_steps; it is not a zero-based JSON array offset. The Registry MUST reject envelopes where a non-null compensation_index does not reference an existing compensation step, or where more than one forward step references the same compensation step.¶

13.5. Compensation Step Schema

Compensation steps define SAGA rollback actions pre-authorised by the principal. If a forward step fails, compensation actions execute without requiring new human approval.¶

A compensation step is selected only through a forward step's compensation_index field. The Registry MUST NOT infer a compensation relationship from matching action_type values, array position, actor identity, or relying party URI.¶

13.6. Approval Envelope Lifecycle

The Registry maintains lifecycle state with valid transitions:¶

           pending_approval --> approved --> executing --> completed
               |                |             |
               v                v             v
           rejected          expired     compensating --> compensated
                                              |
                                              v
                                            failed

           pending_approval --> cancelled
           approved         --> cancelled
           executing        --> cancelled

Transition rules:¶

pending_approval to approved

Principal signs via Principal Wallet. Registry atomically stores principal_signature, sets approved_at, and transitions the envelope to approved. Only envelopes currently in pending_approval can make this transition.¶

pending_approval to rejected

Principal declines.¶

pending_approval to expired

approval_window_expires_at passes before a successful approval transition is committed.¶

approved to executing

First step is claimed. Automatic transition.¶

executing to completed

All required: true steps reach completed status.¶

executing to compensating

Any required: true step fails with compensation_index present.¶

compensating to compensated

All compensation steps complete successfully.¶

compensating to failed

One or more compensation steps fail. Terminal state.¶

pending_approval, approved, or executing to cancelled

Parent Engagement Object transitions to terminated. The Registry MUST NOT transition Approval Envelopes to cancelled solely because the parent Engagement Object transitions to completed.¶

The approval_window_expires_at field is an approval-deadline only. It controls whether an envelope is eligible to transition from pending_approval to approved. Once an envelope has transitioned to approved before that deadline, later passage of approval_window_expires_at MUST NOT transition the envelope to expired and MUST NOT be used to reject step claims. Execution time limits, if any, MUST be expressed by a separate field or by endpoint policy; they MUST NOT be inferred from approval_window_expires_at.¶

Terminal states (no further transitions): completed, compensated, failed, rejected, expired, cancelled.¶

The Registry MUST treat approval, rejection, expiry, cancellation, and first step claim as mutually exclusive state transitions over the same Approval Envelope lifecycle record. Implementations MUST use optimistic locking, compare-and-set, a database transaction, or an equivalent distributed lock so that exactly one concurrent transition out of pending_approval can succeed. If multiple Principal Wallets submit valid approval signatures concurrently for the same principal_id, the first committed approval wins. The Registry MUST NOT replace principal_signature, approved_at, or the winning state with a later approval request. A later approval or rejection request that races with or follows a completed lifecycle transition MUST fail with approval_state_conflict, except that an exact byte-for-byte retry of the already stored approval response MAY be treated as idempotent and return the stored envelope.¶

When an envelope transitions to cancelled, pending forward steps under that envelope MUST transition directly to cancelled. Claimed forward steps MUST be treated as failed for compensation-trigger evaluation, then MUST transition to cancelled after any required compensation resolution completes or fails. Completed, failed, compensated, and skipped steps retain their existing status for audit purposes. The Registry MUST NOT issue new Step Execution Tokens for cancelled envelopes or cancelled steps.¶

13.7. Action Hash Computation

The action_hash binds the principal's approval to the specific content of the action. An agent MUST NOT execute a different action than the principal approved.¶

The action_hash is computed as:¶

action_hash = "sha256:"
  + LCHEX( SHA-256( JCS( action_parameters ) ) )

Where action_parameters contains:¶

• approval_id - The approval_id of the envelope¶
• step_index - The step_index of this step¶
• actor - The actor AID¶
• relying_party_uri - The Relying Party URI¶
• action_type - The action type¶
• parameters - Application-defined JSON object¶

Implementations MUST use an RFC8785-conformant library. Financial amounts MUST be represented as JSON numbers (not strings).¶

13.8. Step Claim and Execution Protocol

To execute a step, an agent follows this protocol:¶

Step 1 - Claim: The agent calls POST /v1/approvals/{id}/steps/{n}/claim with a valid Credential Token and action_parameters.¶

The Registry MUST atomically verify all of the following:¶

1. Envelope status is approved or executing¶
2. Step status is pending¶
3. All triggered_by steps are completed¶
4. Token iss matches step actor¶
5. Credential Token passes validation¶
6. Credential Token aip_scope contains every scope listed in the step's scopes array¶
7. action_hash matches stored value¶

The Registry MUST NOT evaluate approval_window_expires_at as a step-claim condition for an envelope already in approved or executing status.¶

If the triggered_by check fails because one or more prerequisite steps have not reached "completed", the Registry MUST reject the claim with approval_step_prerequisites_unmet and MUST NOT issue a Step Execution Token.¶

If all checks pass, the Registry returns a Step Execution Token signed by a JWK listed in active_verification_keys.step_execution of the Registry Trust Record version current at issuance time:¶

header = {
  "typ": "AIP-SET+JWT",
  "alg": "EdDSA",
  "kid": "<Registry step-execution keyid>",
  "aip_trv": <Registry Trust Record version>
}

payload = {
  "iss": "<Registry ID>",
  "sub": "<actor AID>",
  "aud": "<relying_party_uri>",
  "iat": <now>,
  "exp": <now + 300>,
  "jti": "<UUID>",
  "aip_version": "0.3",
  "aip_scope": ["transactions"],
  "aip_chain": ["<compact Principal Token JWT>"],
  "aip_approval_id": "<approval_id>",
  "aip_step_kind": "forward",
  "aip_approval_step": <step_index>
}

A Step Execution Token is not an agent-issued Credential Token. Its iss is the Registry ID HTTPS URI, its sub is the claimed step actor AID, and its JOSE kid identifies a step-execution verification key from the Registry Trust Record. Relying Parties MUST validate Step Execution Tokens using the SET validation profile in Section 9 before applying Step 10a. The Registry MUST derive the SET aip_scope value from the claimed step's scopes array and MUST derive the SET exp value using the TTL rule in Section 5.4.1.¶

Step 2 - Execute: The agent presents the Step Execution Token to the Relying Party.¶

Step 3 - Complete or Fail: After execution, the agent MUST call /complete or /fail before the claim deadline. The claim deadline is claimed_at + step_claim_timeout_seconds, where step_claim_timeout_seconds is the Registry policy value published in /v1/registry-metadata. The value MUST be an integer from 1 to 600 seconds inclusive.¶

If a claimed step is not completed or failed before that deadline, the Registry MUST treat the claim as timed out, transition the step to failed, and apply the SAGA compensation rules as if the actor had explicitly reported step failure.¶

The JSON body profiles for claim, complete, and fail requests and responses are defined in approval-step-endpoints.schema.json. All request bodies in this section MUST use Content-Type: application/json. The Registry MUST ignore any client-supplied completion or failure timestamp for lifecycle purposes; claimed_at, completed_at, and failure timestamps are Registry receipt times.¶

Claim request: A forward step claim request body MUST conform to the claim_request profile and contain credential_token and action_parameters. The Registry MUST validate the Credential Token using Section 9 with the Registry claim endpoint as the Relying Party. The token issuer, token subject, and leaf Principal Token subject MUST equal the step actor. The Registry MUST recompute the step action_hash from action_parameters using Section 13.7 and MUST reject a mismatch with approval_step_action_mismatch. The Credential Token aip_scope set MUST contain every scope in the claimed step's scopes array; otherwise the Registry MUST reject with insufficient_scope.¶

On a successful forward claim, the Registry MUST atomically transition the forward step from pending to claimed, set claimed_at, store the issued SET jti, transition the envelope from approved to executing if this is the first claimed step, and return a claim_response containing the compact Step Execution Token. If the same actor repeats the same claim request with the same idempotency_key before the claim expires, the Registry MAY return the stored claim response. A different actor, different request body, expired claim, or missing matching idempotency record MUST NOT be treated as an idempotent retry.¶

Complete request: A complete request body MUST conform to the complete_request profile and contain step_execution_token. The Registry MUST validate the SET using the Section 9 SET validation profile, verify that the SET aip_approval_id and step identifier match the request path, verify that the SET sub equals the step actor, verify that the SET jti equals the stored jti for the active claim, and verify that the step or compensation step is currently claimed and has not passed its claim deadline. If any of these checks fail, the Registry MUST reject with approval_step_invalid or approval_step_not_claimed as applicable.¶

On a successful forward-step complete request, the Registry MUST transition the step to completed, set completed_at, persist any supplied result_hash or evidence_uri as audit metadata, and evaluate envelope completion. If all required forward steps are completed and no compensation is pending, the Registry MUST transition the envelope to completed. Exact retries with the same idempotency_key MAY return the stored complete_response; conflicting repeats MUST reject with approval_state_conflict.¶

Fail request: A fail request body MUST conform to the fail_request profile and contain step_execution_token and failure_code. The Registry MUST perform the same SET, actor, path, stored-jti, state, and deadline checks required for completion. On success, the Registry MUST transition the step to failed, persist the supplied failure metadata for audit, and apply the SAGA compensation rules. Exact retries with the same idempotency_key MAY return the stored fail_response; conflicting repeats MUST reject with approval_state_conflict.¶

Compensation endpoints: POST /v1/approvals/{id}/compensation-steps/{n}/claim, /complete, and /fail use the same request and response profiles as forward-step endpoints. The path {n} is the compensation step's compensation_index. Compensation claims are valid only when the envelope is compensating and the compensation step has been triggered by the SAGA rules in Section 13.9. SETs issued for compensation claims MUST contain aip_step_kind: "compensation" and aip_compensation_step, and MUST NOT contain aip_approval_step.¶

13.9. SAGA Compensation Semantics

When any required: true step fails after one or more earlier steps completed, the Registry MUST:¶

1. Transition envelope status to compensating¶
2. Build the compensation set from forward steps whose status is completed and whose compensation_index is non-null. The failed forward step is included in this set only if its status had previously reached completed before the failure was reported.¶
3. Sort that forward-step set by descending step_index.¶
4. For each sorted forward step, trigger the compensation step referenced by that forward step's compensation_index.¶
5. Notify the orchestrating agent¶

Compensation steps that are not referenced by any completed forward step MUST NOT be triggered. If the failed required step has no completed side effects and no completed predecessor has a non-null compensation_index, the Registry MUST transition the envelope directly to failed rather than compensating. If a completed forward step references a compensation step that cannot be found, the envelope is invalid and the Registry MUST treat the compensation attempt as failed.¶

Rollback ordering is based on the forward steps' descending step_index values, not on compensation_index order. The compensation_index value is used only to dereference the pre-authorised compensation step selected for each completed forward step.¶

Because the principal pre-approved all compensation steps, no additional human interaction is required. This is the core SAGA property.¶

If a compensation step itself fails, the envelope transitions to failed (terminal). The Registry MUST set the failed compensation step status to failed, set the envelope status to failed, persist an audit record containing the approval ID, compensation index, actor AID, failure timestamp, and failure reason, and return or expose compensation_failed for the failed transition.¶

The Registry MUST create a principal notification event for the terminal compensation failure. If the Approval Envelope contains a notification_uri, the Registry MUST attempt delivery to that URI. If RPNP is supported and a matching active subscription exists, the Registry MUST also emit an RPNP event. If no delivery channel is configured, the Registry MUST retain the notification event and expose it in the Approval Envelope status response until acknowledged by local policy. Human remediation of the failed business action remains outside AIP, but the failure state, audit record, and notification event are AIP protocol obligations.¶

13.10. Approval Envelope Validation Rules

The Registry MUST reject an Approval Envelope at submission time if any of the following are true:¶

1. principal_id begins with the exact ASCII prefix did:aip:; reject with approval_envelope_invalid. This is a byte-for-byte prefix comparison against the first eight characters of the string; values whose first eight characters are did:aip: identify an agent AID and are not valid principal identifiers.¶
2. engagement_id is present but malformed: reject with approval_envelope_invalid. If engagement_id references an Engagement Object that does not exist, reject with engagement_not_found.¶
3. steps contains circular dependencies in triggered_by: reject with approval_envelope_invalid.¶
4. steps contains duplicate step_index values: reject with approval_envelope_invalid.¶
5. total_value != sum of step values, treating omitted step value fields as 0: reject with approval_envelope_invalid.¶
6. Any present step currency differs from the envelope currency: reject with approval_envelope_invalid.¶
7. approval_window_expires_at is in the past: reject with approval_envelope_expired.¶
8. created_at is in the future beyond 30-second clock skew: reject with approval_envelope_invalid.¶
9. approval_window_expires_at is not strictly after created_at, or is more than 72 hours after created_at: reject with approval_envelope_invalid.¶
10. compensation_index references a non-existent index: reject with approval_envelope_invalid.¶
11. compensation_steps contains duplicate compensation_index values or values that are not sequential starting at 1: reject with approval_envelope_invalid.¶
12. More than one forward step references the same non-null compensation_index: reject with approval_envelope_invalid.¶
13. creator_signature does not verify: reject with approval_envelope_invalid.¶
14. created_by agent is revoked: reject with agent_revoked.¶
15. steps contains more than 20 elements: reject with approval_envelope_invalid.¶
16. triggered_by is 0: reject with approval_envelope_invalid. An absent triggered_by field is a schema violation because the field is REQUIRED by the step schema and is rejected before this semantic validation rule is evaluated.¶
17. A forward or compensation step omits scopes, includes an empty scopes array, includes duplicate scope strings, or includes a scope that is not active in the synced AIP Scope Catalog: reject with approval_envelope_invalid.¶

The Registry MUST also reject envelopes with insufficient_scope unless the submitting orchestrating agent's Credential Token and current Capability Manifest both include the active approvals.create scope from the synced AIP Scope Catalog. Transaction, communication, filesystem, and agent-spawning scopes alone do not grant authority to submit Approval Envelopes.¶

Rule DESTRUCTIVE-1 (Mandatory Approval): Any operation involving a scope whose active AIP Scope Catalog entry has destructive: true MUST be authorised via a dedicated Approval Envelope step or a direct human confirmation ceremony. Registry-mediated G1 grants MUST NOT be used for destructive operations without an additional out-of-band confirmation.¶

14.1. Endorsement Object

Any Relying Party or agent MAY submit a signed Endorsement Object to the Registry after a completed interaction. The schema is in Section 5.8.¶

The Registry MUST verify every submitted Endorsement Object signature. Only success and partial outcomes increment endorsement_count. failure increments incident_count.¶

The optional Endorsement Object notes field is signed audit context only. It MUST NOT be used as an input to reputation scoring, endorsement weighting, validation, or counter updates.¶

Completed Approval Envelope steps SHOULD generate Endorsement Objects. When an Approval Envelope reaches completed status, the orchestrator SHOULD submit an Endorsement Object for each agent that executed a step successfully. This is a reputation-input recommendation, not a protocol validation gate. Registries and Relying Parties cannot prove that an orchestrator failed to submit an expected Endorsement Object, and absence of such an endorsement MUST NOT cause Approval Envelope validation, Credential Token validation, or step-completion processing to fail.¶

14.2. Reputation Scoring

Reputation scoring algorithms, aggregation functions, and score decay policies are implementation-defined and are not subject to conformance testing. A Registry that implements the Reputation Output optional feature MUST expose a reputation score in the range 0.0 through 5.0 at GET /v1/agents/{aid}/reputation in a response containing at minimum:¶

• score: number, current reputation score in the range 0.0 through 5.0;¶
• endorsement_count: integer, total number of accepted endorsements;¶
• computed_at: string, ISO 8601 UTC timestamp of last score computation.¶

A Registry that implements this optional feature MUST expose reputation data for every registered AID at GET /v1/agents/{aid}/reputation. Required fields: registration_date, task_count, successful_task_count, endorsement_count, incident_count, revocation_history, last_active.¶

The aggregate reputation counters are single-resource fields and are not paginated. The revocation_history member is a collection and MUST use the cursor pagination rules in Section 17.21. A response MUST include no more than the effective limit revocation history entries and MUST include a pagination object for continuing the history scan. Absence of older history on the current page MUST NOT be interpreted as absence of older revocations when pagination.has_more is true.¶

The Registry MAY expose a reference advisory score labelled advisory_only: true. Relying Parties MUST NOT treat it as normative. AIP standardises reputation inputs, not the scoring formula.¶

Reputation Non-Transferability: Reputation is bound to a specific AID. Implementations MUST NOT transfer reputation from revoked to new AIDs. Endorsements from AIDs with current full_revoke or principal_revoke status MUST NOT be weighted.¶

17.1. Endpoint Inventory

A conformant AIP Registry MUST implement the following unconditional HTTP endpoints:¶

The following endpoint sets are feature-conditional. A Registry MUST implement every endpoint in the applicable set when it advertises or enables the corresponding feature. A Registry MUST NOT advertise a feature in /v1/registry-metadata, the Registry Trust Record, or other discovery metadata unless it implements the complete endpoint set for that feature.¶

Segmented CRL publication

GET /v1/crl/segments/{segment_id} retrieves a signed CRL segment.¶

grant_tiers_supported includes G1

POST /v1/grants submits a G1 grant, and GET /v1/grants/{grant_id} retrieves G1 grant status.¶

grant_tiers_supported includes G3

POST /v1/oauth/authorize is the G3 authorization endpoint.¶

G3 or token exchange supported

POST /v1/oauth/token is the G3 token endpoint and token exchange endpoint, and GET /.well-known/oauth-authorization-server returns AS metadata per [RFC8414]. Registries that support token exchange MUST also implement POST /v1/resources, GET /v1/resources/{resource_id}, PUT /v1/resources/{resource_id}, and DELETE /v1/resources/{resource_id} as defined in Section 17.14.¶

Engagement Objects supported

POST /v1/engagements creates an Engagement Object, GET /v1/engagements/{id} retrieves it, POST /v1/engagements/{id}/countersign countersigns a proposed Engagement Object, and PUT /v1/engagements/{id} appends an Engagement change-log update.¶

RPNP supported

POST /v1/subscriptions creates an RPNP subscription, GET /v1/subscriptions/{id} retrieves subscription status, and DELETE /v1/subscriptions/{id} cancels the subscription.¶

Reputation Output supported

GET /v1/agents/{aid}/reputation returns advisory reputation data with the response invariants in Section 14.2. A Registry that does not implement this feature MUST return HTTP 501 Not Implemented for this endpoint.¶

Endorsement Acceptance supported

POST /v1/endorsements submits an Endorsement Object and applies the acceptance rules in Section 14.1.1. A Registry that does not implement this feature MUST return HTTP 501 Not Implemented for this endpoint.¶

17.2. AID URL Encoding

In all path parameters, the did:aip: prefix and colons MUST be percent-encoded per [RFC3986]:¶

did:aip:personal:9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3
→ /v1/agents/did%3Aaip%3Apersonal%3A9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3

17.3. Response Format

All Registry responses MUST use Content-Type: application/json, except DID Document responses negotiated by Accept: application/did+json or Accept: application/did+ld+json from GET /v1/agents/{aid}, and CRL responses from GET /v1/crl or the signed endpoints.crl URI, which MUST use Content-Type: application/aip-crl+json.¶

All Registry responses from AIP protocol endpoints MUST include X-AIP-Version as defined in Section 8.1. If a request version is unsupported, the Registry MUST reject the request with unsupported_version and include X-AIP-Version in the error response.¶

Unless an endpoint profile explicitly requires OAuth-native error syntax, every Registry error response from an AIP protocol endpoint MUST conform to error-response.schema.json and the error response rules in Section 18.1.¶

All timestamps MUST be in ISO 8601 UTC format.¶

17.4. Agent Registration Metadata

Unless the client sends Accept: application/did+json or Accept: application/did+ld+json, GET /v1/agents/{aid} MUST return Content-Type: application/json with an Agent Registration Metadata response conforming to agent-registration.schema.json. If the AID is not registered, the Registry MUST return unknown_aid.¶

The response MUST include the requested aid, the current Agent Identity Object as identity, the grant_tier accepted during Registration Envelope validation, registered_at, updated_at, and links for the current public key, current Capability Manifest, live revocation status, and the registration_warnings array. The identity field MUST be the current stored Agent Identity Object at the time of the most recent successful registration or key rotation, and identity.aid MUST equal the top-level aid. The registration_warnings array MAY be empty. If Registration Check 15 accepted a Tier 2 registration without identity.model.attestation_hash, the array MUST include the persisted model_attestation_missing_tier2 warning until the registered Agent Identity Object includes a valid attestation hash.¶

A successful POST /v1/agents response MUST use HTTP 201 and MUST return the same Agent Registration Metadata representation that a subsequent GET /v1/agents/{aid} request would return. Any registration warning created during validation MUST therefore be visible in the registration response and in later metadata reads.¶

Relying Parties use the registered grant_tier value for each participating aip_chain AID during Step 9d Grant Tier Conformance validation.¶

17.5. Agent Key Rotation Endpoint

PUT /v1/agents/{aid} is used only for key rotation of an existing AID. The request body MUST be a complete Agent Identity Object, not a Registration Envelope. The request MUST use Content-Type: application/json and MUST include a DPoP proof for the exact PUT request URI. For an ordinary rotation, the DPoP proof MUST verify against the current active public key for the AID before the rotation is committed. If the DPoP proof key instead equals the stored fallback public key for the AID, the Registry MUST process the request as an Emergency Key Rotation (Section 17.6). If the path {aid} is not already registered, the Registry MUST reject with unknown_aid.¶

The DPoP proof for key rotation MUST include htu, htm, iat, and jti. The Registry MUST reject a missing proof with dpop_proof_required and MUST reject an invalid, stale, or replayed proof with invalid_token. The Registry MUST store enough recent DPoP jti values for each AID to reject replay within the accepted DPoP clock-skew window.¶

The Registry MUST reject the request with invalid_request unless all of the following conditions hold:¶

1. The percent-decoded path {aid} equals identity.aid.¶
2. The submitted identity.version equals the currently stored identity version plus exactly 1.¶
3. The submitted identity.public_key is an Ed25519 JWK conforming to the Agent Identity schema, and its kid equals identity.aid + "#key-" + identity.version.¶
4. The submitted identity.public_key.x is not already associated with any other registered AID, whether as an active public key or as a stored fallback public key, and is not the stored fallback public key of this AID.¶
5. The submitted object changes only version, public_key, and previous_key_signature; all other Agent Identity fields, including fallback_public_key_x and fallback_key_proof when present, MUST be byte-for-byte identical to the currently stored Agent Identity Object.¶
6. previous_key_signature is present, is a non-empty base64url string, and verifies using the immediately previous stored public key over the complete submitted Agent Identity Object serialized per Section 2.1 with previous_key_signature temporarily set to "".¶

The version check and the identity update MUST be performed in one atomic compare-and-commit operation against the currently stored identity version. If another rotation commits first, or if the submitted identity.version is not exactly the currently stored version plus 1, the Registry MUST reject with identity_version_conflict (HTTP 409). A Registry MUST NOT accept a rotation that skips a version number or overwrites a newer stored identity.¶

Exact retries are idempotent. If the submitted Agent Identity Object is byte-for-byte identical to the current stored Agent Identity Object, the Registry MUST return HTTP 200 with the current Agent Registration Metadata and MUST NOT update timestamps, key states, or historical-key records. For this exact-retry case, the DPoP proof MAY verify against the current active key named by the submitted identity. A different request body for the same version is not an idempotent retry and MUST be rejected with identity_version_conflict.¶

On first successful commit, the Registry MUST atomically store the submitted Agent Identity Object as the current identity, mark the previous key as retired, retain the previous public verification key for historical validation according to Section 19.7, and update the registration metadata updated_at timestamp. The successful response MUST be HTTP 200 with Content-Type: application/json and a body equal to the Agent Registration Metadata representation that a subsequent GET /v1/agents/{aid} would return. The Registry MUST NOT process key rotation through POST /v1/agents.¶

17.6. Emergency Key Rotation

Emergency Key Rotation recovers control of an AID whose active private key has been lost or compromised, without abandoning the AID, by using the fallback key registered per Section 5 and Registration Checks 5b and 5c. It uses the same PUT /v1/agents/{aid} endpoint as ordinary rotation. A request whose DPoP proof key differs from the current active public key for the AID MUST be processed as an Emergency Key Rotation attempt. If the AID has no stored fallback public key, the Registry MUST reject the attempt with fallback_key_not_registered. If the AID has a stored fallback public key and the DPoP proof key does not equal it, the Registry MUST reject with invalid_token.¶

An Emergency Key Rotation request MUST satisfy all conditions of an ordinary rotation defined in the preceding section, with the following differences:¶

1. The DPoP proof MUST verify against the stored fallback public key for the AID. The DPoP content requirements (htu, htm, iat, jti) and replay-rejection rules are unchanged.¶
2. previous_key_signature MUST verify against the stored fallback public key, not the replaced active key, over the complete submitted Agent Identity Object serialized per Section 2.1 with previous_key_signature temporarily set to "". The Registry MUST record in the registration metadata and audit log that this rotation was authorized by the fallback key.¶
3. The submitted object MAY change fallback_public_key_x and fallback_key_proof in addition to version, public_key, and previous_key_signature. If the submitted object contains a fallback_public_key_x, it MUST differ from the consumed fallback key, MUST differ from the submitted identity.public_key.x, MUST satisfy the uniqueness conditions of Registration Check 5b, and MUST be accompanied by a fallback_key_proof that satisfies Registration Check 5c. If the submitted object omits fallback_public_key_x, it MUST also omit fallback_key_proof, and the AID is left with no fallback key; a new fallback key can then never be added, because ordinary rotation forbids changing the fallback fields.¶

On first successful commit, in addition to the ordinary-rotation commit actions, the Registry MUST atomically: mark the replaced active key with status compromised rather than retired in its historical key records and public-key endpoint responses, with valid_until equal to the commit time; record a CRL entry for the replaced key with reason key_compromised effective at the commit time, following the Section 11 revocation publication rules; and mark the authenticating fallback key as consumed. A consumed fallback key MUST NOT be accepted again for any Emergency Key Rotation or any registration, for any AID. The Registry MUST retain consumed fallback key values for the lifetime of the Registry to enforce this rule.¶

Relying Parties MUST reject Credential Tokens signed by a key whose public-key endpoint status is compromised when the token iat is at or after the key's valid_until time, and MUST apply the Section 11 revocation semantics for key_compromised to tokens issued before that time.¶

For the exact-retry idempotency case defined for ordinary rotation, the DPoP proof of a retried Emergency Key Rotation MAY verify against the consumed fallback key that authorized the committed rotation. Emergency Key Rotation is subject to the dedicated rate limit defined in Section 19; the Registry MUST apply that limit per AID and SHOULD alert the registered operator contact, when one exists, on every Emergency Key Rotation attempt, successful or not.¶

17.7. Agent Public-Key Endpoints

A conformant AIP Registry MUST implement GET /v1/agents/{aid}/public-key and GET /v1/agents/{aid}/public-key/{key-id}. These endpoints provide the key material and validity interval required by Section 9 Step 3 and Section 9 Step 8d-2.¶

A successful response MUST use HTTP 200 with Content-Type: application/json and a body conforming to public-key-response.schema.json. The response MUST include aid, key_id, kid, jwk, valid_from, valid_until, and status. The kid value MUST equal {aid} + "#" + key_id, and jwk.kid MUST equal kid. The jwk member MUST contain Ed25519 public verification material.¶

GET /v1/agents/{aid}/public-key returns the current active verification key for {aid}. For the active key, status MUST be "active". The valid_until member MAY be null to indicate that the key has not yet been retired.¶

GET /v1/agents/{aid}/public-key/{key-id} returns the retained key version identified by {key-id}, where {key-id} is the JOSE kid fragment without the leading #. Historical responses MUST set status to "retired" when a later key version is active, except for a key replaced through Emergency Key Rotation (Section 17.6), whose status MUST be "compromised". The Registry MUST retain historical keys according to Section 19.4.2.¶

If {aid} is not registered, {key-id} is malformed, the requested key version is not found, or the requested key version is older than the Registry's conformant retention window, the Registry MUST reject with unknown_aid (HTTP 404). Revocation, suspension, or deactivation of an AID MUST NOT suppress public-key lookup for retained keys; Relying Parties need those keys to verify signatures before applying revocation and lifecycle checks.¶

17.8. Agent Capability Manifest Endpoint

A conformant AIP Registry MUST implement GET /v1/agents/{aid}/capabilities. A successful response MUST use HTTP 200 with Content-Type: application/json and a body conforming to capability-manifest.schema.json. The returned manifest MUST be the current Registry-stored Capability Manifest for {aid}, and manifest.aid MUST equal the percent-decoded path {aid}.¶

If {aid} is not registered, the Registry MUST reject with unknown_aid (HTTP 404). If the Registry cannot return a stored manifest for a registered AID, or if the stored manifest is malformed, has an invalid signature, fails catalog constraint validation, or is not bound to {aid}, the Registry MUST reject with manifest_invalid. The Registry MUST return the current manifest even if expires_at has passed; Relying Parties then reject with manifest_expired under Section 9 Step 9.¶

A conformant AIP Registry MUST also implement PUT /v1/agents/{aid}/capabilities to replace the current Capability Manifest. The request body MUST conform to capability-manifest.schema.json, MUST have aid equal to the percent-decoded path {aid}, MUST use a version value exactly one greater than the Registry's current stored manifest version for that AID, and MUST have a valid signature from granted_by. On success, the Registry MUST store the submitted manifest as the new current manifest and return HTTP 200 with the stored manifest body. Unknown AIDs return unknown_aid; malformed manifests, invalid signatures, version conflicts, catalog constraint failures, and AID mismatches return manifest_invalid; submitted manifests whose expires_at has already passed return manifest_expired.¶

17.9. Agent Revocation Status Endpoint

A conformant AIP Registry MUST implement GET /v1/agents/{aid}/revocation. This endpoint returns the authoritative live revocation status used by Section 9 Step 7 for Tier 2 validation.¶

If the path {aid} does not identify a registered AID in the authoritative Registry, the Registry MUST reject with unknown_aid (HTTP 404). If the AID is registered, the Registry MUST return HTTP 200 with a JSON body conforming to revocation-status.schema.json, including when the AID has no active revocations.¶

The response fields are:¶

aid

The registered AID being checked. This value MUST equal the percent-decoded path {aid}.¶

checked_at

ISO 8601 UTC timestamp at which the authoritative Registry evaluated the revocation state.¶

status

"active" when no active revocation applies, "restricted" when only scope_revoke or delegation_revoke applies, and "revoked" when full_revoke applies to the AID, when principal_revoke targets the AID, or when principal_revoke targets the root Principal DID associated with the AID's current registration authority.¶

revoked

Boolean. MUST be true when full_revoke or principal_revoke applies directly to the AID or through the AID's root Principal DID. Relying Parties MUST reject Credential Tokens for the AID when this value is true.¶

delegation_revoked

Boolean. MUST be true when an active delegation_revoke applies. Relying Parties MUST reject delegation-chain use rooted at this AID when this value is true.¶

scopes_revoked

Array containing the union of active scope_revoke scopes for the AID. The array is empty when no active scope revocation applies.¶

active_revocations

Array of the signed Revocation Objects that currently affect this AID. The array is empty when status is "active". When a principal-wide principal_revoke affects the AID, this array MUST include the signed principal_revoke object whose target_id is the Principal DID.¶

A registered, non-revoked AID therefore returns HTTP 200 with status: "active", revoked: false, delegation_revoked: false, an empty scopes_revoked array, and an empty active_revocations array.¶

17.10. Revocation Submission Endpoint

A conformant AIP Registry MUST implement POST /v1/revocations. The request body MUST be a Revocation Object conforming to revocation-object.schema.json. Request validation, issuer authorization, idempotency, response behavior, CRL update effects, and child-propagation processing are defined by Section 11.2.¶

17.11. CRL Response

A conformant AIP Registry MUST implement GET /v1/crl as the canonical origin endpoint for the AIP Certificate Revocation List. The endpoint returns the signed CRL document defined in Section 11.3 and conforming to crl.schema.json. Registries MAY publish an absolute CDN or distributed-object URI in the signed Registry Trust Record's signed.endpoints.crl; the origin endpoint and any published distribution URI MUST return the same current CRL payload or a byte-for-byte older payload that remains valid before its next_update.¶

The CRL endpoint is not a generic paginated collection endpoint. Cursor pagination MUST NOT be applied to the revocations array of a signed CRL document because doing so would change the object covered by the CRL signature and could cause clients to validate against an incomplete revocation set.¶

A Registry whose active CRL is too large to publish as a single efficient document MAY publish a segmented CRL. In that mode, GET /v1/crl returns a signed CRL index document whose signed.publication_mode is "index", whose signed.revocations array is empty, and whose signed.segments array lists signed CRL segment documents. Each segment URI, including /v1/crl/segments/{segment_id} when used by the origin Registry, MUST return Content-Type: application/aip-crl+json and a signed CRL document whose signed.publication_mode is "segment".¶

The signed CRL index MUST identify the partitioning scheme with partition_key_alg: "sha-256-target-id-hex". Segment ranges are inclusive ranges over the lowercase hexadecimal SHA-256 digest of the Revocation Object target_id string. Segment ranges in one CRL index MUST be non-overlapping and together cover every active Revocation Object in the indexed CRL. A Relying Party using a segmented CRL for bounded-staleness validation MUST retrieve and verify every segment whose range contains the partition key for any target identifier it must check, including the token's root Principal DID and every AID in the validated aip_chain.¶

For each referenced segment, the Relying Party MUST verify the segment CRL signature against the Registry Trust Record identified by the segment's signed.trust_record_version, verify that the segment's registry_id, crl_id, sequence, issued_at, and next_update match the signed index, and verify that the JCS canonicalized segment document hashes to the segment reference's sha256 value. If any required segment is unavailable or fails verification, bounded-staleness validation MUST fail with registry_unavailable.¶

17.12. Agent Heartbeat Endpoint

A conformant AIP Registry MUST implement POST /v1/agents/{aid}/heartbeat. This endpoint records liveness for the AID identified by the path parameter and is the submission mechanism used by the optional Dead Man's Switch in Section 21.8.¶

The request MUST include Authorization: DPoP <token>, where <token> is a Credential Token issued by the same AID as the path parameter. The Registry MUST validate the Credential Token using the Section 9 validation algorithm with the Registry as the Relying Party. The token aud claim MUST identify either the Registry's registry_id or the heartbeat endpoint URI. The token aip_scope MUST include registry.heartbeat.¶

The request MUST include a DPoP proof bound to the HTTP method and heartbeat URI. If the DPoP proof is absent, reject with dpop_proof_required. If the proof is malformed or invalid, reject with invalid_token.¶

After Credential Token validation, the Registry MUST verify that the path {aid} equals both the Credential Token issuer (iss) and the leaf Principal Token subject (aip_chain[n-1].sub). If either value differs from the path AID, reject with invalid_token. If the token does not contain registry.heartbeat, or if the current Capability Manifest does not grant registry.heartbeat, reject with insufficient_scope.¶

On success, the Registry MUST record last_heartbeat_at using the Registry's receipt time. Client-supplied body timestamps, if any, MUST NOT be used to advance liveness. A successful heartbeat MAY also update the agent's last_active reputation metadata.¶

17.13. Approval Envelope Endpoints

A conformant AIP Registry MUST implement the following additional endpoints for Approval Envelopes:¶

POST /v1/approvals validation: The Registry MUST validate the request body as an ApprovalEnvelopeSubmission, reject any read-only stored-resource fields in that body, and perform all checks defined in Section 13.10 before accepting an Approval Envelope. The Registry MUST return HTTP 201 with the StoredApprovalEnvelope, including the Registry-assigned status: "pending_approval" and initial step statuses, on success.¶

POST /v1/approvals/{id}/approve flow: This endpoint is called by the Principal Wallet after the principal completes the signing ceremony. The request body MUST contain the principal_signature field: a base64url EdDSA signature computed by the principal's Principal Wallet over the immutable approval signing input defined in Section 13.3. That signing input is the accepted ApprovalEnvelopeSubmission content plus creator_signature and principal_signature: ""; it excludes Registry-managed status, approved_at, and step status/timestamp fields. The signing key MUST be a verification method controlled by principal_id. The Registry MUST verify this signature against the resolved principal_id DID Document before transitioning the envelope to approved.¶

Atomicity requirement for approval: The Registry MUST implement POST /v1/approvals/{id}/approve and POST /v1/approvals/{id}/reject as atomic lifecycle transitions. Approval MUST be a conditional update from pending_approval to approved and MUST succeed only when the request is committed before approval_window_expires_at. Rejection MUST be a conditional update from pending_approval to rejected. Only one concurrent approval or rejection request for the same Approval Envelope can succeed. If another Principal Wallet, expiry job, cancellation cascade, approval, or rejection has already changed the envelope state, the Registry MUST reject the losing request with approval_state_conflict and MUST NOT overwrite the stored principal_signature, approved_at, or terminal state. If the envelope is still in pending_approval and approval_window_expires_at has passed, the Registry MUST reject an approval request with approval_envelope_expired and transition or leave the envelope in expired. A byte-for-byte retry of the winning approval request MAY return the stored approved envelope as an idempotent success.¶

Atomicity requirement for step claim: The Registry MUST implement step-claim operations atomically, for example using optimistic locking or a distributed lock, to prevent two actors from claiming the same step simultaneously. Only one claim MUST succeed; the other MUST receive approval_step_already_claimed.¶

Step endpoint request and response bodies: Forward-step and compensation-step claim, complete, and fail request and response bodies MUST conform to the profiles in approval-step-endpoints.schema.json. Complete and fail requests MUST present the compact Step Execution Token issued for the active claim. The Registry MUST validate the SET, match it to the request path and stored claim jti, enforce the claim deadline, and process exact idempotent retries as defined in Section 13.8.¶

Step Execution Token format: The Step Execution Token returned by POST /v1/approvals/{approval_id}/steps/{step_id}/claim or POST /v1/approvals/{approval_id}/compensation/{compensation_step_id}/claim is a Registry-issued JWT with JOSE typ: "AIP-SET+JWT", alg: "EdDSA", and a kid matching a JWK in active_verification_keys.step_execution of the Registry Trust Record version current at issuance time. The protected JOSE header MUST also include aip_trv equal to that Registry Trust Record version. Its payload claims are described in Section 13.8. Its TTL MUST comply with the Step Execution Token TTL derivation rule in Section 5.4.1.¶

17.14. Resource Registration

AIP Registries that support token exchange (Section 8.4) MUST maintain a resource registry mapping target resource URIs to their authorization configuration. Each Registered Resource Record MUST conform to resource-record.schema.json and MUST include:¶

resource_uri

string, REQUIRED. The RFC 9728 resource identifier.¶

authorization_server

string, REQUIRED. The URI of the authorization server for this resource, either the AIP Registry itself or an external authorization server.¶

enterprise_idp_required

boolean, OPTIONAL. When true, token exchange requests targeting this resource MUST use the Enterprise IdP Federation Profile (Section 8.4.5). Default: false.¶

enterprise_idp_token_endpoint

string, CONDITIONAL. REQUIRED when enterprise_idp_required is true. The Enterprise IdP's token endpoint URI.¶

enterprise_idp_client_id

string, CONDITIONAL. REQUIRED when enterprise_idp_required is true. The Registry's registered client_id with the Enterprise IdP.¶

Resource records are addressed by resource_id, the lowercase hexadecimal SHA-256 digest of the UTF-8 resource_uri value. The Registry MUST reject a create request whose path-derived or body-supplied resource_id does not equal that digest with registration_invalid. The Registry MUST reject duplicate resource_uri create requests with HTTP 409 unless the submitted record is byte-for-byte identical to the stored record, in which case it MAY return the existing record.¶

A Registry MUST NOT accept unauthenticated public writes to the resource registry. The registering caller MUST be authenticated as a Registry operator, the resource owner, or another party authorized by local Registry policy. The Registry MUST validate that resource_uri, authorization_server, and any enterprise_idp_token_endpoint are absolute HTTPS URIs unless a local non-production policy explicitly allows another URI scheme.¶

When enterprise_idp_required is true, the Registry MUST reject the record unless enterprise_idp_federation_supported is true in Registry discovery metadata and both enterprise_idp_token_endpoint and enterprise_idp_client_id are present. Token exchange requests whose resource parameter resolves to such a record MUST follow the Enterprise IdP Federation Profile in Section 8.4.5. Token exchange requests for an unknown resource value MUST be rejected with invalid_target.¶

The resource registration endpoints have the following semantics: POST /v1/resources creates a Registered Resource Record, GET /v1/resources/{resource_id} retrieves one record, PUT /v1/resources/{resource_id} replaces one record atomically, and DELETE /v1/resources/{resource_id} removes the record from future token-exchange matching. Delete does not revoke already issued enterprise IdP access tokens; those tokens remain governed by the enterprise IdP's own lifetime and revocation mechanisms.¶

17.15. OAuth 2.1 Authorization Server

A conformant AIP Registry supporting G3 grants MUST implement an OAuth 2.1 Authorization Server [I-D.ietf-oauth-v2-1] with the following requirements:¶

1. The authorization endpoint MUST be published in the Registry's well-known configuration at /.well-known/oauth-authorization-server per [RFC8414].¶
2. PKCE [RFC7636] with code_challenge_method: "S256" is REQUIRED for all authorization requests.¶
3. For G3 grant ceremonies, the authorization request MUST include aip_grant_request containing the compact-JWS-signed GrantRequest defined in Section 12.2, and the Authorization Server MUST enforce the G3 binding checks in Section 12.10 before issuing an authorization code.¶
4. The scope parameter MUST use AIP scope strings from the synced AIP Scope Catalog or accepted local extension policy.¶
5. The token endpoint MUST redeem an authorization code only against the immutable GrantRequest binding stored during authorization. It MUST reject unbound, expired, replayed, or binding-mismatched authorization codes with grant_request_invalid.¶
6. For G3 grant ceremonies, the token endpoint response MUST follow the G3 token endpoint response mapping in Section 12.10. The access_token value is a transport alias for the compact Principal Token and MUST be byte-for-byte identical to grant_response.principal_token.¶
7. The Principal Token payload returned by the token endpoint MUST include acr and amr claims reflecting the authentication performed.¶
8. The authorization server MUST support the acr_values parameter to declare minimum identity-proofing requirements.¶
9. DPoP [RFC9449] MUST be supported on the token endpoint.¶