Summary

  • draft-wei-aic-jwt-01, posted on 8 September 2026, is an active individual Internet-Draft. It is not an adopted IETF work item, an approved standard or evidence of deployment; Experimental is its author-declared intended status.
  • Its full profile nests a principal-signed DelegationAuthorization JWT inside an issuer-signed AIC-JWT. The inner signature protects the authorization and named agent_id; the outer signature covers the exact inner token and the cnf claim.
  • Revision 01 says the current DA binds authorization to the Agent identity, while a DA-level binding to the Agent’s public key is reserved for a future claim-set revision. The present key binding therefore sits in the issuer-signed outer layer and must be enforced through proof of possession.
  • A compact agent-key binding receipt should preserve the proposition made by each signer instead of reducing the credential to “two signatures valid.” That receipt is my governance proposal, not IETF text.

Revision 01 makes the missing join visible

The news is a specification change, not an adoption event. The I-D announcement timestamped revision 01 at 14:48 UTC on 8 September. The Datatracker lists it under Individual Submissions, with the IESG state I-D Exists, no RFC stream, responsible Area Director or telechat date. Anyone can publish an Internet-Draft. The label “Intended status: Experimental” records the author’s destination, not a community decision that the protocol should advance or be deployed.

That narrow status matters because the text is ambitious. AIC-JWT presents itself as an application-layer companion to the separate X.509 AIC model for HTTP, web and OAuth environments that cannot present X.509 credentials at the transport layer. It does not claim that JWT or OAuth creates the authorization semantics. Those are inherited from the referenced AIC model and deployment policy.

Revision 01 adds a much fuller OAuth projection, changes the inner DA claim set from version 1 to version 2 and tells new implementations to reject the old claim set rather than silently downgrade. It also clarifies the part that deserves operational attention: the identity named in a delegation and the key used to present the resulting credential are not cryptographically bound by the same signer in this revision.

The inner signature preserves the principal’s authorization

The full profile starts with the principal. In the described PKI flow, an Agent generates a key pair and constructs an issuance request with desired capabilities, delegation mode, constraints and a nonce. The principal reviews the request, signs the inner DelegationAuthorization JWT and returns it to the Agent. The Agent presents that DA to a configured CA. In the OAuth mode, the Agent presents the principal-signed DA as an RFC 7523 JWT bearer authorization grant to an authorization server.

The DA is not loose metadata. Its distinct typ=aic+da+jwt prevents it from being confused with the outer credential. Revision 01 requires its issuer, subject, audience, expiry and jti, as well as the agent_id, principal binding, reason, capabilities, delegation mode, constraints, requested lifetime, timestamp and nonce. The principal’s verification key must match the principal binding. The jti must equal the nonce.

The outer token carries the exact compact DA string. A verifier must not reconstruct or reserialize it before checking the inner JWS. The issuer cannot rewrite a capability, change the mode or substitute another agent_id without invalidating the principal’s signature. Conversely, a principal key alone cannot mint a valid outer AIC-JWT because the issuer must sign the surrounding payload.

Those are substantive guarantees. But they do not make the two signatures interchangeable. A correct inner verification proves that the principal signed this DA for the named Agent identity under the contained limits. The draft says that, in revision 01, this is an identity binding: agent_id is inside the principal-signed claim set.

The outer signature carries the current key binding

The presenting key appears elsewhere. The outer AIC-JWT requires a confirmation claim, cnf, that identifies the Agent’s proof-of-possession key. RFC 7800 supplies the confirmation-claim semantics; an RFC 7638 JWK thumbprint in cnf.jkt is recommended. When DPoP is used, that thumbprint must match the DPoP proof key. An mTLS deployment may cross-check the client-certificate key against the same claim.

Revision 01 states the boundary twice, in the PKI and OAuth issuance sections. A DA-level Agent-key binding is reserved for a future DA claim-set revision aligned with X.509 AIC DA v2. In the current revision, the presented Agent key is bound by cnf at consumption time. Because cnf sits in the outer payload, the issuer’s signature covers it together with the exact inner DA.

This is not evidence that an issuer chooses the key behind the Agent’s back. The described PKI flow begins with the Agent generating its key pair, and the principal reviews an issuance request. Nor does the boundary license an issuer to expand capabilities or ignore the DA. The issuer must validate the principal signature, binding, audience, expiry, nonce uniqueness and applicable capability constraints before signing. Outer claims must remain consistent with the DA, and the outer token cannot outlive the principal-signed grant.

The narrower point is retrospective proof. The principal-signed bytes bind authorization to agent_id; they do not yet contain a DA-level thumbprint for the exact Agent key. A later auditor who sees only two successful signature checks cannot infer that the principal’s signature covered the cnf value. The outer issuer signature proves which key binding entered the issued token. Evidence that the principal explicitly inspected or confirmed that key, if a deployment collects it, comes from the issuance process rather than from the revision-01 DA signature.

Presence is also not enforcement. The security section says AIC-JWT is not inherently sender-constrained. A deployment that does not actually demand proof of possession can still allow a stolen token to operate as a bearer credential until expiry. TLS is required; DPoP or an equivalent mechanism is recommended. The cnf claim identifies the expected key, but the verifier’s successful proof-of-possession check is the event that turns the claim into an enforced presentation boundary.

Record the handoff without publishing every key relationship

A useful audit record should therefore preserve more than a green nested-signature badge. I would require an agent-key binding receipt containing the exact DA hash and claim-set version, principal key identifier, agent_id, issuer identifier, outer-token hash, the cnf method and key thumbprint, the issuance policy and version, the nonce-consumption result, the effective expiry intersection, the presentation-proof method and verifier decision. If the principal-facing approval experience exposed and confirmed the Agent key, the receipt should identify that evidence separately rather than retroactively attributing it to the DA signature.

The nonce clocks belong in the same account. Revision 01 uses one DA per issued outer token: the outer jti equals the DA nonce, and the issuer consumes it at first issuance. That does not make the resulting access token single-use. The verifier may see the same token more than once during its lifetime; per-request replay protection belongs to DPoP proof jti or an equivalent mechanism. A receipt that says only nonce used would blur issuance replay and presentation replay just as badly as two signatures valid blurs authorization and key binding.

This proposal does not require exposing stable key thumbprints to every reader. A protected receipt can reveal a commitment, policy result or audit reference according to audience. Minimisation matters because persistent Agent and principal identifiers can become correlation handles. The purpose is accountable reconstruction, not a public inventory of operators and keys.

Heng Lu’s policy-mirror test asks who obtained the decision and who inherited the consequence. Here the principal authorizes an Agent identity and capabilities. The issuer accepts the DA and signs the current key binding. The verifier decides whether proof of possession and local policy are satisfied. The resource owner bears the action that follows. Keeping those decisions distinct is not bureaucracy around cryptography; it is what lets cryptography say exactly what happened.

Sources