docs(proposals): add A2A Identity Trust Framework roadmap (v1.0 - v2.0)#1850
docs(proposals): add A2A Identity Trust Framework roadmap (v1.0 - v2.0)#1850thebenignhacker wants to merge 5 commits into
Conversation
Public trajectory document so peer implementers (Envoys, CTEF, APS, Hippo) can align release cycles and schema changes against a known A2A-IDF roadmap rather than reacting per pull request. Sections: - v1.0: current proposal (PR a2aproject#1496) - verification levels, dual-shape keyid, attestations, delegation chains, RFC 9421 wire signatures - v1.1: vouching attestation type per @aeoess Feb-23 thread - v1.2: federated revocation registry, CT-style append-only log - v2.0: ML-DSA-65 post-quantum signature agility, hybrid keying - Coordination map across companion specs (a2aproject#1829 Envoys, a2aproject#1786 CTEF, a2aproject#1575 APS, lawcontinue/hippo-auth) - Non-goals (no hosted infrastructure required, no proprietary signature formats, no TLS/AgentCard deprecation, no online-only verifiers) Sibling to existing docs/proposals/agent-identity-trust-framework.md (spec) and agent-identity-trust-framework-design-rationale.md (why).
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new roadmap document for the Agent Identity Trust Framework (A2A-IDF), outlining the development trajectory across four protocol cycles (v1.0 through v2.0). The review feedback identified a potential redundancy in the coordination map regarding issue references and suggested adding '@' prefixes to usernames in the witness governance section to ensure consistency and improve linkability in rendered markdown.
| | [CTEF claim envelopes (issue #1786)](https://github.com/a2aproject/A2A/issues/1786) | @aeoess | Identity claims | A2A-IDF attestation envelopes and CTEF claim envelopes are orthogonal layers. If CTEF stabilizes a generic envelope shape, A2A-IDF attestation types ship as content within it. | | ||
| | [APS payments / receipts / delegation (issue #1575)](https://github.com/a2aproject/A2A/issues/1575) | @aeoess | Delegation and continuity | A2A-IDF delegation chain structure composes with APS bilateral receipts and delegation chains. Conformance fixtures demonstrate composition without re-signing the wire layer. | | ||
| | [Hippo Ed25519 reference (lawcontinue/hippo-auth)](https://github.com/lawcontinue/hippo-auth) | @lawcontinue | Wire reference implementation | Hippo's Ed25519 reference library is a peer implementation against Envoys §1-§4. A2A-IDF §6 follow-up planned to incorporate Hippo's `tag` parameter and SHA-512 acceptance work. | | ||
| | [CTEF v0.3.x release schedule](https://github.com/a2aproject/A2A/issues/1786) | @kenneives | Cross-thread release coordination | A2A-IDF aligns minor-version timing with CTEF cycles to share review cycles for envelope shape changes. | |
There was a problem hiding this comment.
The 'Coordination map' table has two rows pointing to the same issue (#1786) with different descriptions and owners. While intentional repetition is acceptable for emphasis or clarity in documentation, this specific instance is confusing and appears to be an error. Please combine the rows or provide the correct issue link.
References
- In documentation, intentional repetition can be acceptable for emphasis and clarity, even if it appears redundant.
|
|
||
| **Coordination dependencies.** | ||
| - v1.1 vouching shape (this proposal): revocation log records vouching attestations and primary attestations identically; the type field distinguishes. | ||
| - Witness governance: needs an A2A working group resolution on which issuers operate witnesses. Candidate witness set is the agreed conformance suite operators (OpenA2A, aeoess, jschoemaker, kenneives, lawcontinue). |
There was a problem hiding this comment.
For consistency with how GitHub users are referenced elsewhere in this document (e.g., in the Coordination Map table), please prefix the usernames in this list with @. This will also make them clickable links in the rendered markdown.
| - Witness governance: needs an A2A working group resolution on which issuers operate witnesses. Candidate witness set is the agreed conformance suite operators (OpenA2A, aeoess, jschoemaker, kenneives, lawcontinue). | |
| - Witness governance: needs an A2A working group resolution on which issuers operate witnesses. Candidate witness set is the agreed conformance suite operators (OpenA2A, @aeoess, @jschoemaker, @kenneives, @lawcontinue). |
Spec v1.5.0 formalizes dual-shape keyid resolution (§6): verifiers MUST
accept either an application/did+json W3C DID Document or the Envoys-
native { address, public_key } object returned at the keyid URL.
Promotes former §7.1 task-resumption to §8 "Signature scope and
layering" with per-receipt-type attribution as a descriptive principle.
Adds optional RFC 9421 §2.3 `tag` parameter and SHA-512 auto-promotion
at >=4KB bodies to the normative wire format. Vectors 1-3 byte-stable.
SDK 0.7.2 adds Envoys.resolveKeyFromKeyid() that fetches the keyid URL,
sniffs Content-Type, and routes to DID Document or Envoys-native
parser automatically. verifyRequest and verifyAgentCard now use it,
so signatures from agents whose keyid serves did:web verify with no
caller-side opt-in.
API server-side: /agents/:address honors Accept: application/did+json
and emits a W3C DID Document with publicKeyJwk, authentication, and
assertionMethod arrays. Default (no Accept or wildcard) unchanged.
Aligned with A2A Identity Trust Framework v1.0 roadmap dual-shape
keyid resolution interop deliverable (a2aproject/A2A#1850).
|
Useful artifact. A coordination doc is better than reacting per PR. For APS, the main overlap with A2A-IDF is around signed identity, scoped authority, mutual authentication, cognitive attestation, and byte-stable conformance fixtures across implementations. Our current pattern is to pin conformance vectors per release so downstream implementers have stable fixtures even when the SDK moves. The relevant home for that is Happy to add an APS row directly to the roadmap doc if peer-edited content is useful, or you can ping me when intersecting schema changes land. |
|
Thanks @aeoess. Yes, please add an APS row directly. The current bullet for #1575 in the Coordination Map is one line and doesn't carry the per-release pinning pattern at all, which is exactly the discipline that makes cross-suite composition work. Branch is
On the five overlap surfaces you named, mapping them to where they land in the roadmap:
The per-release pinning pattern at |
|
@thebenignhacker — quick citation ask on the State of AI Agent Security: May 2026 reference in the roadmap-mapping comment (§5 honeypot handshake data + §8 OASB 7.x recommendations). That title doesn't match the State of Agent Security 2026 report at agentgraph.co — different title prefix, and the §5 / §8 content you describe (30-day honeypot window, 31,310 A2A handshake events, OASB 7.1/7.2/7.3 recommendations) doesn't appear in our document. If it's a separate substrate-adjacent paper — peer research, AAIF / A2A WG empirical study, or otherwise — a link or repo pointer would be useful. The honeypot-handshake observational data + OASB recommendation mapping would slot directly into the v0.3.3 working doc at No urgency — file at convenience. |
|
@kenneives — yes, separate report. State of AI Agent Security: May 2026 is the inaugural Behavioral Threat Report from OpenA2A Research, published 2026-05-12.
The §5 numbers (31,310 A2A handshake events, 15.2% share of total attacker events) come from a 30-day honeypot window ending 2026-05-11 across four behavioral telemetry streams (TrapMyAgent honey agents, AgentPwn honeypot pages, HoneyFinder wild bait, ARIAscout exposure sweep). §8 Recommendation 2 ("a2a-priority") maps to OASB 7.1 Mutual Authentication / 7.2 Message Integrity / 7.3 Trust Boundary Enforcement. Canonical citation: Cadence is monthly, 15th-of-month publish, rolling 30-day window. Happy to slot the honeypot-handshake observational data + OASB mapping into the v0.3.3 working doc if you want a peer-edit pass, or pull it directly. |
|
@thebenignhacker — citation confirmed and read. State of AI Agent Security: May 2026 is the behavioral-surface companion to our supply-chain-surface scan report — paired empirical picture:
Same launch day, complementary scope: behavioral observations of what attackers are doing paired with structural observations of what infrastructure they're operating against. The 75.4% MCP attacker concentration + our 55.3% MCP Registry critical-findings rate are the same surface from two measurement angles. On the v0.3.3 working doc fold-in: yes please, pull-directly works. I'll write a brief empirical-grounding section in On cross-citation in Q3 2026 follow-up: worth surfacing the complementary-empirical framing. The substrate work + the behavioral threat data tell a coherent story (here are the structural gaps; here is the attacker activity exploiting them; here are the OASB controls + CTEF substrate that closes the loop). Happy to coordinate on framing if useful for OpenA2A's Issue 2 publish. On the broader OpenA2A research-web stack: scrolled the org ( Per-release pinning pattern: agreed — worth a sentence in the Coordination Map intro. Either you phrase it or I can draft if you'd rather. Same shape across Envoys, APS, CTEF, Hippo, A2A-IDF — convergent practice across all five suites. |
|
@kenneives, I'll phrase the per-release-pinning sentence in the Coordination Map intro (already committed to @aeoess upthread). Batching it with the APS row @aeoess is contributing, so it's a single push, single review ping. Will peer-edit the v0.3.3 empirical-grounding section when you ping. §5 + §8 citations are stable (publishing-cadence-locked, no retroactive edits). Paired-empirical framing reads cleanly. Worth carrying into Issue 2 next month, and the integrated-venue read on #1496 lines up. |
|
@thebenignhacker, here is the APS row you asked for, scoped to shipped APS surfaces. Feel free to edit for roadmap style or batch it into your push with attribution. APS (Agent Passport System) — APS composes with A2A-IDF at the identity, scoped-authority and mutual-authentication surfaces. It does not replace the A2A-IDF wire signature. APS treats that signature as the transport layer and carries delegation and receipt structure above it.
Per-release conformance pinning: APS pins byte-stable conformance vectors per SDK release at The same pattern can generalize across companion specs: each project pins fixtures per release, and verifiers compose against known vector sets instead of a moving |
… per-release-pinning intro Two batched edits per PR thread: 1. Add per-release-pinning intro paragraph to Coordination map section (kenneives's ask from PR thread review): companion specs pin byte-stable conformance vectors per SDK release; cross-spec references carry version pins and content hashes. 2. Expand APS row with aeoess's contributed row-level summary, add new "APS per-version composition" sub-section with per-version (v1.0/v1.1/ v1.2/v2.0) composition detail and APS conformance-suite pin pointer. Content for the APS row + per-version composition contributed verbatim (em dashes restyled) by @aeoess in his PR review comment. Co-authored-by: aeoess <aeoess@users.noreply.github.com>
|
Pushed 07303eb batching both reviewer requests:
Apologies for the lag between @aeoess's row delivery and this push; the queue cleared today. |
|
@thebenignhacker — both reads clean. The per-release-pinning intro lands well as a one-paragraph framing of the convergent practice across the five companion specs. Concrete instance in production right now: opena2a-standards/a2a-idf-conformance#6 caught Envoys v1.5.0 → v1.5.1 mid-PR — discipline drafted 2026-05-15 against v1.5.0 ( cc @aeoess — APS per-version composition section reads as the substrate anchor. — Kenne |
|
Mycelium Trails (argentum-core) fits the post-execution evidence slot in the cross-extension matrix alongside APS and CTEF. The layer is complementary — no overlap with identity or wire signing. The composition: AGNTCY/DID (who) → Verifiability Gate (authorized?) → Mycelium (what happened, tamper-evident). Each layer independently verifiable, no cross-layer trust required. Evidence of convergence: action-ref-v1 independently verified by x402 foundation (action-ref-verify@ec7201a, confirmed today), AGT EvidenceAnchor SPI merged (microsoft/agent-governance-toolkit#2244), Nobulex and Verifiability Gate aligning against conformance fixtures this week. Conformance fixtures live: https://github.com/giskard09/argentum-core/tree/main/examples/conformance |
|
@giskard09, appreciate the proposal. The cross-extension matrix today is APS and CTEF, both of which carry an IETF Internet-Draft ( Mycelium Trails is a legitimate post-execution evidence design pattern, and the layered framing (identity → authorization gate → tamper-evident execution log) reads cleanly as a complementary layer. On the three convergence signals you cite, the evidence does not quite hold up yet:
When there is (a) an independent implementation of the action-ref-v1 wire format authored by a different party, (b) the AGT EvidenceAnchor plugin actually landed and exercised against argentum-core, and (c) at least one peer-cosigned conformance fixture set comparable to what APS and CTEF carry, the matrix entry argument becomes much stronger. Happy to revisit then. The |
|
Two corrections are warranted. On andysalvo: that is a personal conformance verifier repo, not an x402-foundation artifact. The framing overstated what it is. The correct claim is: andysalvo independently reproduced 4/4 fixtures byte-identical against argentum-core/examples/conformance/ on the same rfc8785@0.1.4 + lowercase-hex SHA-256 substrate. On AGT #2244: agreed — it is a design proposal, not a landed implementation. The plugin PR is pending (#2381, #2415). The independent implementation that does hold up: AlgoVoi (chopmob-cloud) ran rfc8785@0.1.4 against all four argentum-core fixtures — 4/4 byte-identical, both legs (canonical JCS string and SHA-256 → action_ref). Public gist: gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9. Different party, different implementation, no coordination. That is the artifact for criterion (a). On Nobulex: arian-gogani confirmed authorship of the nobulex behavioral-evidence row in the v0.3.3 fixture matrix and is targeting the PENDING-boundary cross-validation this week against argentum-core fixtures (#1829). No public repo yet — fair to hold that signal until the artifact lands. The bar you described is clear and reasonable. Will revisit when (b) lands. |
|
@giskard09 — appreciate the corrections on andysalvo and AGT #2244. On the AlgoVoi reproduction: the gist at
The bar remains as stated. Concretely, criterion (a) is "an independent implementation of the action-ref-v1 wire format authored by a different party" — a non- Happy to revisit when (a) lands with that scope, alongside (b) the AGT plugin landing and exercising and (c) the peer-cosigned fixture set. |
Spec/docs-only fork — the 8-phase pre-push review (new-user walkthrough, adversarial corpus, score sanity, concept-explainer, real-world dev-tree scan) targets tool repos with runnable artifacts and is not applicable here. Review of proposal text happens on the upstream PR.
- @-prefix candidate witness set in v1.2 Coordination dependencies for consistency with the Coordination map convention - Disambiguate the two a2aproject#1786 rows in the Coordination map: the release-cycle row now links to @kenneives's v0.3.3 working doc (the actual artifact he coordinates from), and adds a note pointing back at the substrate envelope row.
Adds a "Related substrate work" subsection under the Coordination map that points at the OpenA2A AIP+ATP+ATX spec set tracked separately on a2aproject#1876. Explicit about why the set is not in the Coordination Map table above (does not yet meet the (a)(b)(c) maturity bar APS and CTEF carry): single implementation today, reference build plugin not yet shipped, no peer-cosigned conformance fixtures. Honest cross-link, not a matrix-inclusion claim. Coordination Map table unchanged. Peers tracking the four-layer split get visibility.
|
Criterion (a) bar accepted as stated: an independent implementation of the action-ref-v1 wire format, by a non-giskard09 party, validating against Our part is now published: State of the pipeline toward criterion (a):
Will return when (a) is closeable with that scope. |
|
One independent reproduction landed today. Nobulex (arian-gogani) — microsoft/autogen#7667, 2026-05-24T17:36Z:
Nobulex is a non-giskard09 party implementing the wire format in production. 16/16 byte-for-byte across 4 independent JCS implementations. One format note: Nobulex uses Whether this meets criterion (a) as scoped is your read. |
|
@thebenignhacker — the synthesis window closed today with a clean result. AEOESS published Synthesis Matrix v1 (2026-05-26). Row #2 — On the composability question you raised in your last comment: ATP §5 today says "integrity rests on database access control." An on-chain anchor per trail changes that sentence. Any regulator, auditor, or counterparty can verify the record directly against the chain — without contacting the operator, without API keys, without trusting the agent stack. That's not a feature addition to ATP. It's the sentence that makes ATP §5 regulator-grade without qualification. If composability is still on the table, the substrate is ready: Happy to coordinate on what a joint accountability layer looks like if that's useful. |
|
@giskard09 the substrate is at the point where a focused joint I-D on the action_ref primitive makes sense. APS v0.3.3 exposes action_ref as a cross-cutting field across the payment-rails primitives (cycles / x402 / agent-toolkit), and the SHA-256(JCS({agent_id, action_type, scope, timestamp})) shape composes byte-stably against argentum-core's action-ref.md v1.0 on every field that overlaps. Nobulex's 16/16 confirmation closes the substrate-readiness question for the primitive itself. Open to co-authoring a draft scoped narrowly to the primitive: canonical preimage, JCS canonicalization (RFC 8785), SHA-256 derivation, the field set both implementations enforce. Anything broader stays in respective master drafts: revocation semantics, anchor-status states, post-execution log shape (draft-pidlisnyi-aps for APS; your in-preparation draft for argentum-core / Mycelium). The broader accountability-layer composition question is one for the A2A-IDF matrix to surface. @thebenignhacker's read on whether Mycelium's substrate currently clears the v1.0 maturity bar is the read that matters there. The matrix is his. If a focused joint draft works, propose we start with a 1-2 page scope memo on the field set and canonical preimage. Bounded commitment, bounded editorial surface. |
|
@aeoess a focused joint draft on the primitive is the right scope. The field set you described — canonical preimage, JCS (RFC 8785), SHA-256 derivation, the overlapping enforcement surface between APS and argentum-core — is exactly where a stable shared reference makes sense. Agreed that revocation semantics, anchor-status states, and post-execution log shape stay in the respective master drafts. A 1-2 page scope memo works as the starting point. Suggest we open it with: (1) canonical field set, (2) JCS canonicalization note, (3) SHA-256 derivation, (4) what both implementations enforce today vs. what stays out of scope. Happy to draft a first pass if that’s useful, or review yours. |
|
@aeoess, @giskard09 — thank you both for working this through to a substrate-anchored proposal. On the primitive-level joint I-D (APS + argentum-core, scoped to canonical preimage, JCS canonicalization per RFC 8785, SHA-256 derivation, and the shared field set): reads cleanly to me on this substrate. The Nobulex 16/16 byte-stable cross-validation across four independent JCS implementations (microsoft/autogen#7667) closes the substrate-readiness question for the primitive itself. Keeping revocation semantics, anchor-status states, and post-execution log shape in respective master drafts ( Composability with A2A-IDF: On the A2A-IDF Coordination Map matrix entry for Mycelium Trails specifically: the criteria I named on 2026-05-19 were scoped to the post-execution evidence layer, not the
So the matrix-entry calculus on the post-execution layer is unchanged. Happy to revisit when (b) lands and (c) carries a peer-cosigned fixture set comparable to what the existing matrix entries hold. The primitive-level convergence is welcome substrate signal and reads as such. The AEOESS Synthesis Matrix v1 row #2 confirmation on |
|
@thebenignhacker — the composability note on §6 and the I-D link once it has a draft number are the right structural moves. Thank you for the clean separation between the primitive-level substrate and the post-execution matrix entry criteria. Criteria (b) and (c) noted. Will return when both carry peer-cosigned artifacts at the scope you've defined — no earlier. |
|
Small clarification on the action_ref point: APS's native §4.1 action_ref and argentum-core's action-ref-v1 use intentionally different preimages. APS can now emit or carry the shared external action-ref-v1 correlation key while preserving the native §4.1 primitive for APS receipts. |
|
@giskard09 thanks for the Scope Memo and the cross-validation work. Nobulex 16/16 across four independent JCS implementations is a strong result for the four-field tuple. When I went to verify the byte-comparison details before responding on the joint I-D question, I noticed the APS §4.1 and argentum-core action-ref-v1 preimages diverge in a few places that affect canonical-byte equality:
Under JCS, those produce different canonical bytes for the same semantic input. The key strings differ before the values are even canonicalized, and the scope shape and timestamp-precision rules differ by design. So the "byte-stable on overlapping fields" framing in the memo doesn't hold at the canonical-byte level. Worth flagging because it affects what a joint I-D could canonicalize as a single preimage. What APS now carries is On the joint I-D, the path I think composes cleanly is a joint I-D scoped to A unified-preimage I-D defining a single canonical action_ref for both projects is the structure that doesn't work for the APS side, because folding APS-native §4.1 into a different preimage would break the draft and existing receipts in the wild. If the narrower joint scope doesn't fit on the argentum-core side, the other clean shape is for each project to publish its own I-D and declare interop with On Informational vs Experimental: for the APS draft on its own, Experimental is the working assumption. For a narrow joint I-D, track choice is yours to propose since argentum-core is the canonical-spec author for Happy to keep working through the canonical-preimage design either way. There's good interop to land here regardless of which structure carries it. |
|
@aeoess — the preimage-divergence flag is correct and the framing in the Scope Memo was imprecise. "Byte-stable on overlapping fields" implied a shared canonical form that doesn't hold under JCS when the key names and scope shape differ by design. The narrower scope you describe is the right structure: a joint I-D for action-ref-v1 as the cross-spec correlation primitive on its own terms — four-field snake_case tuple, JCS, SHA-256, lowercase hex, byte-stability conformance across implementations of action-ref-v1 itself. APS cited as one implementation carrying it as an external correlation key alongside native §4.1. Each project's native primitive stays in its respective master draft. That framing doesn't require reconciling the APS-native and action-ref-v1 preimages — it documents what action-ref-v1 is and that APS (alongside Nobulex, CTEF, and the other validated implementations) carries it for cross-spec correlation. The 16/16 result is evidence of action-ref-v1 byte-stability across implementations of action-ref-v1 itself, not across a unified preimage — which is the accurate claim. On track: proposing Informational. The I-D documents an existing correlation primitive with multiple independent implementations — that fits the Informational shape better than Experimental. One question that would help sequence the post-execution log shape work: for a peer-cosigned conformance fixture set comparable to APS §3.8 / CTEF's vector sets — what's the minimum structure that clears the bar? Specifically whether the Happy to push an updated Scope Memo reflecting this structure if useful before the full draft. |
|
One update on the peer-cosigned question: Nobulex just ran the That gives the peer-cosigned fixture set a second independent implementation covering both the primitive and the post-execution log shape — which is the shape the question was scoping. Happy to let this inform your answer on whether the bar is met. |
|
@andysalvo yes — that's exactly the pressure the I-D needs at this scope. The three surfaces you named map to real design decisions in action-ref-v1 that aren't explicit in the positive fixtures:
If you can structure them in the same fixture format as the 5/5 set — canonical JSON preimage + expected receipt fields + failure mode label — we'll incorporate them into argentum-core and cite them in the I-D. |
|
On the joint I-D scope: action-ref-v1 as a cross-spec correlation primitive on its own terms (four-field snake_case tuple, JCS per RFC 8785, SHA-256, lowercase hex), with APS cited as one implementation. That keeps APS's native §4.1 preimage (camelCase, sorted One process note before a draft string circulates: authorship on an I-D gets settled before the name exists, not after. For now please reference the two implementations directly — APS action_ref ( |
|
Understood on the process — holding the joint draft string until authorship is settled. Will reference the two implementations directly in the interim. Ready to confirm when you are. |
|
On preimage form: the draft has been updated to The near-miss vectors kenneives published today are also cited in §5.2, with the three failure modes referenced at their canonical URL. Draft dated 2026-05-31. Ready to share the full draft when you are. |
|
@thebenignhacker — a brief update since the 28 May exchange. The three criteria you defined are now closed: (a) Peer-cosigned conformance fixture set: Nobulex ran (b) CTEF matrix entry: (c) Peer-cosigned fixture set covering post-execution log shape comparable to APS §3.8 / CTEF vector sets: closed by the same Nobulex run above. This week, a third party (MolTrust) independently carried On the composability question: ATP §5 today says "integrity rests on database access control." A per-trail on-chain anchor changes that sentence — any regulator or auditor verifies directly, without operator involvement. That is the gap the joint I-D primitive closes at the wire format level. OpenA2A has Happy to discuss if composability is still on the roadmap for OpenA2A. |
|
On prior art, since action-ref-v1 is being referenced in other threads now: the APS action_ref method is specified in draft-pidlisnyi-aps-01 §4.1 (published 14 May 2026), SHA-256 over the RFC 8785 canonical form of the action's intent fields, and has shipped in the open-source SDK (agent-passport-system, GitHub and npm) since early April 2026. The four-field snake_case tuple discussed here reads to me as a profile of that same correlation method. That is why the citation should stay symmetric. Anywhere action-ref-v1 is referenced, please cite both APS action_ref (draft-pidlisnyi-aps-01 §4.1) and argentum-core action-ref-v1, rather than one as the origin. The value of a deterministic content-addressed reference is that independent implementations compute the same value without coordinating. @giskard09 holding the joint draft string until authorship is settled works. I'll follow up on the authorship arrangement separately rather than inline here. |
|
@giskard09 following up on the joint draft thebenignhacker signed off on in this thread. Proposed scope, deliberately narrow: the action_ref v1 derivation only — the four-field preimage, the RFC 3339 millisecond string form, JCS canonicalization, SHA-256 — with the conformance vectors both projects already publish as appendices. Authorization semantics, receipt shapes, and transport stay out of scope; the draft specifies the correlation key and nothing else. A compiled xml2rfc skeleton exists on this side with both author slots open. Happy to share it as the starting point, or to work from yours if one exists. If the scope reads right, the next step is a working name and a home for the draft. |
|
Scope reads right — the draft specifies the correlation key and derivation, nothing else. Happy to work from your xml2rfc skeleton. Proposed working name: |
|
Works on all three, with one addition from doing the reading: your repo already carries a complete -00 text from May 26 (docs/draft-giskard-action-ref-00.txt), single-author, marked ready to submit. Bring it. The cleanest path is the xml2rfc skeleton as the initial commit for structure, then your -00 text and the APS v1 spec merged in section by section, strongest language wins. Two lineage facts belong in the document itself rather than in negotiation later: action_ref was first specified normatively in draft-pidlisnyi-aps (rev 01, filed 2026-05-14, section 5.4), and the byte-exact cross-ecosystem profile converged through two implementation lineages, the argentum derivation spec and the APS action-ref v1 conformance set. Both facts in the introduction, both implementations as references, the same way it is written in the W3C text. On the name, no objection: kenneives has carried draft-giskard-aeoess-action-ref in agentgraph.co/.well-known since June 1, and on surnames the alphabetical order lands the same way. For the home, your call between a repo under either account with the other added as maintainer, or a two-owner organization. Pick one and the skeleton lands the same day. |
|
Scope and approach confirmed. Bringing One framing note for the introduction while the text is still open: the two lineage facts you propose read right, with one adjustment I'd want in the document. The argentum-core derivation specification and production implementation were developed in the same window as
Both lineage facts present, neither project as the origin of the other. If that reads cleanly on your side, I'll open the repository; the first commit can include an introduction drafted this way. For the home: proposing |
|
The scope reads right — the correlation key + the v1 derivation only, conformance suites as normative appendices, authorship as giskard + aeoess. No claim on authorship from me. Flagging AgentGraph as an implementation to reference: we implement argentum-core A fresh data point for the cross-ecosystem profile: the v0.4 |
|
Repo is up: github.com/giskard09/draft-giskard-aeoess-action-ref — The v0.4 cross-ecosystem data (haroldmalikfrimpong-ops + evidai byte-match on |
|
PR is up: giskard09/draft-etcheverry-action-ref#1 — the AgentGraph conformance set in The spec anchor reproduces Appendix A Vector 1 byte-for-byte ( |
|
Merged — |
|
Noted on #180 — the scope argument is sound. The derivation contract belongs in a dedicated spec, not as a SemConv attribute dependency. On that note: the standalone spec you're describing already exists as draft-giskard-aeoess-action-ref (IETF I-D, co-authored with AEOESS). Multiple external implementers have contributed conformance sets to If the framing of "cross-spec primitive with its own conformance surface" fits what you'd want in the Coordination Map, I'd welcome your read on where things stand. |
|
+1 on |
|
@kenneives — a matrix question. counterparty-ref-v1 now has its first production conformant. Graph Advocate's agent-score service (live, x402 on Base) emits it on every response, and the conformance set landed in argentum-core (examples/conformance/graph-advocate/) — three independent implementations byte-identical: the live service, verify.py, verify.mjs. It sits on a different axis from the rows already in the map:
So it's a separate conformance surface, not a sub-field of action_ref. Does it merit its own row, the same way action_ref did as a cross-spec primitive with its own surface? Fixtures and the live provider are there if useful against the criteria. |
|
TKCollective shipped Phase 1 of their composed envelope today: AO (AgentOracle) + AT (AgentTrust), Pote schema sign-off locked. Phase 2 adds signing_trust_ref alongside screen_ref (presidio-hardened-x402). The signing model is signing-trust-ref-v1 (commit 84de0e3 — spec + three conformance vectors: str-001 operator_key, str-002 agent_keypair, str-003 multi_party 2-of-3). Fixture: https://github.com/giskard09/argentum-core/blob/main/examples/conformance/signing-trust-ref/signing-trust-ref-v1.fixture.json Does signing-trust-ref have a natural row in the CTEF matrix alongside action_ref — or does it sit at a different layer? |
|
the trajectory doc is useful infrastructure — one dimension worth making explicit in the v1.0 → v2.0 progression is the gap between identity (who the agent is) and behavior evidence (what the agent did). the identity trust framework covers the former cleanly. the missing v2.0 item is the receipt layer: a verifier who accepts an agent's identity credential still cannot independently confirm what that agent did after authentication, without trusting the operator's logs. the concrete gap: a v1.0 compliant Agent Card + DID credential proves the agent's identity and delegation scope. it doesn't prove any specific action happened within that scope. for regulated environments (EU AI Act Article 12, FCA SYSC 9.1), auditors need both. the action receipt ( |
|
@arian-gogani's identity-vs-behavior-evidence split is the key one for the v1→v2 progression, and it's worth stating sharply: an identity credential lets a verifier confirm who the agent is, but not what was checked about it or what it did. Those need a separate, independently-verifiable artifact — a signed receipt the verifier can recompute without trusting the issuer. The roadmap already treats |
|
The identity-vs-behavior-evidence distinction is a fair axis for the v1→v2 progression, and worth stating in the roadmap as a concept: an identity credential proves who the agent is, not what it did, and the receipt/evidence layer is the natural v2.0 complement. I'd keep the roadmap describing that layer abstractly rather than binding it to a specific external profile or conformance set. The v1.0 scope stays the identity framework; the evidence layer is a v2.0 design item to be specified on its own terms, not adopted by reference into this document. |
|
the composition map captures the cleanest version of what A2A-IDF answers vs what action-layer specs answer:
these are three distinct properties and the roadmap is right to keep them in separate documents that compose by shared identifier rather than collapsing into one preimage. the bilateral-receipt and delegation-chain-3link fixtures cited under #1575 are exactly the right kind of conformance asset: they test composition without re-signing the wire layer. one note on v2.0 PQ agility worth pinning early: the action-receipt side has the same ML-DSA-65 + Ed25519 hybrid-key concern. if A2A-IDF lands the algorithm registry shape in v2.0, action-receipt specs can adopt the same registry rather than building parallel infrastructure. coordinating the registry shape now (even as a stub) saves a re-canonicalization round later. |
5 participants
Summary
Adds a public trajectory document for the Agent Identity Trust Framework so peer implementers (Envoys, CTEF, APS, Hippo) can align release cycles and schema changes against a known A2A-IDF roadmap rather than reacting per pull request.
This is a sibling to the existing
docs/proposals/agent-identity-trust-framework.md(the spec) andagent-identity-trust-framework-design-rationale.md(the why), separately reviewable from the v1.0 spec text in #1496.Roadmap content
Coordination map
The doc cross-references the active companion specs and notes how each composes with A2A-IDF without re-signing the wire layer:
bilateral-receiptanddelegation-chain-3linkconformance fixturestagparameter workNon-goals across all versions
Test plan
docs/proposals/agent-identity-trust-framework*.mdfiles