AI Agent Identity Certificate (AIC) Extension for X.509 v3

1.1. Problem Statement

Existing X.509 public key certificates, as profiled in [RFC5280], primarily authenticate identity through a cryptographically signed binding between a distinguished name and a public key. Authorization is intentionally left outside the certificate: relying parties perform access control via external IAM policies, OAuth scopes, RBAC databases, or policy engines evaluated after TLS connection establishment.¶

Autonomous AI agents introduce a new requirement that existing certificate profiles do not address. When an agent acts on behalf of a principal, the relying party needs answers to additional questions:¶

• Who delegated this authority?¶

• What operations are authorized?¶

• Under what constraints may the agent operate?¶

• How long is the authorization valid?¶

• Who remains accountable for the actions performed?¶

These questions cannot be answered by identity alone. They require a standardized mechanism to express delegation relationships, capability constraints, authorization boundaries, and accountability chains within the certificate itself.¶

This document defines an X.509 certificate extension that addresses this gap. The AI Agent Identity Certificate (AIC) extension encodes agent identity, principal binding, capability declarations, delegation modality, authorization boundary constraints, and cryptographic delegation authorization within a single certificate. A companion PrincipalAuthorization extension anchors principal-side grant declarations, authorization constraints, and delegation policies.¶

AIC is designed to complement existing identity infrastructure:¶

• SPIFFE/WIMSE identifies workloads via SAN URIs. AIC adds capability containers, principal binding, and session control on top of workload identity.¶

• OAuth 2.0 and JWT-based authorization ([RFC6749]) provides online token exchange. AIC enables offline authorization decisions during the TLS handshake, without external identity provider lookups.¶

• Standard X.509 extensions (Certificate Policies, Extended Key Usage) express intended use but not delegation relationships or fine-grained capability constraints.¶

AIC is intended for deployments where:¶

• AIC is intended to support deployments that reuse existing PKI infrastructure (enterprise CAs, HSMs, smart cards);¶

• Emerging regulatory frameworks require cryptographic traceability of autonomous actions to accountable principals;¶

• Offline or air-gapped environments require self-contained certificate authorization without external database lookups;¶

• Short-lived workload identities need to be augmented with legal accountability metadata.¶

This document specifies the data model, certificate profile, and validation requirements for AIC. Deployment-specific policy, implementation details, and performance characteristics are outside the scope of this specification.¶

1.2. Scope

This document is organized into three categories:¶

Normative (Core): The following sections are normative: Delegation Model, Certificate Profile (Data Model), AIC Extension Definition, Validation Procedure, and PrincipalAuthorization Extension, including their ASN.1 definitions. Implementations MUST conform to these sections to claim AIC compliance.¶

Informative (Profile): The Deployment Models section describes recommended deployment patterns and gateway behavior. These are not required for AIC compliance but represent best practices.¶

Informative (Reference): The Implementation Status section describes a reference implementation. These are provided as implementation guidance and interoperability examples.¶

The core normative content intentionally separates cryptographic delegation from authorization semantics: AIC defines the cryptographic binding between agent and principal, while capability and policy semantics are defined externally.¶

                     AIC Architecture

   +----------------+      +------------------+
   |   Principal    |      |      Agent       |
   | (User/Org)     |      | (AI Agent)       |
   | PrincipalAuth  |      | AIC Certificate  |
   | Certificate    |      | Identity +       |
   |                |      | Capabilities +   |
   +-------+--------+      | Delegation Mode  |
           |               +--------+---------+
           | Authorization           |
           | signature               |
           +-------+-----------------+
                   |
                   v
         +---------------------+
         |    Gateway (PEP)    |
         |  1. Verify Chain    |
         |  2. Parse AIC       |
         |  3. Verify DA       |
         |  4. Check PA constr |
         |  5. Check AIC constr|
         |  6. Check Caps      |
         |  7. Apply Policy    |
         |  8. Decision        |
         +---------+-----------+
                   |
         +---------v-----------+
         |     Target          |
         |   Resource / API    |
         +---------------------+

1.3. Design Principles

This specification is guided by seven orthogonal concerns, each addressed by a distinct layer:¶

AIC does not redefine trust, transport, or cryptography. It complements X.509 by introducing three orthogonal concepts: Agent Identity, Principal Authorization, and Capability Container. Trust remains in PKI, transport remains in TLS, and enforcement remains in the Gateway.¶

AIC defines the representation and cryptographic binding of authorization-related information (agent identity, principal binding, capability container, constraint container, and delegation evidence). It does not define a universal authorization language: whether an operation is permitted is decided by the capability scheme and the deployment policy, not by the AIC extension itself. The Capability Language Core [CLC] is one such external language: AIC carries the containers and the principal binding; CLC defines a deterministic evaluation over them.¶

1.4. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are used throughout this document:¶

AIC:

AI Agent Identity Certificate Extension -- the X.509 v3 extension defined in this document.¶

Agent:

For the purpose of this document, an AI Agent is a software or hardware entity capable of performing actions on behalf of a principal with varying degrees of autonomy.¶

Principal:

The natural person or organizational entity that authorizes an Agent to act on its behalf. Whether a Principal is legally responsible for actions performed by an Agent is determined by applicable law and deployment policy and is outside the scope of this specification.¶

Delegation Mode:

The protocol-defined relationship between an Agent and its Principal for attribution and authorization purposes. The interpretation of these modes under applicable law is outside the scope of this specification. In authorized mode, the Agent acts under its own identity with principal consent. In representative mode, the Agent acts on behalf of the Principal within the delegated permission scope.¶

Capability:

A container for protocol-level operations that an Agent is authorized to perform, defined by a scheme identifier and a capability identifier within that scheme.¶

Capability Scheme:

A system identified by a scheme identifier (schemeId) that defines the semantics of capabilities. Gateways route capability evaluation to scheme-specific plugins by schemeId.¶

Credential Bundle:

The certificates presented by an Agent during the TLS handshake, including the agent certificate chain and the principal's certificate.¶

DelegationAuthorization:

Cryptographic evidence, carried within the AIC extension, that the principal has authorized the Agent. Contains a digital signature over a DelegationAuthTBS structure.¶

DelegationAuthTBS:

The To-Be-Signed structure whose DER encoding is signed by the principal's private key to produce the DelegationAuthorization.¶

PrincipalAuthorization:

A companion X.509 extension (OID 1.3.6.1.4.1.66257.1.2) carried in the Principal's certificate, declaring grants, authorization constraints, and delegation policies.¶

authorizationConstraints:

An OPTIONAL container within AIC and PrincipalAuthorization that defines authorization boundary conditions (IP ranges, concurrency limits, time windows). Constraints are evaluated offline during TLS handshake.¶

OID:

Object Identifier -- a globally unique sequence of integers used to identify objects in the X.509 standard.¶

PEN:

Private Enterprise Number -- a globally unique identifier assigned by IANA to organizations for private use in OID space.¶

SPKI:

Subject Public Key Info -- the ASN.1 structure defined in [RFC5280] Section 4.1.2.7 containing the public key algorithm and subject public key.¶

1.5. Related Work

Several proposals address agent identity and authorization, either in X.509 certificate extensions or in application-layer protocols.¶

[AGTP] (draft-hood-agtp-agent-cert) defines an X.509 certificate extension that binds an agent identifier and a principal identifier and includes an authority-scope commitment over a set of scope tokens. The scope tokens are carried as a flat list of strings.¶

[APKI] (draft-sharif-apki-agent-pki) defines five separate X.509 extensions for agent capabilities, delegation, trust scoring, provenance, and behavioral attestation. Each extension is encoded independently.¶

[AgentIdentity] (draft-sharif-x509-agent-identity-profile) defines a single X.509 extension combining a trust level, a list of capability names, a maximum delegation depth, and a kill-switch URI.¶

[RFC3820] defines proxy certificates for grid computing. A proxy certificate extends the certificate chain so that the proxy acts on behalf of the issuer; it does not carry agent-specific identity or authorization data.¶

[RFC5755] defines attribute certificates as a separate authorization mechanism bound to an identity certificate. Attribute certificates carry attribute/value pairs and are issued by an attribute authority.¶

[CapabilityBound] (arXiv:2603.14332) embeds a hash of a skills manifest in an X.509 extension. Any change to the manifest requires issuing a new certificate.¶

[DAAP] (draft-mishra-oauth-agent-grants) extends OAuth 2.0 with agent grants, using DID-based identifiers and JSON Web Tokens carried at the application layer. It supports multi-level delegation and cascading revocation, and depends on DID resolution.¶

[AIP] (draft-singla-agent-identity-protocol) defines a decentralized identity, delegation, and authorization framework for autonomous agents: agent identifiers derived from public keys (did:aip), capability manifests, delegation chains, and an online registry for resolution and revocation.¶

[OpenA2A-AIP] (draft-fane-opena2a-aip) defines the OpenA2A Agent Identity Protocol using did:opena2a identifiers and ATX credentials issued by registries; authorization is addressed in a companion protocol rather than in the identity layer.¶

WIMSE and SPIFFE define workload identities using SAN URIs ([SPIFFE]); they identify workloads and do not carry authorization information.¶

The authorization language itself is outside this document. A companion draft, the Capability Language Core [CLC], defines a carrier-neutral language for capability identifiers, entailment, intersection, and delegation containment. AIC's containers can be evaluated by that language, but this specification does not require it.¶

This specification follows the X.509 extension approach used by AGTP, APKI, AgentIdentity, and CapabilityBound. It differs in three respects: (1) the authorization data is signed by the principal and the resulting signature is covered by the certificate authority's signature; (2) capabilities use a structured container with a scheme identifier and a capability identifier, so that evaluation can be routed to scheme-specific plugins; and (3) an authorization constraint container carries offline-verifiable boundary conditions. The design goal is to make the authorization decision fully verifiable offline from the certificate and its credential bundle.¶

2.1. Delegation Modes

Two delegation modes are defined:¶

Authorized mode (default): The Agent acts under its own identity. The agent certificate's agentId is recorded as the actor in audit logs, while the principalUid identifies the authorizing principal. The CA evaluates the agent's declared capabilities against the principal's PrincipalAuthorization.grants at issuance time, and the resulting capability set is locked into the certificate. Gateway runtime does not perform a further P_grants superset check for authorized mode. Authorized mode therefore provides snapshot authorization semantics: principal grant changes after issuance do not affect the capability set of an already issued certificate.¶

Representative mode: The Agent acts on behalf of the Principal within the delegated permission scope. The principalUid is recorded as the actor in audit logs, with the agentId recorded as the executor. Representative mode is the exception to the minimal credential bundle model: it requires the principal's certificate and its PrincipalAuthorization extension to be present in the credential bundle presented during the TLS handshake. Deployments that cannot provide the complete bundle MUST use authorized mode. The agent's declared capabilities MUST be a subset of the principal's grants at both issuance time (CA verification) and runtime (gateway verification), as the principal's permissions may change during the agent certificate's lifetime.¶

2.2. Permission Intersection

The effective permission for any agent operation is governed by the intersection of three sets:¶

The authorization model is the intersection of the principal's grants and the agent's capabilities:¶

P_effective = P_grants (AND) C_agent

where P_grants is the principal's declared capability grants (in PrincipalAuthorization.grants) and C_agent is the agent's declared capability set (in AIC.capabilities). An operation is authorized only if it belongs to both sets. The meaning of "belongs to", including grant coverage and parameter or constraint merging, is defined by the governing authorization language; the Capability Language Core [CLC] is one language that defines it (entailment and intersection, with delegation containment as a separate per-hop relation).¶

In authorized mode, C_agent alone serves as the effective capability set (P_grants intersection was already verified by the CA at issuance time and locked into the certificate). In representative mode, the intersection is computed at runtime for each operation.¶

Gateway-local runtime policy (T_policy) -- rate limits, timeouts, routing, and other deployment-side controls -- is an additional enforcement layer applied by the relying party. It is NOT part of the authorization model defined by this specification and MUST NOT be confused with the P (AND) C authorization intersection.¶

2.3. Multi-Level Delegation

Single-level delegation (Principal -> Agent, chainDepth = 0) is the default and recommended deployment mode. A delegation chain of depth 1 (Principal -> Agent -> sub-Agent, chainDepth = 1) MAY be supported when a deployment requires it, in which case the delegating agent signs a DelegationAuthorization for the sub-agent:¶

• chainDepth = 0 (default): direct delegation from the principal to the agent (Principal -> Agent).¶

• chainDepth = 1 (optional): one additional level (Principal -> Agent -> sub-Agent), in which the delegating agent signs a DelegationAuthorization for the sub-agent.¶

Each level of the chain produces an independent DelegationAuthorization signed by the delegator's private key, and capabilities are recursively intersected along the chain. The per-hop requirement that a child grant stay within its parent is a containment check, not an intersection; the Capability Language Core [CLC] defines that relation and a fused chain check over it. Chain depth is carried in a DelegationDepthControl extension with chainDepth and maxDepth fields. In any chain, chainDepth MUST NOT exceed maxDepth.¶

Chains deeper than 1 are not prohibited by this specification, but they are not recommended, and this revision does not define their semantics. For the strongest accountability, deployments SHOULD keep delegation to a single hop from the principal to the acting agent (chainDepth = 0): authority and responsibility then rest with one named party at a known depth. A deployment that requires an intermediate delegator MAY use chainDepth > 1 (see the guardrails below), accepting one specific consequence: responsibility boundaries blur as the chain grows. Each intermediate agent acts under authority it received and then passes it on, so the legal status of the intermediate agents and the audit actor semantics become ambiguous; every additional level also expands the attack surface and grows the credential bundle. A larger numeric depth limit (for example, the 255-level maximum in [AgentIdentity] or the depth-10 chains in [AIP]) is not treated as a feature. Conformance targets the default profile (chainDepth = 0) and the depth-1 option. Deeper chains are outside the scope of this revision; a future revision MAY define them only under the guardrails below. The accountability model of this specification is anchored to the natural person at the top of the chain and is best preserved by a shallow chain.¶

4.1. OID Tree

1.3.6.1.4.1.66257 (IANA PEN -- Varwof PKI)
+-- 1 Identity & Authorization Core
|   +-- 1 AIC (Agent Identity Certificate Extension)
|   |   +-- 1 AgentIdentity (agentId, principalUid, delegationMode)
|   |   +-- 2 DelegationAuthorization (reason, requestedLifetime,
|   |   |     timestamp, nonce, signatureAlgorithm, signatureValue)
|   |   +-- 4 DelegationDepthControl (chainDepth, maxDepth)
|   |   |   +-- 1 chainDepth
|   |   |   +-- 2 maxDepth
|   +-- 2 PrincipalAuthorization (grants, authorizationConstraints,
|   |     delegationPolicy)
|   |   +-- 4 DelegationPolicy
+-- 3 National/Industry Certification
|   +-- 1 MarketAccessId

4.2. Capability Glob Matching Syntax

Capability matching uses the following matching rules:¶

Matching priority (highest to lowest): 1. Exact match 2. Single-segment wildcard 3. Multi-segment wildcard 4. Method wildcard 5. Scheme-wide wildcard¶

When multiple rules match, the highest priority rule applies. If no rule matches, the capability MUST be treated as Deny.¶

Unqualified wildcards (bare * without a preceding namespace and colon separator) are NOT permitted. All wildcards MUST be scoped within a schemeId namespace.¶

4.3. ASN.1 Module

This section defines the ASN.1 module for the AIC extension, using the conventions specified in [RFC5912].¶

Encoding tag conventions:¶

• Mandatory fields use universal tags (INTEGER, UTF8String, OCTET STRING, SEQUENCE); no context-specific tags are applied.¶

• All OPTIONAL fields use context-specific explicit tags ([n] EXPLICIT), numbered from 0 in field order within each structure. Tag numbers are unique within a structure and MAY be reused across structures.¶

• Standard external types (AlgorithmIdentifier) follow RFC 5280 encoding conventions.¶

• DEFAULT fields MAY be omitted from DER encodings when equal to the default value; implementations MUST accept both forms.¶

The AIC and PrincipalAuthorization extensions MUST be non-critical so that systems unaware of these extensions can safely ignore them.¶

VARWOF-AIC DEFINITIONS
    { iso(1) identified-organization(3) dod(6) internet(1)
      private(4) enterprise(1) varwof(66257) modules(2)
      id-mod-varwof-aic(1) }
DEFINITIONS ::= BEGIN

-- All SEQUENCEs SHALL use DER encoding (ordered, no indefinite-length).
-- See RFC 5912 Sec. 3 for DER encoding rules.
-- Implementations MUST reject BER indefinite-length encodings.

IMPORTS
    EXTENSION
        FROM PKIX-CommonTypes-2009
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-pkixCommonTypes-02(57) },
    AlgorithmIdentifier
        FROM PKIXAlgs-2009
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-pkix1-algorithms2008-02(56) } ;

-- OID Assignments

id-varwof        OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 66257 }
id-aic           OBJECT IDENTIFIER ::= { id-varwof 1 1 }

-- AIC Extension

aicExt EXTENSION ::= {
    SYNTAX         AIC
    IDENTIFIED BY  id-aic
    CRITICAL       FALSE
}

AIC ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode DEFAULT authorized,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationAuthorization  DelegationAuthorization,
    extensions               [1] EXPLICIT AICExtensions OPTIONAL
}

DelegationMode ::= INTEGER {
    authorized     (0),
    representative (1)
} (0..1)

PrincipalUid ::= SEQUENCE {
    version     INTEGER (0..255) DEFAULT 1,
    realm       UTF8String (SIZE(1..128)),
    identifier  UTF8String (SIZE(1..256)),
    keyHash     OCTET STRING (SIZE(1..64)),
    hashAlgo    [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}
-- hashAlgo omitted defaults to SHA-256 (OID 2.16.840.1.101.3.4.2.1);
-- keyHash = hashAlgo(SPKI). Only hash algorithms with output length
-- not exceeding 64 bytes are supported (SHA-2/SHA-3 family, SM3,
-- BLAKE2/BLAKE3). keyHash length is determined by the algorithm.

Capability ::= SEQUENCE {
    schemeId        UTF8String (SIZE(1..128)),
    capabilityId    UTF8String (SIZE(1..256)),
    parameters      [0] EXPLICIT OCTET STRING (SIZE(0..4096)) OPTIONAL
}

-- Reason for delegation authorization (mandatory in
-- DelegationAuthorization / DelegationAuthTBS; not present in
-- PrincipalAuthorization)

Reason ::= SEQUENCE {
    reasonCode  UTF8String (SIZE(1..64)),
        -- controlled vocabulary, e.g., SCHEDULED_MAINTENANCE
    description UTF8String (SIZE(1..512))
        -- human-readable description
}

DelegationAuthorization ::= SEQUENCE {
    reason              Reason,
    requestedLifetime   INTEGER (1..86400),  -- SHOULD 3600-86400
    timestamp           GeneralizedTime,     -- MUST be UTC (Z form)
    nonce               OCTET STRING (SIZE(32)),
    signatureAlgorithm  AlgorithmIdentifier,
    signatureValue      OCTET STRING
}

-- DelegationAuthTBS (To-Be-Signed structure)
-- The principal's private key signs the DER encoding of this structure.

DelegationAuthTBS ::= SEQUENCE {
    version                  INTEGER { v1(1), v2(2) } DEFAULT v1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    reason                   Reason,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    requestedLifetime        INTEGER (1..86400),  -- SHOULD 3600-86400
    timestamp                GeneralizedTime,     -- MUST be UTC (Z)
    nonce                    OCTET STRING (SIZE(32)),
    agentKeyBinding          [1] EXPLICIT AgentKeyBinding OPTIONAL
}

-- Version/validation matrix (normative):
--   version = 1 (legacy): agentKeyBinding MUST be absent;
--   version = 2 (current): agentKeyBinding MUST be present and valid;
--   any other version value: rejected.
-- Newly issued DAs MUST be version 2.

AgentKeyBinding ::= SEQUENCE {
    keyHash  OCTET STRING (SIZE(1..64)),
    hashAlgo [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}
-- Binds the DA to the agent's public key: keyHash = hashAlgo(SPKI DER),
-- hashAlgo omitted defaults to SHA-256 (OID 2.16.840.1.101.3.4.2.1).
-- Only hash algorithms whose output does not exceed 64 octets are
-- supported (SHA-2/SHA-3 family, SM3, BLAKE2/BLAKE3); keyHash length
-- MUST equal the declared algorithm's output length. An unknown or
-- unsupported hashAlgo MUST be rejected (no silent fallback); SHA-1
-- MUST NOT be used.

-- PrincipalAuthorization Extension (OID: 1.3.6.1.4.1.66257.1.2)
-- Carried in the Principal's certificate.

paExt EXTENSION ::= {
    SYNTAX         PrincipalAuthorization
    IDENTIFIED BY  id-principal-auth
    CRITICAL       FALSE
}
id-principal-auth OBJECT IDENTIFIER ::= { id-varwof 1 2 }

PrincipalAuthorization ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    grants                   SEQUENCE SIZE(1..MAX) OF Capability,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationPolicy         [1] EXPLICIT DelegationPolicy OPTIONAL,
    extensions               [2] EXPLICIT AICExtensions OPTIONAL
}

DelegationPolicy ::= SEQUENCE {
    version             INTEGER DEFAULT 1,
    maxAgents           INTEGER DEFAULT 1,
    allowedMode         DelegationModeEnum DEFAULT authorizedOnly,
    maxSessionHours     [0] EXPLICIT INTEGER OPTIONAL
}

DelegationModeEnum ::= INTEGER {
    authorizedOnly        (0),
    representativeAllowed (1)
} (0..1)

-- Extensibility Framework

AICExtensions ::= SEQUENCE SIZE (1..MAX) OF ExtField

ExtField ::= SEQUENCE {
    extnID      OBJECT IDENTIFIER,
    critical    BOOLEAN DEFAULT FALSE,
    extnValue   OCTET STRING
}

-- DelegationDepthControl carries the delegation chain depth.
-- Placed in AIC extensions slot, OID 1.3.6.1.4.1.66257.1.1.4.
-- chainDepth MUST NOT exceed maxDepth.
-- This revision defines semantics for chainDepth = 0 and chainDepth = 1
-- only.  Deeper chains are not refused, but they are outside the scope
-- of this specification; a deployment that uses them does so under its
-- own policy and cannot claim conformance for them.

id-ddc OBJECT IDENTIFIER ::= { id-aic 4 }
DelegationDepthControl ::= SEQUENCE {
    chainDepth  INTEGER (0..255),  -- OID .1.1.4.1
    maxDepth    INTEGER (0..255)   -- OID .1.1.4.2
}

END

4.4. Example AIC Extension Encoding

The following example illustrates the AIC extension for an agent with agentId "agent-1", a principal identified as "zhangsan" in the "corp.com" realm, and a single HTTP capability:¶

AIC ::= {
    agentId         "agent-1",
    principalUid    {
        realm       "corp.com",
        identifier  "zhangsan",
        keyHash     <32-byte hash of the principal's SPKI>
    },
    capabilities    {
        { schemeId "http", capabilityId "GET:/api/v1/users" }
    },
    delegationAuthorization {
        reason      {
            reasonCode  "SCHEDULED_MAINTENANCE",
            description "temporary maintenance window"
        },
        requestedLifetime 3600,
        timestamp   "2026-08-18T00:00:00Z",
        nonce       <32-byte CSPRNG value>,
        signatureAlgorithm ecdsa-with-SHA256,
        signatureValue <DER-encoded signature over DelegationAuthTBS>
    }
}

In the DER encoding of this example, the DEFAULT fields (version, delegationMode) are omitted as permitted by the ASN.1 module, and the OPTIONAL fields (authorizationConstraints, extensions) are absent. Each field is encoded in the order given in the ASN.1 module using DER rules RFC5280 [RFC5912]. The signatureValue is produced by the principal's private key over the DER encoding of the corresponding DelegationAuthTBS structure and varies per authorization.¶

4.5. Field Definitions

PrincipalUid ::= SEQUENCE {
    version     INTEGER (0..255) DEFAULT 1,
    realm       UTF8String (SIZE(1..128)),
    identifier  UTF8String (SIZE(1..256)),
    keyHash     OCTET STRING (SIZE(1..64)),
    hashAlgo    [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}

DelegationAuthorization ::= SEQUENCE {
    reason              Reason,
    requestedLifetime   INTEGER (1..86400),
    timestamp           GeneralizedTime,
    nonce               OCTET STRING (SIZE(32)),
    signatureAlgorithm  AlgorithmIdentifier,
    signatureValue      OCTET STRING
}

DelegationAuthTBS ::= SEQUENCE {
    version                  INTEGER { v1(1), v2(2) } DEFAULT v1,
    agentId                  UTF8String (SIZE(1..256)),
    principalUid             PrincipalUid,
    reason                   Reason,
    capabilities             SEQUENCE SIZE(1..MAX) OF Capability,
    delegationMode           DelegationMode,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    requestedLifetime        INTEGER (1..86400),
    timestamp                GeneralizedTime,
    nonce                    OCTET STRING (SIZE(32)),
    agentKeyBinding          [1] EXPLICIT AgentKeyBinding OPTIONAL
}

AgentKeyBinding ::= SEQUENCE {
    keyHash  OCTET STRING (SIZE(1..64)),
    hashAlgo [0] EXPLICIT AlgorithmIdentifier OPTIONAL
}

5.1. Validation Pipeline

The gateway performs the following validation steps in order after TLS handshake completion:¶

1. Certificate Chain ([RFC5280]): Verify the certificate chain up to a trusted root, including signature validation, validity periods, and basic constraints.¶

2. Revocation Status: Verify that neither the end-entity certificate nor any intermediate certificate in the chain has been revoked. Implementations MAY use CRLs ([RFC5280]), OCSP ([RFC6960]), or OCSP Must-Staple ([RFC7633]). In offline deployments, a locally cached CRL or a short validity window MAY serve as an alternative revocation mechanism.¶

3. AIC Extension Parsing: Parse the AIC SEQUENCE. If the extension is marked critical and cannot be parsed, the certificate MUST be rejected.¶

4. DelegationAuthorization Verification: Verify the principal's signature in delegationAuthorization.signatureValue:¶

   • Reconstruct the DER encoding of DelegationAuthTBS (including reason and authorizationConstraints if present). The TBS is DER-encoded in the field order defined in the ASN.1 module; DEFAULT fields MAY be omitted and are interpreted with their default values.¶

   • Use the principal's public key (identified by principalUid.keyHash) to verify signatureValue.¶

   • Cross-verify that hashAlgo(principal_cert.SPKI) equals principalUid.keyHash (hashAlgo omitted means SHA-256).¶

   • Verify the version/validation matrix: version = 1 requires agentKeyBinding to be absent (legacy-only, accepted under the substitution mitigations); version = 2 requires a valid agentKeyBinding; any other version value MUST be rejected. When the binding is present, cross-verify that hashAlgo(agent_cert.SPKI) equals agentKeyBinding.keyHash (hashAlgo omitted means SHA-256) and that the keyHash length equals the declared algorithm's output length; an unknown or unsupported hashAlgo MUST be rejected.¶

   • Verify that the principal's certificate chain validates to the same configured trust anchor as the agent certificate chain; chains that terminate at different trust anchors MUST be rejected (Fail-Close).¶

   • Verify that the certificate validity period (notAfter - notBefore) does not exceed delegationAuthorization.requestedLifetime, and that requestedLifetime is at most 86400 seconds (1 day).¶

   • Verify that signatureAlgorithm is one of the permitted algorithms: ECDSA with SHA-256 (MUST), ECDSA with SHA-384 or SHA-512 (MAY), RSA with SHA-256 (MUST), RSA with SHA-384 or SHA-512 (MAY), RSA-PSS with SHA-256, SHA-384, or SHA-512 (MAY), or Ed25519 (MAY). Any other algorithm MUST be rejected.¶

5. PA.authorizationConstraints Check: If the PrincipalAuthorization extension in the principal's certificate contains authorizationConstraints, evaluate them. PA constraints limit the authorization behavior and are independent of AIC.authorizationConstraints.¶

6. AIC.authorizationConstraints Check: If AIC.authorizationConstraints is present, evaluate each constraint it recognizes with AND logic. All constraints MUST be satisfied. Unknown constraint types are logged as audit warnings and ignored (forward-compatible). This step is executed before capability evaluation for fast rejection of unauthorized connections.¶

7. Delegation Mode Check: If delegationMode is representative:¶

   • Load the principal's certificate and its PrincipalAuthorization extension.¶

   • Verify allowedMode permits representative delegation.¶

   • Verify that C_agent is a subset of P_grants (P (AND) C (AND) T).¶

8. Delegation Depth Check: If a DelegationDepthControl extension is present, verify that chainDepth does not exceed maxDepth. As a best practice, deployments SHOULD prefer chains within the recommended envelope (chainDepth <= 1). A chain with chainDepth > 1 is not refused by this specification, but its semantics are outside the scope of this revision: a deployment that accepts one relies on its own policy for the responsibility boundaries along the chain.¶

9. Capability Evaluation: For the capability required by the current request, route evaluation to the plugin registered for its schemeId. If no plugin is registered or the capability is unknown, the request MUST be denied. Other capabilities carried in the certificate but not relevant to the current request do not affect the decision.¶

10. Decision: If all validation steps pass, the relying party SHOULD allow the connection. If any step fails, the relying party MUST reject the request. Deployments SHOULD record the rejection with sufficient diagnostic information for audit purposes.¶

5.2. Offline Validation

In offline or air-gapped deployments without access to CRL or OCSP responders, the relying party MUST accept the risk that a revoked certificate may be accepted until the next cache refresh. Mitigations include:¶

• Short certificate validity windows (RECOMMENDED <= 1 hour);¶

• Locally cached CRL shards with freshness checks;¶

• authorizationConstraints evaluated entirely offline during TLS handshake.¶

The principal's certificate is obtained from the Credential Bundle presented by the Agent during TLS handshake (TLS 1.3 allows multiple CertificateEntry messages). If the principal's certificate is not present in the chain and no local cache is available, the gateway MUST reject the connection (Fail-Close). The same-trust-anchor requirement applies in online and offline deployments alike. The transport mechanism for the credential bundle is a deployment detail and is not defined as a new TLS message type by this specification.¶

6.1. ASN.1 Definition

PrincipalAuthorization ::= SEQUENCE {
    version                  INTEGER DEFAULT 1,
    grants                   SEQUENCE SIZE(1..MAX) OF Capability,
    authorizationConstraints [0] EXPLICIT SEQUENCE
        SIZE(0..32) OF Capability OPTIONAL,
    delegationPolicy         [1] EXPLICIT DelegationPolicy OPTIONAL,
    extensions               [2] EXPLICIT AICExtensions OPTIONAL
}

DelegationPolicy ::= SEQUENCE {
    version             INTEGER DEFAULT 1,
    maxAgents           INTEGER DEFAULT 1,
    allowedMode         DelegationModeEnum DEFAULT authorizedOnly,
    maxSessionHours     [0] EXPLICIT INTEGER OPTIONAL
}

DelegationModeEnum ::= INTEGER {
    authorizedOnly        (0),
    representativeAllowed (1)
} (0..1)

The grants field defines the set of capabilities the principal may grant to agents -- serving as the upper bound (P_grants) in the permission intersection model.¶

The authorizationConstraints field carries principal-level authorization boundary constraints, reusing the Capability container with schemeId="varwof/constraint-v1". PA constraints and AIC constraints are evaluated independently -- they operate at different semantic layers and are not in a subset relationship.¶

The delegationPolicy field defines the Principal's delegation boundary: how many concurrent agents are permitted (maxAgents), which delegation modes are allowed (allowedMode), and optionally the maximum session hours (maxSessionHours).¶

maxAgents (in DelegationPolicy) and the max-concurrent constraint (in authorizationConstraints) have distinct semantics: maxAgents limits how many Agent instances the Principal may delegate to concurrently, whereas max-concurrent limits how many concurrent connections a single Agent may establish. They are enforced at different layers (policy boundary vs execution boundary) and are not interchangeable.¶

6.2. Principal Key Rotation

When the principal's private key is compromised and a new key pair is generated, the SPKI hash in principalUid.keyHash changes, causing all existing representative-mode agent certificates to fail authorization checks. This is an intentional design: when the key pair changes, all associated agent certificates are automatically invalidated through a key management operation rather than a revocation broadcast. When the principal renews their certificate using the same key pair, the SPKI remains unchanged and existing agent authorizations continue without requiring re-issuance.¶

7.1. Enterprise/Regulated Model

• The principalUid field MUST be populated with a verifiable natural person identifier.¶

• The delegationAuthorization field MUST be present and cryptographically validated.¶

• Representative mode MUST only be used with explicit PrincipalAuthorization delegation grants.¶

• The agent certificate chain and the principal certificate chain MUST validate to the same configured trust anchor (the agent CA and the principal CA MUST belong to the same trust domain).¶

• Certificate validity SHOULD be short-lived (hours to days).¶

• authorizationConstraints SHOULD carry IP range, concurrency, and time window boundaries.¶

• All AIC-bearing connections SHOULD be logged.¶

7.2. Consumer/Individual Model

• The principalUid MAY be omitted or contain a pseudonymous identifier.¶

• The delegationAuthorization field MAY be omitted for low-risk operations.¶

• Representative mode SHOULD NOT be used.¶

• Deployments in this model prioritize consumer privacy protections over granular identity binding.¶

• When a DelegationAuthorization is present, the same-trust-anchor requirement of Section 5 applies.¶

10.1. Threat Model

This specification considers the following adversary models:¶

Network Attacker (E): A network-level adversary capable of intercepting, modifying, and replaying TLS connections. This adversary does not have access to any private keys.¶

Malicious Agent (M): An authenticated agent in possession of a valid AIC certificate that attempts to escalate privileges, impersonate other agents, or exceed its authorized capabilities.¶

Compromised Principal (P): A principal whose private key has been leaked. The attacker can sign arbitrary DelegationAuthorization payloads using the compromised key.¶

Compromised CA (C): An adversary with access to a CA signing key. This adversary can issue arbitrary certificates and is the most powerful in the model.¶

Trust boundary. This specification assumes a trusted-CA model: the CA issuing the agent certificate correctly binds agentId to the subject public key and faithfully encodes the principal-signed delegation fields in the AIC extension. Compromise of a CA signing key or of a configured trust anchor is outside the protection scope of the mechanisms defined in this document; deployments MUST protect CA signing keys (e.g., HSM or equivalent isolation) and MUST apply the same-trust-anchor requirement of Section 5 so that agent and principal chains share a single trust domain.¶

10.2. Threat Mitigations

10.3. Offline Validation Risks

In offline deployments, the risk of accepting a revoked certificate exists until the next cache refresh. Mitigations include short certificate validity windows and strict authorizationConstraints that limit the blast radius (IP range, concurrency caps).¶

10.4. Authorization Constraint Integrity

The authorizationConstraints field is carried inside the AIC extension, which is covered by the CA signature over the TBSCertificate; a modification of any constraint therefore fails certificate signature validation. The effectiveness of constraint enforcement also depends on the gateway evaluating the constraints it recognizes and on constraint plugins implementing the declared semantics. Constraints are boundary conditions that limit the blast radius of a compromised or malicious agent; they are not a substitute for gateway-local policy controls such as rate limiting or resource quotas.¶

10.5. Principal Key Hash Binding

The principalUid.keyHash field binds the delegation authorization to the principal's public key through the hash algorithm identified by hashAlgo. The hash output is limited to 64 bytes by the ASN.1 SIZE constraint, and a collision in a cryptographically secure hash function is assumed to be computationally infeasible under the security assumptions of the selected hash algorithm. In addition, keyHash is used to locate and bind the principal's certificate within the credential bundle; signature verification uses the principal's public key after certificate chain validation, so a hash collision alone would not enable an attacker to produce a valid principal signature. keyHash itself does not establish trust: trust derives from certificate chain validation and the principal's signature. keyHash is a locator and binding mechanism only.¶

10.6. Nonce Replay Protection

The 32-byte nonce in DelegationAuthTBS is signed as part of the DER encoding, making it a cryptographic input to the principal's signature -- not a plaintext parameter. The CA verifies nonce uniqueness at issuance time and persists used nonces. The gateway MAY optionally maintain a local NonceCache for additional replay detection, but this is not required: the primary defense is the CA-level uniqueness check. Replay protection is therefore enforced at the CA issuance layer (nonce uniqueness at issuance time), not at the gateway runtime; the gateway's optional cache is a secondary defense only.¶

11.1. Private Enterprise Number Assignment

This document uses the IANA Private Enterprise Number 66257, assigned to Varwof PKI (contact: Jijie Wei, pki@varwof.com). The OID prefix is:¶

1.3.6.1.4.1.66257

11.2. OID Registration

The following OIDs are defined in this document:¶

1.3.6.1.4.1.66257.1.1:

AIC Extension (Section AIC Extension Definition)¶

1.3.6.1.4.1.66257.1.2:

PrincipalAuthorization Extension (Section PrincipalAuthorization)¶

1.3.6.1.4.1.66257.1.1.4:

DelegationDepthControl (Section Multi-Level Delegation)¶

Additional OIDs under branch 3 (National/Industry Certification) are reserved for future allocation. The full OID tree is defined in Section OID Tree.¶

11.3. Capability Scheme Registry

This version of the specification does not request an IANA registry. Capability scheme identifiers and constraint types are registered through an external or community registry of scheme identifiers, which follows the vendor/product naming convention. An IANA registry may be requested in a future revision if the scheme namespace is transitioned to IANA administration.¶

The initial entry in the external registry:¶

The http and database scheme identifiers are reserved as examples of externally defined capability schemes; their semantics are defined by the capability schemes themselves and not by this document.¶

13.1. Relationship to WIMSE and SPIFFE

WIMSE and SPIFFE identify workloads through SAN URIs ([SPIFFE]); they do not carry authorization data. AIC composes with them at the certificate layer: an AIC-enabled certificate MAY carry a SPIFFE ID as its URI SAN, and a verifier that enforces AIC admission MAY use the SPIFFE ID as the identity selector for the admission decision.¶

The AIC-specific rules in this composition are limited to the following:¶

• Identifier mapping. When a certificate carries a SPIFFE ID, the AIC extension's agentId is the agent name, corresponding to the final path segment of the SPIFFE ID; the full spiffe:// URI appears in the certificate SAN. New issuance MUST use the plain-name form in agentId. Certificates issued by earlier revisions that stored the full URI in agentId MAY be accepted for backward compatibility, but a relying party MUST NOT treat the SAN URI and agentId as independent identities.¶

• Verification semantics by reference. This specification does not redefine SPIFFE ID syntax or validation. A verifier that enforces a SPIFFE requirement (for example, require-SPIFFE, a trust-domain allowlist, or an exact SPIFFE ID allowlist) MUST validate the SAN URI according to [SPIFFE] and MUST fail closed when the URI is absent, malformed, outside the allowed trust domain, or outside the allowlist.¶

• Renewal continuity. SPIFFE/SPIRE-style workloads commonly rotate short-lived SVIDs. AIC anchors identity to the subject public key via principalUid.keyHash rather than to the certificate fingerprint (see Principal Key Rotation); a renewed SVID that reuses the same key therefore preserves the agent identity and its issued authorization without re-issuance or cascading re-signing. Authorization breaks on key change, not on certificate renewal.¶

Workload API delivery, SVID rotation protocols, and cross-trust- domain federation are outside the scope of this specification; they belong to the SPIFFE/SPIRE ecosystem. AIC's role in that ecosystem is certificate-format and offline-verification compatibility, not the replacement of workload identity lifecycle mechanisms.¶

The reference implementation issues certificates carrying spiffe:// SANs and enforces trust-domain and allowlist checks at the gateway; byte-level conformance of the SPIFFE ID construction and issued-certificate SAN against the SPIRE reference parser is covered by the implementation test suite (see Implementation Status).¶

13.2. Relationship to Standard X.509 Extensions

13.3. Interoperability Test Matrix

13.4. TLS Integration

19.1. Normative References

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC2119]

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

[RFC8174]

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

[RFC4648]

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

[RFC5912]

Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

[RFC6960]

Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.

[RFC7633]

Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, <https://www.rfc-editor.org/info/rfc7633>.

19.2. Informative References

[RFC6749]

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

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/info/rfc9846>.

[RFC3820]

Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. Thompson, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", RFC 3820, DOI 10.17487/RFC3820, June 2004, <https://www.rfc-editor.org/info/rfc3820>.

[RFC5755]

Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, <https://www.rfc-editor.org/info/rfc5755>.

[SPIFFE]

SPIFFE Community, "SPIFFE Standard", May 2022, <https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md>.

[AGTP]

Hood, C., "AGTP Agent Certificate Extension", 28 June 2026, <https://datatracker.ietf.org/doc/draft-hood-agtp-agent-cert/>.

[APKI]

Sharif, R., "Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents", 10 April 2026, <https://datatracker.ietf.org/doc/draft-sharif-apki-agent-pki/>.

[AgentIdentity]

Sharif, R., "X.509 Certificate Profile for Autonomous AI Agent Identity", 31 July 2026, <https://datatracker.ietf.org/doc/draft-sharif-x509-agent-identity-profile/>.

[DAAP]

Kumar, S., "Delegated Agent Authorization Protocol (DAAP)", 2 March 2026, <https://datatracker.ietf.org/doc/draft-mishra-oauth-agent-grants/>.

[AIP]

Singla, P., "Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents", 10 June 2026, <https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/>.

[OpenA2A-AIP]

Fane, A., "OpenA2A Agent Identity Protocol", 6 August 2026, <https://datatracker.ietf.org/doc/draft-fane-opena2a-aip/>.

[CapabilityBound]

Zhou, Z., "Governing Dynamic Capabilities: Cryptographic Binding and Reproducibility Verification for AI Agent Tool Use", 19 March 2026, <https://arxiv.org/abs/2603.14332>.

[AIC-JWT]

Wei, J., "AI Agent Identity Certificate (AIC) JSON Web Token Profile", September 2026, <https://datatracker.ietf.org/doc/draft-wei-aic-jwt/>.

[CLC]

Wei, J., "Capability Language Core", September 2026, <https://datatracker.ietf.org/doc/draft-wei-capability-language-core/>.