Proposal: A2A Verifiable Task Evidence Extension

2026-09-26 · Steven Mih · v3.2 discussion draft
Provisional extension URI: https://agentactioncapsule.org/extensions/a2a-task-evidence/v1
Status: independent proposal; not an official A2A extension

This proposal supersedes the earlier “Account Card” and broad “task-history” designs. A2A already defines one Agent Card, GetTask, ListTasks, and Task history. This proposal addresses one narrower gap: how a caller can require and receive a portable evidence object for one terminal A2A Task.

v3.2 adds two things to v3.1: how this extension composes with the A2A Traceability sample extension (§4.1), and how evidence records a Task that pauses in TASK_STATE_INPUT_REQUIRED or TASK_STATE_AUTH_REQUIRED and later resumes (§8.1). The extension URI is unchanged.

The examples define proposed extension fields, not existing A2A fields or a finished conformance specification. AAC, CPB, and CLL are work-in-progress Internet-Drafts. This document does not claim that their A2A mapping is already implemented.

1. Abstract

This document proposes an optional A2A data-and-requirement extension. It defines:

1. a request-time declaration that Task evidence is preferred or required;
2. an explicit server acceptance or rejection of that requirement before an external effect is attempted;
3. a TaskEvidenceReference carried in namespaced Task metadata; and
4. a portable evidence bundle carried inline or in an A2A Artifact and retrievable through existing GetTask behavior.

The evidence record binds a semantic projection of the A2A Task—including its accepted Message transcript, terminal state, and non-evidence Artifacts—by digest. The base profile authenticates the producer and can prove that the record entered a producer-operated Checkpointed Local Log whose signed checkpoint was registered with a SCITT Transparency Service. A checkpoint-aware witness can add a separate continuity assertion.

The extension defines no new RPC method. It does not assert that the Task output is correct, that every eligible Task was recorded, that a signing key identifies a legal person, that a claimed external-world effect occurred, or that an agent should be ranked above another.

2. The specific A2A gap

A2A v1 already provides discovery, Messages, Tasks, Artifacts, Task history, authentication and authorization, Agent Card signing, extension metadata, and multiple protocol bindings. A terminal Task and its history remain operational objects served by the agent. Core A2A does not define a standard convention for a caller to require evidence before work begins or for the terminal Task to carry a content-derived evidence record with independently checkable log and registration proofs.

The gap is therefore:

This is a composition extension. A2A owns negotiation and carriage. Agent Action Capsule (AAC), Canonical Payload Binding (CPB), the Checkpointed Local Log (CLL), SCITT, and identity systems retain their own formats and verification rules.

3. Why no new method

A2A already permits namespaced metadata on Tasks and explicit extension metadata on Messages and Artifacts. Artifacts can carry structured data or raw bytes, and GetTask retrieves the current Task and its Artifacts. The first interoperable experiment should use those facilities.

The extension therefore adds no GetTaskEvidence operation and no separate historyEndpoint.

A later version may add dedicated retrieval only if implementation shows that existing A2A cannot express a necessary semantic, such as evidence retention after Task purging, late-arriving proof negotiation, selective disclosure, or authorization distinct from the Task. That case must be made from deployed requirements rather than assumed in advance.

4. Relationship to adjacent work

The A2A community already has adjacent proposals. This extension should compose with them rather than claim an empty field.

Before opening a new A2A Issue, the project should comment on the existing accountability and verifier-artifact threads and ask whether this work should share a composition point.

4.1 Composition with the Traceability sample extension

The A2A samples repository publishes a Traceability extension (https://github.com/a2aproject/a2a-samples/extensions/traceability/v1). It returns a ResponseTrace—a trace_id and a list of Step objects describing tool and agent invocations, parent/child structure, cost, tokens, latency, and timing—in Message or Artifact metadata or as an additional Artifact. It is operational telemetry: it carries no signature, digest, or receipt, and it does not need one to do its job.

The two extensions answer different questions. The trace says what the server reports its steps were. Task evidence says what a key committed about the Task, whether that commitment entered a log, and whether the log checkpoint was registered. This proposal does not re-implement tracing, define a trace format, or ask the Traceability extension to change.

When a client activates both extensions on the same Task:

1. Independent activation. Each extension is activated, advertised, and ignored independently. Activating one never implies the other. Evidence acceptance (§8) says nothing about whether a trace will be returned.
2. The capture policy says whether the trace is committed. A trace delivered as an additional Artifact is a non-evidence Artifact and is already bound by §12. A trace carried in Message or Artifact metadata under the Traceability key is bound only if the capture-policy identifier says that key is included in the committed metadata digest. A relying party reads the capture policy; it does not assume inclusion.
3. What is committed is the returned trace object. The payload commits to the canonical form of the ResponseTrace as returned at the boundary, by digest. Later alteration of the returned trace is then detectable. Cost, token, latency, and step values are not made true by being committed; they remain the server’s report, and outcomeCorroboration is unaffected.
4. Citation runs outward, never back to itself. For an AgentInvocation step where the callee also returned task evidence, the caller may record the callee Task’s evidence ID in Step.additional_attributes under the key https://agentactioncapsule.org/extensions/a2a-task-evidence/v1#evidenceId. That makes the caller’s evidence cite the callee’s by ID without changing the trace schema. A step must not carry the evidence ID of the Task whose trace it is; that value is outside the payload by §12’s exclusion set, and embedding it would make the ID depend on itself.
5. Correlation, not authority. A trace_id, step_id, or cited evidence ID is a correlation handle. It grants nothing, and a verifier checks a cited callee record under its own trust configuration, not because the caller’s trace named it.
6. Privacy. ToolInvocation.parameters and AgentInvocation.requests can carry sensitive content. The default-deny admission rule of §14 applies: a capture policy that includes traces commits digests of those fields, not their values, unless the selected profile supplies appropriate protection.

5. Design principles

1. One Task, not a history. Aggregate histories, pair accounts, routing properties, and rankings are out of scope.
2. Negotiate before acting. A caller that requires evidence must know whether the server accepted that obligation before the server attempts an external effect.
3. Use existing A2A operations. Evidence travels in Task metadata and an Artifact; GetTask retrieves it.
4. One base evidence graph. The base profile commits the evidence-record ID into a local CLL checkpoint and registers that checkpoint with SCITT. Direct per-record SCITT registration is a separate future profile.
5. Immutable terminal bundle. Every assurance promised for the terminal response is either present or explicitly failed when the Task becomes terminal. Later evidence does not silently mutate the bundle.
6. Orthogonal verification. Content binding, signature, inclusion, registration, continuity, identity, coverage, and corroboration have distinct results.
7. Authorization still applies. A Task ID, Artifact ID, or digest is not a bearer capability.
8. Binding-independent semantics. JSON-RPC, gRPC, and HTTP+JSON representations of the same logical Task produce the same record ID. Transport details may be signed separately but do not alter that stable identity.

6. Discovery

An agent advertises the exact extension URI in AgentCapabilities.extensions. The extension is inactive unless the client activates it using the standard A2A-Extensions service parameter and includes the URI in the initiating Message’s extensions array.

Illustrative Agent Card fragment:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://agentactioncapsule.org/extensions/a2a-task-evidence/v1",
        "description": "Portable evidence for terminal A2A Tasks",
        "required": false,
        "params": {
          "recordProfiles": [
            "https://agentactioncapsule.org/profiles/a2a-task-evidence/aac-cll-scitt/v1"
          ],
          "deliveryModes": ["INLINE_METADATA", "EVIDENCE_ARTIFACT"],
          "minimumEvidenceLevels": [
            "SIGNED_RECORD",
            "EXTERNALLY_REGISTERED"
          ]
        }
      }
    ]
  }
}

The profile URIs above are provisional identifiers. Before deployment, each must identify a durable published specification. They are not A2A-owned namespaces or endorsements.

The Agent Card advertises support, not achievement. The terminal evidence result determines what was actually produced for a particular Task.

7. Request-time evidence requirement

An A2A client activates the extension and places a namespaced requirement in the initiating Message metadata.

Illustrative SendMessageRequest:

{
  "message": {
    "messageId": "msg-123",
    "role": "ROLE_USER",
    "parts": [
      {"text": "Apply the approved configuration change."}
    ],
    "extensions": [
      "https://agentactioncapsule.org/extensions/a2a-task-evidence/v1"
    ],
    "metadata": {
      "https://agentactioncapsule.org/extensions/a2a-task-evidence/v1": {
        "requirement": "REQUIRED",
        "recordProfile": "https://agentactioncapsule.org/profiles/a2a-task-evidence/aac-cll-scitt/v1",
        "minimumEvidence": "EXTERNALLY_REGISTERED",
        "deliveryModes": ["EVIDENCE_ARTIFACT"],
        "maximumRegistrationDelaySeconds": 60,
        "requireTask": true
      }
    }
  }
}

requirement has two values:

• PREFERRED: the server may proceed without evidence, but the client treats absence as EVIDENCE_NOT_PRODUCED rather than as evidenced success.
• REQUIRED: an extension-aware server must either accept the exact evidence obligation or reject before accepting the Task or attempting an external effect.

Because A2A permits unsupported optional extensions to be ignored, a client must not send a consequential REQUIRED request unless the current Agent Card advertises the exact URI and requested profile. The client must still verify explicit acceptance in the response. A stale, dishonest, or extension-unaware server can violate advertised behavior; this extension makes that violation observable but cannot cryptographically prevent the server from acting.

When requireTask is true, an extension-aware server must create a Task or reject. It must not return a direct Message as successful completion. If an extension-unaware server returns a direct Message, the client reports failure of its evidence policy.

8. Acceptance and Task lifecycle

Before an external effect is attempted, the server evaluates the evidence requirement. If it accepts, the first returned Task carries:

{
  "metadata": {
    "https://agentactioncapsule.org/extensions/a2a-task-evidence/v1": {
      "evidenceAcceptance": {
        "state": "ACCEPTED",
        "recordProfile": "https://agentactioncapsule.org/profiles/a2a-task-evidence/aac-cll-scitt/v1",
        "minimumEvidence": "EXTERNALLY_REGISTERED",
        "maximumRegistrationDelaySeconds": 60
      },
      "evidenceStatus": "EVIDENCE_STATUS_PENDING"
    }
  }
}

Acceptance is a server protocol commitment, not independently attributable caller or callee evidence. A future bilateral-signature profile may make it cryptographic.

The underlying Task outcome and the evidence outcome remain separate. A Task may be TASK_STATE_COMPLETED while evidence registration failed. The terminal Task must state both facts. Failure to obtain evidence does not undo an external effect and must not trigger automatic re-execution of a non-idempotent action.

For this first profile, evidence assembly occurs before the terminal response is emitted. The recorder freezes the business-result projection, seals it, then attempts the negotiated proofs within a bounded waiting period. maximumRegistrationDelaySeconds starts when that projection is frozen, measured by a local monotonic timer; it is an operational timeout, not cryptographic proof of event-to-registration latency. The business-result time, evidence seal time, and external registration time remain separate. A server crash can still prevent terminal delivery; the caller must report missing evidence rather than assume a recorded refusal.

At terminal transition, evidenceStatus is exactly one of:

• EVIDENCE_STATUS_SIGNED_RECORD;
• EVIDENCE_STATUS_EXTERNALLY_REGISTERED;
• EVIDENCE_STATUS_CONTINUITY_WITNESSED; or
• EVIDENCE_STATUS_FAILED.

EVIDENCE_STATUS_PENDING is forbidden on a terminal Task. If the requested minimum is not achieved by the declared deadline, the terminal Task carries EVIDENCE_STATUS_FAILED and a typed reason. The server does not downgrade silently.

The terminal evidence bundle is immutable. A later receipt, credential, or corroboration must appear in a new successor manifest that cites the prior manifest; it does not change the original evidence-record ID or terminal manifest digest. Successor-manifest discovery is outside this version.

8.1 Interrupted states: input-required and auth-required

A2A defines TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED as interrupted states, not terminal ones. A Task can pause in either state, receive a further Message from the client, and continue. The evidence rules for a paused Task are:

1. One Task, one terminal record. A pause does not end the evidence obligation or split the Task into two records. The terminal bundle covers the whole Task, before and after every pause.
2. The status stays pending while paused. On an interrupted Task, evidenceStatus is EVIDENCE_STATUS_PENDING. No terminal status is emitted and no terminal bundle is attached at a pause.
3. The accepted obligation carries across the pause. evidenceAcceptance is fixed for the life of the Task. A resuming Message that omits the extension metadata inherits it. A resuming Message that carries a different requirement, profile, or minimum is rejected with a typed error; it is not silently applied and not silently ignored.
4. The pause and the resume are in the transcript. The boundary records, in sequence, the Message that requested input or authentication, the transition into the interrupted state, the resuming Message (its messageId and Task/context binding), and the transition out. Sequence positions are contiguous across the pause. A verifier can therefore see where the Task paused and what resumed it, and an omitted or substituted resumption breaks the sequence.
5. Effects before the pause are recorded before the pause. If an external effect was attempted before the Task paused, the transcript records it ahead of the pause entry. A resumption is never evidence that nothing happened earlier.
6. Optional interim record. A producer may seal an interim record when a Task pauses, for example when the pause may be long or an effect has already been attempted. An interim record is not a terminal bundle and does not change evidenceStatus. If one is sealed, the terminal Task Evidence payload cites its evidence ID, and both records enter the same local log. The chain across the pause is then one committed sequence: the interim record is included in a checkpoint, and the terminal record, which cites it, is included in the same or a later checkpoint of that log.
7. Authentication material stays out. For TASK_STATE_AUTH_REQUIRED, the transcript records that authentication was requested and that the Task resumed. It does not record credentials or tokens. Whether the resuming party was authorized is an identity and authority question (identityAuthorityBinding), not something the transcript establishes.
8. Paused time does not count against the registration deadline. maximumRegistrationDelaySeconds starts when the terminal business-result projection is frozen, as in §8. Time spent paused is not part of it.
9. A Task that never resumes still gets a terminal record. If a paused Task is canceled, fails, or is rejected, the terminal bundle is produced as for any other terminal Task. It covers the transcript up to the pause and the terminal transition.

9. TaskEvidenceReference and delivery

Every terminal Task for which the server accepted the extension carries an evidence result in Task.metadata[extensionUri]. If a record was successfully sealed, that result includes TaskEvidenceReference. If sealing itself failed, the result instead carries a typed failure reason and omits nonexistent IDs, digests, and Artifact references. If only registration failed, the result may retain the signed record and identifies each missing proof separately.

Illustrative reference:

{
  "extensionVersion": "1",
  "evidenceId": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "recordProfile": "https://agentactioncapsule.org/profiles/a2a-task-evidence/aac-cll-scitt/v1",
  "coreManifestDigest": "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789",
  "evidenceStatus": "EVIDENCE_STATUS_EXTERNALLY_REGISTERED",
  "coverageScope": "TASK_TRANSCRIPT",
  "terminalState": "TASK_STATE_COMPLETED",
  "deliveryMode": "EVIDENCE_ARTIFACT",
  "evidenceArtifactId": "artifact-evidence-123"
}

The identifier representation is defined by the record profile. For the current CPB/AAC construction it is a 64-character lowercase hexadecimal value; implementations must not invent or silently coerce another representation.

Delivery modes:

• INLINE_METADATA: the immutable evidence bundle is carried inside the namespaced Task metadata. This is suitable only for small bundles.
• EVIDENCE_ARTIFACT: evidenceArtifactId identifies an Artifact returned with the Task. The Artifact declares the extension in Artifact.extensions and carries the immutable bundle in a raw or data Part with an evidence media type.

This version does not use a mutable Part.url for the evidence bundle. A future reference-delivery profile must define immutable addressing, authorization, retention, and the distinction between the locator digest and the resolved-content digest.

Existing GetTask retrieves the Task and available evidence Artifact under ordinary A2A authorization. A server that later purges the Task may make the bundle unavailable; retention beyond Task lifetime is explicitly outside this version.

10. The base evidence graph

The base profile defines one path:

flowchart TD
    A["A2A Task Evidence payload"] -->|"CPB"| B["Derived evidence ID"]
    B --> C["AAC Producer Envelope"]
    B -->|"Local MMR inclusion"| D["Signed CLL checkpoint"]
    D -->|"SCITT statement + TS Receipt"| E["External registration"]
    E -->|"Checkpoint-aware assertion"| F["Optional continuity result"]

The bundle keeps these objects distinct:

1. Task Evidence payload: the canonical logical record of the A2A interaction.
2. Derived evidence ID: computed under CPB using the payload class’s declared canonicalization and exclusion set.
3. AAC Producer Envelope: the producer signature over the evidence ID. It is not itself a SCITT Signed Statement.
4. CLL inclusion proof: proves the evidence ID is an entry in the local MMR committed by the checkpoint.
5. Signed CLL checkpoint: commits to the local log identity, size, MMR commitment, prior checkpoint, and cadence policy.
6. Checkpoint registration statement: the signed CLL checkpoint itself, when it satisfies SCITT Signed Statement requirements. No additional wrapper is implied. Any future wrapper profile must specify exactly which checkpoint bytes it commits to.
7. Transparency Service Receipt: proves registration of the checkpoint statement using the VDS identified by that Receipt.
8. Optional continuity assertion: a signed statement that a checkpoint-aware witness applied a named policy to the stated prior and new checkpoints and accepted the consistency proof.

The local MMR proof profile and every Transparency Service Receipt/VDS profile have separate identifiers. Merkle-style is not a proof format. A Receipt for direct registration of an AAC evidence ID is not interchangeable with a Receipt for a CLL checkpoint and belongs to a different evidence profile.

11. Immutable core manifest

The evidence Artifact or inline bundle carries a core manifest containing the exact bytes or digests of every object required by the selected profile:

• Task Evidence payload and derived ID;
• Producer Envelope(s);
• CLL checkpoint and local inclusion proof;
• checkpoint registration statement and corresponding Transparency Service Receipt when minimumEvidence requires external registration;
• continuity assertion and its consistency-proof references when continuity is claimed;
• media types, algorithm identifiers, proof/VDS profiles, and digest representations; and
• cryptographic key material needed to perform signature mathematics.

coreManifestDigest commits to that immutable manifest under a separately declared canonicalization and digest context. The digest is carried outside its own preimage; the manifest must not embed a self-referential copy of the Task reference. The profile must prescribe byte encoding for COSE objects, deterministic ordering for collections, and domain separation from the Task Evidence payload. Objects added after terminal completion require a successor manifest with its own digest.

Bundle-carried keys are cryptographicKeyMaterial, not trust anchors. The verifier obtains trust anchors from configuration or an external identity policy. Identity and authority evidence names its issuer, subject, scope, and validity interval; it is evaluated at the relevant historical time, including any policy for compromise discovered later.

12. Task Evidence semantic projection

The stable evidence ID is derived from a transport-independent logical payload class, not from JSON-RPC, gRPC, or HTTP serialization bytes.

The payload binds:

• a stable server/agent issuer identifier;
• tenant or security domain when applicable;
• Task ID and contextId;
• the accepted Task transcript captured at the A2A boundary, including every transition into and out of an interrupted state (§8.1);
• the evidence IDs of any interim records sealed for this Task at a pause (§8.1);
• terminal Task state;
• every non-evidence Artifact and its semantic content commitment;
• a digest of any Traceability ResponseTrace the capture policy includes (§4.1);
• the producer’s declared seal time; and
• the capture-policy identifier.

The Task transcript is not reconstructed from Task.history, because A2A does not guarantee that all Messages are persisted there. The extension-aware boundary records each accepted Message with a sequence position, messageId, role, Task/context binding, Part commitments, and the digest of any metadata the capture policy includes.

The payload class’s exclusion set removes:

• Task.metadata[extensionUri], including TaskEvidenceReference;
• the evidence Artifact itself;
• Producer Envelopes, checkpoints, proofs, and receipts added after the payload ID is derived;
• transport-only representation fields; and
• volatile retrieval metadata.

This exclusion prevents the evidence ID from depending on a Task field that already contains that same ID.

Selected transport, interface details, and the observed Agent Card digest may be recorded in a signed context object inside the manifest, but they do not enter the stable Task Evidence payload. Binding-independent identity means that different serializations of the same captured logical record derive the same ID—not that separate executions with different Task IDs, messages, or seal times have identical IDs. The stable issuer identifier must be checked against configured identity/authority policy; a producer cannot establish authority simply by choosing that string.

For a Part.url, the payload distinguishes the locator from its content. If the referenced content affects the Task request or result, the recorder must commit to the resolved bytes, media type, and length at the evidence boundary or mark the content NOT_RESOLVED. A URL string alone is not evidence of immutable content.

The normative profile must define handling of absent fields, defaults, Unicode, numbers, map ordering, ordered Parts, Artifact identity, append and replacement updates, lastChunk, retries, and idempotency. Cross-binding vectors must demonstrate that independent implementations derive identical IDs.

13. Verification result

A verifier returns a structured result. Each property is PASS, FAIL, NOT_PRESENT, NOT_CHECKED, or INCONCLUSIVE, with diagnostic evidence.

No aggregate trusted: true result is defined. A valid bundle can have PASS for content and signatures while identity, capture coverage, or outcome corroboration remains unestablished.

14. Security, authorization, and privacy

Evidence carried with a Task is protected by the Task’s authorization policy. An ID or digest is not authorization. Servers should avoid revealing whether a guessed Task, Artifact, or evidence ID exists across authorization boundaries.

The specification and tests must address:

• unsupported-extension downgrade and stale Agent Cards;
• evidence-required requests that receive direct Messages;
• cross-tenant Task or proof substitution;
• Task, Message, and Artifact ID reuse or ambiguity across authorities;
• omitted or reordered multi-turn Messages;
• a different or forged resumption spliced into a paused Task, or a requirement changed at resume;
• mutable URL content and incomplete streamed Artifacts;
• replay or transplantation of an evidence reference;
• stale checkpoints presented as current;
• equivocation across witnesses or relying parties;
• selective capture and boundary bypass;
• false claims by an otherwise valid signer;
• bundle-carried keys promoted incorrectly to trust anchors;
• key compromise, rotation, historical validity, and succession;
• low-entropy digest guessing;
• leakage of counterparties, log size, cadence, and business activity;
• denial of service through oversized evidence bundles; and
• retention and deletion requirements for local preimages and personal data.

Evidence payload admission is default-deny for secrets, personal data, and low-entropy fields unless the selected profile supplies appropriate protection. Digest-only commitments do not eliminate dictionary attacks or metadata leakage.

15. Deferred work and non-goals

This version does not define:

• a new RPC, separate evidence endpoint, or evidence retention after Task purging;
• a trace format, trace signing, or any change to the Traceability extension;
• direct per-Capsule SCITT registration;
• late proof discovery or selective disclosure;
• caller signatures or bilateral completeness;
• aggregate Task history, ranges, or pair accounts;
• dispute adjudication or appeals;
• proof that the Task output or claimed effect is true;
• proof that every eligible Task was captured;
• a client PKI, universal identity system, or legal non-repudiation;
• hardware-attestation semantics;
• platform migration or key-succession protocol;
• a registry operated by the proposer; or
• changes to A2A core.

A future bilateral profile may bind a replay-resistant caller commitment to an immediate callee acceptance/refusal and later terminal evidence. Until then, the evidence is unilateral and aggregate denominators such as “completed n of m Tasks” are not supported.

16. Experimental acceptance criteria

Before requesting experimental sponsorship, demonstrate:

1. two independent implementations derive identical evidence IDs and verify each other’s bundles;
2. an A2A v1 client activates the extension, receives explicit acceptance, completes a Task, retrieves the immutable bundle with GetTask, and verifies it offline;
3. the same semantic Task over every implemented A2A binding derives the same ID;
4. conformance vectors cover every normative field, terminal state, multi-turn sequence, interrupted-state pause and resume, streaming rule, exclusion, proof object, and error path;
5. negative vectors detect mutation, omission, substitution, stale proof, wrong issuer/tenant, wrong Task binding, an omitted or spliced resumption, a dropped interim citation, wrong trust anchor, and false continuity claims;
6. tests keep signature, local inclusion, external registration, continuity, identity, capture coverage, and truth results distinct;
7. witness independence is assessed externally; a same-operator service may establish registration under an accepted key but is labeled producer-operated, and never promoted to independent continuity;
8. a published privacy review documents checkpoint metadata and low-entropy digest risks; and
9. one independent relying party changes a real decision when required evidence is absent, invalid, late, or below the negotiated minimum.

Latency, registration service-level objectives, test-vector counts, pilot duration, and Task volume should be measured under a published workload before thresholds are proposed. They are benchmark hypotheses, not protocol truths.

17. Governance and implementation sequence

The formal A2A lifecycle is:

1. open an Issue in a2aproject/A2A with an abstract, motivation, adjacent-work comparison, and initial technical approach;
2. refine the proposal through community discussion;
3. obtain an A2A Maintainer sponsor;
4. have the sponsor create experimental-ext-task-evidence under the A2A organization;
5. iterate on the specification, implementations, and early adoption in the experimental repository; and
6. seek graduation only after production-quality implementation, community adoption or interest, committed maintainers, and the required TSC vote.

Recommended preparation before the first Issue is smaller: one running A2A flow, one positive vector, one tamper-negative vector, a threat-model sketch, and comments on the adjacent A2A threads. These are evidence that the composition is concrete, not prerequisites imposed by A2A governance.

The provisional URI and any later A2A-owned URI are different protocol identifiers. Any migration requires explicit dual advertisement or a declared transition; silently changing the URI breaks deployed clients.

Before contribution, document the licensing and IPR boundary between the IETF-defined evidence formats and schema, code, or prose contributed under A2A’s Apache-2.0 requirements.

18. Existing work and remaining work

AAC, CPB, CLL, emitters, witness work, and offline verification can serve as implementation substrate. The capsule-emit-mesh plugin (v0.1.0) for mesh-llm is a field implementation of parts of that substrate, not evidence that this A2A extension interoperates or has been adopted.

Before public filing, every implementation-status claim should link to a release, commit, test result, or reproducible demonstration under one status vocabulary. The A2A middleware, normative Task Evidence payload class, exclusion set, manifest schema, cross-binding vectors, conformance tests, second implementation, checkpoint-aware independent witness, and requiring-party pilot remain to be demonstrated.

The v3.2 additions are specification text only. The existing reference flow and its positive and tamper-negative vectors predate them; interrupted-state and Traceability vectors are not yet published.

19. Why this is worth doing

The extension does not make an agent trustworthy. It gives a relying party a precise way to require evidence before consequential work begins and to inspect what a particular key committed about the resulting Task, whether that commitment entered the declared local history, whether the checkpoint was externally registered, whether continuity was separately established, and which stronger claims remain unproved.

That is narrow enough to implement, specific enough to test, and useful enough for a party bearing liability to require.

Version history

References

• A2A Project, Protocol Specification.
• A2A Project, Extensions.
• A2A Project, Extension and binding governance.
• A2A Samples, Traceability extension, v1.
• IETF SCITT, RFC 9942 and RFC 9943.
• IETF, HTTP Message Signatures, RFC 9421.
• IETF Internet-Drafts: Agent Action Capsule, Canonical Payload Binding, and Checkpointed Local Log.
• A2A discussions: cross-organization accountability #1713, verifier-side artifacts #1769, trust signals #1628, and discussion #1962.