Network Working Group J. Wei Internet-Draft Individual Intended status: Experimental 25 August 2026 Expires: 26 February 2027 AI Agent Identity Certificate (AIC) JSON Web Token Profile draft-wei-aic-jwt-00 Abstract This document defines the JSON Web Token (JWT) profile of the AI Agent Identity Certificate (AIC), a companion specification to draft- wei-aic-identity-cert-00. The AIC X.509 extension binds an AI Agent's cryptographic identity to a responsible principal, carries a structured capability container, authorization boundary constraints, delegation mode, and principal-signed delegation evidence, and enables fully offline authorization decisions at the TLS layer. AIC-JWT encodes the same data model as an application-layer JWT so that the same authorization semantics can be enforced by HTTP APIs, web applications, and OAuth 2.0 ecosystems where transport-layer certificate presentation is not available. The specification defines: * a nested JWS structure that preserves the two-layer signature model of AIC -- a principal-signed DelegationAuthorization (DA) JWT embedded in and covered by an issuer-signed outer JWT; * a namespaced aic claim carrying agent identity, principal binding, structured capabilities, delegation mode, and authorization constraints; * principal binding by SPKI hash or JWK thumbprint, with optional credential bundle presentation in PKI deployments; * issuance flows for both PKI-based CAs and OAuth 2.0 authorization servers, including RFC 7523 assertion exchange and RFC 8693 token exchange; * validation rules, IANA registrations, and security considerations aligned with the OAuth 2.0 and JOSE specifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Wei Expires 26 February 2027 [Page 1] Internet-Draft AIC-JWT August 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to the X.509 AIC Extension . . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Related Work . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Token Roles and Trust Model . . . . . . . . . . . . . . . 8 3.2. Relationship to OAuth 2.0 Roles . . . . . . . . . . . . . 8 3.3. Relationship to mTLS . . . . . . . . . . . . . . . . . . 9 4. Token Structure . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Nested JWS Construction . . . . . . . . . . . . . . . . . 9 4.2. Outer JOSE Header . . . . . . . . . . . . . . . . . . . . 9 4.3. Inner DA JOSE Header . . . . . . . . . . . . . . . . . . 10 4.4. PA JOSE Header . . . . . . . . . . . . . . . . . . . . . 10 4.5. Algorithm Allowlist . . . . . . . . . . . . . . . . . . . 10 5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Outer Claims . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Standard Claims . . . . . . . . . . . . . . . . . . . 12 5.1.2. The aic Claim . . . . . . . . . . . . . . . . . . . . 13 5.1.3. The da Claim . . . . . . . . . . . . . . . . . . . . 14 Wei Expires 26 February 2027 [Page 2] Internet-Draft AIC-JWT August 2026 5.2. DA JWT Payload (DelegationAuthTBS Equivalent) . . . . . . 14 5.3. PA JWT Payload (PrincipalAuthorization Equivalent) . . . 15 5.4. Mapping from ASN.1 . . . . . . . . . . . . . . . . . . . 16 6. Capabilities and Matching . . . . . . . . . . . . . . . . . . 16 6.1. Capability Object . . . . . . . . . . . . . . . . . . . . 16 6.2. Glob Matching . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Parameter Intersection . . . . . . . . . . . . . . . . . 18 7. Authorization Constraints . . . . . . . . . . . . . . . . . . 18 8. Delegation Model . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Delegation Modes . . . . . . . . . . . . . . . . . . . . 19 8.2. Permission Intersection . . . . . . . . . . . . . . . . . 19 8.3. Multi-level Delegation . . . . . . . . . . . . . . . . . 20 9. Credential Bundle (Optional) . . . . . . . . . . . . . . . . 20 9.1. Bundle Composition . . . . . . . . . . . . . . . . . . . 20 9.2. Principal Binding Check . . . . . . . . . . . . . . . . . 21 9.3. Deployment Note: Offline Operation . . . . . . . . . . . 21 9.4. Browser Key Material . . . . . . . . . . . . . . . . . . 21 10. Issuance Flows . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. PKI Mode . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. OAuth Authorization Server Mode . . . . . . . . . . . . 22 10.3. Lightweight Consumer Profile . . . . . . . . . . . . . . 22 10.4. Token Exchange Usage . . . . . . . . . . . . . . . . . . 23 10.5. Deployment Architectures . . . . . . . . . . . . . . . . 23 10.6. X.509 AIC Interoperability . . . . . . . . . . . . . . . 23 11. Validation Pipeline . . . . . . . . . . . . . . . . . . . . . 24 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Outer AIC-JWT . . . . . . . . . . . . . . . . . . . . . 25 12.2. Inner DA JWT . . . . . . . . . . . . . . . . . . . . . . 26 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13.1. Algorithm Confusion . . . . . . . . . . . . . . . . . . 26 13.2. Token Theft and Replay . . . . . . . . . . . . . . . . . 26 13.3. Audience Confusion . . . . . . . . . . . . . . . . . . . 27 13.4. Nested Token Confusion . . . . . . . . . . . . . . . . . 27 13.5. Principal Key Binding . . . . . . . . . . . . . . . . . 27 13.6. Threat Model . . . . . . . . . . . . . . . . . . . . . . 27 13.7. Size Limits . . . . . . . . . . . . . . . . . . . . . . 27 13.8. Web Browser Runtime Considerations . . . . . . . . . . . 28 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 15.1. Media Type Registration . . . . . . . . . . . . . . . . 29 15.2. JWT Claims Registration . . . . . . . . . . . . . . . . 29 15.3. OAuth Token Type URN . . . . . . . . . . . . . . . . . . 30 15.4. OAuth Authorization Server Metadata . . . . . . . . . . 30 16. Compatibility with the Varwof Unified JWT Profile . . . . . . 30 17. Intellectual Property . . . . . . . . . . . . . . . . . . . . 32 18. Implementation Status . . . . . . . . . . . . . . . . . . . . 32 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 Wei Expires 26 February 2027 [Page 3] Internet-Draft AIC-JWT August 2026 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 21.1. Normative References . . . . . . . . . . . . . . . . . . 34 21.2. Informative References . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction 1.1. Problem Statement The AIC X.509 extension defined in [AIC] answers five questions at TLS handshake time: who delegated the authorization, which operations were authorized, under which constraints the Agent may run, how long the authorization is valid, and who is accountable for the Agent's actions. Its design goal is that the complete authorization decision can be made offline, from the certificate and its credential bundle alone. 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 must be carried in an application-layer token. This document defines that token as a JWT [RFC7519] secured by JWS [RFC7515], and names it *AIC-JWT*. 1.2. Relationship to the X.509 AIC Extension AIC-JWT is a companion profile, not a replacement. The X.509 AIC extension remains the transport-layer profile used during TLS handshakes in managed, regulated, and air-gapped environments. AIC- JWT carries the same semantic model at the application layer: Wei Expires 26 February 2027 [Page 4] Internet-Draft AIC-JWT August 2026 +============+=========================+=======================+ | Concern | X.509 AIC (transport) | AIC-JWT (application) | +============+=========================+=======================+ | Encoding | ASN.1/DER | JSON (JWT claims) | +------------+-------------------------+-----------------------+ | Signature | X.509 / [RFC5280] | JWS / RFC 7515 | | framework | | | +------------+-------------------------+-----------------------+ | Principal | DelegationAuthorization | Inner DA JWT | | signature | | (typ=aic+da+jwt) | +------------+-------------------------+-----------------------+ | Issuer | CA signature over | Outer JWT signature | | coverage | TBSCertificate | over the full payload | +------------+-------------------------+-----------------------+ | Key | X.509 subject public | cnf claim (RFC 7800) | | binding | key | | +------------+-------------------------+-----------------------+ | Revocation | CRL / OCSP / short | Token Status List / | | | lifetime | short lifetime | +------------+-------------------------+-----------------------+ | Trust | Certificate chain | JWKS / x5c / | | bootstrap | | credential bundle | +------------+-------------------------+-----------------------+ | Transport | TLS handshake (mTLS) | HTTP Authorization | | | | header | +------------+-------------------------+-----------------------+ Table 1 The two profiles share: agentId, principalUid, the Capability container (schemeId/capabilityId/parameters), delegationMode, authorizationConstraints, the DelegationAuthorization structure, the permission intersection model, capability glob matching, and the credential bundle verification model. 1.3. Scope The following sections are normative: token structure, claims definition, DA JWT definition, issuance flows, validation pipeline, credential bundle requirements, and IANA registrations. Deployment models, implementation status, and performance characteristics are informative. Wei Expires 26 February 2027 [Page 5] Internet-Draft AIC-JWT August 2026 As in the X.509 AIC specification, this document deliberately separates cryptographic delegation from authorization semantics: AIC- JWT defines the representation and cryptographic binding of authorization-related information. Whether an operation is permitted is determined by capability schemes and deployment policy, not by 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 a CA or an OAuth authorization server. DA JWT: The inner JWT (typ=aic+da+jwt) signed by the principal, the JSON equivalent of DelegationAuthorization / DelegationAuthTBS. PA JWT: An optional companion JWT (typ=aic+pa+jwt) carrying the JSON equivalent of the PrincipalAuthorization extension. Issuer: The entity that signs the outer AIC-JWT. It is either a CA (PKI mode) or an OAuth authorization server (AS mode). 1.6. Related Work [DAAP] (draft-mishra-oauth-agent-grants) defines a delegated agent authorization protocol with DID-based agent identity, JWT grant tokens, and online verification. AIC-JWT differs in that identity is anchored to a PKI/AS trust root, and the principal's consent is a nested principal-signed JWT covered by the issuer signature. Principal key resolution is online by default (JWKS) or, in PKI deployments, via the optional credential bundle. [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. Wei Expires 26 February 2027 [Page 6] Internet-Draft AIC-JWT August 2026 [WIMSE] (draft-ietf-wimse-s2s-protocol) defines workload identity tokens carrying iss, sub, exp, jti, and cnf. WIMSE tokens identify workloads but do not carry authorization semantics; AIC-JWT adds the AIC authorization model on top of the same JOSE primitives. [ATN], [PEDIGREE], and [HDP] carry delegation information in application-layer JWS/DID documents but rely on online discovery or flat scope representations. AIC-JWT keeps the structured capability container, the nested principal signature, and authorization constraints of AIC. 2. Design Principles This specification is guided by five orthogonal principles, carried over from the X.509 AIC specification: 1. *Two-layer signature nesting.* The principal signs the DA JWT; the issuer signs the outer AIC-JWT covering the complete payload including the DA JWT. Neither party can modify the authorization content unilaterally. A compromised CA/AS cannot forge a principal-signed DA; a compromised principal key cannot mint a valid outer token. 2. *One container, three contexts.* The Capability structure (schemeId/capabilityId/parameters) is reused in aic.capabilities, aic.constraints, and grants of the PA JWT. Gateways route evaluation by schemeId to scheme-specific plugins; the certificate format stays frozen while semantics evolve through registries. 3. *Online-first, OAuth-native verification.* Verification follows standard OAuth/JOSE practice: issuer keys come from JWKS (optionally cached), token status from Token Status Lists [TSL], and sender binding from cnf/DPoP. Offline self-contained verification is NOT a design goal of the JSON profile; it is the domain of the X.509 AIC (mTLS) profile. 4. *Delegation mode as a cryptographically bound field.* delegation_mode distinguishes authorized (agent acts in its own name) from representative (agent acts in the principal's name), with different runtime checks and audit semantics, exactly as in the X.509 profile. 5. *OAuth alignment.* Standard JOSE and OAuth primitives are reused wherever possible: iss/sub/aud/iat/exp/jti claims, cnf (RFC 7800), DPoP (RFC 9449), Rich Authorization Requests (RFC 9396), token exchange [RFC8693], JWT assertions [RFC7523], and Token Status Lists [TSL]. Wei Expires 26 February 2027 [Page 7] Internet-Draft AIC-JWT August 2026 3. Overview 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. * *Agent*: the AI agent presenting the token. The agent identity is the sub claim. The agent key is bound by cnf. * *Issuer*: the CA (PKI mode) or OAuth authorization server (AS mode) that validates the DA JWT and signs the outer AIC-JWT. * *Verifier/Gateway*: the policy enforcement point that validates the token and makes the access decision. The issuer's public key comes from configured JWKS/x5c material (optionally cached). The principal's public key comes either from an online JWKS or, in PKI deployments, from the credential bundle presented with the token. 3.2. Relationship to OAuth 2.0 Roles +==================+==========================+ | AIC-JWT role | OAuth 2.0 role | +==================+==========================+ | Principal | Resource Owner / subject | +------------------+--------------------------+ | Agent | Client / actor | +------------------+--------------------------+ | Issuer (AS mode) | Authorization Server | +------------------+--------------------------+ | Verifier/Gateway | Resource Server | +------------------+--------------------------+ Table 2 The Agent acts as the OAuth *actor* ([RFC8693] actor_token); the Principal is the *subject* (subject_token). The AIC-JWT can serve as an access token (RFC 9068-style), an assertion [RFC7523], or the output of a token exchange [RFC8693]. Wei Expires 26 February 2027 [Page 8] Internet-Draft AIC-JWT August 2026 3.3. Relationship to mTLS AIC-JWT does not require mutual TLS (mTLS). Sender binding is provided at the application layer by the cnf claim (Section 5.1.1) and MAY be strengthened with DPoP [RFC9449]. Where a deployment uses mTLS, the verifier MAY additionally check that the mTLS client certificate key corresponds to 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. Token Structure 4.1. Nested JWS Construction The AIC-JWT is a nested JWS per Section 5.2 of [RFC7515]: 1. The principal creates the DA JWT (Section 5.3) 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 DA JWT string. 3. The issuer signs the outer payload, producing the AIC-JWT. The outer signature covers the complete inner JWT string. Any modification of the inner token invalidates the outer signature. The AIC-JWT uses the JWS compact serialization. The inner DA JWT uses the JWS compact serialization as well. 4.2. Outer JOSE Header The outer header MUST contain: * alg: a JOSE algorithm from the allowlist in 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 SHOULD contain x5c or x5t when the issuer's key is an X.509 certificate (PKI mode), to bridge X.509 trust anchors. Wei Expires 26 February 2027 [Page 9] Internet-Draft AIC-JWT August 2026 4.3. Inner DA JOSE Header The DA JWT header MUST contain: * alg: a JOSE algorithm from the allowlist in 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 access token; the distinct typ value prevents confusion with the outer token. 4.4. PA JOSE Header When the optional PA JWT (Section 5.4) is used, its header MUST contain: * alg: a JOSE algorithm from the allowlist in Section 4.5. * typ: the string aic+pa+jwt. * kid: the issuer's signing key identifier. 4.5. Algorithm Allowlist The following JOSE algorithms are permitted, mirroring the signature algorithm policy of the X.509 AIC specification: Wei Expires 26 February 2027 [Page 10] Internet-Draft AIC-JWT August 2026 +=================+=============+=========================+ | JOSE | Requirement | X.509 counterpart | +=================+=============+=========================+ | ES256 | MUST | ecdsa-with-SHA256 | +-----------------+-------------+-------------------------+ | ES384 | MAY | ecdsa-with-SHA384 | +-----------------+-------------+-------------------------+ | ES512 | MAY | ecdsa-with-SHA512 | +-----------------+-------------+-------------------------+ | RS256 | MUST | sha256WithRSAEncryption | +-----------------+-------------+-------------------------+ | RS384 | MAY | sha384WithRSAEncryption | +-----------------+-------------+-------------------------+ | RS512 | MAY | sha512WithRSAEncryption | +-----------------+-------------+-------------------------+ | PS256 | MAY | RSASSA-PSS with SHA-256 | +-----------------+-------------+-------------------------+ | PS384 | MAY | RSASSA-PSS with SHA-384 | +-----------------+-------------+-------------------------+ | PS512 | MAY | RSASSA-PSS with SHA-512 | +-----------------+-------------+-------------------------+ | EdDSA (Ed25519) | MAY | Ed25519 | +-----------------+-------------+-------------------------+ Table 3 The allowlist is the union of the SPIFFE JWT-SVID algorithm set ([RFC7518] Sections 3.3-3.5) and EdDSA, so that a token can be verified by both JWT-SVID and AIC-JWT validators. ES256 and RS256 are the common MUST-level core shared with RFC 9068 and JWT-SVID; interoperable deployments SHOULD use ES256 or RS256. Implementations MUST reject all other algorithms. Implementations MUST follow the JSON Web Algorithm Confusion prevention guidance of [RFC8725]: the alg header MUST be validated against the allowlist, the kid MUST be resolved to the expected key, and symmetric algorithms such as HS256 MUST NOT be accepted for AIC-JWT. 5. Claims 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. Wei Expires 26 February 2027 [Page 11] Internet-Draft AIC-JWT August 2026 5.1.1. Standard Claims * iss (REQUIRED): the issuer identifier, a URL per [RFC9068] and [RFC9207]. * sub (REQUIRED): the agentId, a string of 1 to 256 characters. The subject of the AIC-JWT is the Agent, consistent with the X.509 profile where the certificate subject is the Agent. This deviates from RFC 9068's default sub semantics (the OAuth resource owner); the responsible principal is carried in aic.principal. * aud (REQUIRED): a string or array of strings identifying the intended resource servers or gateways. Verification follows RFC 9068 Section 4. Deployments that base decisions solely on capability evaluation MUST still include a deployment-scoped audience to prevent audience confusion. * iat (REQUIRED): NumericDate of issuance. * exp (REQUIRED): NumericDate of expiry. The lifetime exp - iat MUST NOT exceed the DA's requested_lifetime, which MUST NOT exceed 86400 seconds (1 day). * nbf (OPTIONAL): NumericDate before which the token MUST NOT be accepted. * jti (REQUIRED): a unique token identifier used for replay prevention and status lists. When a DA JWT is present, jti SHOULD equal the DA's nonce value. * cnf (REQUIRED): a confirmation claim per [RFC7800] binding the token to the Agent's proof-of-possession key. The jkt member ([RFC7638] thumbprint) is RECOMMENDED. When DPoP [RFC9449] is used, the jkt member MUST match the DPoP proof key thumbprint. Where a deployment uses mTLS, the verifier MAY cross-check the mTLS client certificate key against cnf (Section 3.3). * scope (OPTIONAL): an OAuth scope string projection of the capabilities, for interoperability with generic OAuth resource servers. The aic.capabilities claim remains the canonical authorization input. * client_id (OPTIONAL): the OAuth client identifier in AS mode, per RFC 9068. * status (OPTIONAL): a Token Status List reference per [TSL], with idx and uri members. Wei Expires 26 February 2027 [Page 12] Internet-Draft AIC-JWT August 2026 * authorization_details (OPTIONAL): a Rich Authorization Requests [RFC9396] projection of aic.capabilities, for consumption by standard OAuth resource servers. 5.1.2. The aic Claim The aic claim (REQUIRED) is a JSON object: "aic": { "ver": 1, "principal": { "realm": "corp.com", "id": "zhangsan", "key_hash": "", "hash_alg": "sha- 256" }, "delegation_mode": "authorized" | "representative", "capabilities": [ ... ], "constraints": [ ... ], "chain_depth": 0, "max_depth": 1, "extensions": { ... } } * ver (REQUIRED): AIC-JWT profile version, currently 1. * principal (REQUIRED): the principal binding, with members: - realm (REQUIRED): globally unique namespace, 1 to 128 characters; - id (REQUIRED): identifier within the realm, 1 to 256 characters, MUST NOT contain raw PII (see Section 14); - key_hash (REQUIRED): the principal binding hash, either (a) the base64url [RFC4648] encoding of hash_alg(SPKI) where SPKI is the DER SubjectPublicKeyInfo of the principal's X.509 certificate, or (b) the [RFC7638] JWK thumbprint (jkt) of the principal's JWK in pure-JSON deployments. The hash_alg member disambiguates. - hash_alg (REQUIRED when key_hash is an SPKI hash): the hash algorithm name (e.g., sha-256, sha-384, sha-512, sha3-256, sm3) or its ASN.1 OID string. When the key is a JWK thumbprint, hash_alg MUST be "jkt". * delegation_mode (REQUIRED): "authorized" (default) or "representative". * capabilities (REQUIRED, 1 to 256 entries): the Agent's declared capabilities; each entry is a Capability object (Section 6). * constraints (OPTIONAL, 0 to 32 entries): authorization boundary constraints; each entry is a Capability object whose scheme MUST be varwof/constraint-v1. * chain_depth (OPTIONAL, 0 to 255): current delegation depth, default 0. Wei Expires 26 February 2027 [Page 13] Internet-Draft AIC-JWT August 2026 * max_depth (OPTIONAL, 0 to 255): maximum delegation depth; MUST NOT exceed 1 as a best practice; chain_depth MUST NOT exceed max_depth. * extensions (OPTIONAL, 0 to 32 entries): an object keyed by OID strings; each value is { "critical": boolean, "value": }. Unknown extensions with critical: true MUST cause rejection; unknown extensions with critical: false (default) MAY be ignored. 5.1.3. The da Claim The da claim (CONDITIONAL) contains the complete DA JWT string. It is REQUIRED in the full profile. It MAY be omitted only in the lightweight consumer profile (Section 10.3) where the delegation mode is authorized, risk is low, and the deployment does not require principal non-repudiation. When present, the verifier MUST validate the DA JWT and MUST check consistency between the DA JWT payload and the outer aic claim (Section 13). 5.2. DA JWT Payload (DelegationAuthTBS Equivalent) The DA JWT payload is the JSON equivalent of DelegationAuthTBS. All ten members MUST be present: { "ver": 1, "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": "" } * ver (REQUIRED): 1. * agent_id (REQUIRED): the agent identifier; MUST equal the outer sub. * principal (REQUIRED): MUST equal the outer aic.principal. * 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. Wei Expires 26 February 2027 [Page 14] Internet-Draft AIC-JWT August 2026 * 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): base64url encoding of 32 bytes 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 (PrincipalAuthorization Equivalent) The optional PA JWT carries the JSON equivalent of the PrincipalAuthorization extension. It is REQUIRED in representative mode when no principal X.509 certificate with the PrincipalAuthorization extension is present in the bundle: { "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. Wei Expires 26 February 2027 [Page 15] Internet-Draft AIC-JWT August 2026 5.4. Mapping from ASN.1 +===========================+================================+ | X.509 AIC (ASN.1) | AIC-JWT | +===========================+================================+ | version | aic.ver | +---------------------------+--------------------------------+ | agentId | sub (outer), agent_id (DA) | +---------------------------+--------------------------------+ | principalUid.realm | aic.principal.realm | +---------------------------+--------------------------------+ | principalUid.identifier | aic.principal.id | +---------------------------+--------------------------------+ | principalUid.keyHash | aic.principal.key_hash | +---------------------------+--------------------------------+ | principalUid.hashAlgo | aic.principal.hash_alg | +---------------------------+--------------------------------+ | capabilities (Capability) | aic.capabilities | +---------------------------+--------------------------------+ | delegationMode | aic.delegation_mode | +---------------------------+--------------------------------+ | authorizationConstraints | aic.constraints | +---------------------------+--------------------------------+ | DelegationDepthControl | aic.chain_depth, aic.max_depth | +---------------------------+--------------------------------+ | extensions | aic.extensions | +---------------------------+--------------------------------+ | DelegationAuthorization | da (inner JWT) | +---------------------------+--------------------------------+ | DelegationAuthTBS | DA JWT payload | +---------------------------+--------------------------------+ | PrincipalAuthorization | PA JWT or principal x5c | +---------------------------+--------------------------------+ | notBefore / notAfter | nbf / exp | +---------------------------+--------------------------------+ | serialNumber / nonce | jti / DA nonce | +---------------------------+--------------------------------+ Table 4 6. Capabilities and Matching 6.1. Capability Object Each capability is a JSON object: { "scheme": "http", "id": "GET:/api/v1/users", "params": { "max_rows": 100 } } Wei Expires 26 February 2027 [Page 16] Internet-Draft AIC-JWT August 2026 * scheme (REQUIRED): the capability scheme identifier, 1 to 128 characters. Semantics are defined by the scheme, not by this specification. Unknown schemes are routed to scheme-specific plugins; requests referencing unknown schemes MUST be rejected (fail-closed). * id (REQUIRED): the capability identifier within the scheme, 1 to 256 characters, supporting glob wildcards (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. 6.2. Glob Matching Capability matching uses the same rules as the X.509 AIC specification: +=======================+=================+========================+ | Pattern | Meaning | Example | +=======================+=================+========================+ | scheme:method:path | exact | http:GET:/api/v1/users | +-----------------------+-----------------+------------------------+ | scheme:method:path/* | single segment | http:GET:/api/v1/* | | | (no /) | | +-----------------------+-----------------+------------------------+ | scheme:method:path/** | multi segment | http:GET:/api/v1/** | +-----------------------+-----------------+------------------------+ | scheme:{a,b}:path | alternation | http:{GET,POST}:/api/* | +-----------------------+-----------------+------------------------+ | scheme:[a-z]*:path | character class | http:[A-Z]*:/api/* | +-----------------------+-----------------+------------------------+ | scheme:*:path | single-segment | http:*:/api/v1/* | | | wildcard in the | | | | method position | | +-----------------------+-----------------+------------------------+ | scheme:* | scheme-level | http:* | | | wildcard | | +-----------------------+-----------------+------------------------+ Table 5 Wei Expires 26 February 2027 [Page 17] Internet-Draft AIC-JWT August 2026 Matching precedence (highest to lowest): exact, single-segment wildcard, multi-segment wildcard, alternation {a,b}, character class [a-z], scheme-level wildcard. When multiple rules match, the highest-precedence rule applies. If no rule matches, the capability MUST be denied. Bare * without a scheme namespace MUST NOT be allowed. Matching is implemented as a two-level token stream: the pattern and the target are first split on :; each segment 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]*). This algorithm was verified by the reference implementations (Go and TypeScript/WebCrypto) against the examples in this section. 6.3. Parameter Intersection When matching P_grants against C_agent: * if C_agent.params exceeds the bounds of P_grants.params, the capability entry is invalid and MUST be filtered or rejected; * otherwise the agent-specified params value is adopted in full. Example: P_grants.params = {"max_rows": 1000} with C_agent.params = {"max_rows": 100} is accepted with max_rows=100; with max_rows=5000 it is rejected. 7. Authorization Constraints aic.constraints is an optional array of Capability objects whose scheme MUST be varwof/constraint-v1; other scheme values MUST be rejected. The id distinguishes constraint types; the following types are defined as examples, extensible through the capability scheme registry: Wei Expires 26 February 2027 [Page 18] Internet-Draft AIC-JWT August 2026 +================+====================+====================+ | | format | Description | +================+====================+====================+ | allowed-cidr | ["10.0.0.0/8", | Allowed IP ranges | | | "192.168.0.0/16"] | | +----------------+--------------------+--------------------+ | max-concurrent | {"max": 5} | Maximum concurrent | | | | agent instances | +----------------+--------------------+--------------------+ | time-window | {"start": "22:00", | Allowed execution | | | "end": "06:00"} | window (UTC) | +----------------+--------------------+--------------------+ Table 6 Constraints are evaluated with logical AND: all constraints MUST be satisfied. The constraint count MUST NOT exceed 32. Unknown constraint types default to audit-and-ignore for forward compatibility; deployments MAY configure strict rejection. aic.constraints (execution boundaries) and PA constraints (authorization boundaries) are evaluated independently; there is no subset relationship between them. Runtime policy (timeouts, retries, rate limits, routing) MUST NOT be placed in authorizationConstraints; it remains in gateway local policy configuration. 8. Delegation Model 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 capability set is locked at issuance; no runtime P_grants superset check is performed. 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 sub as the executor. The bundle MUST contain the principal's PA material. At issuance and at runtime, C_agent MUST be a subset of P_grants. Wide scope x short lifetime, with runtime P_grants intersection at each operation. 8.2. Permission Intersection The effective permission set is the intersection of principal grants and agent capabilities: Wei Expires 26 February 2027 [Page 19] Internet-Draft AIC-JWT August 2026 P_effective = P_grants (AND) C_agent In authorized mode the intersection was verified at issuance and locked into the token. In representative mode the intersection is computed at runtime for each operation. Gateway local runtime policy (T_policy) is an additional enforcement layer and MUST NOT be confused with the P (AND) C intersection. 8.3. Multi-level Delegation Single-level delegation (Principal -> Agent, chain_depth=0) is the default and recommended deployment mode. Depth-1 chains (Principal -> Agent -> sub-Agent, chain_depth=1) are supported optionally; each hop produces an independently signed DA JWT whose signer is the delegating agent. Capabilities are recursively intersected along the chain. Any chain_depth MUST NOT exceed max_depth; max_depth MUST NOT exceed 1 as a best practice. A sub-agent MUST NOT delegate further. Recursive verification: starting from the presented token, verify each DA JWT with the signer's key (identified by the previous level's principal/cnf), check that declared capabilities are a subset of the delegator's effective capabilities, and repeat until the original principal or the depth limit is reached. Cycles are prevented by strictly monotonic chain_depth; credential bomb attacks are limited by a gateway-configured maximum bundle size (default 8 certificates or equivalent tokens). 9. Credential Bundle (Optional) 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 Wei Expires 26 February 2027 [Page 20] Internet-Draft AIC-JWT August 2026 - 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. Only hash algorithms with output length not exceeding 64 bytes are supported (SHA-2/SHA-3 family, SM3, BLAKE2/BLAKE3). * JWK thumbprint: key_hash = jkt per RFC 7638, hash_alg = "jkt". Mismatch MUST cause rejection (fail-closed). 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. Deployment Note: Offline Operation AIC-JWT is designed for online verification and does not claim offline self-contained verification. 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 and SHOULD rely on a server-side helper to convert any X.509 key material to JWK before it reaches the browser. Wei Expires 26 February 2027 [Page 21] Internet-Draft AIC-JWT August 2026 10. Issuance Flows 10.1. PKI Mode 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). 10.2. OAuth Authorization Server Mode 1. The principal provides consent through the standard OAuth flow (authorization code with requested_actor, or an OBO-style flow). 2. The Agent presents the principal-signed DA JWT as an assertion, using the [RFC7523] grant_type (urn:ietf:params:oauth:grant- type:jwt-bearer) or as a client_assertion/client_assertion_type pair, together with the token request. 3. The AS validates the DA JWT (signature, nonce uniqueness, subset checks) and issues the outer AIC-JWT signed with the AS key. 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. 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. Wei Expires 26 February 2027 [Page 22] Internet-Draft AIC-JWT August 2026 10.4. Token Exchange Usage An AIC-JWT MAY be produced or consumed through [RFC8693] token exchange: * subject_token: the principal's credential (e.g., an OAuth access token or a principal-bound JWT); * actor_token: the Agent's AIC-JWT (or a workload identity token); * subject_token_type / actor_token_type: the registered token types, including urn:ietf:params:oauth:token-type:aic+jwt for AIC-JWT. The exchanged token SHALL carry the AIC claims of the actor and the intersection of the actor's capabilities with the subject's grants. 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 original [AIC] profile with mTLS is used; the JSON profile is not. 10.6. X.509 AIC Interoperability When the same authorization is carried in both profiles, the following equivalences apply: Wei Expires 26 February 2027 [Page 23] Internet-Draft AIC-JWT August 2026 * 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 encodings of the same binding; 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 same ten-field structure; 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 a single authorization can be presented at the transport layer (mTLS) and at the application layer (Bearer) with identical semantics. Interoperability between the two profiles is a deployment mechanism, not a new token format; both profiles share the data model defined by [AIC]. 11. Validation Pipeline The verifier/gateway MUST execute the following steps in order after receiving the AIC-JWT and bundle: 1. *JWS verification*: verify the outer signature using the issuer's key resolved from kid (JWKS or x5c), per RFC 7515. 2. *Header checks*: validate typ == "aic+jwt", alg in the allowlist, and reject none and symmetric algorithms (RFC 8725). 3. *Time checks*: nbf <= now <= exp (with deployment-configured clock skew); exp - iat <= requested_lifetime <= 86400. 4. *DA validation* (full profile): verify the inner DA JWT signature with the principal key material (credential bundle, online JWKS, or a locally cached copy); check key_hash against that key material; check that the DA nonce decodes to 32 bytes. The DA nonce uniqueness check is performed by the ISSUER at issuance (Section 10) and MUST NOT be treated as single-use by the verifier: the same access token is legitimately presented multiple times within its lifetime. A verifier MAY keep an optional local replay cache for additional detection, but such a cache MUST NOT reject a valid token on legitimate reuse. Per- request single-use replay protection at the verifier is provided by DPoP proof jti (Section 13.2), not by the DA nonce. Wei Expires 26 February 2027 [Page 24] Internet-Draft AIC-JWT August 2026 5. *Consistency checks*: DA agent_id == sub, DA principal == aic.principal, DA capabilities == aic.capabilities, DA delegation_mode == aic.delegation_mode, DA constraints == aic.constraints. Any mismatch MUST cause rejection. 6. *PA check* (representative mode): load the PA JWT or principal certificate from the bundle; verify allowed_mode permits representative delegation; verify C_agent is a subset of P_grants (with parameter intersection per Section 6.3). 7. *Constraint evaluation*: evaluate aic.constraints with AND semantics (IP ranges, concurrency, time windows), then PA constraints independently. Constraint evaluation precedes capability evaluation for fast rejection. 8. *Delegation depth check*: verify chain_depth <= max_depth. 9. *Capability evaluation*: route the capability required by the current request to the scheme plugin registered for its scheme. Unknown schemes or unknown capabilities MUST be rejected (fail- closed). Capabilities irrelevant to the current request MUST NOT affect the decision. 10. *Status check* (optional): if a status claim is present, fetch or use a cached Token Status List [TSL] and verify the referenced token is valid. 11. *Decision*: if all steps pass, permit; otherwise deny and log sufficient diagnostic information for audit. 12. Examples 12.1. Outer AIC-JWT Header: { "alg": "ES256", "typ": "aic+jwt", "kid": "ca-2026-01" } Payload: { "iss": "https://ca.example.com/aic", "sub": "agent:db-analyst-01", "aud": ["https://gw.example.com"], "iat": 1755500000, "exp": 1755503600, "jti": "aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789abcdef", "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyHnXgk7dNsQo0c1V3iR4vY" }, "aic": { "ver": 1, "principal": { "realm": "corp.com", "id": "zhangsan", "key_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "hash_alg": "sha-256" }, "delegation_mode": "representative", Wei Expires 26 February 2027 [Page 25] Internet-Draft AIC-JWT August 2026 "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": "" } 12.2. Inner DA JWT Header: { "alg": "ES256", "typ": "aic+da+jwt", "kid": "principal-zhangsan- 2026" } Payload: { "ver": 1, "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": "aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789abcdef" } 13. Security Considerations 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 a bearer token by default. Deployments MUST use TLS. The token MUST carry cnf binding it to the Agent key, and deployments SHOULD additionally use DPoP [RFC9449] 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. Wei Expires 26 February 2027 [Page 26] Internet-Draft AIC-JWT August 2026 13.3. Audience Confusion The aud claim MUST be validated per RFC 9068. 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. 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. Wei Expires 26 February 2027 [Page 27] Internet-Draft AIC-JWT August 2026 * 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). Wei Expires 26 February 2027 [Page 28] Internet-Draft AIC-JWT August 2026 * 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. 14. Privacy Considerations The GDPR / right-to-be-forgotten considerations of the X.509 AIC specification apply: 1. aic.principal.id MUST NOT contain raw PII (full names, national identifiers, email addresses). Pseudonymous identifiers (UUIDs) MUST be used, with the mapping table stored in a compliant, deletable database. 2. Revocation (Token Status List [TSL] or short lifetime) is the mechanism for expressing "the principal no longer authorizes this Agent"; revocation does not erase the token itself. 3. AIC-JWT is a stateless credential: it MAY be parsed and validated in memory and discarded, without persistence. 4. Audit logs MUST be minimized: session binding fingerprint, operation summary, decision, and pseudonymous identifier are sufficient. 5. Cryptographic evidence is independent of log mappings: deleting the pseudonym mapping table does not invalidate the DA JWT signature. 6. No sensitive data MUST be placed in any claim; all AIC-JWT data is visible to any party that receives the token. 15. IANA Considerations 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: Wei Expires 26 February 2027 [Page 29] Internet-Draft AIC-JWT August 2026 +==================+==============================================+ | Claim | Description | +==================+==============================================+ | aic | AIC-JWT namespaced claims object | +------------------+----------------------------------------------+ | da | Principal-signed DelegationAuthorization JWT | +------------------+----------------------------------------------+ | aic+da (inner | DelegationAuthTBS equivalent | | payload members) | | +------------------+----------------------------------------------+ | aic+pa (payload | PrincipalAuthorization equivalent | | members) | | +------------------+----------------------------------------------+ Table 7 15.3. OAuth Token Type URN Register urn:ietf:params:oauth:token-type:aic+jwt for use with RFC [RFC8693] token exchange and [RFC7523] assertions. 15.4. OAuth Authorization Server Metadata Consider registering metadata entries indicating AIC-JWT support, such as aic_jwt_supported and aic_jwt_profiles_supported (pki | oauth-as), following the OAuth Authorization Server Metadata specification. 16. Compatibility with the Varwof Unified JWT Profile The internal design note "AIC x SPIFFE x OAuth/OIDC Interop" (dev- docs/aic/11-spiffe-oauth-interop.md) defines a Unified JWT Profile that projects one AIC identity onto SPIFFE JWT-SVID and RFC 9068 access tokens simultaneously. This section maps the AIC-JWT claims of this specification to that profile. The two documents use different naming; the mapping below keeps them interoperable: Wei Expires 26 February 2027 [Page 30] Internet-Draft AIC-JWT August 2026 +=====================+===========================+===============+ | AIC-JWT (this | Unified JWT Profile (11) | SPIFFE JWT- | | document) | | SVID / RFC | | | | 9068 view | +=====================+===========================+===============+ | iss (CA or AS URL) | iss (OAuth URL) | -- (JWT-SVID | | | | validators do | | | | not process | | | | iss; trust | | | | domain | | | | anchored by | | | | sub + bundle) | +---------------------+---------------------------+---------------+ | sub = agentId | sub = | sub (SPIFFE); | | | spiffe:///agent/, | sub (RFC | | | agent_id | 9068) | +---------------------+---------------------------+---------------+ | aud | aud | aud | +---------------------+---------------------------+---------------+ | iat / exp / nbf / | same | same | | jti | | | +---------------------+---------------------------+---------------+ | aic.principal | principal_uid | -- | +---------------------+---------------------------+---------------+ | aic.capabilities | scope + capabilities | scope | +---------------------+---------------------------+---------------+ | aic.delegation_mode | delegation_mode | -- | +---------------------+---------------------------+---------------+ | aic.constraints | -- (deployment-side) | -- | +---------------------+---------------------------+---------------+ | da (nested | -- (11 has no DA; this | -- | | principal-signed | document keeps the two- | | | JWT) | layer signature) | | +---------------------+---------------------------+---------------+ | cnf / DPoP | -- | RFC 9068 + | | | | DPoP | +---------------------+---------------------------+---------------+ Table 8 Projection rules for interoperable deployments: * in SPIFFE mode (is_spiffe=true), the AIC certificate's agentId is itself the SPIFFE ID (spiffe:///agent/) and is dual- written to the certificate SAN URI; the AIC-JWT sub inherits that SPIFFE ID directly and no conversion is required; Wei Expires 26 February 2027 [Page 31] Internet-Draft AIC-JWT August 2026 * when the AIC X.509 certificate carries a SPIFFE URI SAN but the AIC-JWT was issued with a bare agentId, a converter MAY emit sub as the SPIFFE ID (spiffe:///agent/) while keeping aic.principal unchanged; * aic.capabilities MAY be projected to the OAuth scope string (space-separated scheme:capabilityId entries) for generic resource servers; aic.capabilities remains canonical; * the two-layer signature (principal-signed da covered by the issuer signature) is preserved in AIC-JWT and is NOT represented in the 11 profile; verifiers requiring principal non-repudiation MUST use the da claim; * the AIC-JWT iss remains the OAuth/RFC 9068 issuer URL; JWT-SVID validators do not process iss -- the trust domain is anchored by the sub SPIFFE ID and the SPIFFE bundle used for signature verification. Deployments requiring RFC 9068 conformance MUST NOT replace iss with spiffe://; * the issuer signing key SHOULD be published both in the OAuth JWKS and as a JWT-SVID bundle entry (use=jwt-svid), so that the same token can be verified by OAuth resource servers (JWKS) and SPIFFE/ JWT-SVID validators (bundle) without conversion; * the AIC-JWT typ remains aic+jwt. A JWT-SVID validator that enforces the JWT-SVID typ restriction (only JWT or JOSE) will reject the token; deployments presenting AIC-JWT to such validators SHOULD issue a projected token with typ JWT and a single-value aud. 17. Intellectual Property This document is subject to BCP 79 (RFC 8179). The author has filed patent applications related to the technologies described in the companion X.509 profile (draft-wei-aic-identity-cert), including Chinese patent applications CN2026112384541 and CN2026112384607 (filed with the China National Intellectual Property Administration). IPR disclosure 7553, filed for the companion profile, grants a Royalty-Free, Reasonable and Non-Discriminatory license to all implementers; the author will file an IPR disclosure covering this document on the same terms in accordance with BCP 79. Any applicable IPR disclosures are available through the IETF IPR disclosure system. 18. Implementation Status Per [RFC7942], reference implementations exist and were used to verify this specification: Wei Expires 26 February 2027 [Page 32] Internet-Draft AIC-JWT August 2026 * A Go reference implementation (standard library only) implements the claims model, the 11-step validation pipeline, capability matching, constraints, key binding, and the OAuth scenarios (RFC 9068, RFC 7523, RFC 8693, RFC 9449, OBO-style flows, and Token Status Lists [TSL]). Test suites in types/aicjwt and the aic-jwt repository pass (go test ./...). * A TypeScript/WebCrypto reference implementation implements the same pipeline for browser-compatible runtimes, including EdDSA and RSA-PSS coverage with feature detection. Test suite: 15 cases, all passing (node --test ts/aicjwt.test.ts). The Go core is maintained in github.com/varwof/types (package types/ aicjwt); the wrapper, OAuth protocol-layer simulation, and the TypeScript/WebCrypto implementation are in https://github.com/varwof/ aic-jwt. Findings verified by these implementations are incorporated in Sections 6.2, 9.4, 10.5, 10.6, 11, and 13.8. 19. Acknowledgements The author thanks the IETF community for ongoing discussion of agent identity and accountability frameworks. 20. Change Log draft-wei-aic-jwt-00 (2026-08-24, revision 5): * Section 16: clarified that the AIC-JWT iss remains the OAuth URL and is not processed by JWT-SVID validators (trust domain is anchored by sub + SPIFFE bundle); added the SPIFFE-mode sub inheritance rule, the key dual-publication rule (OAuth JWKS + JWT- SVID bundle entry) and the typ projection rule. draft-wei-aic-jwt-00 (2026-08-24, revision 4): * Added PS384 and PS512 to the algorithm allowlist (Section 4.5) to align with the SPIFFE JWT-SVID algorithm set; EdDSA remains a MAY extension beyond the JWT-SVID set. draft-wei-aic-jwt-00 (2026-08-23, revision 3): * Added compatibility mapping with the Varwof Unified JWT Profile (Section 16), keeping AIC-JWT interoperable with SPIFFE JWT-SVID and RFC 9068 projections. draft-wei-aic-jwt-00 (2026-08-23, revision 2): Wei Expires 26 February 2027 [Page 33] Internet-Draft AIC-JWT August 2026 * Clarified the two-level capability matching algorithm (Section 6.2). * Clarified that DA nonce uniqueness is enforced at issuance and MUST NOT be treated as single-use by the verifier (Section 11). * Added deployment architectures, including pure OAuth/JSON, hybrid server-side PKI helper, and X.509 interoperability (Sections 10.5-10.6). * Added browser key-material guidance (Section 9.4) and WebCrypto runtime constraints (Section 13.8). * Added implementation status for the Go and TypeScript/WebCrypto reference implementations. draft-wei-aic-jwt-00 (2026-08-23): * Initial individual draft. 21. References 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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Wei Expires 26 February 2027 [Page 34] Internet-Draft AIC-JWT August 2026 [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, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [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, . Wei Expires 26 February 2027 [Page 35] Internet-Draft AIC-JWT August 2026 [RFC9470] Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [TSL] Looker, T., Bastian, P., and C. Bormann, "Token Status List", June 2026, . [AIC] Wei, J., "AI Agent Identity Certificate (AIC) X.509 v3 Extension", August 2026, . 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, . [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, . [DAAP] Kumar, S., "Delegated Agent Authorization Protocol (DAAP)", March 2026, . [OBO] Dissanayaka, A., "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", August 2025, . [WIMSE] Campbell, B., "WIMSE Service to Service Authentication", 2026, . [ATN] Somoza, J., "ATN Agent Trust Negotiation", 2026, . Wei Expires 26 February 2027 [Page 36] Internet-Draft AIC-JWT August 2026 [PEDIGREE] Rampalli, V., "PEDIGREE Verifiable Delegated Identity", 2026, . [HDP] "Human Delegation Provenance Protocol", 2026, . Author's Address Jijie Wei Individual Email: pki@varwof.com URI: https://varwof.com Wei Expires 26 February 2027 [Page 37]