Summary

  • AIC-JWT revision 02 makes the principal sign an inner Delegation Authorization, including a hash of the authorised agent key in version 3, while an issuer signs the outer credential carrying that exact compact token.
  • A verifier must match the outer cnf proof-of-possession key to the principal-signed agent_key_binding; a valid issuer signature cannot authorise a substituted key, and renewal requires a fresh principal-signed DA and nonce.

The outer token passed every obvious test. Its issuer was recognised, its signature was intact, its expiry was near, and its cnf claim named the key presented by the agent. Yet the verifier stopped before granting access. Inside the token, the principal had signed a delegation for a different key.

That rejection is the useful control in revision 02 of AI Agent Identity Certificate (AIC) JSON Web Token Profile. The draft was posted on 2 October 2026 as an active individual Internet-Draft and expires on 5 April 2027. The archived text calls its intended status Informational. It is not an RFC, an IETF consensus document, an IETF endorsement, or evidence that anyone has deployed it. Its value here is narrower: it exposes which actor is entitled to state each fact in a delegated machine identity.

Two signatures, two authorities

The construction begins with a Delegation Authorization, or DA. A principal creates the DA as a compact JWT and signs it. The agent or issuing service then places that complete compact string in the outer AIC-JWT's da claim. The issuer signs the outer token, so any alteration to the nested JOSE header, payload or signature changes the outer payload and invalidates the issuer signature.

That nesting is not permission to parse the inner token and build an equivalent replacement. The verifier is instructed to verify the exact compact DA string it received. Reordering JSON members, changing base64url choices or regenerating a semantically similar JWT produces different signed bytes. A system that stores only a parsed object loses the evidence the principal actually signed.

The signatures answer different questions. The issuer's signature says that this issuer stands behind the outer carrier and its claims. The principal's signature says that this principal authored the delegation inside it. Neither role absorbs the other. A trusted issuer cannot rewrite the principal's grant merely because it can issue a fresh outer credential, and a correctly signed DA does not establish that an arbitrary outer issuer belongs to the accepted trust domain.

The token classes also need explicit separation. The inner DA is not a standalone AIC-JWT or access token. Distinct typ values prevent a signed object created for one protocol role from being replayed as another. This is a mundane header check with constitutional force: it keeps an authorisation request from masquerading as the credential that results from it.

The key the principal selected

Revision 02's current DA version is ver=3. It requires agent_key_binding, a hash of the agent public key's DER SubjectPublicKeyInfo under the declared algorithm. Because the field is inside the DA, the principal's signature covers the binding. The outer AIC-JWT separately requires cnf, which binds the issued token to a proof-of-possession key.

Full verification therefore compares the key identified by cnf with the principal-signed agent_key_binding. Both may be individually well formed while the pair is invalid. If the issuer replaces the agent key, accidentally associates the wrong device, or accepts a request from an intermediary with its own key, the outer signature still verifies. The mismatch is the evidence that the carrier's key is not the key the principal approved.

Version 2 is a legacy case. It binds an agent_id but not the agent key, so the draft accepts it only with specified substitution mitigations. Version 1 must be rejected, and newly issued DAs use version 3. Operators should not compress these states into “compatible”. A version number here describes the strength and location of authority, not just a decoder branch.

This boundary is distinct from ordinary key discovery. kid helps select a candidate from an already trusted and correctly scoped key set; it does not make that set trustworthy. Likewise, the presence of x5c or x5t does not establish a certificate path or policy. The outer issuer key and the inner DA signer key must both validate under configured trust, and the draft requires them to anchor in the same accepted trust domain. A convenient header cannot promote an untrusted root.

Renewal is new consent

The principal also limits time. The outer token's lifetime cannot exceed the duration requested in the DA, and its expiry cannot extend beyond the DA expiry. An issuer may shorten the effective window. It cannot lengthen the principal's grant.

The DA nonce is its jti and is consumed at first issuance. The same DA and nonce must not support a second outer token. Renewal or re-issuance requires a newly signed DA carrying a fresh nonce. That makes renewal a new consent event rather than a clerical extension performed by the issuer.

There are two replay clocks, and conflating them produces bad alarms. The DA nonce prevents repeated issuance from one authorisation. Once an access token exists, the same token may legitimately be presented more than once during its life. Per-request replay protection belongs to the proof layer—for example the jti in a DPoP proof—not to the already-consumed DA nonce. One ledger answers “was another credential minted?”; the other answers “was this request proof repeated?”

The operational receipt should retain both. Record the digest of the exact compact DA, the nonce-consumption transaction, the resulting token identifier and the request-proof identifier separately. Otherwise a legitimate repeated token presentation may look like illicit re-issuance, while an actual second issuance may hide among ordinary API requests.

Consistency before permission

The full profile compares claims across the two layers: principal, capabilities, delegation mode, constraints and the mode-specific subject or actor placement. A mismatch is rejected. Capabilities are not silently filtered into a convenient subset and presented as if that were what the principal signed. If the requested and issued scopes do not satisfy the profile's subset rules, the credential is invalid.

Only after those integrity checks does local policy have a meaningful object to evaluate. Effective authority is bounded by the principal grant, agent capabilities and AIC constraints, with gateway policy adding another restriction. A successful cryptographic check does not say that today's purchase, route change or data transfer is appropriate. It does not prove execution, and execution does not prove that an external system reached the intended state.

The optional lightweight consumer profile deliberately weakens this evidence chain: in a low-risk authorised mode it may omit the DA, and therefore lacks the full profile's cryptographic attestation of principal authorisation. That can be an explicit risk choice. It must not be labelled as equivalent evidence.