On May 18, 2026, at 9:27 PM, Paola Di Maio <paola.dimaio@gmail.com> wrote:
Ben and Erik,thanks for keeping everyone in the loop, could you perhaps clarify the overlap/convergence of this effort with parallel IETF draft specs as I may be losing trackFor me it is important to understand whether contributions made through W3C end up in IETF *with attribution is OK of courseThank youBestPDMOn Tue, May 19, 2026 at 11:15 AM Ben Stone <swarmsync@gmail.com> wrote:Thanks, Erik — this framing makes sense to me.I’ll comment directly on the GitHub issues where the original draft-stone-aivs-00 design intent is most relevant, especially around the self-verifiable bundle model, AIVS-Micro, verify.py behavior, conformance tiers, and the relationship between the core offline proof format and optional higher-assurance layers like SCITT.I agree that the CG should treat both inputs as material for discussion rather than as fixed drafts. My main goal is to preserve the core AIVS property that made the original draft useful: a portable proof bundle that can be verified offline without depending on a service, while still allowing stronger profiles for signatures, transparency registration, and attestation.BenOn May 18, 2026, at 8:31 AM, Erik Newton <eriknewton@gmail.com> wrote:Welcome, Jinghan, and thank you for the strawman input.Filing the open design questions as scoped GitHub issues is exactly the async-review-then-meeting-lock shape this CG needs ahead of the first meeting. Members: please comment directly on the eight open issues at https://github.com/swarmsync-ai/aivs-spec/issues so the meeting can focus on resolution rather than rediscovery.One framing note for the group. Jinghan's strawman is one input draft, not the editor's draft; editorship and authorship are for the CG to agree. The relationship to Ben Stone's draft-stone-aivs-00 holds the same way: Ben's I-D is the problem-framing input on the IETF side, Jinghan's strawman is a wire-format input on the W3C side, and the CG decides what to fold, replace, or carry forward. Both inputs are welcome and neither is privileged.Substantively, the SCITT-registration-profile question (issue #14) overlaps directly with prior art the group should look at as part of the discussion: the Concordia session-receipt schema (https://github.com/eriknewton/Concordia, v0.6 cut shipped to PyPI 2026-05-17) and the Sanctuary attestation envelope (https://github.com/eriknewton/sanctuary-framework, v1.3.0-rc.2 published 2026-05-17). Both are public, both have receipt structures that compose cleanly with the AIVS-Micro size target (issue #15), and both are open to AIVS profile alignment if the CG decides to define one. I will write that up as a comment on issues #14 and #15 over the next few days so the group has concrete prior-art pointers to react to.I will also fold Jinghan's availability slots (May 23 03:00 UTC, May 27 03:00 UTC) into the consolidated availability tally for the first-meeting scheduling. That tally will go out as a separate message on the list once a few more replies arrive.ErikCo-chair, AIVS CGErik NewtonOn Sun, May 17, 2026 at 11:33 AM, 张靖瀚 <zhangjinghan1122@bupt.edu.cn> wrote:Hi Erik and all,As discussed on the list, I have prepared an input strawman for AIVS v1.0 to support the group's discussion ahead of and during the first meeting. It is explicitly contributed as a starting point, not as a pre-decided editor's draft — editorship and authorship are for the group to agree.The draft builds on the problem framing in Ben Stone's draft-stone-aivs-00 and proposes a concrete wire format (hash chain + Ed25519 + manifest + AIVS-Micro).To make review easier both before and during the meeting, I have:Filed the open design questions as individual GitHub issues (linked below), each scoped so members can comment in parallel.Marked the strawman's most uncertain sections with "OPEN-ISSUE" anchors that point back to those issues.Committed to circulating a revision summary within one week after the meeting, incorporating whatever the group decides — whether discussed live or in writing.Draft PR:Open design issues for async review:[#10] Hash input canonicalization: length-prefix vs JCS —[#11] Should input/output content be bound to row_hash? —[#12] Action type registry — initial seed values and registration policy —[#13] verify.py interface contract —[#14] Relationship to SCITT — should AIVS define a registration profile? —[#15] AIVS-Micro use cases — is ~200 bytes the right size target? —[#16] TEE attestation — SGX-only or generalized profile? —[#17] Conformance levels — should AIVS define tiered profiles? —Please feel free to comment directly on the issues, in this thread, or on a PR against the draft. I will track everything and reconcile it in the next revision.Best,JinghanErik Newton <eriknewton@gmail.com> 在 Fri,May 8,2026 4:50 AM写道:Welcome, Jinghan. Glad to have you on the list.Yes, please draft the five-section repository structure ahead of the first meeting. Members can review and comment async, and we lock the structure at the meeting once we have quorum.Noting your availability slots (May 23 03:00 UTC and May 27 03:00 UTC). I will fold them into the consolidated availability tally and post the candidate meeting times once a few more replies arrive.ErikErik NewtonOn Tue, May 05, 2026 at 10:26 PM, 张靖瀚 <zhangjinghan1122@bupt.edu.cn> wrote:Hi Erik, Ben, and AIVS Community Group members,Thank you to both chairs for starting this discussion.My name is Jinghan Zhang, and I am a senior undergraduate student at BeijingUniversity of Posts and Telecommunications (BUPT). My research interests are mainlyin trusted AI agent systems, including applied cryptography and verifiabilitymechanisms, decentralized infrastructure, agent interaction protocols, and agentreputation and auditability.What especially interests me about AIVS is the verification layer. Withoutportable, self-verifiable, and tamper-evident proofs of agent sessions and actions,the upper layers of identity, reputation, and compliance can easily fall back tovendor-attested claims. I am also interested in how this kind of specification canremain strongly verifiable while still being practical to adopt across existingagent frameworks and implementation paths.For the first meeting, I am currently available at:May 23, 03:00 UTCMay 27, 03:00 UTCIf needed, I will also do my best to accommodate nearby times.If useful to the group, I would also be happy to continue contributing todiscussions around repository structure, document collaboration, and earlywork-item organization.I look forward to working with everyone on this effort.Best regards,Jinghan ZhangErik Newton <eriknewton@gmail.com> 在 Tue,May 5,2026 2:41 AM写道:Hi all,
Welcome to the Agentic Integrity Verification Specification (AIVS) Community Group. Ben Stone and I are the designated co-chairs, and this is our official kickoff note. The CG was chartered on April 5 with 8 participants (we're up to 10 now) — thank you to the founding proposers (Ben Stone, Ruoxi Ran, Robert Douglas Muncaster, Khushboo Parmar, and Erik Delgado) for getting us here.
It's been about a month since we launched, and Ben and I want to schedule our first working meeting before momentum slips.The charter we drafted in March points at a real and increasingly important problem space: portable, self-verifiable cryptographic proof of agent sessions, with EU AI Act Article 19, ISO/IEC 42001, and NIST AI RMF as the regulatory tailwinds. The agent stack is wiring itself together fast around us, and the verification layer is one of the seams where standards work matters most. We should not let it slip while everyone else moves.
I'd like to propose a first meeting in the window of May 22 through June 12, 2026. Sixty minutes, via video. The agenda would be deliberately open and collaborative:
Confirm scope. Are we still aligned on what AIVS v1..0 should look like, or has our shared understanding shifted since March? If it has, that is healthy, and we should re-anchor.
Surface existing aligned work in the problem space. The AIVS v1.0 starting-point spec is one anchor. Members are likely tracking or contributing to other open-source efforts in the same neighborhood; a brief tour from anyone who wants to share is welcome.
Identify our first work item or items together. Member-driven. The chairs facilitate; members drive.
Establish a regular meeting cadence. Monthly is the typical CG default; we can adjust.
Two asks before the first meeting:
- Introduce yourself on this thread — name, organization, and what aspects of verifiable signals for AI agents interest you most.
- Please reply with your availability in May 22 through June 12, 2026 window. I will consolidate responses and send a final time once we have quorum.
If anyone has work-item suggestions they would like circulated before the meeting so members can review in advance, send them to the public list and I will batch them into a pre-meeting digest.
Looking forward to getting started.
Best,Erik NewtonCo-chair, AIVS Community GroupErik Newton