OpenA2A/specs
ATP1.1.0-draftDraft, dated September 2026

Agent Trust Protocol

The protocol that issues, verifies, distributes and revokes trust assertions. Issuance and revocation events are appended to an RFC 6962 Merkle log; the Registry publishes signed tree heads and inclusion and consistency proofs that anyone can fetch and check; no monitor outside OpenA2A runs today.

The question it answers

“How are trust statements issued, logged, audited and revoked?”

If you know one thing already

It’s like Certificate Transparency (CT) logs.

Co-authors wantedThis spec is proposed and open to co-authors. How to help.

Why it exists

ATX is the credential; ATP is the protocol around it. It standardizes how trust assertions are issued, verified, distributed and revoked, and, above all, how every one of those acts is recorded in a public RFC 6962 Merkle log so that trusting an agent is itself auditable.

Key idea

The lesson ATP borrows from the web

After certificate authorities mis-issued certificates, the web added Certificate Transparency: log every certificate to a public append-only tree that anyone can audit. ATP adopts the same RFC 6962 structure for agent trust, so that granting a malicious agent a high trust level leaves a public log entry with an inclusion proof.

The trust assertion

A trust proof is a small, signed statement about a subject DID: its level, score, verdict and validity window. Proofs are short-lived (the spec caps validity at 24 hours) and are signed over a canonical byte form, never raw JSON, so the signature is reproducible regardless of field ordering.

Trust proof (ATP-SPEC §4.2)json
{
  "did": "did:opena2a:mcp_server:agent_conformance_test_001",
  "trustLevel": 3,
  "trustScore": 0.825,
  "verdict": "passed",
  "issuedAt": "2026-05-23T12:00:00Z",
  "expiresAt": "2026-05-24T06:00:00Z",
  "issuerDid": "did:opena2a:authority:opena2a.org",
  "signatures": [
    {
      "keyId": "did:opena2a:authority:opena2a.org#key-1",
      "algorithm": "Ed25519",
      "value": "L6Q6Dh+zPLq+BB9NutK9OV+zX2/cxbSd33k23OwZxmhvlJr+I5/eEDdcxEnSHpgqRFFLt/+b19IMb1mNseWtBw=="
    }
  ],
  "transparencyLogIndex": 42
}

# canonical signing form (pipe-delimited, deterministic):
# {did}|{trustLevel}|{trustScore:.6f}|{verdict}|{issuedAt}|{expiresAt}|{issuerDid}

Five trust levels

0, Blocked
Known-bad. Reject.
1, Warning
Significant concerns; proceed only with caution.
2, Listed
Catalogued, but not yet scanned.
3, Scanned
Passed security scanning. Levels 3-4 must be cosigned by a second authority.
4, Verified
Highest assurance, multiple authorities have cosigned.

The transparency log, visualized

Issuance, revocation and key rotation events are appended as leaves of an RFC 6962 Merkle tree. Two cheap proofs make the whole thing trustworthy without downloading it: an inclusion proof (this entry is in the log) and a consistency proof (the log only ever grew).

Signed Tree Head
root hash · tree size · signed
h01 = H(·‖·)
h23 = H(·‖·)
h0
issued
h1
issued
h2
revoked
h3
key rotated

Inclusion proof

To prove leaf h2 is in the log, a verifier needs only h3 and h01, recompute the root and compare. ~log₂(n) hashes, not the whole log.

Consistency proof

Shows each new tree is a superset of the last: an entry altered or back-dated after publication fails this proof. Anyone can fetch a consistency proof from the Registry and check it.

A Signed Tree Head, the signed root hash and size, is published at least every hour (ATP §5.6). Issuance and revocation events are appended to an RFC 6962 Merkle log; the Registry publishes signed tree heads and inclusion and consistency proofs that anyone can fetch and check; no monitor outside OpenA2A runs today. If an entry were ever altered or back-dated, the proofs would fail.

The full lifecycle

  1. 1
    authorityIssue≤ 24h TTL

    Evaluate the agent (scans, provenance), build the proof, sign the canonical form with Ed25519 (optionally + ML-DSA-65).

  2. 2
    authorityLog

    Append the issuance as a leaf, recompute the Merkle root, publish a new Signed Tree Head.

  3. 3
    relying partyVerify + check inclusion

    Check expiry, issuer, signature; if a log index is present, verify the inclusion proof against the published root.

  4. 4
    relying partyCache

    Hold the proof for its validity window; poll the revocations endpoint (every ~5 min recommended).

  5. 5
    authorityRevoke< 60s budget

    On compromise, append a revocation leaf and push a CRL delta to federation nodes. ATP sets a delivery budget of under 60 seconds for that push; the reference registry has no peer push today, so verifiers poll its revocation lists.

Three conformance levels

Level 1, Basic Trust
A single authority signs and verifies proofs, with a discovery endpoint. For one organization managing its own agents.
Level 2, Auditable Trust
Adds the transparency log, inclusion proofs, and revocation infrastructure. For a public authority that must be tamper-evident.
Level 3, Decentralized Trust
Adds federation: multi-authority cosigning for levels 3-4 and cross-authority revocation propagation. For ecosystem-wide trust.

Federation, specified and not yet demonstrated

ATP specifies federation: at Level 3 two or more authorities cosign a proof. One authority operates today, no second authority cosigns proofs yet, and credentials carry trust level 2 at most while that is so. Levels 3 and 4 requireat least two distinct authorities, so no single organization can unilaterally hand out the highest trust. The protocol's own status note reads: “A decentralized response, co-signed by several trust authorities (federation, conformance Level 3), is specified and not yet demonstrated: no second authority co-signs proofs yet, and no conformance fixture covers a co-signed proof.”

Note

ATP and ATX, precisely

ATX is the agent-specific credential formatdefined on top of ATP's base trust proof. ATP defines the format, the did:opena2a method, the transparency-log format, the federation protocol and the revocation format. ATX adds the agent fields (capabilities, build attestation, behavioral profile, scan summary) to the proof.