AI Agent Identity Certificate (AIC) JSON Web Token Profile

1.1. Problem Statement

The AIC X.509 extension defined in [AIC] binds an AI agent's cryptographic identity to a responsible principal and carries the information needed to determine whether a requested operation is authorized, including the delegated authority, capabilities, authorization constraints, validity, and accountability information. Its design goal is that the authorization decision can be made offline from the certificate and its credential bundle alone, including at the TLS layer.¶

Many deployment contexts cannot present X.509 certificates at the transport layer:¶

• third-party APIs and web applications consume HTTP Authorization headers rather than mTLS client certificates;¶

• web and mobile clients cannot manage client certificates;¶

• OAuth 2.0 [RFC6749] ecosystems use bearer tokens and token exchanges;¶

• serverless and managed gateways terminate TLS on behalf of the application.¶

In these contexts, the AIC data model needs an application-layer carrier. This document defines that carrier as a JSON Web Token (JWT) [RFC7519] secured by JSON Web Signature (JWS) [RFC7515], and names it AIC-JWT.¶

1.2. Relationship to the X.509 AIC Extension

AIC-JWT is a companion profile of the AIC X.509 extension, not a replacement and not a new authorization model. The X.509 AIC extension remains the transport-layer representation used during TLS handshakes in managed, regulated, and air-gapped environments. AIC-JWT carries the same AIC semantic model at the application layer:¶

The two profiles share the same semantic elements, including the agent identity, principal identity, the Capability container (schemeId/capabilityId/parameters), delegation mode, authorization constraints, the DelegationAuthorization structure, the permission intersection model, capability glob matching, and the credential-bundle verification semantics.¶

[AIC] is the authoritative specification for AIC semantics. This document does not redefine those semantics. Where this document and [AIC] could otherwise be read as disagreeing about the AIC model, [AIC] governs the semantics, while this document governs the JWT representation, JWT-specific validation, and OAuth-facing projection.¶

AIC-JWT is a credential representation, not a policy engine. It carries the AIC delegation and constraint semantics for the consumer to evaluate; how a relying party combines those semantics with its own local execution policy is a deployment decision outside this document.¶

1.3. Scope

AIC-JWT is a JWT [RFC7519] profile and does not require OAuth-specific processing, an RFC 9068 access-token profile, or token-exchange semantics. An AIC-aware validator applies the additional validation rules defined by this document to the AIC-JWT claims.¶

This document defines the JWT carrier mapping of the AIC model specified in [AIC], together with the OAuth-facing consumption constraints needed to present that carrier at existing OAuth 2.0 endpoints. The AIC data model -- including delegation modes, capability container semantics, permission intersection, and principal/agent role definitions -- is defined by the AIC specification [AIC] and is not restated or extended here.¶

Normative content includes token structure, claim definitions, the mapping of the AIC data model to JWT claims (Section 5.4), the validation pipeline, credential bundle requirements, the OAuth consumption profile, and IANA registrations. Design principles, deployment architectures, and performance characteristics are informative.¶

Out of scope:¶

• authorization semantics and policy evaluation -- this document does not define or modify how capabilities, grants, or authorization constraints are evaluated; those semantics are defined by [AIC] and deployment policy;¶

• obligations, PDP behavior, or any mechanism that changes the scopes or the authority of an issued token after issuance;¶

• semantic equivalence between capabilities expressed in different vocabularies or across service domains;¶

• new OAuth 2.0 flows or protocols: AIC-JWT is consumed through the existing [RFC7523] JWT bearer grant mechanism. Integration with [RFC8693], DPoP [RFC9449], Token Status Lists [TSL], or [RFC9068] access tokens is deployment-specific and outside this specification.¶

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

1.5. Terminology

This document uses the terms defined in [AIC] (AIC, Agent, Principal, Delegation Mode, Capability, Capability Scheme, Credential Bundle, DelegationAuthorization, DelegationAuthTBS, PrincipalAuthorization, authorizationConstraints, SPKI, PEN). In addition:¶

AIC-JWT:

The outer JWT defined by this specification (typ=aic+jwt), signed by the configured AIC issuer.¶

DA JWT:

The inner JWT (typ=aic+da+jwt) signed by the principal, carrying the principal-signed delegation authorization content defined by [AIC].¶

PA JWT:

An optional companion JWT (typ=aic+pa+jwt) carrying the application-layer representation of the PrincipalAuthorization extension defined by [AIC]. When present, it is part of the credential bundle and is not itself the outer AIC-JWT.¶

Issuer:

The entity that signs the outer AIC-JWT. In PKI deployments, the issuer is a CA or other configured PKI issuer; in OAuth deployments, it is an authorization server (AS).¶

Audit actor vs. OAuth actor:

The audit actor recorded per Section 8.1 is the principal in representative mode (the agent is the executor). This is distinct from the RFC 8693 act claim (Section 5.1.1), which names the executing agent on tokens whose sub is the resource owner. The terms "audit actor" and OAuth act are not semantically equivalent.¶

1.6. Related Work

[DAAP] (draft-mishra-oauth-agent-grants) defines a delegated agent authorization protocol with DID-based agent identity and JWT grant tokens. AIC-JWT differs in architecture: identity is anchored to a PKI/AS trust root, and the principal's consent is carried as a nested principal-signed DA JWT covered by the issuer signature, rather than as a standalone grant produced by a delegated-agent flow. Principal public key resolution may use JWKS in OAuth deployments or a credential bundle in PKI deployments; the trust model is defined by the validation rules of this specification.¶

[OBO] (draft-oauth-ai-agents-on-behalf-of-user) extends OAuth 2.0 flows with requested_actor and actor_token parameters. AIC-JWT is a token format that can be produced by such flows.¶

The WIMSE working group separates workload identifiers (draft-ietf-wimse-identifier) from workload credentials (X.509 WIC and JWT WIT forms; draft-ietf-wimse-workload-creds). These documents identify workloads and do not carry delegation or authorization data. AIC-JWT is the JWT mapping of the AIC model defined in [AIC]; it composes with WIMSE/SPIFFE workload identities at the credential layer, and it does not add authorization semantics of its own. In this composition, WIMSE/SPIFFE identifies the workload; AIC expresses what that agent is authorized to do and by whom.¶

Other delegation-oriented application-layer credential formats, including [ATN], [PEDIGREE], and [HDP], explore related mechanisms for representing delegation and provenance. AIC-JWT instead defines the JWT representation of the AIC model specified in [AIC], including its structured capability container, nested principal authorization, and authorization constraints.¶

3.1. Token Roles and Trust Model

The AIC-JWT trust model has four roles:¶

• Principal: the natural person or organization that signs the DA JWT. The principal's public key is identified by aic.principal.key_hash. In representative mode, the Principal is projected as the OAuth resource owner and is the subject (sub) of the DA and, where applicable, of the issued token; a deployment whose accountable operator differs from the resource owner MUST represent that operator separately and MUST NOT place it in the grant subject (Section 10.2).¶

• Agent: the AI agent presenting the token. The Agent key is bound by cnf at presentation time. In representative mode, the Agent is projected as the OAuth actor and MAY also be the OAuth client presenting the credential; in authorized mode, the Agent MAY occupy sub as the authorized accessor, consistent with the authorization-grant semantics of RFC 7523 Section 3, item 2A.¶

• Issuer: the CA (PKI mode) or OAuth authorization server (AS mode) that validates the DA JWT and signs the outer AIC-JWT. The Principal is not the issuer of the outer AIC-JWT; the Principal signs only the DA JWT.¶

• Verifier/Gateway: the policy enforcement point that validates the AIC-JWT and its credential bundle and makes the access decision according to [AIC] and deployment policy.¶

The issuer's verification key is obtained from configured or otherwise trusted JWKS/x5c material and MAY be cached. The principal's verification key is resolved from trusted JWKS material or, in PKI deployments, from the credential bundle presented with the token. Key resolution does not by itself establish trust; the trust relationship for the resolved key MUST be established by the deployment before the DA is accepted.¶

3.2. Relationship to OAuth 2.0 Roles

In representative mode, the Principal is projected as the resource owner and the Agent as the OAuth actor; the Agent MAY also be the OAuth client presenting the credential. In authorized mode, the Agent is the authorized accessor and MAY occupy sub, consistent with the RFC 7523 authorization-grant semantics (Section 3, item 2A). RFC 7523 distinguishes this authorization-grant use from client authentication, for which sub identifies the OAuth client.¶

AIC-JWT is a self-contained credential: the authorization claims and the principal-signed DA travel inside the token. Self-containment of the credential does not imply offline self-contained verification (Section 9.3). This document does not define an RFC 9068 access-token profile and does not modify RFC 8693. Deployments MAY present AIC-JWT within existing OAuth flows (for example, the DA as an RFC 7523 authorization grant) where their deployment profile permits; conformance of such presentations to RFC 9068 or RFC 8693 is outside this specification.¶

The OAuth act claim identifies the executing Agent in the representative projection; it is distinct from the audit actor defined in Section 8.1, which identifies the Principal represented by the Agent in representative mode.¶

3.3. Relationship to mTLS

AIC-JWT does not require mutual TLS (mTLS). Sender binding MAY be enforced at the application layer using the cnf claim (Section 5.1.1) and, where applicable, DPoP [RFC9449]. Where a deployment uses mTLS, the verifier MAY additionally check that the mTLS client certificate public key corresponds to the key identified by cnf, for example by comparing the JWK thumbprint of the certificate public key with the jkt member. Whether and how mTLS is deployed is a deployment decision and outside the scope of this specification; in particular, offline handshake-time decisions remain the domain of the X.509 AIC (mTLS) profile.¶

4.1. Nested JWS Construction

The AIC-JWT is a nested JWT in which the inner Delegation Authorization (DA) JWT is carried as a claim value in an outer JWS. The nested JWT model is defined by [RFC7519], and the signatures use the JWS mechanisms defined by [RFC7515].¶

1. The principal creates the DA JWT (Section 5.2) and signs it with the principal's private key.¶

2. The agent or issuer constructs the outer payload (Section 5.1) containing the da claim whose value is the complete compact-serialized DA JWT string.¶

3. The issuer signs the outer payload, producing the AIC-JWT.¶

The outer JWS therefore provides integrity protection over the complete DA JWT string as carried in the da claim. Any modification of the inner JWT -- including its JOSE header, payload, or signature -- changes the outer payload and causes outer signature verification to fail.¶

The AIC-JWT uses the JWS compact serialization, as does the inner DA JWT.¶

The da claim value MUST be processed as the exact compact-serialized DA JWT string received in the outer payload. A verifier MUST NOT reconstruct or reserialize the DA JWT before performing inner JWS signature verification.¶

4.2. Outer JOSE Header

The outer header MUST contain:¶

• alg: a JOSE algorithm permitted by Section 4.5. The value none MUST NOT be used.¶

• typ: the string aic+jwt.¶

• kid: the identifier of the issuer's signing key, per [RFC7515] Section 4.1.4.¶

The outer header MAY contain x5c or x5t when the issuer's signing key is represented by an X.509 certificate. An x5c value MAY provide the X.509 certificate chain needed for certificate-based key validation; an x5t value identifies an X.509 certificate by its thumbprint. The presence of x5c or x5t MUST NOT by itself establish trust; verifiers MUST validate the issuer key against their configured trust policy.¶

4.3. Inner DA JOSE Header

The DA JWT header MUST contain:¶

• alg: a JOSE algorithm permitted by Section 4.5.¶

• typ: the string aic+da+jwt.¶

• kid: the identifier of the principal's signing key.¶

The DA JWT MUST NOT be accepted as a standalone AIC-JWT or access token. Verifiers operating in an AIC-JWT context MUST validate the typ value and apply the DA-specific validation rules defined by this specification. The distinct typ value provides explicit JWT typing and helps prevent cross-type token confusion.¶

4.4. PA JOSE Header

When the optional PA JWT (Section 5.3) is used, its header MUST contain:¶

• alg: a JOSE algorithm permitted by Section 4.5.¶

• typ: the string aic+pa+jwt.¶

• kid: the identifier of the PA signing key.¶

In pure-JSON and OAuth deployments, the PA JWT is signed by the issuer that attests the principal identity; in the AS mode of Section 10.2 this is the same issuer that signs the outer AIC-JWT. In PKI deployments the PrincipalAuthorization is carried in the principal's X.509 certificate rather than as a PA JWT, and the PA JWT form is not used. Verifiers MUST validate the PA signing key and its trust relationship before accepting the PA (Section 5.3).¶

4.5. Algorithm Allowlist

The following JOSE algorithms are permitted, mirroring the signature algorithm policy of the X.509 AIC specification:¶

The allowlist is based on the algorithm set of the SPIFFE JWT-SVID specification ([RFC7518] Sections 3.3-3.5), with EdDSA added so that tokens can be verified by both JWT-SVID and AIC-JWT validators and by Ed25519-based deployments. Interoperable deployments SHOULD use ES256 or RS256.¶

Implementations MUST reject all other algorithms, including symmetric MAC algorithms such as HS256. Implementations MUST follow the JWT Best Current Practices of [RFC8725]: the alg value MUST be validated against the allowlist before signature verification, and the selected verification key MUST be compatible with the declared algorithm and key type.¶

The kid value is used only to select a candidate verification key from a trusted and appropriately scoped key set. A kid value MUST NOT by itself establish trust.¶

5.1. Outer Claims

The outer payload is a JSON object. AIC-specific claims are carried inside the namespaced aic claim to avoid collisions with registered JWT and OAuth claims.¶

5.2. DA JWT Payload

The DA JWT payload carries the principal-signed delegation authorization content defined by [AIC]; it is the JWT counterpart of the X.509 DelegationAuthTBS signing structure, not a byte-level encoding of it. In addition to the AIC members below, every DA JWT MUST carry the RFC 7523 claims iss, sub, aud, exp and jti:¶

{ "ver": 2, "iss": "corp.com:zhangsan", "sub": "corp.com:zhangsan", "aud": "https://as.example.com", "exp": 1755503600, "iat": 1755500000, "jti": "<same value as nonce>", "agent_id": "agent:db-analyst-01", "principal": { ... same structure as aic.principal ... }, "reason": { "code": "DATA_ANALYSIS", "desc": "Scheduled data analysis window" }, "capabilities": [ ... ], "delegation_mode": "representative", "constraints": [ ... ], "requested_lifetime": 3600, "ts": 1755500000, "nonce": "<base64url of 32 random bytes>" } ¶

• ver (REQUIRED): 2. ver=2 is the DA claim set defined by this revision (-01); ver=1 is the -00 claim set and MUST be rejected by -01 implementations (fail closed rather than silently downgraded). da.ver is the DA claim-set version and is distinct from aic.ver (the AIC-JWT profile version).¶

• iss (REQUIRED): the principal identifier realm:id; MUST equal the realm and id of the principal binding (RFC 7523 issuer).¶

• sub (REQUIRED): mode-dependent grant subject. In authorized mode MUST equal agent_id; in representative mode MUST equal the resource owner / principal realm:id (RFC 7523 Section 3, item 2A allows the resource owner or an authorized delegate).¶

• aud (REQUIRED): MUST identify the intended authorization server (token endpoint) that will redeem the grant.¶

• exp (REQUIRED): MUST equal ts + requested_lifetime (a single, canonical expiry expression).¶

• iat (OPTIONAL): if present MUST equal ts.¶

• jti (REQUIRED): MUST equal nonce (RFC 7519 replay identifier).¶

• agent_id (REQUIRED): the agent identifier. In authorized mode it MUST equal the outer sub; in representative mode it MUST equal the outer act.sub and the OAuth client_id.¶

• principal (REQUIRED): MUST equal the outer aic.principal. The key used to verify the DA JWT signature MUST correspond to the principal key identified by principal.key_hash and principal.hash_alg.¶

• reason (REQUIRED): code (1 to 64 characters, controlled vocabulary, e.g., SCHEDULED_MAINTENANCE, AUTO_RENEWAL, DATA_ANALYSIS) and desc (1 to 512 characters, human readable).¶

• capabilities (REQUIRED): MUST equal the outer aic.capabilities.¶

• delegation_mode (REQUIRED): MUST equal the outer aic.delegation_mode.¶

• constraints (OPTIONAL): MUST equal the outer aic.constraints.¶

• requested_lifetime (REQUIRED): 1 to 86400 seconds; SHOULD be 3600 to 86400.¶

• ts (REQUIRED): NumericDate of the principal's signature.¶

• nonce (REQUIRED): the unpadded base64url encoding of exactly 32 octets from a CSPRNG, used for replay prevention. The issuer MUST check uniqueness and persist used nonces.¶

The signing input is the UTF-8 encoding of the JWS payload as defined by RFC 7515 (that is, the payload is not a DER encoding; JSON field order in the signed payload is the order produced by the JWS serialization and MUST be preserved as signed).¶

5.3. PA JWT Payload

The optional PA JWT carries the JSON representation of the PrincipalAuthorization extension defined by [AIC]. It is REQUIRED in representative mode when no principal X.509 certificate with the PrincipalAuthorization extension is present in the bundle.¶

In pure-JSON and OAuth deployments, the PA JWT MUST be signed by the issuer that attests the principal identity; in the AS mode of Section 10.2 this is the same issuer that signs the outer AIC-JWT, and the PA JOSE header kid (Section 4.4) identifies that signing key. In PKI deployments the PrincipalAuthorization is carried in the principal's X.509 certificate, and the PA JWT form is not used:¶

{ "ver": 1, "principal": { ... same structure as aic.principal ... }, "grants": [ ... capabilities ... ], "constraints": [ ... ], "delegation_policy": { "max_agents": 1, "allowed_mode": "authorized_only" | "representative_allowed", "max_session_hours": 24 }, "extensions": { ... } } ¶

• principal (REQUIRED): the principal to which the PA JWT belongs.¶

• grants (REQUIRED, 0 to 256 entries): the principal's capability grants; the upper bound P_grants.¶

• constraints (OPTIONAL): principal-level authorization boundary constraints, evaluated independently from aic.constraints.¶

• delegation_policy (OPTIONAL): max_agents (default 1), allowed_mode (authorized_only default or representative_allowed), and optional max_session_hours.¶

• extensions (OPTIONAL): same structure as aic.extensions.¶

Alternatively, in PKI mode, the principal's X.509 certificate carrying the PrincipalAuthorization extension MAY be presented in the bundle as x5c; the verifier then evaluates the ASN.1 form.¶

5.4. Mapping from ASN.1

6.1. Capability Object

Each capability is a JSON object:¶

{ "scheme": "http", "id": "GET:/api/v1/users", "params": { "max_rows": 100 } } ¶

• scheme (REQUIRED): the capability scheme identifier, 1 to 128 characters. The scheme is the namespace that defines the semantics of the capability, including identifier matching and parameter subset rules. The scheme value MUST be matched exactly; wildcards MUST NOT be used in the scheme member, and a capability with scheme="*" MUST NOT be used (a bare * is not a cross-scheme capability). Unknown schemes MUST be rejected unless the verifier has an explicit scheme-specific implementation or plugin for that scheme (fail-closed).¶

• id (REQUIRED): the capability identifier within the scheme, 1 to 256 characters. The syntax and matching semantics of id are defined by the capability scheme; the HTTP-style examples in this section use the identifier matching rules of Section 6.2.¶

• params (OPTIONAL): a JSON value (object, array, string, number, or boolean) whose semantics are defined by the scheme. When serialized, params MUST NOT exceed 512 bytes.¶

The Capability object is the unified container reused in three contexts: aic.capabilities, aic.constraints, and PA grants. Although the container is the same, the authorization role of each context is defined by the AIC semantic model; reuse does not imply semantic equivalence.¶

Capability matching and parameter-subset evaluation define the effective AIC authorization input; they are not the final execution decision of a resource server or gateway. Deployment-local execution policy is outside the AIC-JWT credential.¶

6.2. Identifier Matching

For schemes that use the HTTP-style capability syntax, the matchable identifier is the full identifier scheme + ":" + id (for example, http:GET:/api/v1/users). The scheme member is the exact first component of the full identifier and MUST NOT be wildcarded; the glob operators below apply to the id portion after the scheme prefix.¶

A scheme-level wildcard (scheme:*) MUST NOT be used; scheme is always exact. A bare * without a scheme prefix MUST NOT be interpreted as a cross-scheme capability.¶

The full identifier is matched as a two-level token stream: the pattern and target are first split on : into the scheme and id components, and each id component is then split on /. * matches exactly one path segment that does not contain / (or one colon-segment in the method position), while ** matches one or more segments and MAY cross / boundaries. Within a literal segment, {a,b} alternation matches one of the alternatives and [a-z] character classes match a single character in the class; an embedded * matches any characters within the segment (for example, [A-Z]*).¶

Precedence is limited to specificity: literal segments are more specific than *, and * is more specific than **. Alternation and character classes are per-segment matching operators and do not by themselves define an authorization precedence. If more than one capability pattern matches, the scheme defines whether and how the matching entries combine, and the result MUST be deterministic. If no capability grant matches the requested capability, the capability MUST be denied.¶

The exact syntax, escaping rules, and matching algorithm for a given capability scheme are defined by that scheme; the HTTP-style rules in this section MUST NOT be assumed for an unknown or unrelated scheme. This algorithm is verified by the reference implementations (Go and TypeScript/WebCrypto) against the examples in this section.¶

6.3. Capability Subset and Parameter Semantics

Authorization between a principal grant and an agent capability is a subset relation:¶

C_agent <= P_grant

meaning the agent capability is within the authority granted by the principal grant. The definition of this relation is scheme-specific: a capability scheme MUST define how identifiers and params are compared and what constitutes a valid subset.¶

For example, an HTTP-style scheme MAY treat P_grant.params.max_rows = 1000 and C_agent.params.max_rows = 100 as a valid subset (100 <= 1000), and max_rows = 5000 as invalid.¶

If C_agent.params is not a valid subset of P_grants.params under the scheme-defined relation, the credential MUST be rejected; a verifier MUST NOT silently filter or rewrite the signed agent capability. Where the subset relation holds, the effective parameter value is the agent value (which is at least as restrictive as the grant), evaluated according to scheme semantics.¶

This specification does not define a universal ordering or intersection operation over arbitrary JSON values; scheme-specific implementations MUST define subset semantics for every parameter type they support.¶

The effective AIC authorization is obtained by evaluating agent capabilities against principal grants and the applicable AIC authorization constraints (Section 7). The final execution decision MAY additionally be restricted by deployment-local gateway or resource-server policy, which is outside the AIC-JWT credential.¶

8.1. Delegation Modes

authorized (default): the Agent acts in its own name. The audit log records sub (agentId) as the actor and aic.principal.id as the authorizing principal. The effective capability set is established at issuance and cryptographically bound to the credential; unless a deployment explicitly requires dynamic grant evaluation, the verifier does not re-fetch or re-evaluate the principal's grants for each operation. Narrow scope x longer lifetime (up to 24 hours with renewed DA on renewal).¶

representative: the Agent acts in the principal's name. The audit log records aic.principal.id as the actor and act.sub (the agentId) as the executor. The bundle MUST contain the principal's PA material. At issuance and at runtime, C_agent MUST be a subset of the principal's current grants P_grants(t). Wide scope x short lifetime, with runtime P_grants(t) intersection at each operation.¶

8.2. Permission Intersection

The effective AIC authority is the intersection of principal grants and agent capabilities, further restricted by the token's AIC constraints:¶

P_aic = P_grants (AND) C_agent Permit_AIC(request) = CapabilityMatch(request, P_aic) (AND) ConstraintsSatisfied(request, aic.constraints) ¶

In authorized mode the intersection is established at issuance (P_grants(t0)) and locked into the token. In representative mode the intersection is computed at runtime against the principal's current grants P_grants(t) for each operation. Gateway local runtime policy (T_policy) is an additional enforcement layer and MUST NOT be confused with the AIC authorization layers:¶

Permit(request) = Permit_AIC(request) (AND) GatewayPolicy(request, T_policy) ¶

8.3. Multi-level Delegation

Single-level delegation (Principal -> Agent, chain_depth=0) MUST be supported and is the default. Depth-1 chains (Principal -> Agent -> sub-Agent, chain_depth=1) MAY be supported. Multi-level delegation requires an explicit delegation authority at each delegating level: an agent may delegate only if the DA that authorized it carries an explicit right to delegate (for example, a may-delegate capability or a delegation-policy allowance with an explicit depth bound); an agent without that right MUST NOT sign a DA for a sub-agent.¶

Each hop in a supported chain produces an independently signed DA JWT. The signer of a hop is the delegating agent; the original principal remains the root authorizing party and MUST be identified separately from the hop signer (delegator vs. delegate vs. root principal). The delegator's own DA MUST record the delegation right and the current chain_depth; capabilities are recursively narrowed along the chain. Verification of a hop MUST establish all of the following: the hop signer holds an explicit delegation authority; the delegated capabilities are a subset of the delegator's effective capabilities; chain_depth increases by exactly one per hop; and chain_depth does not exceed max_depth. Cycles are prevented by strictly monotonic chain_depth. Deployments SHOULD use max_depth = 1; larger values MAY be supported only with equivalent chain-size, capability- narrowing, and resource limits. A sub-agent at the configured max_depth MUST NOT delegate further. Credential bomb attacks are limited by a gateway-configured maximum bundle size (default 8 certificates or equivalent tokens).¶

9.1. Bundle Composition

The credential bundle is an optional deployment mechanism and the JSON analog of the X.509 credential bundle. It is presented with the AIC-JWT to avoid online principal key resolution. It is RECOMMENDED in PKI deployments and in deployments where the principal's key is not reliably resolvable online; when online resolution is available (for example, from a principal JWKS), the bundle MAY be omitted. The bundle contains:¶

• the AIC-JWT (outer token);¶

• the principal key material:¶

  • in PKI mode: the principal's X.509 certificate chain (x5c), from which the verifier extracts the SPKI and computes hash_alg(SPKI); or¶

  • in pure-JSON mode: the principal's JWK, from which the verifier computes the RFC 7638 thumbprint;¶

• in representative mode: the PA JWT or the principal certificate carrying the PrincipalAuthorization extension;¶

• optionally, intermediate CA certificates or issuer JWKS entries.¶

9.2. Principal Binding Check

The verifier MUST compute the binding from the principal key material (from the credential bundle, an online JWKS, or a locally cached copy) and MUST compare it to aic.principal.key_hash. The binding method is determined by hash_alg:¶

• SPKI hash: key_hash = base64url(hash_alg(SPKI)), with hash_alg defaulting to SHA-256. The default binding is SHA-256 over the DER-encoded SPKI; additional hash algorithms MAY be specified by the AIC registry.¶

• JWK thumbprint: key_hash = jkt per RFC 7638, hash_alg = "jkt". The value jkt denotes the RFC 7638 JWK Thumbprint binding method (computed with SHA-256 over the canonical JWK members); it is not itself a hash algorithm name.¶

Mismatch MUST cause rejection (fail-closed). A successful binding check does not by itself establish trust in the Principal; the resolved key MUST also satisfy the verifier's configured trust policy. The same SPKI-hash design rationale as the X.509 profile applies: certificate renewal with the same key pair preserves the binding; key rotation invalidates all existing delegations without broadcast revocation.¶

9.3. Cached Verification and Disconnected Deployments

AIC-JWT is designed primarily for application-layer verification with online or cached trust and status information; it does not claim offline self-contained verification (that property belongs to the X.509 AIC profile and its credential bundle). In air-gapped deployments that still use the JSON profile, the verifier MUST accept the risk that a token revoked after its last status check may be accepted until the next cache refresh; mitigations include short lifetime windows (RECOMMENDED <= 1 hour) and locally cached status lists. Deployments that require offline self-contained authorization decisions SHOULD use the X.509 AIC (mTLS) profile instead.¶

9.4. Browser Key Material

Browsers have no native ASN.1/DER or X.509 parsing API. Consequently, the x5c bundle path (SPKI hash of an X.509 certificate) is not available in browser-only deployments without a third-party ASN.1 library or a server-side helper (Section 10.5, Mode B). Browser deployments SHOULD use the JWK thumbprint form (hash_alg: "jkt") exclusively. When the originating credential is X.509-based, a trusted server-side component MAY perform the X.509-to-JWK conversion before key material reaches the browser.¶

10.1. PKI Mode

In PKI mode the DA is presented to a CA rather than redeemed at an authorization server: aud (Section 5.2) identifies the configured AIC issuance service that is authorized to accept the DA, and the CA validates it when configured.¶

1. The Agent generates a key pair and constructs an issuance request containing the desired capabilities, delegation mode, constraints, and a 32-byte nonce.¶

2. The principal reviews the request (least privilege; wildcard capabilities require explicit confirmation), signs the DA JWT (Section 5.2), and returns it to the Agent.¶

3. The Agent submits the DA JWT to the CA.¶

4. The CA validates: the DA JWT signature against the principal key identified by principal.key_hash; nonce uniqueness (persisted); in representative mode, that capabilities are a capability-level and parameter-level subset of P_grants.¶

5. The CA constructs and signs the outer AIC-JWT, with exp - iat = min(requested_lifetime, local policy cap) and exp not exceeding the DA exp (Section 5.1.1).¶

Where a DA-level Agent key binding is present (a future DA claim-set revision aligned with the X.509 AIC DA v2), the CA MUST verify that the key identified by cnf matches that binding before signing; in this revision the presented Agent key is bound by cnf at consumption time.¶

10.2. OAuth Authorization Server Mode

1. The principal provides consent through an applicable OAuth authorization or delegation flow (for example, an authorization-code flow combined with a deployment-specific actor/delegation mechanism, or an OBO-style flow).¶

2. The Agent presents the principal-signed DA JWT with the token request as an [RFC7523] authorization grant (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, the DA JWT as the assertion parameter). A scope parameter MAY accompany the grant but MUST NOT extend the capabilities carried in the DA JWT. Client authentication at the token endpoint follows standard OAuth 2.0 practice and is outside this specification.¶

3. The AS validates the DA JWT under both the JWT bearer assertion requirements of RFC 7523 (signature, iss, aud, and expiry) and the AIC-JWT DA rules of Section 5.2: exp MUST equal ts + requested_lifetime and MUST NOT have passed (subject to configured clock skew); the DA identifier (jti/nonce) MUST be unique within the configured replay-detection window; and the per-mode sub rules of Section 5.2 apply. It then issues the outer AIC-JWT signed with the AS key, with exp bounded per Section 5.1.1 and role placement per Section 3.2. An AS MAY require the DA sub to equal the subject identifier it registers for the resource owner, verifying the mapping from the principal binding before issuance.¶

4. The AS MAY expose a JWKS endpoint and Token Status List [TSL] for verification and revocation.¶

The AS MUST NOT sign the outer token without a valid principal-signed DA JWT (full profile), preserving the two-layer trust model. Where a DA-level Agent key binding is present (a future DA claim-set revision aligned with the X.509 AIC DA v2), the AS MUST verify that the key identified by cnf matches that binding before signing; in this revision the presented Agent key is bound by cnf at consumption time.¶

If the DA JWT is invalid or cannot be validated, the AS MUST return the invalid_grant error as required by RFC 7523 Section 3.1.¶

Where the accountable operator of the agent differs from the resource owner (for example an enterprise-operated agent acting on an end user's data), the operator MUST be represented by a separate binding outside the grant subject. This profile records that binding as future work and does not conflate the two parties.¶

10.3. Lightweight Consumer Profile

For low-risk consumer deployments, the DA JWT MAY be omitted and delegation_mode MUST be authorized. The issuer signs the outer token directly from principal consent recorded in the issuance process. This profile mirrors the consumer model of the X.509 specification and MUST NOT be used in representative mode.¶

The lightweight profile does not provide the cryptographic principal authorization attestation of the full profile; its trust depends on the issuer's authenticated consent-recording process. A token without a da claim is valid only under this profile and MUST NOT be accepted under full-profile validation, which requires the da claim (Section 5.1.3).¶

10.4. Token Exchange Usage

This section is informative. Deployments that already use [RFC8693] MAY carry an AIC-JWT as an actor or subject token. Role mapping follows RFC 8693; AIC claims are carried in the token unchanged. This specification does not alter RFC 8693 semantics and does not define an RFC 8693 profile for AIC-JWT.¶

10.5. Deployment Architectures

Three deployment architectures are supported and MAY be combined:¶

Mode A - Pure OAuth/JSON (no X.509). All key material is JWK; principal binding uses hash_alg: "jkt"; trust bootstrap uses JWKS; revocation uses Token Status Lists [TSL]. No ASN.1/DER or X.509 processing is required anywhere in the stack. This is the RECOMMENDED mode for browser, web, and OAuth-native deployments.¶

Mode B - Hybrid with a server-side PKI helper. A browser or application-layer client performs what WebCrypto supports natively (JWS verification, JWK thumbprints, DPoP), while a server-side helper (an authorization server, a gateway, or a dedicated service such as a Go reference implementation) performs the PKI operations that browsers cannot: X.509 certificate parsing and chain validation, CRL/OCSP processing, hardware-key-backed signing, and mTLS client-certificate cross-checks. The helper MAY translate X.509 AIC credentials into AIC-JWTs (Section 10.6) or expose principal keys as JWKs so that browser verifiers only ever handle JWK material.¶

Mode C - PKI (X.509) mode. The X.509 AIC profile with mTLS is used as the primary carrier; an AIC-JWT MAY still be generated as an application-layer representation when an application protocol requires it (Section 10.6).¶

10.6. X.509 AIC Interoperability

When the same authorization is carried in both profiles, the following equivalences apply:¶

• key binding: aic.principal.key_hash with a SHA-2 hash_alg (SPKI hash) and the [RFC7638] JWK thumbprint of the same key are two interoperable representations of a public key binding for the same underlying key; a helper MAY convert a presented X.509 certificate to a JWK and a verifier MAY accept either form;¶

• DelegationAuthorization: the ASN.1 DelegationAuthTBS and the DA JWT payload carry the AIC DelegationAuthorization semantic fields defined by [AIC]; the DA JWT additionally carries the RFC 7523 claims iss, sub, aud, exp, iat, and jti, which have no ASN.1 counterpart in the X.509 profile. A PKI helper MAY translate between the two for issuance, verification, or audit;¶

• PrincipalAuthorization: the ASN.1 extension and the PA JWT carry the same grants, constraints, and delegation policy;¶

• issuance: a server-side helper MAY accept an X.509 AIC credential bundle and issue the equivalent AIC-JWT (Mode B), so that the same authorization semantics can be enforced at the transport layer (mTLS) and at the application layer (Bearer).¶

Interoperability between the two profiles is a deployment mechanism, not a new token format; both profiles share the data model defined by [AIC].¶

12.1. Outer AIC-JWT

Header:¶

{ "alg": "ES256", "typ": "aic+jwt", "kid": "ca-2026-01" } ¶

Payload:¶

{ "iss": "https://ca.example.com/aic", "sub": "corp.com:zhangsan", "act": { "sub": "agent:db-analyst-01" }, "aud": ["https://gw.example.com"], "iat": 1755500000, "exp": 1755503500, "jti": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA", "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyHnXgk7dNsQo0c1V3iR4vY" }, "aic": { "ver": 1, "principal": { "realm": "corp.com", "id": "zhangsan", "key_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "hash_alg": "sha-256" }, "delegation_mode": "representative", "capabilities": [ { "scheme": "database", "id": "query:SELECT", "params": { "max_rows": 100 } } ], "constraints": [ { "scheme": "varwof/constraint-v1", "id": "allowed-cidr", "params": ["10.0.0.0/8"] } ], "chain_depth": 0, "max_depth": 1 }, "da": "<DA JWT from Section 12.2>" } ¶

12.2. Inner DA JWT

Header:¶

{ "alg": "ES256", "typ": "aic+da+jwt", "kid": "principal-zhangsan-2026" } ¶

Payload:¶

{ "ver": 2, "iss": "corp.com:zhangsan", "sub": "corp.com:zhangsan", "aud": "https://ca.example.com/aic", "exp": 1755503500, "iat": 1755499900, "jti": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA", "agent_id": "agent:db-analyst-01", "principal": { "realm": "corp.com", "id": "zhangsan", "key_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "hash_alg": "sha-256" }, "reason": { "code": "DATA_ANALYSIS", "desc": "Scheduled production data analysis window" }, "capabilities": [ { "scheme": "database", "id": "query:SELECT", "params": { "max_rows": 100 } } ], "delegation_mode": "representative", "constraints": [ { "scheme": "varwof/constraint-v1", "id": "allowed-cidr", "params": ["10.0.0.0/8"] } ], "requested_lifetime": 3600, "ts": 1755499900, "nonce": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA" } ¶

13.1. Algorithm Confusion

Follow [RFC8725]: validate the alg allowlist, resolve kid to the expected key, reject none and symmetric algorithms, and reject unexpected typ values. AIC-JWT MUST always be asymmetric.¶

13.2. Token Theft and Replay

AIC-JWT is not inherently sender-constrained: in a deployment that does not enforce proof of possession, a party in possession of the token can use it as a bearer credential until expiry. Deployments MUST use TLS. The token MUST carry cnf binding it to the Agent key, and deployments SHOULD additionally use DPoP [RFC9449] (or an equivalent proof-of-possession mechanism) to prevent token theft and replay. Where higher assurance is required, the AS MAY challenge the principal with step-up authentication [RFC9470] before issuing or refreshing tokens. Where mTLS is deployed, the verifier MAY cross-check the mTLS client certificate key against cnf (Section 3.3). Replay is additionally bounded by the DA nonce/jti uniqueness check at issuance and by the short lifetime. The nonce is a signed input of the DA JWT, not a plaintext parameter.¶

13.3. Audience Confusion

The aud claim MUST be validated per [RFC7519] and the deployment's audience policy. Issuers MUST use distinct issuer identifiers per trust domain (RFC 9207) so that a token issued by one AS cannot be accepted by another.¶

13.4. Nested Token Confusion

The DA JWT and the AIC-JWT use distinct typ values (aic+da+jwt vs aic+jwt). A DA JWT MUST NOT be accepted as an AIC-JWT, and an AIC-JWT MUST NOT be accepted as a DA JWT. Verification of the inner token MUST use the principal key identified by the DA's principal, never the issuer key.¶

13.5. Principal Key Binding

The principal binding is a hash of the principal's SPKI (or JWK thumbprint). Under the security assumptions of the selected hash algorithm, collisions are computationally infeasible. The hash is a locating and binding mechanism, not a trust anchor: trust comes from the bundle key material cross-check and the DA signature verification.¶

13.6. Threat Model

The threat model of the X.509 AIC specification applies:¶

• network attacker (no private keys): mitigated by TLS, signatures, and token binding;¶

• malicious Agent (valid token, attempts escalation): mitigated by capability subset checks, constraint evaluation, and fail-closed capability routing;¶

• compromised Principal (key leak): mitigated by SPKI-hash binding -- key rotation invalidates all existing delegations;¶

• compromised CA/AS: mitigated by the two-layer signature -- the attacker still cannot forge a principal-signed DA JWT. A compromised issuer could re-issue an outer token with a different cnf key; DA-level Agent key binding (a future DA claim-set revision) closes this gap, and deployments that require principal-to-key binding MUST constrain issuance policy accordingly until that binding is available.¶

13.7. Size Limits

• aic.capabilities: 1 to 256 entries; more MUST be rejected.¶

• aic.constraints: 0 to 32 entries; more MUST be rejected.¶

• params when serialized: at most 512 bytes.¶

• aic.extensions: at most 32 entries.¶

• Recommended total token size: 16 KB (compact); hard limit 64 KB. Unlike the X.509 profile, no TLS handshake limit applies at the application layer, but excessive sizes MUST be rejected to prevent denial of service.¶

13.8. Web Browser Runtime Considerations

The reference TypeScript implementation uses WebCrypto only (crypto.subtle, TextEncoder/TextDecoder, btoa/atob, BigInt) and was verified in Node and in WebCrypto-compatible runtimes. The following browser constraints were verified and MUST be taken into account by browser implementations:¶

• All cryptographic operations are asynchronous; the validation pipeline MUST be implemented with promises/async.¶

• WebCrypto ECDSA signatures are raw R||S, which is JOSE-compatible; no DER conversion is required.¶

• A DPoP proof header MUST carry the public key only. Including the private JWK (with d and key_ops: ["sign","verify"]) causes key import with usages: ["verify"] to fail in WebCrypto implementations.¶

• When importing a JWK (from a DPoP header or elsewhere), key_ops MUST be removed or aligned with the requested usages.¶

• RSA-PSS signing and verification require an RSA-PSS key; a key generated for RSASSA-PKCS1-v1_5 MUST NOT be used for PS256.¶

• Ed25519 WebCrypto support varies by runtime and browser version; implementations MUST feature-detect Ed25519 before using EdDSA.¶

• WebCrypto hash algorithms are limited to SHA-1/SHA-256/SHA-384/ SHA-512. sha3-*, sm3, and BLAKE2/BLAKE3 are NOT available and require WASM libraries when those hash_alg values are used.¶

• Browsers cannot access TPM/HSM/smart-card keys directly. WebAuthn covers only RP-scoped challenge signing and MUST NOT be assumed to sign arbitrary DA payloads; hardware-backed principal signing in browser scenarios SHOULD be delegated to a server-side helper (Section 10.5, Mode B).¶

• Browsers do not expose the mTLS client certificate to script; the Section 3.3 cnf/mTLS cross-check is therefore not available in browsers. DPoP is the sender-binding mechanism for browser deployments.¶

• Long-running background agents are constrained by page and service worker lifecycles; browser-hosted agents SHOULD be session-scoped, with long-running execution delegated to a backend.¶

15.1. Media Type Registration

Register the media type application/aic+jwt, following the template of RFC 9068's application/at+jwt.¶

15.2. JWT Claims Registration

Register the following JWT claims in the IANA JSON Web Token Claims registry:¶

Members of the DA and PA JWT payloads are namespaced member names carried inside those JWTs; they are not registered as standalone top-level JWT claims.¶

15.3. OAuth Token Type URN

This document does not request registration of an OAuth token type URN.¶

15.4. OAuth Authorization Server Metadata

This document does not request any OAuth Authorization Server Metadata entries.¶

21.1. Normative References

[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/rfc/rfc2119>.

[RFC4648]

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

[RFC6749]

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

[RFC7515]

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

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[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/rfc/rfc8174>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[RFC9207]

Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, <https://www.rfc-editor.org/rfc/rfc9207>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[TSL]

Looker, T., Bastian, P., and C. Bormann, "Token Status List", June 2026, <https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/>.

[AIC]

Wei, J., "AI Agent Identity Certificate (AIC) X.509 v3 Extension", August 2026, <https://datatracker.ietf.org/doc/draft-wei-aic-identity-cert/>.

21.2. Informative 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/rfc/rfc5280>.

[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/rfc/rfc7942>.

[DAAP]

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

[OBO]

Dissanayaka, A., "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", August 2025, <https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/>.

[ATN]

Somoza, J., "ATN Agent Trust Negotiation", May 2026, <https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/>.

[PEDIGREE]

Rampalli, V., "PEDIGREE Verifiable Delegated Identity", 2026, <https://datatracker.ietf.org/doc/draft-rampalli-pedigree/>.

[HDP]

"Human Delegation Provenance Protocol", 2026, <https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/>.