]> Aelethion OU

rgburls@gmail.com

Security Network Working Group AI agent agent identity Merkle Tree Certificates WIMSE post-quantum audit This document profiles Merkle Tree Certificates (MTC) for the identity of AI agents. An MTAC certificate is an MTC whose subject is one AI agent instance, named by a workload identifier in a URI subject alternative name, so that it is also a Workload Identity Certificate. It carries a mandatory non-critical extension naming the sponsor the CA recorded as accountable for the agent, and two optional ones: scopes declared for the agent at issuance, and the model and configuration components the agent is issued for, each graded by how the CA came to record it. The document also defines an audit cosigner role and a procedure by which an auditor, possibly without network access and possibly long after issuance, can establish that a certificate was issued and logged and what it declared. An MTAC certificate identifies an agent. It does not authorize the agent to do anything, and it does not record what the agent did. Records of agent actions can be expressed as signed statements in a transparency service that refer to an MTAC certificate as the acting party.

Introduction

Problem AI agents increasingly act across organizational boundaries, on behalf of people and of other agents. In this document "agent" means an AI agent as defined in . After an agent has acted, a relying party, auditor or investigator often needs to determine three things: which agent instance acted, which organization a CA recorded as accountable for it, and what model and configuration were declared for it at the time. They may need to determine this without network access to the issuer, and over a period longer than classical signatures are expected to resist a cryptographically relevant quantum computer. An identity credential does not make an agent safe. An agent whose identity and permissions are all valid can still be induced to misuse access it legitimately holds. Preventing that needs controls on what an agent can reach and do, enforced outside the model, which this document does not specify. It addresses the narrower question those controls leave open: which identifier and declared configuration a CA bound to a key, and when.

Approach Merkle Tree Certificates (MTC) define X.509 certificates whose authenticity comes from inclusion in a CA-operated issuance log, cosigned by the CA and optionally by other cosigners, rather than from a per-certificate signature. MTC states that "X.509 extensions apply to Merkle Tree Certificates without any modifications" and that other documents may define cosigner roles. This document uses both extension points and defines no new log, tree, proof or signature format. This document specifies: a profile of the certificate contents for an AI agent subject, in which the subject is named by a workload identifier (); three certificate extensions describing the agent (); an audit cosigner role (); an audit verification procedure for a relying party that verifies a certificate after the fact and possibly offline (); how an MTAC certificate relates to workload identity credentials () and to transparency-service records of agent actions (). Because an MTAC certificate is an X.509 certificate with exactly one URI subject alternative name carrying a workload identifier, it is also a Workload Identity Certificate as described in .

Relationship to the previous version The previous version of this document specified a standalone credential format: a CBOR leaf, a bespoke signed tree head, a bespoke witness note and a bespoke holder commitment. Its stated distinguishing property, issuance by batch, is also the design of MTC, which applies it to any X.509 subject. This version therefore replaces the standalone format with a profile of MTC. maps each element of the previous format to its counterpart here.

What this document does not specify A relying party MUST NOT infer any of the following from a successful verification under this document. Authorization. Declared scopes () are recorded at issuance as the requesting party stated them. They are not permissions. This document defines no mechanism by which they constrain an agent, and a relying party MUST NOT treat a declared scope as evidence that the agent operated within it. Behavior. Verification establishes that a certificate was issued and logged, and what it declared. It does not establish what the agent subsequently did. Action records. No format for records of agent actions is defined; describes how such records can refer to an MTAC certificate. Runtime attestation. A configuration claim marked as declared () is a statement made at issuance. It is not evidence that the declared model or configuration was the one that executed. Authority of the sponsor. The sponsor, capacity and mandate fields () record what the CA was told and, under its policy, checked. They are not evidence that the sponsor has authority over the agent, that the requester could bind the sponsor, or that the sponsor has any legal duty for the agent. Those are matters for law and for the parties' arrangements. Presenter identity. Holding the certificate bytes says nothing about the presenter. A proof of possession () shows control of the certified key, not that the presenter is the agent named in the certificate.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses the terms CA, CA ID, issuance log, log entry, cosigner, cosigner ID, subtree, checkpoint, standalone certificate, landmark-relative certificate, MTCProof, TBSCertificateLogEntry and relying party as used in .

AI agent:

A workload that iteratively interacts with a large language model or comparable model to decide its actions, following the usage in . In this document "agent" on its own is shorthand for "AI agent". It never means the node-local credential provisioning component that also calls an agent.

Agent instance:

One deployed AI agent, identified by one agent identifier (). Its key and declared configuration can change over time; each change is reflected in a new certificate.

MTAC certificate:

A Merkle Tree Certificate that conforms to .

Sponsor:

The organization or person that requested issuance of an MTAC certificate and that the issuing CA records as accountable for the agent instance.

Declared:

Stated by the party requesting issuance and recorded by the CA without independent verification.

Audit cosigner:

A cosigner acting in the role defined in .

Audit:

In this document, technical verification carried out after the fact, with the inputs of . It does not mean professional assurance or an audit in an accounting or regulatory sense.

Audit relying party:

A relying party that verifies an MTAC certificate for the purpose of establishing, after the fact, that it was issued and logged and what it declared, using the procedure in .

Time of interest:

The instant an audit relying party is asking about, for example the time an action attributed to the agent instance took place.

Architecture Overview An MTAC deployment has the following parts, each of which is an MTC role unless noted: An MTC CA with one or more issuance logs, operating a CA cosigner. One or more audit cosigners (), which this document defines as an MTC cosigner role. Agent instances, each holding the private key for its certificate. Online relying parties, which verify a presented certificate as any MTC relying party does and, where they require it, a proof of possession. Audit relying parties, which verify a retained certificate after the fact. Optionally, a transparency service in which signed statements about agent actions are registered (). This is not part of the profile. The flow is as follows. A sponsor requests a certificate for an agent instance, supplying the agent's public key, its workload identifier and the values for the extensions in . The CA validates what its policy requires, adds a TBSCertificateLogEntry to its issuance log and, following Section 6.3 of , obtains cosignatures from its CA cosigner and from at least one audit cosigner (). The agent instance receives a standalone certificate. Online relying parties verify it when the agent presents it. An auditor who later holds the certificate, the cosigner keys and the material listed in can verify it without contacting the CA. This document does not change how MTC CAs operate their logs, how cosigners sign, or how certificates are constructed.

Certificate Profile An MTAC certificate MUST be a Merkle Tree Certificate as specified in , Section 6, whose log entry has type tbs_cert_entry. This document defines no new MTCLogEntryType and no MTCLogEntryExtensionType. The following requirements apply to the TBSCertificateLogEntry and therefore, by Section 6.2 of , to the certificate.

Version The version MUST be v3, because the profile uses extensions.

Subject and agent identifier The agent identifier MUST be a workload identifier as defined in Section 4.1 of : an absolute URI whose authority component is the trust domain, with no query, fragment, user information or port component. The certificate MUST contain a subjectAltName extension with exactly one GeneralName of type uniformResourceIdentifier, and that GeneralName is the agent identifier. The certificate MAY contain subjectAltName entries of other types. With these rules the certificate meets the subject naming requirements for a Workload Identity Certificate in Section 6.1 of . The subject field SHOULD be an empty sequence. When it is empty, the subjectAltName extension MUST be marked critical, as Section 4.2.1.6 of requires. Relying parties MUST compare agent identifiers as complete URIs, as Section 4.3 of requires. An agent identifier names one agent instance. An issuer MUST NOT use the same agent identifier for two agent instances. Several certificates for the same identifier can be valid at once, for example during renewal and key rotation as Section 10.4 of recommends, or briefly after a configuration change (). A relying party therefore MUST determine the key and the declared configuration from the certificate actually presented or referenced, and not from the identifier alone. A CA MUST NOT issue an MTAC certificate for an agent identifier in a trust domain it is not authorized for under its certificate policy. Relying parties MUST bind each trust domain to the CA IDs authorized to issue for it, as Section 3 of requires of consumers, and MUST reject a certificate whose issuing CA is not authorized for the identifier's trust domain. A relying party MAY enforce the binding by supplying the authorized trust domains as initial-permitted-subtrees (Section 6.1.1 of ) or as trust anchor constraints . Name constraints placed in an MTC CA certificate are not processed when that certificate is used as a trust anchor.

Subject public key The subjectPublicKeyInfo carries the agent instance's public key. This document does not restrict its algorithm. Deployments that require post-quantum protection for the agent's own signatures SHOULD use ML-DSA as specified for X.509 in . Recommendations for long-lived records are in . The keyUsage extension, if present, MUST include digitalSignature and MUST NOT include keyCertSign. The basicConstraints extension, if present, MUST NOT assert cA.

Validity notBefore and notAfter have their meaning: the period during which the CA vouches for the binding. Issuers SHOULD keep validity short, in line with the guidance in that agent credentials be short-lived. Because each issuance run costs each cosigner a small constant number of signatures however many certificates it covers (Section 6.3 of ), short validity does not multiply signing cost. It does increase log size and monitoring load (Section 10.1 of that document). An audit relying party evaluates validity against a time of interest, not only against the time of verification. defines how the two are reported.

Profile extensions An MTAC certificate MUST contain the Agent Sponsor extension and MAY contain the other extensions defined in . Each of them MUST be marked non-critical. A relying party that does not recognize them is not affected by ignoring them, because none of them grants anything.

Issuance requirements An MTAC CA MUST make the standalone form of every MTAC certificate available to the subject, even when it also issues a landmark-relative form, and MUST include in every standalone MTAC certificate a subtree signature from at least one audit cosigner () in addition to its CA cosigner signature. Without one, the certificate cannot pass audit verification (). The material that dates issuance () is a timestamped checkpoint and a subtree consistency proof, and MTC permits CAs and mirrors to stop serving old entries (Section 10.3 of ). An MTAC CA SHOULD therefore deliver to the subject, as soon as an audit cosigner has signed a timestamped checkpoint covering the certificate, that checkpoint signature and the subtree consistency proof between the certificate's subtree and that checkpoint. Because a CA usually requests a checkpoint cosignature before collecting subtree cosignatures (Section 6.3 of ), such a checkpoint normally exists at issuance. Any party that retains an MTAC certificate for later audit is responsible for retaining this material with it.

Agent Extensions The ASN.1 module for these extensions is in . Object identifiers are to be assigned by IANA ().

Agent Sponsor

The Agent Sponsor extension names the sponsor: the party that requested the certificate and that the CA records as accountable for the agent instance. It is the one extension every MTAC certificate MUST contain. A relying party that implements this profile recognizes an MTAC certificate by the presence of this extension, and a party that does not implement it treats the certificate as an ordinary Merkle Tree Certificate. sponsor is one or more GeneralNames that all identify the same sponsor, for example one organization by register code and by directory name. It MUST NOT name different parties. A deployment can name the sponsor with whatever identifier its context already uses, for example a directoryName for an organization registered in a legal entity register, a uniformResourceIdentifier, or an rfc822Name. A URI that names an organization by a register code, using a scheme the deployment defines or adopts, is RECOMMENDED where such a register exists, because it is stable and language neutral. This document defines no such scheme. capacity, when present, is text naming the office or role in which the sponsor acts for this agent, for example "authorised signatory". It is declared, not verified, unless the CA's certificate policy states otherwise. mandate, when present, is a URI that points to an external authorization under which the sponsor acts or acted, for example a signed power of attorney or an entry in a mandate register. MTAC does not store, fetch or evaluate the mandate, and a relying party MUST NOT treat the presence of this field as evidence that any authority exists or that the mandate is valid, current or covers this agent. The URI is recorded in a log that many parties can read: it MUST NOT contain a credential, token, or any value that grants access, and a relying party MUST NOT dereference it automatically. An agent is not a legal person under this document, and nothing in an MTAC certificate gives an agent legal capacity. The sponsor can be a natural person or a legal person; the extension records which one the CA recorded as accountable. Whether and how the law holds that party responsible for the agent is outside this document. The CA MUST validate the sponsor's identity, and SHOULD establish that the requester is entitled to name that sponsor, to the level its certificate policy states before including this extension. This document does not define such a level. A relying party learns from this extension only that the CA, under its own policy, recorded this sponsor as accountable. The names in this extension are not subject to name constraints, which apply only to subject names and subject alternative names. They are not subject alternative names and are not matched as such. Issuers SHOULD name an organization rather than a natural person; see .

Declared Scopes

The Declared Scopes extension records, as text, the operation classes the sponsor declared for the agent instance at issuance. This document defines no vocabulary for the strings; deployments agree on one among themselves. They are intended for an auditor, who can later compare the operation classes the sponsor declared with what the sponsor and agent actually did, using records outside this document. A declaration can go stale; a changed declaration is a new certificate (). Declared scopes are not authorization. A relying party MUST NOT treat a declared scope as a permission or as evidence of behavior. In particular, an implementation MUST NOT map a declared scope to an OAuth scope or authorization_details value without a separate authorization decision. The order of the strings has no defined meaning.

Agent Configuration

The Agent Configuration extension records the components declared for, or verified by the CA for, the agent instance: which model, which runtime, which configuration, and optionally which data sets. role names the kind of component. This document defines the following values. Any other value MUST be an absolute URI under the control of the party that defines it, so that independently defined roles do not collide. role meaning model a model the agent instance invokes model-weights the specific weights of a model, normally identified by digest runtime the inference or serving runtime agent-framework the software that drives the agent loop system-instructions the standing instructions given to the model toolset the set of tools the agent instance is configured to use dataset a data set used to train, tune or ground the agent instance policy a policy document the agent instance is configured with name and version are human-readable labels. They are informative and SHOULD NOT be the basis of an automated decision on their own. digest, when present, is a cryptographic digest of the component or of a description of it. This document does not define what is digested; that is identified by reference or by a deployment profile. Two parties can compare digests only if they agree on that input. The AlgorithmIdentifier parameters MUST be absent, and the length of value MUST equal the output length of the algorithm, so that each digest has one encoding. The algorithm MUST be one the relying party's policy accepts. The ASN.1 type admits the SHA-2 algorithms of and is extensible; this document does not choose one. reference, when present, is a URI , following the rules of Section 7.4 of for URIs in certificates, at which more information about the component can be found, for example an Entity Attestation Token claims set , a model card, or a bill of materials. The CA does not vouch for the content at that URI unless digest covers it. source grades how the CA came to record the component: declared: the sponsor stated it and the CA recorded it without checking. issuerVerified: the CA checked it against something under the CA's control or inspection, as described in its certificate policy, before issuance. attested: the CA appraised remote attestation evidence for the component before issuance, under a policy its certificate policy states. describes one such issuance flow. A relying party MUST treat a component marked declared as a statement by the sponsor, not as evidence of what executed. A CA MUST NOT mark a component attested on the basis of a name or version string alone. A component marked attested or issuerVerified reflects the CA's appraisal at issuance only. It is not evidence of what ran at any later time, including a time of interest. A relying party that encounters a source value it does not recognize MUST treat the component as declared. This extension does not define a vocabulary for model properties. Deployments that need one SHOULD reference an existing claims format through reference and digest rather than extending this structure. defines a detailed vocabulary for model, runtime and decoding settings, and also grades each claim by source.

Configuration epochs An issuer SHOULD issue a new certificate, with a new serial number, whenever any component in the Agent Configuration extension changes, and SHOULD set notAfter no later than the end of the period for which it expects the configuration to remain unchanged. Where the issuer follows this, the issuance log records when a certificate with a changed declared configuration was issued for an agent identifier. Combined with the certificate actually used at a time of interest (for example the one carried in a signed statement, ), that lets an auditor determine which configuration was declared for that use. It does not show whether the agent instance's decisions were consistent across configurations. When a configuration changes, the earlier certificate may remain valid until it expires; an issuer that needs it to stop being accepted sooner must revoke it.

Audit Cosigner Role Section 5.3 of permits other documents to define cosigner roles. This section defines the audit cosigner role.

Statements and obligations Every MTC cosigner is already required to keep the subtrees it signs consistent with each other (Section 5.3.2 of ). An audit cosigner obtains that assurance by checking consistency proofs, as a witness does in . An audit cosigner's subtree signatures make no additional statement about the subtree. An audit cosigner has one operational obligation, which it states in its published policy: it retains every checkpoint signature it produces with a non-zero timestamp, and makes them available to audit relying parties, for at least a stated audit retention period. An audit cosigner makes no statement about the content of any log entry. In particular it does not certify agent identifiers, sponsors, scopes or configurations. Those are the CA's statements alone.

Timestamped checkpoints An audit cosigner SHOULD sign timestamped checkpoints (non-zero timestamp, Section 5.3.1 of ) at an interval stated in its published policy. A timestamped checkpoint from an audit cosigner serves two purposes for an auditor: It is a high-water mark. An auditor that holds a timestamped checkpoint of size N can detect a later view of the log that is inconsistent with it. It dates issuance. If an MTAC certificate's log entry is included in a tree that an audit cosigner signed with timestamp T, the entry existed no later than T, independently of any time the certificate itself states. That date rests on the audit cosigner's clock and honesty, since the timestamp is the cosigner's own statement of when it signed.

Independence An audit cosigner provides a property beyond the CA cosigner only to the extent that it is operated independently of the CA. An audit cosigner SHOULD be operated by a party administratively independent of the CA. A deployment in which the same party operates the CA and the audit cosigner obtains consistency checking without independence, and an audit relying party SHOULD be told which is the case. Each audit cosigner MUST use a cosigner ID distinct from every other cosigner role its operator performs, as Section 5.3 of requires.

Algorithms An audit cosigner MUST sign with a post-quantum signature algorithm, because its signatures are what an auditor relies on long after issuance. Where the cosigning protocol in use supports one, an audit cosigner SHOULD use a signature algorithm from a different family than the CA cosigner, for example SLH-DSA where the CA cosigner uses ML-DSA, so that a break of one signature family does not on its own permit forgery of a certificate an auditor accepts. Deployments should note that the cosignature protocol of does not currently define SLH-DSA, and that SLH-DSA signatures are considerably larger than ML-DSA signatures, which works against the size goals of MTC. Section 5.3.3 of requires a new cosigner ID for any change of key or algorithm, which fixes the algorithm for every signature under a given cosigner ID.

Public corroboration An audit cosigner MAY additionally publish its timestamped checkpoints, or digests of them, to an independent public medium. A value published this way corroborates the checkpoint only. It says nothing about the content of any entry, and the availability and durability of the medium are outside the scope of this document.

Proof of Possession An MTAC certificate presented without proof of possession of the subject private key is a bearer presentation: anyone holding the certificate bytes can present it, and a copied certificate is indistinguishable from the original. This document does not define a possession protocol. A relying party that requires proof of possession SHOULD use an existing one in which the subject key signs over a fresh value, for example TLS client authentication with the certificate, or the workload proof mechanisms described in and when used with a WIT backed by the certificate (). Any such protocol used with an MTAC certificate MUST meet the following: Freshness. The signed message MUST include either a challenge the relying party generated from a cryptographically secure random source, at least 16 octets long and used once, or a unique identifier that the relying party checks for replay within a bounded acceptance window. Binding. The relying party MUST associate the result with the agent identifier taken from the verified certificate, not with any identifier the presenter supplies. Signature. The relying party MUST verify the signature with the certificate's subject public key. provides the second form of freshness, through its jti claim, and binds to a WIT rather than directly to a certificate. A successful possession check shows that the presenter controlled the certified private key at presentation. It does not show that the presenter is the agent instance named in the certificate.

Verification

Online verification An online relying party performs X.509 path validation as Section 6.1 of specifies, with the signature verification step replaced by the procedure of Section 7.2 of , under its configuration (Section 7.1 of that document) and cosigner policy (Section 7.3). It then applies the following profile checks: The certificate contains exactly one URI subjectAltName, and that URI conforms to Section 4.1 of . The issuing CA is authorized for the trust domain of that identifier (). The Agent Sponsor extension is present, and any extension defined in decodes as specified (). A relying party MUST reject a certificate in which such an extension is present but does not decode. Unknown values of an extensible field are not decoding failures. Where the relying party requires it, proof of possession succeeds ().

Decoding and what may be relied on The signature verification of Section 7.2 of authenticates the TBSCertificate fields exactly as they are copied into the log entry. What a relying party then reads from the certificate must be those same authenticated bytes, and nothing else. Accordingly: A relying party MUST parse the TBSCertificate, and the value of each extension defined in , with a conforming DER parser, and MUST reject a value that is not valid DER, including values with non-minimal lengths, trailing octets, or any other encoding a DER encoder would not produce for the same abstract value. Where a value contains no content the relying party does not recognize, re-encoding the decoded value with DER MUST reproduce the received octets exactly. A relying party that does not use a conforming DER parser MUST apply the additional checks of Section 12.6 of . Every value a relying party reports, records or acts on, including the agent identifier and the contents of every extension in , MUST be taken from the decoded fields of the TBSCertificate whose signature verification succeeded. It MUST NOT be taken from any other bytes, such as an unverified copy of the certificate, a field supplied alongside it, or a search of the raw encoding. A relying party MUST NOT compute or verify the entry hash over a re-encoding of only the fields it recognizes. Fields it does not recognize, including unknown additions within an extensible structure, are part of what was authenticated. A relying party MAY disregard their meaning, but when it reports the contents of an extension it MUST indicate that unrecognized content was present rather than presenting the extension as if that content were absent.

Audit verification This section defines how an audit relying party verifies an MTAC certificate after the fact.

Inputs An audit relying party needs: The certificate, in standalone form (Section 6.3 of ). A landmark-relative certificate cannot be verified without the landmark material that applied when it was issued, which an auditor may no longer be able to obtain. An audit configuration: the CA ID, the log hash algorithm, the CA cosigner ID and public key, the IDs and public keys of the audit cosigners it accepts, and the trust domains the CA was authorized for, all as they were when the certificate was issued. These are the items of Section 7.1 of , archived, plus the trust domain binding of . They MUST have been obtained by a means the auditor trusts. Keys taken from the material being audited provide no assurance. A cosigner policy naming the CA cosigner, which certifies entries, and at least one audit cosigner, which adds consistency checking and dating. None of these cosigners other than the CA cosigner is an issuer. Revocation information, together with the time at which each part of it was current: archived revoked ranges (Section 7.5 of ) and any other revocation information the CA publishes, such as a CRL. A time of interest. Optionally, a timestamped checkpoint signed by an audit cosigner and a subtree consistency proof (Section 4.4 of ) between the certificate's subtree and that checkpoint, to date issuance. A party that retains an MTAC certificate for later audit MUST retain its standalone form, even if it presents a landmark-relative form in protocols that prefer one (for example Section 8.2 of for TLS). It SHOULD also retain any CRL or OCSP response it obtains that lists the certificate, because a suspension that is later released can no longer be reconstructed. This document does not define a serialization that bundles these inputs.

Procedure Verify the certificate's MTCProof as Section 7.2 of specifies, under the audit configuration and cosigner policy, using as its revoked ranges those of the audit configuration as they were at issuance (which include the bound on log numbers that Section 12.2.2 of that document relies on, but not later retirement of this certificate), and perform the other path validation checks of Section 6.1 of except those on validity and revocation. Revocation is evaluated separately in step 4, because a relying party routinely revokes the serial numbers of expired certificates (Section 7.5 of ), which would otherwise make every old certificate fail this step. If this step fails, the result is a failure and no further step applies. Apply profile checks 1 to 3 of the online procedure, and the rules of . Evaluate the validity period against the time of interest and, separately, against the time of verification. Evaluate revocation. Report whether the serial number falls in an archived revoked range, and whether other revocation information lists it with a date and reason. A revoked range carries no reason or date, so it cannot distinguish routine retirement of expired serial numbers from revocation for cause; report such a match as "in a revoked range, reason unknown". Record the time at which each piece of revocation information was current. If a timestamped checkpoint and consistency proof are supplied, check that the checkpoint is for the certificate's issuance log and covers the subtree [0, N) for its stated size N, verify its signature under the audit cosigner's key, verify the consistency proof, and record the checkpoint timestamp as the time by which the entry existed. Extract the agent identifier and the contents of each extension in , including each component's source value.

Results An audit relying party MUST report the outcome of each step separately and in a machine-readable form. It MUST NOT collapse them into a single "valid" result, because they answer different questions: Question Answered by Did this CA issue and log this certificate, with these contents? step 1 Was the time of interest within the certificate's validity period? step 3 Is the certificate within its validity period now? step 3 Does the certificate meet the profile of and decode as requires? step 2 Is the serial number in a revoked range or listed as revoked, with what date and reason if known, and how current was that information? step 4 By what time is the certificate known to have existed? step 5 What did the certificate declare, and how was each configuration claim graded? step 6 A certificate whose validity period has ended still passes step 1. That result means the certificate was issued and logged with the stated contents. It does not mean the certificate was valid at any particular time, and an implementation MUST NOT present it as current validity. The result of step 1 depends on the CA cosigner and audit cosigners named in the audit configuration. An implementation SHOULD report which cosigners' signatures were verified.

Offline operation Every step of the procedure is local computation over the inputs. An auditor or relying party that operates without network access, for example in an isolated environment, needs the inputs to have been provisioned before it was disconnected. Revocation is the input most affected. A verifier without fresh revocation information cannot know about revocations made since its information was current. A deployment that verifies offline MUST state its policy, either to fail when revocation information is older than a stated bound or to accept with a stated bound, and a verifier MUST report the time at which the revocation information it used was current.

Revocation and Suspension This section states what this profile provides for ending an agent's identity, and what it does not. An MTAC certificate stops being accepted by a relying party through one of these mechanisms: Expiry. The validity period ends. Issuers SHOULD keep validity short (), because expiry is the one mechanism that works for every relying party, including those that are offline. It is also the bound on the delay for a relying party that applies no other mechanism: such a party continues to accept an unwanted certificate until notAfter. CRL and OCSP. Existing mechanisms apply to Merkle Tree Certificates unchanged (Section 12.7 of ). They carry a revocation time and a reason. Revoked serial number ranges. A relying party's configuration includes revoked ranges (Section 7.5 of ), which it can extend from out-of-band information. Serial numbers are assigned in log order, so a range can disable a run of certificates or a whole log. A range carries no reason and no date. MTC defines no way for a CA to publish ranges; a deployment needs to supply one. How quickly each takes effect depends on how often the relying party obtains the information. An MTAC CA SHOULD publish a revocation policy stating which mechanisms it operates, how often it publishes, and the worst-case delay between a decision to revoke and publication. A relying party that needs prompt effect MUST obtain revocation information more often than the delay it can accept, or rely on short validity. Reasons. When a CA revokes through a CRL or OCSP it SHOULD use the reason codes of with these meanings in this profile: keyCompromise: the agent's key may be exposed. invalidityDate is set to the earliest time the CA believes this to be so. affiliationChanged: the sponsor no longer stands as the recorded party, for example because the sponsor ended the mandate or ceased to exist. superseded: a replacement certificate has been issued, including for a changed configuration (). cessationOfOperation: the agent instance has been retired. certificateHold: suspension, which is reversible. In a complete CRL the entry is omitted from later lists; in a delta CRL it is removed with removeFromCRL (Section 5.3.1 of ); an OCSP responder reports the certificate as good again. Revoking or suspending a certificate ends only the identity it carried. It does not withdraw any authority the sponsor granted to the agent elsewhere, and it does not undo anything the agent did. This document defines no status protocol of its own. An audit relying party can see only the revocation information it holds (). In particular, a suspension that was later released leaves no trace in later complete CRLs, and the interval between a key compromise and its revocation is visible only if invalidityDate was set and the relevant CRL was archived.

Relationship to Workload Identity This section is informative. treats AI agents as workloads, requires each to have exactly one workload identifier, and names the Workload Identity Token (WIT) and the Workload Identity Certificate (WIC) of as credential formats, noting that the choice depends on the deployment's trust model. An MTAC certificate is a WIC: an X.509 certificate with the workload identifier in exactly one URI subject alternative name. It is one way to issue a WIC, adding issuance transparency, audit cosigners and the agent extensions. It does not replace the WIT. A deployment that uses WITs can back them with an MTAC certificate. An identity server that issues a WIT for an agent instance holding an MTAC certificate can set the WIT sub to the certificate's agent identifier, set cnf.jwk to the certificate's subject public key (for an ML-DSA key, in the form defines), and set the WIT expiry no later than the certificate's notAfter. A relying party can then check that the WIT and the certificate name the same identifier and key. The WIT's own signature algorithm is chosen independently, so a deployment that needs post-quantum protection end to end needs a post-quantum WIT signature as well. Interoperability is a further constraint: requires general purpose implementations to support ES256, not ML-DSA, so a general purpose WIT verifier need not accept an ML-DSA key in cnf.jwk. An MTAC certificate could be presented as a subject_token or actor_token in OAuth Token Exchange or as input to a Transaction Token service . Defining the token type for that is left to a future version. describes binding an AI agent to an accountable owner. The Agent Sponsor extension () is one way to carry that binding in a certificate.

Relationship to Transparency Services for Agent Actions This section is informative. Records of agent actions are a separate layer from identity. Several documents define such records as signed statements registered in a transparency service following , for example , and . They generally leave open how a verifier relates the signing key to an agent identifier. An MTAC certificate supplies the CA's binding between the signing key and an agent identifier, without new registrations. It does not show which software produced a given signature. The agent instance signs the statement with its certified private key. The signature shows that the statement was signed with the certified key. It is not a fresh proof of possession in the sense of . The protected header carries the MTAC certificate in x5chain, or identifies it with x5t and carries it in x5chain in the unprotected header, as defines and , Section 5.1.1.1, permits for X.509 signed statements. Because the same MTC certificate can carry different MTCProof values (Section 12.6 of ), statements cannot be correlated reliably by x5t; correlating them by CA ID and serial number, or by agent identifier, avoids this. The CWT claims header carries iss equal to the certificate's agent identifier, which satisfies the requirement of , Section 6, that iss be a URI when x5chain is used. sub identifies the artifact the statement is about, and iat is the signing time. A verifier then verifies the statement's signature with the certificate's subject key, checks that iss equals the agent identifier, checks the transparency service receipt as specifies, and verifies the certificate as in . The time of interest is the registration time, where the transparency service states one in a signed claim of the Receipt (for example iat; , Section 7.2, describes optional time claims in Receipts). That time rests on the transparency service's clock and honesty. The statement's own iat is set by the key holder, who can set it to any value, so it is only a claim; a verifier reports any difference from the registration time beyond a stated tolerance. Where no signed registration time is available, a verifier reports that it has no time of interest it can rely on, rather than falling back to the statement's iat. Registration can use the interface defined in . Section 5.1.1.1 of requires a transparency service that accepts X.509 signed statements to build and validate a certification path from the issuer's certificate to a trust anchor it has registered. A transparency service can therefore accept statements identified this way only if it can verify Merkle Tree Certificates and has the MTAC CA registered as a trust anchor, which also requires to be made transparent by registering it as a signed statement. The audit cosigners' public keys can be registered the same way. Records need not be SCITT statements. , for example, defines an audit record for agent authorization decisions with an agent.id that carries a WIMSE identifier and an agent.credentialDigest that is the digest of the credential the identifier was read from. For an agent holding an MTAC certificate, agent.id can be the certificate's agent identifier, and the credential digest can be computed over the DER encoding of the TBSCertificate, which is not malleable, rather than over the whole certificate, whose MTCProof is (Section 12.6 of ). The hash algorithm is the one that record format specifies. A reader of such a record can then retrieve the certificate, verify it as in , and see which party the CA recorded as accountable for the agent and what was declared for it. An MTC proof is not a COSE Receipt. An MTCProof proves inclusion in a subtree under the signatures of cosigners, while a Receipt proves inclusion in a tree under the transparency service's own signature. In particular, requires at least one inclusion path element, so the empty path of a one-entry tree cannot be carried as a Receipt.

Publication of Issuer Information This section is informative. A relying party needs the configuration of Section 7.1 of for each MTAC CA it accepts: the CA ID, the log hash algorithm, the CA cosigner and audit cosigner keys, the cosigner policy, and revocation information. This profile adds one more item, the trust domains the CA is authorized for (). Much of this information is also carried by the CA certificate structure of Section 5.5 of , which a registry can publish directly. A national, sectoral or organizational registry can list MTAC CAs, publishing that configuration together with the CA's certificate policy and revocation policy, so that relying parties obtain it from a place they already trust and an auditor can later retrieve the configuration as it stood at a past time. Such a registry decides which CAs it lists and on what basis. Any legal or regulatory status of a CA derives from its listing, not from an MTAC certificate. The format and operation of a registry are outside the scope of this document.

Post-Quantum and Long-Term Considerations states requirements PQ-R1 to PQ-R7 for post-quantum agent identity and observes that the previous version of this document addressed issuance only. This section states how this profile relates to each requirement. It does not claim conformance to that document, which is itself an individual draft.

PQ-R1 (algorithm agility):

Nothing in this profile fixes an algorithm. The subject key's algorithm is explicit in the subjectPublicKeyInfo. Cosigner algorithms are identified only by reference: the MTCProof carries cosigner IDs, and the algorithm for each comes from the relying party's configuration (Section 5.3.3 of ). The MTCProof therefore does not meet PQ-R1's requirement for an explicit algorithm identifier in the credential. Relying parties MUST be able to accept cosigners with different algorithms concurrently. A deployment that wants hybrid protection for subject keys can use composite signatures .

PQ-R2 (post-quantum issuance for retained credentials):

MTAC certificates are intended to be retained for later audit (). Their authenticity rests on cosigner signatures. requires audit cosigners to sign with a post-quantum algorithm. A deployment that needs post-quantum protection for the whole path MUST also use a post-quantum CA cosigner.

PQ-R3 (non-separable delegation binding):

An MTAC certificate is a single credential, not a delegation chain. Where it is an input to a chain, the chain mechanism is responsible for this requirement.

PQ-R4 (trust anchor precedence):

The keys a relying party is configured with are the CA cosigner key and the audit cosigner keys. A deployment that issues MTAC certificates under post-quantum cosigners from the start never has a classical cosigner key to retire. Any change of cosigner algorithm requires a new cosigner ID, so relying parties stop accepting an old key by removing it from their configuration. This profile does not state a migration order or a cut-off date, which PQ-R4 asks a specification to state.

PQ-R5 (downgrade resistance):

A relying party's cosigner configuration (Section 7.1 of ) fixes which keys and algorithms it accepts. A relying party MUST NOT derive acceptable algorithms from the certificate.

PQ-R6 (chain strength visibility):

A standalone MTAC certificate carries its own binding to the cosigner keys its relying parties are configured with: the inclusion proof and the cosignatures. The standalone certificate carries that binding, so it is retained with the certificate.

PQ-R7 (audit record longevity):

The audit cosigners' timestamped checkpoints and their retention obligation () provide post-quantum anchoring of the certificate, where the audit cosigner has signed a timestamped checkpoint covering it, dated by the checkpoint, and witnessed independently when the audit cosigner is independent of the CA. Family diversity between the CA cosigner and an audit cosigner does not meet PQ-R7's recommendation of two separate protections that share neither a hash function nor an authority, because both cosigners sign the same SHA-256 subtree hash within one structure. This profile does not define renewal of protection over time, and it does not address the retention of action records, which is the responsibility of whatever system holds them.

CNSA 2.0 MTAC certificates cannot conform to the Commercial National Security Algorithm Suite 2.0 profile for certificates . That profile requires the signature on every certificate to be made with ML-DSA-87, whereas the signature of an MTC certificate is an MTCProof identified by id-alg-mtcProof. It also requires SHA-384 or SHA-512 for other hashing, and a critical keyUsage extension, an extended key usage extension and an authority key identifier in end-entity certificates. ML-DSA-87 can be used for subject keys and cosigners, since this profile fixes none of those algorithms, but conformance would need a CNSA profile that admits MTC proofs; choosing a SHA-384 log hash would not be enough. SLH-DSA, the example of a different signature family given in , is not a CNSA 2.0 algorithm. The hash-based algorithms CNSA 2.0 does list, LMS and XMSS, are stateful, and no cosignature protocol currently defines them.

Implementation Status This section is to be removed before publication as an RFC, per . There is no implementation of this version of the profile. The author's existing software implements the standalone format of the previous version , in which the name "MTAC" referred to that format, and is not a conforming implementation of this version or a reference for its requirements. A Python library for verifying that format is published under the Apache-2.0 license as aegis-verifier; its current release is 0.1.4, of 2026-10-14. The issuing and verifying tool is not publicly available at the time of writing. An MTAC deployment is expected to reuse MTC CA, log and cosigner software rather than reimplement it. The author intends to publish a reference implementation of this profile under an open source license, and welcomes independent implementations. Interoperability between at least two independent implementations, using the vectors in , is a precondition the author applies before asking for further progress of this document.

Security Considerations

Identity is not safety An MTAC certificate identifies an agent instance and records what was declared about it. An agent with a valid certificate can still be induced to misuse its access. Nothing in this document reduces that risk, and a deployment that treats an MTAC certificate as a control on behavior is relying on something this document does not provide.

Bearer presentation Without proof of possession (), presentation of an MTAC certificate is bearer presentation. Relying parties that need to know the presenter controls the certified key MUST require proof of possession explicitly.

Authenticated bytes A verifier that authenticates one encoding of a certificate but reads its claims from another, for example by hashing a re-encoding of the fields it recognizes, or by searching raw octets for a value, can be made to accept content that was never certified while the signatures still verify. requires strict DER decoding and requires every reported or acted-on value to come from the authenticated fields.

Dereferencing, free text and size The mandate and reference fields contain URIs. A relying party MUST NOT dereference them automatically, because doing so lets a certificate request cause network access from the relying party, and the resource can change after issuance. Free text fields (name, version, capacity, declared scopes) can contain characters, including bidirectional controls, that make displayed text differ from what was recorded; relying parties SHOULD display such text with controls neutralized and SHOULD NOT use it in access decisions. Because an MTC log entry has a size limit (Section 5.2.1 of ) and the log is append-only, CAs SHOULD bound the size and number of the strings and components they accept.

Sponsor claims A CA that does not establish that a requester is entitled to name a sponsor can be used to create a certificate that appears to be sponsored by a party that never agreed to it. The certificate policy of the CA is what a relying party relies on here.

Declared claims Declared scopes and components marked declared are statements by the sponsor that the CA did not check (, ). Treating them as evidence of behavior or of what executed is an error.

Configured cosigner keys A relying party's configuration names the CA cosigner key, which certifies entries, and any audit cosigner keys, which add consistency checking and dating. A verifier that takes any of these keys from the material it is verifying gains no assurance, because an adversary who supplies a substituted key can supply matching signatures. Audit relying parties need archived keys obtained by a trusted means.

Trust domain authorization A relying party that skips the trust domain check of gives every CA it accepts authority over every trust domain.

Cosigner independence An audit cosigner operated by the same party as the CA does not protect against that party. Audit relying parties SHOULD know which cosigners are independent of the CA and SHOULD require at least one that is.

Revocation and offline verification A verifier without fresh revocation information can accept a certificate that has since been revoked; see .

Key use across protocols If an agent instance uses its certified key in more than one protocol, for example TLS and COSE, the separation between those uses rests on each protocol's own domain separation. Deployments MAY issue separate certificates for separate key uses.

Key custody The value of an MTAC certificate depends on the protection of the CA cosigner, audit cosigner and agent keys. This document does not specify key protection. Deployments SHOULD protect CA and cosigner private keys in hardware security modules or equivalent.

Privacy Considerations MTC issuance logs are intended to be observable by monitors. An MTAC issuance log therefore reveals the agent identifiers, sponsors, declared scopes and configuration components of every agent instance a CA certifies, and when each changed. Deployments SHOULD consider this before including sponsor names, configuration details or data set identifiers. A sponsor named as a natural person, for example by an email address, puts personal data into an append-only log that is designed to be monitored and from which entries cannot be removed, which can conflict with rights of erasure; issuers SHOULD name organizations instead. Issuers SHOULD NOT include personal data of a third party who has not agreed to it in the capacity or mandate fields, in agent identifier paths or in register codes. The mandate URI and the references in the Agent Configuration extension can also disclose the existence and location of internal documents. A deployment can limit what it reveals by using digests rather than names in the Agent Configuration extension, by omitting optional extensions, or by operating logs that are visible only to a limited set of monitors, at the cost of reducing what those outside that set can audit. The privacy considerations of also apply.

IANA Considerations IANA is requested to make the following assignments in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1): Decimal Description References TBD1 id-pe-mtacAgentSponsor this document TBD2 id-pe-mtacDeclaredScopes this document TBD3 id-pe-mtacAgentConfiguration this document IANA is requested to make the following assignment in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0): Decimal Description References TBD0 id-mod-mtac-2026 this document This document requests no MTC log entry type or log entry extension type.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. Google LLC Apple Inc. Cloudflare Cloudflare Geomys This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to existing X.509 constructions and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. This document is not an Internet Standards Track specification; it is published for informational purposes. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. National Institute of Standards and Technology C2SP Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. Entrust Limited Bundesdruckerei GmbH UK National Cyber Security Centre AppViewX Inc Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has been defined for the use case of the WebPKI. In this document we explore when and how MTC in parts or full can be used in different use cases. Some of this use-cases may provide benefit for private PKI usage. NSA Center for Cybersecurity Standards This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance. Independent Researcher A delegation record retained as evidence must remain verifiable long after the key that signed it is retired. A signature of any algorithm establishes who signed, not when, so such a record needs anchoring in trusted time, renewed before the algorithms protecting it weaken. That is long-settled practice for archived signatures. It is rarely required for agent delegation, and where it is, the anchor is not itself required to be post-quantum. An anchor is only as good as the protection behind it, and an RFC 3161 timestamp is itself a signature: an adversary holding a cryptanalytically relevant quantum computer can mint one bearing any date it chooses. Because such a machine may be built without announcement, anchoring must become post-quantum anchoring by a stated transition date, and be applied early, so that the only assumption left about when such a machine appeared is that none existed before a record was first anchored that way. The earlier that date, the weaker the assumption, which makes choosing it a security decision and not only a scheduling one. This document states requirements that software and AI agent identity mechanisms should satisfy in order to remain sound across the transition, and identifies four that no such mechanism yet imposes on delegation credentials in general. The algorithms binding each hop of a delegation chain to its trust anchor must be visible to a verifier and retained with any record kept as evidence; where a signing key is fetched from a key set over TLS, as OAuth deployments commonly do, that binding is rarely recorded and no mechanism for agent delegation requires it to be, so in practice it is absent. Trust anchors must migrate before the credentials issued under them. Every retained record must be anchored, that anchoring must become post-quantum anchoring from a stated transition date and be maintained by renewal, and credentials of any type kept as evidence must be signed post-quantum from that same date. Delegation chains also propagate the weakest algorithm in the chain, and routinely cross organizational boundaries where no common trust anchor policy can be assumed. Huawei Huawei Sandelman Software Works This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. It also discusses mechanisms for cryptographically binding an AI agent identity to an accountable user or organization. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. This document defines a record format for AI agent authorization decisions and the effects that followed them. The format is one in- toto predicate type, signed inside a DSSE envelope. A record carries the decision and the observed effect with a derived agreement between them, whether the decision point could evaluate the request and how fresh each input it relied on was, and a canonicalization contract under which a party that trusts neither the agent nor its operator recomputes the record's consistency from its bytes. The document also defines what a party that retains a record keeps beside it, so that the record can later be dated from anchors that party does not control. The format carries the seven minimum audit fields of the WIMSE AI Identity Management System framework, and it is offered as a data model for the audit records the proposed AUDIT working group would specify. It defines no policy. Outside the Stacks Blue Cross Blue Shield of Michigan The migration of public Web PKI authentication to post-quantum mechanisms must fit enterprise certificate management and TLS termination architectures. This document examines whether an urgent need for post-quantum authentication would justify transitional support for standalone ML-DSA certificates in browser root-store policy while standalone MTC deployment capabilities mature. The scope is limited to enterprise public websites accessed by unmanaged clients using the public Web PKI. Note: a large enterprise may operate many such sites. The document describes enterprise-managed, third-party-hosted, and CDN-fronted deployments, identifies the components needed to serve standalone Merkle Tree Certificates (MTCs), and examines realistic authentication attack paths and migration priorities. It distinguishes the browser-to-edge connection from origin and internal connections, and server authentication from identity-provider login. The document draws on initial browser and TLS client testing of Trust Anchor ID signaling, and proposes interoperability tests and deployment requirements rather than changes to the MTC wire format. Relative priorities are illustrative and not empirical attack probabilities. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Independent Action State Group, Inc. This document defines the model_attestation block of the Agent Action Capsule (AAC) profile — referenced twice by the base profile but never defined there — and, within it, the compute_attestation container that already carries runtime extensions in the field: the model-serving runtime, the agent's own execution environment (architectural pattern, orchestration framework, sandbox confinement, invoked tool version), and host hardware, together with model and weights claims. Every claim carries an explicitly declared source; a verifier grades claims by how they were observed and never infers a stronger grade than the evidence supports. Hardware or platform attestation, when present, is cited by content-addressed reference to a foreign attestation record and verified with that record's own verifier. Veridic Inc. Veridic Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS, and MiFID II. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. Automated agents, such as artificial intelligence (AI) agents, act for people. This document specifies records that let anyone check, later and offline, what an agent was allowed to do and what it recorded doing: a permission a person signs with a passkey, with limits a machine can check; a receipt the agent signs for each action, with Ed25519 and the post-quantum Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87); and a log whose tree head is signed and time-stamped. A verifier says whether each action stayed within its permission, apart from whether the records are sound. The 1F916 Protocol Project Autonomous AI agents increasingly act as economic parties: they are hired, they pay, and they make claims about their own past conduct. No deployed standard lets a relying party verify an agent's identity continuity, the integrity of its claimed history, or the intactness of its persisted memory without trusting the agent's operator or platform. This document describes the Agent Record architecture: per-agent append-only event logs bound to Ed25519 keys, checkpointed with signed Merkle tree heads following the RFC 6962 construction, countersigned by independent witnesses, and exported as portable, offline-verifiable dossiers. Memory integrity is anchored by hash commitments recorded in the log, allowing an agent's future sessions, and any third party, to detect tampering with persisted state. The architecture is deployed in production at a founding registry; this document records its wire formats and security model to invite independent implementation and review, and to align terminology with the SCITT architecture, of which this system is an application- specific instance. CyberSecAI Ltd Autonomous artificial intelligence (AI) agents are increasingly performing actions on the Internet that require verifiable identity: financial transactions, regulated data access, tool invocations, and inter-agent coordination. Traditional Public Key Infrastructure (PKI) based on X.509 certificates was designed for human-operated clients and long-lived servers. It lacks primitives for graduated trust scoring, capability constraints, delegation chains, model provenance, and the ephemeral lifecycles characteristic of AI agents. This document defines Agent Public Key Infrastructure (APKI), a certificate-based identity and trust system for autonomous AI agents. APKI extends X.509v3 with five agent-specific extensions, defines the agent:// URI scheme for agent identification, specifies Agent Transparency Logs modelled on Certificate Transparency (RFC 9162), and provides mechanisms for cross-organizational trust federation. APKI is designed to be compatible with existing PKI deployments, SPIFFE workload identity, and the IETF WIMSE working group's specifications. CyberSecAI Ltd This document defines an X.509 certificate profile for identifying autonomous AI agents. It specifies a new X.509v3 extension, AgentIdentity, that encodes agent-specific metadata within a standard X.509 certificate, including agent trust level, operational capabilities, delegation constraints, owner attribution, and revocation control endpoints. The profile enables certificate authorities (CAs) to issue interoperable agent identity certificates that any relying party can parse, validate, and enforce, regardless of the issuing CA or the platform that provisioned the agent. The design builds on existing PKI infrastructure (RFC 5280), SPIFFE Verifiable Identity Documents (SPIFFE SVIDs), and the MCPS cryptographic signing layer (draft-sharif-mcps-secure-mcp). It does not require changes to X.509v3 certificate parsing or to existing CA issuance pipelines beyond supporting a new non-critical extension. OpenA2A This document defines the OpenA2A Agent Identity Protocol (OpenA2A AIP), an open standard for creating, managing, and verifying cryptographic identities for AI agents. As AI agents proliferate across browsers, cloud platforms, and enterprise environments, systems need a standardized answer to the question of which agent is present, what it is permitted to do, and whether it should be trusted. OpenA2A AIP is distinguished by five elements that it places at the center of the design: a multi-factor behavioral trust score that is computed from independently verifiable signals; a portable signed credential, the Agent Trust eXtension, carrying a hybrid Ed25519 and ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log for identity and credential issuance; agent identifiers expressed as W3C Decentralized Identifiers, provider-scoped as a did:web profile at the identity- provider layer and ecosystem-scoped under the registered did:opena2a method at the trust-fabric layer; and a structured capability vocabulary with reserved namespaces. On top of these, the protocol specifies challenge-response verification, behavioral governance policies, a lifecycle model, and an append-only audit log. The qualifier "OpenA2A AIP" is used throughout this document because the abbreviation "AIP" is shared by other Internet-Drafts. OpenA2A AIP is framed as complementary to agent communication protocols such as A2A and the Model Context Protocol, and to identity and credential standards such as OpenID Connect, WebAuthn, and the W3C Verifiable Credentials Data Model. Violet Sky Security SEZC Current authorization is role-scoped: an actor is granted a role whose authority persists across every action it takes. This fails exactly when actors fail -- under compromise, prompt injection, or goal hijacking -- because a compromised actor retains full role authority. This document specifies SPT-Txn, a family of transaction- bound authorization tokens in which authority exists only inside a short-lived token bound to one declared action, on one resource, under one jurisdictional policy, verified against how the requesting workload was attested. Delegation across agents and tools is expressed as a cryptographically sealed chain that can only narrow authority and is verifiable offline. Each authorization decision emits a signed, tamper-evident receipt as a byproduct of enforcement. This document specifies normative intent binding, transaction receipts and their transparency log, attested issuance via OAuth 2.0 Token Exchange, per-token status-list revocation, and cryptographic algorithm agility including hybrid post-quantum signing. It also hardens attested issuance in response to an adversarial security review of the reference implementation: it makes an audience and a verifiable expiry mandatory on the presented attestation, requires the issuer to bound the delegated depth it grants, and clamps a token's lifetime to the attestation it was minted on. The issuer- side requested-versus-permitted scope intersection is retained; the enforcement point re-checks the chain independently. J.P. Morgan Chase & Co. Sandelman Software Works Fraunhofer SIT There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. There are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document describes an architecture by which Remote Attestation is utilized for providing Attesters with Identity Documents (keys or credentials) to authenticate to RUPs. This architecture is intended to work with common credential acquisition protocols and mechanisms such as EST, SPIFFE/SPIRE, ACMEv2, and many others. Another important but separate goal is to encapsulate the Attester- side complexity of Remote Attestation and credential acquisition similar to how Envoy does it. This allows Attesters to be implemented in a way that abstracts away the details of credential acquisition: both the protocols used and the Credential Acquisition Mechanisms employed, whether minting new (Enrollment), or requesting existing (Retrieval) credentials. Likewise, the choice between RATS Passport and Background Check models is made opaque to the Attester, further simplifying its development. Somos, Inc. Somos, Inc. TransNexus Twilio This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI ecosystem to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR ecosystem, focusing on verifiable control over telephone number or service provider code resources.

ASN.1 Module This module uses the ASN.1 conventions and imports the modules of .

Examples This appendix is informative. Each example gives an extension value, in ASN.1 value notation, and its DER encoding in hexadecimal. The encodings were produced from the module in and checked with a second, independent DER parser. The object identifiers for the extensions themselves are not yet assigned, so only the extension values (the contents of extnValue) are shown.

Agent Sponsor

Declared Scopes

Agent Configuration Each component carries a SHA-256 digest. For reproducibility, the digests in this example are computed over short ASCII strings standing in for real inputs: "example-model weights v1" (24 octets) for the model and "example-runtime 2.4.1 evidence" (30 octets) for the runtime. A real deployment would digest the component, or the evidence, in a form its deployment profile defines. The runtime component is marked attested; its reference locates the attestation evidence the CA appraised, and its digest covers that evidence, so a relying party can check that what it retrieves is what the CA appraised.

Test Vector This appendix is informative. It gives a complete log entry for a synthetic agent, the hash of that entry, and a worked inclusion proof in a four-entry log, so that an implementer can check an encoder, a decoder and a Merkle tree implementation against known values. Nothing in it is signed. The values were produced by a script written from this document and , cross-checked with an independent DER parser and independent SHA-256 implementations, and by a separately written implementation of the subtree inclusion proof evaluation of Section 4.3.2 of that document. The three extension object identifiers are placeholders in the documentation arc 1.3.6.1.4.1.32473.2.1, .2 and .3 (sponsor, declared scopes, agent configuration), standing in for the values IANA assigns. The CA ID is the trust anchor ID 32473.1, so the issuer name is a single relative distinguished name of type id-rdna-trustAnchorID with value 0d0481fd5901.

The agent Field Value agent identifier wimse://x-road.example/EX/BUSINESS/00000000/reporting-agent (the path structure is illustrative; this document defines none) subject empty; subjectAltName critical subject key ML-DSA-65; the 1952 octets of the public key are 0, 1, 2, ..., 255, 0, 1, ... (octet i is i mod 256) validity 2026-10-19 00:00:00 UTC to 2026-10-26 00:00:00 UTC sponsor the value of the Agent Sponsor example in declared scopes repository:read, ci:run configuration one component, role model, name example-model, version 2026-09, digest SHA-256 of the ASCII string "example-model weights v1", source declared The SHA-256 hash of the DER encoding of the SubjectPublicKeyInfo (1974 octets) is:

The TBSCertificateLogEntry The DER encoding (463 octets) is:

The log entry and its hash The MTCLogEntry (Section 5.2.1 of ) has an empty extensions vector, encoded as the two octets 0000, then the type tbs_cert_entry, encoded as the two octets 0001, then tbs_cert_entry_data, which is the TBSCertificateLogEntry above without its outer SEQUENCE tag and length octets (the 459 content octets). Its length is 463 octets and it begins 00000001a003020102. The entry hash is the SHA-256 hash of the octet 0x00 followed by the entry:

A four-entry log The agent entry is at index 2 of a log whose other entries are of type null_entry or carry only entry extensions. Their entries and entry hashes are:

The hash of the subtree [0, 4), computed with the tree construction of Section 2.1.1 of as Section 4.1 of specifies, is:

The subtree inclusion proof for the agent entry (index 2) in [0, 4) consists of the hash of entry 3, then the hash of the node over entries 0 and 1:

Concatenated, as they appear in MTCProof.inclusion_proof, they form 64 octets.

Certificate serial number and the signed message If the log has log number 1, the serial number of the certificate for the agent entry is (1 << 48) | 2 = 281474976710658 (0x1000000000002), DER 020701000000000002. A cosigner with cosigner ID 32473.3 signing this subtree for the issuance log with ID 32473.1.0.1 signs the following CosignedSubtree (Section 5.3.1 of ), 120 octets, with timestamp zero, start 0 and end 4:

Mapping from the Previous Version This appendix is informative. It maps each element of the standalone format in to its counterpart in this profile. Previous version This version schema_version X.509 version v3 agent_id the URI subjectAltName, constrained to a workload identifier () sponsor_id Agent Sponsor extension () authorized_scopes (capability tokens) Declared Scopes extension (), renamed so it does not read as authorization authorized_scopes holder token aegis:holder:<jkt> removed; the holder key is the subjectPublicKeyInfo, whose hash MTC already logs not_before, not_after validity, with audit semantics in CBOR leaf and leaf hash ( tree) TBSCertificateLogEntry and MTC entry hash (same tree construction) AEGIS-STH-v1 signed tree head CA cosigner subtree signature (MTC Sections 5.3.1 and 5.4) inclusion proof array(3) MTCProof subtree inclusion proof AEGIS-WITNESS-v1 witness note audit cosigner subtree signature () AEGIS-HWM-v1 high-water mark audit cosigner timestamped checkpoint AEGIS-HOLDER-v1 challenge-response any possession protocol meeting public ledger corroboration optional audit cosigner publication batch-scoped revocation (roadmap) MTC revoked ranges (MTC Section 7.5) no model or configuration information Agent Configuration extension ()

Related Work This appendix is informative. Merkle Tree Certificates provide the mechanism this document profiles. discusses MTC outside the web PKI, and is an example of a non-web X.509 identity ecosystem adopting transparency as a profile rather than a new mechanism. is the IETF working group document on AI agent identity management. This profile is intended to fit its credential layer (). states post-quantum requirements that addresses. describes the components an enterprise needs to serve standalone Merkle Tree Certificates, which are the form this profile requires. also profiles X.509 for AI agent identity, with a non-critical extension carrying capabilities, a trust level, delegation constraints, an owner organization and a kill switch endpoint, and a SPIFFE URI subject alternative name. The differences are that this profile uses Merkle Tree Certificate issuance and logging, defines an audit cosigner role and an audit verification procedure, grades configuration claims by source, and gives its fields no authorization or enforcement meaning, where that profile's capabilities and kill switch are intended to be enforced by relying parties. Its owner organization corresponds to the Agent Sponsor extension here. Other individual drafts define agent credentials with their own formats: defines an X.509 agent PKI with Certificate Transparency style logging of each certificate, defines hybrid classical and ML-DSA agent credentials with per-event logging, and defines witness-countersigned per-agent event logs. This profile differs from these in reusing MTC rather than defining a format. Individual drafts also define records of agent actions or authorizations: , , , and . describes an architecture for auditing agent delegation and interactions. These address what an agent did or was permitted to do. This profile addresses only which agent it was, and describes how the two connect. defines a vocabulary for the model, runtime and decoding settings behind an agent action, with each claim graded by source. The Agent Configuration extension adopts the grading idea and defers to such vocabularies for detail.

Changes from draft-burls-mtac-00 This section is to be removed before publication. Restructured as a profile of . Removed the standalone leaf, signed tree head, inclusion proof, witness note, high-water mark and holder commitment formats, and their test vectors. Removed the claim that batch issuance distinguishes this work. Named the AI agent by a workload identifier in a URI subjectAltName, so that an MTAC certificate is also a WIMSE Workload Identity Certificate. Replaced sponsor_id and authorized_scopes with the Agent Sponsor and Declared Scopes extensions. Added the Agent Configuration extension with source grading and configuration epochs. Replaced the witness with an audit cosigner role under MTC Section 5.3, requiring post-quantum signatures and recommending a different signature family from the CA. Added the audit verification procedure, with separate, machine-readable results, an explicit statement that an expired certificate still shows issuance but not current validity, and offline revocation policy. Replaced the bespoke possession mechanism with requirements on any possession protocol. Added relationships to WIMSE workload credentials and to transparency-service records of agent actions, including a binding through x5chain. Removed the statement that the previous inclusion proof could be carried as a COSE Receipt proof, which was wrong for single-entry trees. Added a section relating the profile to PQ-R1 to PQ-R7 of and stated non-conformance to CNSA 2.0. Made the Agent Sponsor extension mandatory and added optional capacity and mandate-reference fields, stated that an agent is not a legal person, required the CA to establish that the requester may name the sponsor, and added a Revocation and Suspension section and an informative section on publication of issuer information. Required strict DER decoding of the profile's extensions, and required that every value a relying party reports or acts on come from the authenticated TBSCertificate fields. Required CAs to bind trust domains and relying parties to check that binding, and required at least one audit cosignature in every certificate. Added a test vector (). Removed the description of the author's software from Implementation Status except for what a reader needs to avoid confusion with the previous format. Updated the implementation status, related work and references, including the closest prior X.509 agent profile. Replaced the reference to draft-klrc-aiagent-auth with its successor . RFC 9162 is no longer cited as a normative reference.

Acknowledgments This profile builds on the work of the authors of Merkle Tree Certificates and of the IETF working groups for platform-independent transparency of certificates and for workload identity. A question on the PLANTS mailing list about why agent identity could not use X.509 and Merkle Tree Certificates directly prompted this revision.