]> Aelethion OU

rgburls@gmail.com

Security Network Working Group AI agent transparency log post-quantum ML-DSA Merkle tree agent identity This document specifies Merkle Tree Agent Certificates (MTAC), a credential format and issuance profile in which a certificate authority commits a batch of AI agent identity credentials to a Merkle tree, signs only the tree head with the post-quantum signature algorithm ML-DSA-65, and distributes a per-credential inclusion proof. A relying party verifies a credential offline against the signed tree head without contacting the issuer. Each batch root is additionally co-signed by an independently keyed witness, providing per-batch integrity and continuity attestation, and its root can be corroborated against an independent public record. MTAC defines the leaf structure, its deterministic encoding, the leaf hash preimage, the signed tree head wire format, the witness co-signature, and an optional challenge-response proof of possession that binds a credential to a holder key. Test vectors are provided. This document specifies a credential issuance and verification mechanism. Declared scopes carried in a credential are self-reported parameters recorded at issuance; this document does not specify a runtime authorization mechanism.

Introduction Autonomous AI agents increasingly act across organizational boundaries. A relying party receiving a request from such an agent needs to determine what credential that agent was issued, by which authority, under what declared parameters, and whether that credential is present in a tamper-evident log that can be independently checked. Existing credential formats address parts of this problem, but issuing an individual signed certificate per agent scales poorly when agent populations are large and credential lifetimes are short, and post-quantum signatures are substantially larger than the classical signatures they replace. Merkle Tree Agent Certificates (MTAC) addresses this by making the batch, rather than the individual credential, the unit of issuance. A certificate authority collects agent identity assertions over a batch window, constructs a Merkle tree over the resulting leaves, and produces a single ML-DSA-65 signature over the tree head. Each agent receives an inclusion proof of size logarithmic in the batch size. One signing operation covers the whole batch, and verification is a local hash computation against a signed tree head that the verifier already holds.

Position of this work As of 21 July 2026, no third-party public document, specification, or shipped system specifies Merkle batch issuance as the unit of credential issuance for AI agent identity under post-quantum (ML-DSA-65) signed tree heads, with each batch root independently co-signed by a distinct witness key and publicly corroborated. Adjacent work occupies other compositions. MAGIQ (arXiv:2605.06933) performs post-quantum batch authorization over a private, unlogged aggregation and states that it provides no revocation. The GoDaddy Agent Name Service operates a production, publicly queryable log labelled RFC9162_SHA256 recording per-entry agent registrations under classical signatures. draft-coetzee-oauth-spt-txn-tokens co-signs Merkle tree heads with an external witness over post-hoc authorization receipts rather than over credential issuance. draft-fane-opena2a-aip and draft-sharif-apki-agent-pki perform per-event Certificate Transparency style logging of agent credentials. specifies post-quantum Merkle batch issuance for non-agent subjects, and its working group is chartered for WebPKI and TLS. The closest artifact is a shipped implementation rather than a specification. CIRISVerify requires hybrid Ed25519 and ML-DSA-65 signed tree heads over an RFC 6962 log for AI agents, and additionally defines N-of-M co-signature of those tree heads by independently keyed witnesses. It holds every element named above except one: its log records licence verification events, and its licences are signed individually rather than committed as a batch. The distinguishing property of this specification is therefore the issuance unit, not the witness arrangement and not the use of post-quantum signatures, both of which are present in prior work. See . This document does not claim novelty in Merkle tree construction, in inclusion proofs, in post-quantum signatures, or in carrying an inclusion proof alongside a credential. Each of those is established practice, and identifies where.

What this document does not specify The distinction matters for correct implementation, so it is stated here rather than only in . Declared scopes in an MTAC leaf are self-reported parameters recorded at issuance. This document specifies how they are encoded, committed, and verified as having been issued. It does not specify a runtime authorization mechanism, and a relying party MUST NOT treat the presence of a scope token as evidence that the agent operated within it. Verification establishes that a credential was validly issued by the named authority and is present in the log at the given tree head. It does not establish what the agent subsequently did.

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.

Batch:

The set of agent identity assertions committed to a single Merkle tree by one certificate authority during one batch window.

Leaf:

The canonical encoding of a single agent identity assertion, as defined in .

Leaf hash:

The 32-octet SHA-256 value computed over the preimage defined in .

Signed Tree Head (STH):

The structure defined in , binding a log identifier, a tree size, a timestamp, and a Merkle root, signed with ML-DSA-65.

Witness:

An entity holding a signing key distinct from the certificate authority key, which co-signs batch roots as described in .

Holder commitment:

A thumbprint of a public key, carried as a scope token in a leaf, committing the credential to a key whose possession can later be demonstrated ().

Declared scope:

A self-reported parameter recorded in a leaf at issuance. The term "declared" is load-bearing throughout this document.

Architecture Overview A certificate authority (CA) operates a log. The log has a log_id, defined in as the SHA-256 of the CA's raw ML-DSA-65 public key. During a batch window the CA collects agent identity assertions. At the close of the window it encodes each assertion as a leaf (), computes each leaf hash (), constructs a Merkle tree following the structure of Section 2.1, and signs the resulting tree head (). A witness independently co-signs the batch root (). Each agent receives its leaf, its inclusion proof, and the signed tree head. A relying party verifies by recomputing the leaf hash from the leaf bytes, folding the inclusion proof to a root, comparing that root against the signed tree head, and verifying the ML-DSA-65 signature over the tree head. All four steps are local computation. No network interaction with the CA is required at verification time.

MtacLeaf

Structure An MtacLeaf contains exactly six fields. All six are mandatory. There are no optional fields in schema version 1.

Field	CBOR type	Description
schema_version	unsigned integer	MUST be 1
agent_id	text string	Identifier of the agent
sponsor_id	text string	Identifier of the sponsoring entity
authorized_scopes	array of text string	Declared scopes; see
not_before	unsigned integer	Start of the validity window, seconds since the Unix epoch
not_after	unsigned integer	End of the validity window, seconds since the Unix epoch

schema_version is an ordinary map entry. It is not a CBOR tag and not an envelope. A decoder that encounters schema_version other than 1 MUST reject the leaf. Implementations MUST NOT assume that not_before is less than or equal to not_after. The encoding layer is value-agnostic, and coherence of the validity window is a policy check performed above this layer. A verifier that requires a coherent window MUST check it explicitly.

Canonical encoding A leaf is encoded as a CBOR map using the deterministic encoding rules of Section 4.2.1 (CDER), with the additional constraints in this section. The rules below are normative and are restated here rather than incorporated by reference, because two of them are commonly implemented incorrectly and both change the leaf hash.

1. Map key ordering is bytewise over the ENCODED key. Keys MUST be sorted by comparing their complete CBOR encodings as octet strings, which includes the initial length head. This is not string-lexicographic ordering of the key text. See .
2. Integers MUST use the shortest form. An encoder MUST NOT emit a value in a wider representation than necessary. A decoder MUST reject non-shortest-form integers.
3. Text strings MUST be in Unicode Normalization Form C (NFC), and normalization is applied before the length head is computed. An encoder that emits non-NFC UTF-8 produces a different leaf hash for a semantically equal leaf. A decoder MUST reject text that is not in NFC.
4. Duplicate map keys MUST be rejected by decoders.
5. Array element order is preserved and is significant. Only map keys are reordered by the canonical form. Two leaves whose authorized_scopes contain the same elements in a different order are different leaves with different leaf hashes. Implementations MUST NOT sort authorized_scopes as a normalization step.

A decoder that accepts any of the forms this section requires to be rejected introduces malleability: two distinct octet strings would decode to the same leaf, while hashing to different leaf hashes.

Map key ordering, worked The six schema version 1 keys, with their encoded first octet:

Key	Length	First encoded octet
agent_id	8	0x68
not_after	9	0x69
not_before	10	0x6a
sponsor_id	10	0x6a
schema_version	14	0x6e
authorized_scopes	17	0x71

Because the length head is the first octet compared, shorter keys sort first. The correct order is therefore: Sorting the same six keys as text strings yields a different order: An implementation that produces the second order produces a different octet string and therefore a different leaf hash. This is the single most likely source of interoperability failure in this specification.

Declared scopes authorized_scopes is an array of text strings. Two token classes are defined. A capability scope token describes an operation class the agent declares it may perform. Capability scope tokens are self-reported by the requesting entity and recorded by the CA. They are declared parameters. This document specifies no vocabulary for them and no mechanism by which they constrain agent behaviour. A holder commitment token has the form aegis:holder:<jkt>, where <jkt> is the 43-character thumbprint defined in . A holder commitment token is a key commitment. It grants nothing and gates nothing by itself. It is not a permission and not an access grant. Its only function is to identify the key whose possession may be demonstrated under . A relying party MUST NOT interpret either token class as evidence about agent behaviour.

Leaf hash The leaf hash is SHA-256 over a preimage of exactly four concatenated segments:

Offset	Length	Contents
0	1	0x00, the Section 2.1.1 leaf type octet
1	16	DOMAIN_LABEL, defined below
17	32	CA public key fingerprint, defined below
49	L	The canonical leaf encoding from

The total preimage length is 49 + L octets. DOMAIN_LABEL is the following 16 octets: The CA public key fingerprint is the SHA-256 of the raw 1952-octet ML-DSA-65 public key as defined by Section 5.3. The public key MUST NOT be wrapped in any ASN.1, DER, or other structure before hashing. Implementations that wrap the key before hashing will compute a different fingerprint, a different leaf hash, and will fail to interoperate. The same 32-octet value is used as the log_id in . One value therefore binds a leaf to its issuer and identifies the log in the signed tree head. No length prefix and no separator appears before the trailing leaf encoding. The construction is unambiguous because the three preceding segments are of fixed width, so the boundary between the fingerprint and the leaf encoding is determined by position alone. Implementations MUST NOT insert a length prefix. Leaf index and batch epoch are deliberately absent from the preimage. Position in the tree is bound by the inclusion proof and the verification algorithm that consumes leaf_index, following Section 2.1.3.2.

Test vector The following vector is fully reproducible. The CA public key is synthetic and defined by a rule rather than supplied as a blob, so no key file is required. Leaf field values: Canonical leaf encoding, L = 138 octets: CA public key: 1952 octets where octet i has value (i mod 256), for i from 0 to 1951. Its SHA-256 fingerprint is: Preimage length: 1 + 16 + 32 + 138 = 187 octets. Resulting leaf hash: An implementation that reproduces this value has correctly implemented and this section, including the map key ordering of .

Signed Tree Head

Wire format The signed tree head is a CBOR array of two elements: The envelope and the body are emitted in definite-length shortest form. The octet string in position 1 is the signed message: the signature is computed over exactly those octets as received. A verifier MUST verify over the received octets and MUST NOT re-encode the body before verifying, because any re-encoding that differs by a single octet produces a different message and a failed verification. log_id is the SHA-256 of the raw ML-DSA-65 CA public key, the same value used as the fingerprint in . timestamp is milliseconds since the Unix epoch. sth_extensions is an array, empty in this version. This document defines no extension semantics; the field exists so that the signed body has a place for future extension, and it is covered by the signature. Implementations MUST accept an empty array and MUST NOT assume the field is absent. The wire order is tree_size before timestamp. Implementations MUST emit and parse the body in the order given above. Any ordering derived from a struct declaration, a serialization library's field order, or alphabetical sorting is incorrect.

Signature and domain separation The signature is ML-DSA-65 over the signed message, using the FIPS 204 Section 5.2 context parameter with the value: Domain separation is therefore dual layer: the context string appears both as the tag in position 0 of the envelope, which is inside the hashed message, and as the FIPS 204 context, which is not. A verifier MUST supply the context string. Verifying with an empty context will reject valid signatures. The signature is 3309 octets. The CA public key is 1952 octets. Both lengths are as specified in for ML-DSA-65 and are cross-referenced in .

Relationship to ML-DSA in JOSE and COSE MTAC signatures are raw signatures. They are not JOSE or COSE signatures, and this document does not define a COSE or JOSE serialization. This distinction is stated explicitly because Section 5 requires that "the ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65, and ML-DSA-87" when ML-DSA is used in JOSE or COSE, whereas every MTAC signature uses a non-empty FIPS 204 context. There is no conflict: that requirement governs the JOSE and COSE serializations defines, and MTAC uses neither. is cited normatively by this document for two things only: the AKP key type and the ML-DSA-65 algorithm name used in the holder thumbprint of , and the confirmation of key and signature lengths. It is not cited as the serialization for any MTAC signature. An implementation that wishes to carry MTAC evidence inside COSE, for example as a COSE Receipt, cannot reuse an MTAC signature directly: a COSE object asserting ML-DSA-65 must have been produced with an empty context, so it would be a second, separate signature over a different input. That is a known consequence of the design and is discussed further in .

Inclusion proof An inclusion proof is a CBOR array of three elements, emitted in definite-length shortest form: Note the element order: tree_size precedes leaf_index. The two elements are both unsigned integers, so a decoder cannot detect a transposition by type, and an implementation that reverses them will verify single-leaf trees successfully while failing on every larger tree. This order is deliberately the same as the inclusion proof of Section 5.2, so that an MTAC proof can be carried as a COSE Receipt proof without reordering. See . path contains the sibling hashes from the leaf to the root, in leaf-to-root order. Interior nodes are hashed with the 0x01 prefix, per Section 2.1.1, so that no interior node hash can collide with a leaf hash, which uses the 0x00 prefix given in . For a tree of size 1 the path is empty and the leaf hash equals the root hash. A single-leaf proof therefore encodes as the four octets 83 01 00 80, which is array(3) followed by tree_size 1, leaf_index 0, and an empty path. Verification folds the path using the bits of leaf_index, following Section 2.1.3.

Witness co-signature

Purpose and limits A witness holds a signing key distinct from the CA key and co-signs batch roots. The witness provides per-batch, independent-key co-signed integrity and continuity attestation. It protects a relying party that checks it against a compromise limited to the CA key, and against dropped or truncated batches. The witness described here does NOT provide non-equivocation. Achieving that property would require an independently operated third-party witness and a route by which entries can be enumerated, neither of which this document specifies. Implementers and reviewers comparing this mechanism against the receipts of , which does address that property, should note the difference. The witness check is additive: it does not replace the primary verification result defined in .

Co-signature format The witness signs a five-line note. The note is deliberately human-readable rather than CBOR, so that an auditor can inspect a co-signature artifact by eye. The signed octets are exactly, with no trailing octet after the final newline: \n size:\n root_hash:\n timestamp:\n ]]> Byte-exact reconstruction is required to verify the signature, so each field is specified precisely:

origin

A textual log identifier, assigned by the operator and carried in the log's metadata. It is not cryptographically bound to log_id in this version, and a verifier MUST NOT treat it as an authenticated identifier. It is present so that a human auditor can tell two logs apart in a co-signature artifact. Binding it is a candidate for a future revision.

size

The tree_size of the signed tree head being co-signed, rendered as decimal ASCII with no leading zeros and no separators.

root_hash_hex

The root_hash of that signed tree head, rendered as exactly 64 lowercase hexadecimal characters.

timestamp

The timestamp field of the signed tree head being co-signed, rendered as decimal ASCII with no leading zeros. It is the log's timestamp, not the witness's own signing time, so a verifier reproduces it from the tree head rather than from any clock.

The signature algorithm is ML-DSA-65 with the FIPS 204 context: This context MUST differ from the CA context of . A verifier MUST NOT accept a witness co-signature as a CA tree head signature or the reverse. The batch identifier is NOT part of the signed note. A verifier locates a co-signature by root_hash, not by batch identifier.

Witness trust root The witness public key is a trust root. A verifier MUST obtain it out of band, from a list of trusted witnesses it maintains, and MUST NOT take it from the co-signature artifact itself. An artifact-supplied key verifies its own contents and provides nothing: the artifact is controlled by the same party that produced it, so accepting an inline key reduces the check to self-attestation. A verifier that encounters a co-signature whose public key is not in its trusted list MUST treat the co-signature as untrusted rather than as absent, because the two conditions have different causes and a deployment may wish to distinguish them.

High-water mark To detect truncation of the batch sequence, a witness maintains a signed high-water mark. The signed payload is 21 octets: The FIPS 204 context for the high-water mark signature is: This context MUST differ from the contexts of and . Note that the context string and the payload prefix are not the same octets: the payload prefix carries a trailing colon and the context string does not. An implementation that reuses one for the other will produce signatures no conforming verifier accepts. A verifier that observes a latest batch number lower than a previously observed signed high-water mark MUST treat the sequence as truncated.

Holder proof of possession This mechanism is OPTIONAL. A credential carrying no holder commitment is a bearer credential, and verification behaviour is unchanged.

Thumbprint computation The holder commitment is the base64url encoding, without padding Section 5, of the SHA-256 of a canonical JSON object with exactly three members, in this order: "} ]]> There is no whitespace. The member order is lexicographic by member name, as required by the Section 3 process. The kty value AKP and the algorithm name ML-DSA-65 are as registered in Section 3. The pub member carries the raw Section 5.3 public key encoding. The resulting thumbprint is 43 characters. This document specifies SHA-256 as the thumbprint hash. Neither nor mandates a particular hash for this computation: Section 3.4 leaves the choice to the application. Implementations MUST use SHA-256 for MTAC holder commitments. The COSE integer values registered in for the key type and algorithm are not used in this computation. The JSON member values are the strings above.

Test vector Using the same synthetic key rule as , namely 1952 octets where octet i has value (i mod 256), the canonical JSON object begins: and the resulting thumbprint is: One synthetic key therefore serves both test vectors in this document.

Committed form The commitment is carried as a single scope token in authorized_scopes: ]]> The token is 56 characters. No field is added to the leaf. The leaf structure of is unchanged, and a verifier that does not implement this section parses the leaf normally and treats the token as an opaque scope string.

Challenge and response A verifier generates a challenge and transmits it to the presenting party. The presenting party signs a payload constructed as a CBOR array of two elements, encoded in definite-length shortest form: The session identifier is the value of the leaf's agent_id field. It is taken from the verified leaf, not from any value the presenting party supplies. The signature uses ML-DSA-65 with the FIPS 204 context: This gives three-way domain separation across the tree head, witness, and holder contexts. Payload test vector, for a 16-octet challenge of 00 01 02 ... 0f and session identifier urn:aegis:session:golden:

Verifier requirements A verifier performing a possession check MUST:

1. Reconstruct the signed payload from the challenge IT generated and the session identifier committed in the credential. It MUST NOT use values supplied by the presenting party for either.
2. Verify the signature BEFORE comparing the thumbprint. The check order is signature first, then thumbprint.
3. Recompute the thumbprint from the presented public key per and compare it against the committed token.

A challenge MUST be at least 16 octets. Challenge uniqueness is an operational obligation of the verifier. This specification defines no challenge generator, no nonce store, no replay ledger, and no challenge expiry. A verifier that reuses a challenge, or that accepts a challenge it did not itself generate, obtains no possession guarantee. See . A successful possession check demonstrates that the presenting party holds the private key committed at issuance, at the time of presentation. It does not establish that the presenting party is the agent named in the credential, and it does not establish independent actor status. Where a single operator holds both the CA key and the holder key, key custody is deployment-dependent.

Verification

Primary verification A relying party verifying a credential MUST perform all of the following:

1. Decode the leaf, rejecting any non-canonical form per .
2. Recompute the leaf hash per .
3. Fold the inclusion proof to a candidate root.
4. Compare the candidate root against root_hash in the signed tree head.
5. Verify the ML-DSA-65 signature over the signed tree head with the context of , using a CA public key obtained out of band.

The result of primary verification is that the credential was validly issued by the authority identified by log_id and is present in the log at the given tree head. This is the complete meaning of a successful result. It carries no implication about the agent's subsequent behaviour. The CA public key is a trust root. It MUST be obtained out of band and pinned. A verifier that accepts a CA public key supplied alongside the credential obtains no security property, because a substituted key accompanied by a re-signed tree head verifies successfully.

Freshness and replay A verifier MAY additionally require freshness by rejecting a tree head older than a configured maximum age, and MAY reject a tree head whose timestamp is not strictly greater than the last one observed for the same log_id. Both are implemented in the reference verifier described in .

Additive checks The witness check of and the possession check of are additive. Where a relying party demands one and it fails, that is a distinct outcome from primary verification failure, and implementations SHOULD signal the two distinctly.

Public corroboration An MTAC log operator MAY publish batch roots to an independent public medium so that a relying party can confirm that a root matches what the log committed, without trusting the log operator. Where such corroboration is published on a public ledger, the published value corroborates the signed tree head Merkle root only. It does not establish anything about agent behaviour, and the availability properties of the publishing medium are outside the scope of this document.

Roadmap and extensions This section is INFORMATIVE and describes work that is NOT implemented and NOT specified by this document. It is included to indicate direction. Nothing in this section may be relied upon by an implementer.

Batch-scoped revocation Because a batch has a bounded window, omitting an assertion from the next batch causes the credential to lapse at the end of the current window without a revocation list or an online status protocol. This document does not specify a revocation mechanism, and no revocation mechanism is implemented.

Third-party witnessing and enumeration An independently operated witness, together with a route by which log entries can be enumerated, would permit a stronger property than the one described in . Neither is specified here.

Relationship to existing work This section is INFORMATIVE.

Merkle Tree Certificates specifies batch Merkle issuance with post-quantum signed tree heads. It is the direct architectural antecedent of the issuance model used here. Its working group is chartered for WebPKI and TLS, its leaf encodes TLS certificate fields, and it contains no AI agent identity content. MTAC applies the same issuance shape to a different subject with a different leaf.

SCITT defines an architecture for transparency over supply chain statements, and defines receipts proving properties of a verifiable data structure. An MTAC signed tree head and inclusion proof are structurally analogous to a receipt over a Merkle verifiable data structure. defines reference APIs. A profile mapping MTAC batches onto SCITT statements and receipts is plausible future work and is not specified here.

Certificate Transparency The Merkle tree construction and the leaf type octet follow Section 2.1.1. Note that both and its predecessor are Experimental. This document cites because it is the later specification and defines the constructions used here; several adjacent agent-identity documents cite instead, and implementers comparing them should be aware that the two differ.

Other agent identity work The following documents address adjacent problems and several of them combine two or three of the same elements MTAC uses. Each is named and distinguished, because a reader who finds them independently is entitled to know why this document is not redundant with them. Revision numbers and dates are as of 21 July 2026. Documents that combine post-quantum signatures, a Merkle transparency structure, and AI agent identity, in some arrangement:

• draft-fane-opena2a-aip-00 specifies hybrid Ed25519 and ML-DSA-65 agent credentials with an RFC 6962 style transparency log covering identity and credential issuance events. The logging is per event rather than per batch, and the batch is not the unit of issuance.
• draft-sharif-apki-agent-pki-00 defines agent transparency logs as append only Merkle trees over agent certificate issuance, permits ML-DSA-65, and requires migration to post-quantum algorithms. It places one certificate per leaf, so issuance remains per certificate in the classical Certificate Transparency shape.
• draft-ailex-vap-legal-ai-provenance-03 requires that events be batched into a binary Merkle hash tree following , and names ML-DSA-65. It is the closest work found on the batching mechanism itself. What is batched is audit events rather than identity credentials.
• draft-marques-asqav-compliance-receipts-07 signs a root over a batch of receipts rather than signing each receipt, with ML-DSA-65 and Merkle inclusion proofs. The subject is compliance receipts for actions already taken, not credentials issued in advance.
• draft-coetzee-oauth-spt-txn-tokens-03 requires both a classical and an ML-DSA signature, and periodically signs Merkle tree heads over an append only log with an external witness co-signature. That witness arrangement is the closest work found to . Its log covers post hoc authorization decision receipts.
• draft-ihsanullah-dnsid-01 provides DNS anchored durable identity for AI agents with records published to a Certificate Transparency style log. Post-quantum support is algorithm agility rather than a requirement, and batches are an optional registration convenience rather than the issuance unit.
• draft-rotzin-spice-afir-profile-00 uses ML-DSA-65 as its primary algorithm and composes with a Merkle inference chain. Its subject is inference provenance rather than an identity credential.

Documents that combine a Merkle transparency structure with agent identity, without post-quantum signatures:

• draft-hood-agtp-log-02 specifies a transparency log protocol aligned with and issues receipts per . It is a log protocol rather than a credential format, and it does not address post-quantum signatures.
• draft-narajala-courtney-ansv2-01 establishes how an agent is named, discovered and anchored to a domain. MTAC defines no namespace and can carry any identifier in agent_id, so the two compose directly.

Documents addressing request-time and after-the-fact concerns:

• draft-klrc-aiagent-auth-03 addresses how an agent authenticates and is authorized at request time. MTAC addresses what credential was issued. The issuance-time boundary between the two is stated in .
• draft-bu-agentproto-security-principal-binding-03 binds a security principal to an agent communication protocol. MTAC does not define a communication protocol.
• draft-noa-scitt-ai-agent-receipt-00 profiles receipts for agent actions after they occur. A receipt layer composes with an issuance layer.
• draft-dawkins-scitt-ai-article50-00 maps transparency artifacts to the EU AI Act Article 50 obligation. An MTAC credential provides evidence relevant to a provider's or deployer's Article 50(1) documentation. It does not substitute for the content-level machine-readable marking required by Article 50(2), and compliance is a legal status assessed by a competent authority.

Beyond Internet-Drafts, at least one published implementation goes further than any of the drafts above and deserves to be described accurately. CIRISVerify (CIRISAI, AGPL-3.0) signs tree heads over an RFC 6962 log for AI agents with hybrid Ed25519 and ML-DSA-65 signatures, and requires both rather than permitting the post-quantum one as an option. It also defines N-of-M co-signature of its tree heads by independently keyed witnesses, for split-view detection. That is the same defensive shape as , arrived at independently, and this document does not claim the witness arrangement as novel. What differs is the unit. CIRISVerify's log records licence verification events, and its licences are signed individually rather than committed as a batch. Identity is rooted in a hardware key ceremony. The batch is not the thing issued. This document therefore does not claim that any individual element, or any pair of them, is unaddressed, and it does not claim the witness co-signature as its own idea. The arrangement it specifies, in which the batch is the unit of credential issuance, is what the preceding list does not contain. Every other property described here is present somewhere in the work above.

Implementation Status This section is to be removed before publication as an RFC, per .

Reference verifier An independent verifier implementation is published and installable:

Property	Value
Version	0.1.3
Released	2026-05-21
License	Apache-2.0
Requires	Python 3.11 or later
Coverage	Linux x86_64 and aarch64 (manylinux and musllinux), macOS universal2, Windows x86_64

The distribution is built from a Rust core with PyO3 and maturin. liboqs is statically bundled, so no native build dependencies are required at install time.

What the published version verifies Version 0.1.3 performs primary verification as defined in : signed tree head signature, Merkle inclusion, and leaf hash. It additionally implements the freshness and replay checks described in , exposing a stateful verifier that tracks the last seen tree head per log_id. Version 0.1.3 does NOT implement the witness co-signature check of or the holder possession check of . Those checks were added to the issuing implementation after this version was released and are performed by the issuing side tooling. A future release is expected to cover them.

Verified behaviour The following were executed against the published distribution on 2026-07-21. Primary verification of a genuine ML-DSA-65 signed batch succeeded, returning leaf index, tree size, and tree head timestamp. Three negative controls were each rejected: a corrupted signature, a substituted CA public key, and a single flipped octet in the leaf. The leaf hash test vector of was computed independently in two implementations, a Python reimplementation written from this document and the Rust reference, producing identical output. The thumbprint golden vector of was likewise confirmed by executing the reference implementation's own test suite against the pinned reference revision. The FIPS 204 public key encoding was confirmed by taking the ML-DSA-65 example from Appendix A, which the RFC states is the Section 5.3 encoding, and verifying the RFC's published signature under the RFC's published public key using the same liboqs build the implementation uses. Verification succeeded and a tampered-message control was rejected. The decoder rejections required by were each confirmed against the reference decoder: non-shortest-form integers, misordered map keys, duplicate map keys, and non-NFC text are all rejected.

Public corroboration deployment The issuing implementation publishes batch roots to a contract on the Ethereum Sepolia testnet, dev-grade key. A relying party can compare a published root against the signed tree head root it already holds. The published value corroborates the signed tree head Merkle root only.

Security Considerations

The issuance-time boundary This is the most important consideration in this document. MTAC establishes what credential a session or agent was issued, by which authority, under what declared parameters, and that the credential is present in the log. It does not establish what the agent does at request time. A credential that verifies successfully may be held by an agent whose behaviour has since changed. Declared scopes are not proof of behaviour. A relying party that treats a scope token as a behavioural guarantee has made an error this specification cannot detect. Relying parties requiring assurance about request-time behaviour need a mechanism outside this document.

Challenge freshness The possession mechanism of derives its value entirely from challenge freshness, and this specification places that obligation on the verifier. The software requirement is a minimum challenge length of 16 octets and nothing more. There is no challenge generator, no nonce store, no replay ledger, and no expiry defined here or implemented in the reference tooling. A verifier that reuses challenges, accepts challenges generated elsewhere, or fails to bind the challenge to the session under check obtains no possession guarantee, while the protocol appears to succeed. Implementers MUST generate challenges from a cryptographically secure random source, MUST use each challenge once, and SHOULD bind challenge lifetime to the transaction.

Bearer behaviour by default A credential carrying no holder commitment is a bearer credential. Anyone holding the credential bytes can present them and primary verification will succeed. Where a relying party does not demand a possession check, behaviour is identical to bearer. Deployments requiring more MUST demand the check explicitly rather than assuming it occurred.

Encoding malleability The decoder requirements of are security requirements, not style preferences. A decoder that accepts non-canonical forms permits two distinct octet strings to decode to the same logical leaf while hashing to different leaf hashes, which breaks the correspondence between what was committed and what is verified. The NFC requirement is easy to overlook. Two agent identifiers that render identically but differ in Unicode normalization produce different leaf hashes. The array-order requirement is similarly easy to overlook: implementations MUST NOT sort authorized_scopes.

Trust root distribution The CA public key is the trust root and MUST be pinned out of band. A verifier that takes the CA key from the same channel as the credential gains nothing, because an adversary supplying both a substituted key and a re-signed tree head produces a successful verification. The log_id binding of means a substituted key also changes every leaf hash, so a mismatched pin is detectable, but only if a pin exists.

Witness limits The witness of protects against a compromise limited to the CA key and against dropped or truncated batches. It does not protect against an adversary who controls both the CA key and the witness key, and it does not provide non-equivocation. A deployment operating both the CA and the witness under one administrative authority obtains integrity and continuity attestation, not independence.

Post-quantum posture ML-DSA-65 is used for all signatures. Signature size is 3309 octets and public key size is 1952 octets. Batch issuance amortizes the signing cost across a batch, but each relying party still transports one tree head signature. Deployments with constrained transport should size batches accordingly. The security of the construction also depends on SHA-256, used for the leaf hash, the Merkle tree, and the thumbprint.

IANA Considerations This document has no IANA actions. All identifiers used in this document are either registered elsewhere, namely the AKP key type and the ML-DSA-65 algorithm name in , or are string constants scoped to this specification and carried inside structures this document defines.

References Normative References 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. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. 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. 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 Informative References This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate 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. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. 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. 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. 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. 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.

Acknowledgments The Merkle tree construction and leaf type octet follow . The batch issuance model follows . The thumbprint computation follows the process with the key type and algorithm registered in .