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.

A public implementation appears, verified independently rather than accepted from the draft

This record's original verification, on 20 and 23 August 2026, found that draft wei aic identity cert 00 described a private Go reference implementation with no public repository link, and graded the evidence accordingly: public design plus an author claimed private implementation, not demonstrated public enforcement. On 31 August 2026, Moona Intelligence independently checked whether that had changed, rather than accepting a description of a claimed revision 01 at face value. It had. A GitHub account named varwof, identified by an ORCID rather than a company profile, now publishes seven public repositories corresponding to this draft's architecture. Types defines the ASN.1 structures for AIC, PrincipalAuthorization and DelegationAuthorization. Core is a certificate authority implementing issuance, revocation, an OCSP responder and offline authorization. Engine is a separate in memory subsystem handling certificate status and OCSP data. Gateway and gateway-core describe a relying party gateway that enforces an AIC verification step and routes capability meaning to plugins, matching the enforcement architecture this record already read from the draft's own text. Client is a command line tool for certificate lifecycle operations. This session fetched each repository directly, confirmed source code implementing the field names the draft defines, confirmed tagged releases on the types repository dated between 24 and 26 August 2026, and confirmed GitHub Actions continuous integration runs recorded as passing on the repositories that carry a workflow. This session did not itself execute any test suite, so continuous integration status here is independently observed rather than independently reproduced, and every one of these repositories is marked a preview not intended for production, several carrying zero or one star. Licensing is mixed across the ecosystem, Apache 2.0 for types, gateway, gateway-core, client and the companion aic-jwt repository, AGPL 3.0 for core and engine. That is a genuine, material change to this record's evidence grade for public implementation, from unknown to verified, and this record credits it precisely rather than rounding a technical preview up to a finished, audited or adopted system.

What this record could not confirm, and why it says so rather than repeating it

Three further claims accompanied the description of this update, and this record narrows each to what independent verification actually supports. First, a revision 01 of the draft itself, said to have been posted 30 August 2026. Both datatracker.ietf.org and www.ietf.org returned a policy level rejection from this session's own network egress proxy on every attempt, not a transient failure, so this record could not fetch either directly. An open web search for a revision 01 of this draft returned no result referencing one anywhere, including on the mailing list archives that carry IETF intellectual property rights disclosures. The varwof account's own types repository, which mirrors this exact draft's text in full text, markdown, XML and HTML form and was itself updated as recently as 30 August 2026, carries only draft wei aic identity cert 00 in every format, with no revision 01 file present. This record therefore continues to cite revision 00, the only text it could independently confirm, and does not carry a revision 01 changelog it could not verify. Second, an independent interoperability result against an implementation described to this session by the name EMILIA, said to reproduce thirteen positive and hostile conformance cases against this draft's verifier output. This session searched for such an implementation and found none. The only public project named EMILIA it could locate, EMILIA Protocol Inc, is an authorization receipt protocol for high risk agent actions by a different author, already evaluated as its own record in this corpus, with no reference anywhere in its own repository or public material to draft wei aic identity cert, to a crossing profile, or to a conformance result against it. This record does not carry an independent interoperability claim for this draft. Third, specific throughput and latency figures, including a Raspberry Pi 5 measurement. The core repository does publish a dated benchmark report, from 27 August 2026, describing a load test matrix and a reproduction script, and this session confirmed the report exists and read its stated scope. This session did not itself run the benchmark or verify the reported figures against an independent measurement, so this record describes the report as existing and documented, not as independently reproduced, and does not treat its numbers as production gateway latency or as representative of any deployment beyond the vendor's own test harness. A companion artifact, a JOSE based token profile called AIC JWT with its own separate Internet Draft, does exist as a public, tested implementation in Go and in TypeScript with WebCrypto for browser use. This record keeps it as a distinct artifact from the X.509 extension evaluated here, sharing an author and a type definitions dependency rather than being the same specification.

A regulator supervised financial sandbox reaches its first cohort

On 5 March 2026, the Hong Kong Monetary Authority, the Securities and Futures Commission, the Insurance Authority and the Mandatory Provident Fund Schemes Authority launched GenA.I. Sandbox++ with Cyberport. On 27 August 2026, the four regulators jointly announced the program's first cohort. From nearly 100 proposals, 36 use cases were selected, involving 30 financial institutions and 27 technology partners, prioritised on innovation, technical complexity and potential value to the financial industry with advice from a selection committee of academic experts. This cohort focuses on agentic A.I. rather than content generation alone, spanning customer onboarding, payments, insurance claims and customer interactions, and, building on an A.I. versus A.I. theme from an earlier GenA.I. Sandbox cohort, also includes use cases examining how one A.I. system can provide dynamic oversight of actions taken by another. Participants are being onboarded to a platform managed by Cyberport's Artificial Intelligence Supercomputing Centre, with technical trials expected to begin later in 2026. This record treats that announcement precisely as what it is: a regulator led program selecting pilot use cases for supervised testing. It is not a statute, a binding technical standard, an authorization protocol or a licensing approval for any resulting system, and being selected into the cohort is not commercial or regulatory approval of a participant's technical design. The cohort is also broader than any single participant. This record does not read all 36 use cases as agent identity evidence; it reads one of them, described below, because that one bears directly on the Authority Provenance question this record already tracks.

HKT Payment's Agentic ID, and what it would bind

The same day, HKT Payment Limited said it had been selected for a Sandbox++ pilot on registration and verification of AI agents that initiate payment flows, working with Red Date Technology, a Hong Kong headquartered decentralised technology and digital infrastructure provider, on a proposed framework HKT calls Agentic ID. HKT Payment Limited is not a new or untested entity in this space. It holds Hong Kong Monetary Authority stored value facility licence SVF0002, one of the first batch granted, and operates Tap and Go, a mobile wallet already integrated with Hong Kong's Faster Payment System for instant top up and peer to peer transfer. That licence establishes HKT Payment as a regulated stored value facility operator participating in the pilot. It does not, on anything this record could verify, establish that Agentic ID itself has been approved, reviewed or endorsed by the Hong Kong Monetary Authority; a stored value facility licence long predates this pilot and covers a different regulatory question, the safety of the stored value facility itself, not the technical design of an AI agent identity framework layered on top of it.

HKT describes Agentic ID as using decentralised identifiers, verifiable credentials and zero knowledge proof technology so that, in HKT's own stated aim, each AI agent is bound to a verified individual or enterprise principal, offered as a more secured and standardised way to register and verify AI agents acting on behalf of individuals and enterprises. The stated target workflows are payments, wallet top ups, peer to peer transfers and cross institution transactions, which line up closely with what Tap and Go already does today, this time with an agent, rather than a person, initiating the action. HKT frames the need for this against a specific gap: that existing Know Your Customer and Know Your Business frameworks were not designed to verify AI agents or to determine who is ultimately responsible for their actions. That framing is accurate as far as it goes and this record does not dispute it, but it describes a customer identity gap, not a transaction authority gap, and the two are not the same question. HKT also says the framework aims to help mitigate the risk of impersonation or unauthorised actions and to establish a clearer audit trail for AI driven transactions. This record narrows both claims to what HKT's own material states. On the audit trail, HKT's own public description says the framework aims to establish a clearer audit trail, without specifying what that trail contains; this record does not describe it as a signed transaction receipt, a cryptographic authorization record or an immutable audit log, because HKT's own material does not say that, and what the trail can be shown to establish, an agent's identity, its principal's identity, and an association between the two, is a narrower claim than evidence of what that principal actually authorized. On the zero knowledge proof claim, HKT describes the technology as enabling data to be verified and used without being revealed, giving users ownership and control over their private information. This record does not describe that as anonymous payments, full privacy or cryptographic proof of authority, because the public material does not specify which claims the proof covers, which credential fields stay hidden, or which party performs the verification; those are implementation details a zero knowledge system can be built several different ways around, and this record does not guess among them.

Agent to principal binding, applied to a second architecture

This record's Authority Provenance ledger, set out above for draft wei aic identity cert 00, applies here too, and the public material behind Agentic ID answers far fewer of its questions. That is not a criticism of a pilot at this stage; it is why this record narrows rather than assumes.

Authority grantor. HKT states each AI agent will be bound to a verified individual or enterprise principal. How that binding is technically established, what identity assurance level applies, and how a corporate principal's own authorized signatories are determined before an enterprise credential is issued, are not addressed in the public material this record could verify. This record does not infer resource ownership, account authority or corporate signing authority from the bare fact of a verified principal identity; verified principal identity and a principal's entitlement to delegate a specific financial resource are kept separate, and the latter is unknown here.

Mandate or basis. The public HKT and regulator announcements describe principal identity binding. Neither describes a transaction level mandate object, an amount, a purpose, a recipient category, a merchant, a time window or a transaction type tied to a specific delegation. This record does not invent one. Mandate or basis is unknown or undocumented on the material verified here.

Delegated scope. A verifiable credential can technically carry an authority scope claim. HKT's public material describes principal identity, not a documented scope schema for what a bound agent may spend, on whose behalf, or against which counterparties. This record does not infer a scope merely because the underlying credential technology is capable of representing one. Delegated scope is undocumented.

Explicit limits. No amount limit, merchant allowlist, geography restriction, time window or transaction cap is specified in the HKT or regulator material this record verified. This record does not borrow limits from unrelated Know Your Agent commentary or from other payment authority architectures already covered elsewhere in this corpus. Explicit limits are unknown.

Inherited permissions and assumptions. The dangerous assumption this record watches for across every agent identity architecture is that an agent bound to a principal thereby inherits all of that principal's permissions. Nothing in HKT's public material claims that, and nothing in it rules it out either. This record records the assumption as a risk to watch during technical trials rather than as a documented feature of the pilot in either direction.

Revocation or modification. Decentralised identifiers and verifiable credentials, as standards, both support status and revocation mechanisms. Whether this specific pilot implements DID status revocation, verifiable credential status lists, agent deregistration or principal level revocation is not documented in the public material this record could verify. This record does not infer an implementation from what the underlying standards make possible. Revocation is unknown.

Challenge authority. No human confirmation, step up approval or transaction level approval step is described in the public material for this pilot. This record does not add one because a payment is consequential; consequence is not evidence of a control existing. Challenge authority is unknown.

Recovery. No mechanism for agent credential compromise response, deregistration, transaction dispute or credential replacement is documented. This record also keeps identity recovery, restoring a compromised agent's credential, separate from payment reversal, undoing a settled transaction, and infers neither from the other. Recovery is unknown.

Provenance evidence quality. What is potentially established, on HKT's own description: an agent's identity, the identity of the principal it is bound to, and an association between the two, once the pilot's technical trials produce something to verify against rather than a design description alone. What HKT's material does not establish, and what this record therefore will not claim on its behalf: that a specific principal authorized a specific payment, that an agent's spending was within any bounded scope, or that a transaction can be traced to a live, unrevoked mandate. Agent to principal binding is a real and useful signal for whose agent this is. It is not, on the material available at the time of this pilot selection, evidence of what that principal actually authorized.

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. HKT Payment's Agentic ID pilot, added to this record above, does not change that: it is a much earlier stage, regulator supervised pilot proposing the same category of claim, an agent bound to a verified principal, without the certified principal authority boundary, delegation signature or gateway validation pipeline the AIC draft specifies, and this record folds it in here rather than treating it as a rival architecture. 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. Hong Kong's regulators are now asking a version of the same question inside a supervised payment sandbox: HKT's Agentic ID can potentially establish whose agent this is. It does not yet establish what that principal authorized, and this record will treat that as a separate, unresolved fact until Hong Kong's technical trials produce evidence to verify against.