Your Agent Has a Certificate. Now the Certificate Wants to Prove Where Its Authority Came From.

Draft wei aic identity cert 00 was posted to the IETF Datatracker on 19 August 2026. Moona Intelligence verifies it now, more than four days later, against the text as it currently reads, not against the posting announcement alone. The current radar date for this record is 23 August 2026, and that date is when this verification was performed, not when the draft was published.

What the draft actually is, precisely

The Datatracker record shows an Internet Draft, individual submission, intended status Experimental, revision 00, with no working group, no IETF stream beyond individual submission, and no RFC number attached to it. Anyone may submit an Internet Draft to the IETF Datatracker. That is a low bar by design, one that lets any individual publish a proposal for public comment, and it is not evidence of adoption, review consensus, or endorsement by the IETF, a working group, or any standards body. This record does not describe draft wei aic identity cert 00 as an RFC, an IETF standard, IETF approved, IETF adopted, IETF endorsed, or industry adopted. The correct description, and the one this record uses throughout, is an individual Experimental Internet Draft proposing an X.509 extension.

Eight layers, kept separate on purpose

The draft's architecture separates Agent Identity, Principal Authorization, Capability, Delegation, Authorization Constraints, Gateway Enforcement, PKI Trust and TLS Transport into distinct layers rather than one bundled claim. The draft states directly that it does not define a universal authorization language. Capability semantics, what a given capability actually permits an agent to do inside an application, remain external to the AIC extension itself, defined by whatever capability scheme a deployment adopts, and deployment policy still participates in the final admission decision alongside the certificate. This record does not credit AIC with universally determining whether every application action is authorized. It determines something narrower: whether a claimed capability sits inside a chain of certified and signed authority, leaving what that capability means, in any specific application, to a scheme the draft does not itself specify.

What the agent's own certificate carries

The AIC extension, read from its ASN.1 module, carries an agentId identifying the agent, a principalUid identifying the authorizing principal, a capabilities container, a delegationMode, an authorizationConstraints container, a delegationAuthorization field holding the principal's cryptographic signature over the delegation, and extension fields reserved for forward compatibility. This record uses those field names exactly as the draft defines them and does not add or infer additional fields beyond what the specification carries.

PrincipalAuthorization, and the certificate authority behind it

A companion PrincipalAuthorization extension, carried in the principal's own certificate rather than the agent's, declares the principal's grants, its own authorization constraints, a delegation policy, and extensions. This is the extension doing the actual work of Authority Provenance, and it is also where the draft's own stated limits matter most. The draft describes technical issuance checks a certificate authority can apply, but it does not define the organizational or legal process by which a principal's underlying mandate, a corporate office, an account ownership right, a board delegation, a statutory authority, is established before a certificate authority places PrincipalAuthorization in that principal's certificate. The editorial significance here is not that a human signs a delegation, which the draft's delegation mechanism already provides for. It is that a relying party can now test whether an agent's claimed capabilities remain inside authority a trusted issuer certified the principal as holding, which is a materially stronger claim than a bare signed mandate with no certified boundary behind it, and a materially weaker claim than proof that the certificate authority's own determination of the principal's mandate was itself correct.

Authorized mode and representative mode

Effective agent permission is governed by the relationship between the principal's grants and the agent's declared capabilities, resolved in one of two modes the draft defines, and this record does not manufacture a third. In authorized mode, principal authorization is verified at issuance and the selected capability set is locked into the agent certificate; this is snapshot semantics, so a principal narrowing its own grants after issuance does not retroactively change a certificate already issued, only future issuance or reissuance. In representative mode, the principal's grants and the agent's authority are intersected dynamically at runtime, at each operation, so a change to the principal's grants can take effect at the gateway's next check rather than waiting for reissuance. These are two different revocation behaviors wearing the same certificate format, and this record does not flatten them into one.

Parameter intersection is a generic mechanism, not application semantics

The draft provides worked examples where an agent capability parameter inside the principal's declared boundary is accepted, and one exceeding that boundary is rejected. That intersection logic is generic: whether a specific parameter value is inside or outside a boundary is a comparison the gateway can perform mechanically once both sides are expressed the same way. What that parameter actually means to the application it addresses, whether an amount ceiling applies to a single transaction or a running total, whether a scope string names a resource or a category of resources, is left to the individual capability scheme, not to the base AIC specification. This record does not imply that the base specification understands arbitrary application semantics; it understands boundaries once a scheme has defined what the numbers and strings inside them mean.

Three kinds of limits, and only two of them are delegated authority

authorizationConstraints appears twice in this architecture, and the draft keeps the two appearances independent rather than merging them. The principal's own PrincipalAuthorization certificate can carry authorization constraints, and the agent's AIC certificate can carry its own authorizationConstraints, evaluated separately, with documented examples including IP ranges, concurrency limits and time windows. Both are constraints set by an authorizing party and both are evaluated at the gateway. Gateway local runtime policy, the deployment's own routing, rate limiting or logging configuration, sits outside this permission model entirely, in the draft's own account. This record preserves that three way distinction: principal authority constraints, agent execution constraints, and deployment runtime policy. An ordinary timeout, a routing rule or a logging setting is not, on this draft's own architecture, delegated authority, and this record does not treat it as such.

What the principal's signature actually covers

The principal cryptographically signs a DelegationAuthTBS structure, and the fields that signature covers are specific: agentId, principalUid, a stated reason, capabilities, delegationMode, authorizationConstraints when present, a requestedLifetime, a timestamp, and a nonce. That signature is cryptographic evidence that the corresponding principal key authorized that specific agent and those specific authority parameters, at that specific time, for that stated reason. The draft specifies a 32 byte random nonce and issuance time uniqueness checking as its replay protection design. This record describes that as protocol design, verified from the specification text, not as demonstrated replay resistance in a public implementation, because no public implementation of this draft exists for this record to test against.

A requested lifetime is not the same fact as a mandate

A principal requests a certificate lifetime as part of the DelegationAuthTBS structure; the issuing certificate authority determines the actual lifetime the certificate carries, subject to its own policy. Certificate expiry and mandate revocation are two different events in this architecture, and this record does not conflate them. A certificate can expire on schedule while the underlying mandate remains fully intact, and a mandate can be revoked while a certificate issued under it remains technically valid until the revocation propagates, which is exactly the gap the draft's own security considerations acknowledge.

The validation pipeline, and its off switch

Read directly from the draft, the relying gateway or party performs, in order, certificate chain validation, revocation checking, AIC parsing, delegation signature verification, principal constraint evaluation, agent constraint evaluation, delegation mode checks, delegation depth checks, capability evaluation, and deployment policy, before admitting a request. The editorial thesis behind this entire architecture depends on that admission decision happening before the target resource is reached, and the draft's own worked model places it there, at a gateway. What the draft does not do is make that pipeline universal. It states explicitly that a relying party that wants AIC authorization has to be configured to require and process the extension. An ordinary TLS server that never looks for the extension, or a relying party that has not deployed the gateway logic this draft describes, gets none of this. AIC does not become an authorization boundary by existing; it becomes one only where a relying party has actually built and enabled the pipeline the draft describes, and this record does not imply otherwise.

Revocation stops future admission. It does not undo what already happened.

The draft relies on standard certificate revocation mechanisms, CRLs and OCSP, with cached CRLs or short validity windows discussed specifically for offline deployments where a live revocation check is not always possible. It states plainly that certificate revocation is how a principal signals it no longer authorizes a particular agent. This record keeps four distinct outcomes separate rather than treating revocation as a single undifferentiated event. Revocation denies future admission decisions once it has propagated to whatever the relying party checks against. It does not, on anything this draft documents, terminate a TLS session already established under a certificate that was valid when that session began. It does not reverse an action the agent already completed before the revocation took effect. And recovery from a consequential action already executed under authority later found illegitimate, a rollback, a compensation mechanism, a dispute process, is not addressed anywhere this record could find in the draft text. Certificate revocation prevents acceptance going forward. It does not restore a deleted resource, reverse a payment, or undo anything else that already ran.

Delegation depth: one hop by default, one more at most

The default and recommended model in this draft is direct delegation from principal to agent, a single hop. The draft optionally supports one additional level, an agent delegating to a sub agent, with each level signing its own independent DelegationAuthorization and each level's capability set recursively intersected with the capability set above it, so a sub agent's effective authority can only be equal to or narrower than the agent that delegated to it, never broader. The draft recommends against chains deeper than that single additional hop. This record does not describe arbitrarily deep agent chains as supported; the draft itself recommends against them, for reasons the draft states as complicating attribution and accountability, and this record preserves that limit rather than extending it.

The Authority Provenance ledger

This is the part a Datatracker posting is never built to state on its own, so Moona Intelligence separates it out deliberately, distinguishing what the draft's cryptographic architecture establishes from what it leaves dependent on certificate authority issuance policy, and marking what the draft does not address as undocumented rather than inferring a mechanism that is not there.

Authority grantor. The principal identified through principalUid is the proximate grantor. The DelegationAuthorization signature is cryptographic evidence that the corresponding principal key authorized the agent and the specific parameters covered by DelegationAuthTBS. This record verified the binding the draft describes between principalUid and a keyHash carried in the principal's own certificate, which ties the delegation signature to a specific certified identity. It does not, on its own, establish a natural person's legal identity in every deployment; the draft describes different enterprise and consumer deployment models, and this record does not universalize a single identity assurance level across all of them.

Mandate or basis. This is the most important dimension, and the draft is explicit about where it stops. PrincipalAuthorization attempts to represent the principal's own authority boundary, certified by a certificate authority. The draft states directly that it does not constrain the authority of a certificate authority to issue a PrincipalAuthorization extension. The trustworthiness of PrincipalAuthorization therefore depends entirely on the issuing certificate authority's own issuance policy and on the relying party's trust anchor configuration. The resulting chain can establish that a trusted certificate authority certified the principal as holding grant set G, that the principal signed a delegation to the agent, that the agent carries capability set C, and that C sits inside G. It does not independently establish that the certificate authority's underlying organizational, contractual, statutory, fiduciary or governance determination was correct. No stronger mechanism is documented in this draft, so this record keeps mandate legitimacy dependent on certificate authority issuance policy rather than treating it as cryptographically solved.

Delegated scope. Documented at the level of the base specification's own fields, capabilities, delegationMode, authorizationConstraints, and undocumented beyond that at the level of what any specific capability actually permits inside an application, which the draft leaves to external capability schemes. This record does not interpret the draft's own example capability schemes, such as illustrative HTTP or database style capabilities, as standardized semantics; the draft itself states those schemes are externally defined.

Explicit limits. Documented where the draft specifies them: a requested certificate lifetime subject to certificate authority policy, authorizationConstraints such as IP ranges, concurrency limits and time windows, a delegationMode selecting authorized or representative behavior, and a delegation depth capped at one additional hop beyond direct principal to agent delegation. This record represents only limits the draft actually specifies, not limits inferred from what a deployment might reasonably add.

Inherited permissions and assumptions. The draft uses capability intersection, not automatic unrestricted inheritance. In multi agent delegation, each level's capabilities are recursively intersected with the level above it. This record found no mechanism in the draft by which a downstream delegation's authority can exceed what was delegated to it; the intersection operation is structurally non increasing, and this record does not infer monotonic authority growth beyond that.

Revocation or modification. Standard certificate revocation through CRLs and OCSP, with an acknowledged offline gap where a revoked certificate can be accepted until the next cache refresh, mitigated by short validity windows rather than eliminated. Authorized mode and representative mode behave differently here, and this record does not flatten them together. In authorized mode, a change to the principal's grants does not affect a certificate already issued; only reissuance or revocation changes what that certificate carries. In representative mode, principal grants are checked at runtime, so a narrower grant can take effect at the gateway's next evaluation without reissuing anything. Neither mode reverses an action already completed, and neither terminates a TLS session already established under a certificate that was valid when that session began.

Challenge authority. Undocumented. This record searched the draft for a mechanism allowing another organizational actor, a relying party, a resource owner, or a governance authority, to formally dispute the legitimacy of an existing PrincipalAuthorization once a certificate authority has issued it. Certificate rejection or revocation, which the draft does document, is not itself a formal challenge process; it is an outcome, not a channel for contesting whether the underlying certification was ever correct. No such channel is described in the draft text this record could verify, and this record records challenge authority as undocumented rather than assuming rejection or revocation fills that role.

Recovery. Undocumented. This record searched the draft for rollback, compensation, reversal or remediation mechanisms addressing a consequential action already executed before a revocation or a PrincipalAuthorization change took effect, and found none. Certificate revocation prevents future acceptance. It does not restore a deleted resource, reverse a payment, or undo any other action that already ran, and the draft does not claim otherwise.

Provenance evidence quality. Layered, and this record does not collapse the layers into one claim that AIC proves legitimate authority. Agent identity is documented at the specification level, through agentId and the agent's own certificate. Principal identity is documented the same way, through principalUid and the principal's certificate. The principal authority certificate, PrincipalAuthorization, is documented as a mechanism, but its trustworthiness is only as strong as the issuing certificate authority's own policy, which this draft does not define. Certificate authority issuance policy itself is, on this draft's own account, outside its scope entirely; the draft specifies technical checks a certificate authority can apply without specifying the organizational or legal process behind a principal's mandate. The principal signed delegation is documented in detail, with an exact field list covered by signature and a specified nonce and timestamp design, though replay resistance is protocol design rather than demonstrated behavior, since no public implementation exists to test. Delegated scope and constraints are documented at the specification field level and undocumented at the application semantics level, which the draft leaves external. Runtime validation is documented as a described pipeline, not independently demonstrated, again for lack of a public implementation. Revocation state is documented with an acknowledged gap. Challenge authority and recovery are both undocumented.

A private reference implementation is not a public one

The draft's implementation status section states that a Go reference implementation exists and covers certificate issuance, AIC parsing, admission decisions, revocation, offline authorization, constraint handling, delegation signature verification, permission intersection, and capability routing. The same section states, in the draft's own words, that the implementation is not yet publicly available and that repository links will be added when it is published. This record does not describe AIC as open source or as publicly implemented, and does not describe its tests as independently verifiable, because they are not, on the draft's own account, available for anyone outside the author to inspect. Moona Intelligence searched independently for a public repository, package, release, or interoperability report referencing this draft and found none as of this verification. The evidence level this record assigns is public design plus an author claimed private reference implementation, not demonstrated public enforcement. If a public artifact appears after this record is published, it is a distinct fact this record does not currently carry and would need to be verified and graded separately, not assumed from the draft's own claim.

Where this sits against what Moona Intelligence has already verified

x401 already owns a generic, credential neutral HTTP mechanism for demanding and verifying proof before an agent acts, with delegation evidence as an optional, composable layer rather than a certified boundary carried in the credential itself. Estonia's AI ID proposal already owns a government identity layer still short of an enacted technical specification. Nuggets' Authority Control Plane already owns a vendor enforcement layer that signs a receipt for its own permit, deny or refer decision, evaluated against a stored delegation record rather than a certified principal authority boundary. GitLab's composite identity already owns how a human role and a service account role intersect inside one company's own execution surface. BIND already owns a research proposal binding a fresh human biometric to a specific agent identity and task scope at the moment of delegation. Alipay's AHA protocol and Uber's actor chain architecture, covered in the same record, already own how identity and authorization propagate across multiple agent hops inside one company's own systems. None of them, on the material this record could verify, does what draft wei aic identity cert 00 proposes: using X.509 certificate extensions to cryptographically join a certified principal authority boundary, an agent's identity, a signed delegation record, capability and constraint fields, and gateway validation, into one certificate architecture, with a companion extension in the principal's own certificate representing what a trusted issuer certified that principal as holding. That is this draft's distinct contribution, and it is why this record treats it as its own canonical rather than folding it into any of the above.

It is also why this record refuses to let that distinct contribution round up into more than the draft itself claims. A relying party that builds and enables the full pipeline this draft describes can verify an agent's identity, its principal's signed delegation, the principal's own certified authority boundary, the agent's narrower capability set, additional constraints, current validity and revocation state, before admitting a request. What that relying party still cannot verify, from the certificate alone, is whether the certificate authority that certified the principal's authority boundary was right to do so. The draft says as much itself, by declining to constrain that authority. Agent credentials are beginning to carry Authority Provenance. Whether the provenance they carry is trustworthy still depends on the policy and trustworthiness of whoever issued it, not on the certificate.