Re: [aivs] Kickoff and first meeting

PDM,

Two parts to it.

On venue overlap: W3C AIVS (Jinghan Zhang at swarmsync-ai/aivs-spec) and
Ben's IETF draft are parallel tracks working similar shape problems. I
don't know if they're formally coordinated; Ben can speak to the IETF side.
My read from the substrate side is that the signing primitives compose
either way, so contributions land usefully in both venues regardless of
formal alignment.

On attribution: both W3C and IETF preserve contributor lineage as a matter
of process, and cross-venue informative references are standard.
Self-attributing contributions (signing your name on the issue or PR) is
the simplest way to make sure lineage carries through.

Concordia v0.6.0 receipt schema and Sanctuary's attestation envelope are
open-source and available to both venues. I commented on W3C issues #14
(SCITT registration profile) and #15 (AIVS-Micro size target) earlier this
week to put the substrate work on record. Happy to coordinate if AIVS wants
a venue-mapping sketch.

— Erik


Erik Newton



On Mon, May 18, 2026 at 8: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 track
> For me it is important to understand whether contributions made through
> W3C end up in IETF *with attribution is OK of course
> Thank you
> Best
> PDM
>
>
> On 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.
>
> Ben
>
> On 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.
>
> Erik
> Co-chair, AIVS CG
>
>
> Erik Newton
>
>
>
> On 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: https://github.com/swarmsync-ai/aivs-spec/pull/1
> Open design issues for async review:
> [#10] Hash input canonicalization: length-prefix vs JCS —
> https://github.com/swarmsync-ai/aivs-spec/issues/10
> [#11] Should input/output content be bound to row_hash? —
> https://github.com/swarmsync-ai/aivs-spec/issues/11
> [#12] Action type registry — initial seed values and registration policy —
> https://github.com/swarmsync-ai/aivs-spec/issues/12
> [#13] verify.py interface contract —
> https://github.com/swarmsync-ai/aivs-spec/issues/13
> [#14] Relationship to SCITT — should AIVS define a registration profile? —
> https://github.com/swarmsync-ai/aivs-spec/issues/14
> [#15] AIVS-Micro use cases — is ~200 bytes the right size target? —
> https://github.com/swarmsync-ai/aivs-spec/issues/15
> [#16] TEE attestation — SGX-only or generalized profile? —
> https://github.com/swarmsync-ai/aivs-spec/issues/16
> [#17] Conformance levels — should AIVS define tiered profiles? —
> https://github.com/swarmsync-ai/aivs-spec/issues/17
> 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,
> Jinghan
>
>
> ----------回复的邮件信息----------
> Erik 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.
>
> Erik
>
>
> Erik Newton
>
>
>
> On 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
> Beijing
>   University of Posts and Telecommunications (BUPT). My research interests
> are mainly
>    in trusted AI agent systems, including applied cryptography and
> verifiability
>   mechanisms, decentralized infrastructure, agent interaction protocols,
> and agent
>   reputation and auditability.
>
>
>   What especially interests me about AIVS is the verification layer.
> Without
>   portable, self-verifiable, and tamper-evident proofs of agent sessions
> and actions,
>    the upper layers of identity, reputation, and compliance can easily
> fall back to
>   vendor-attested claims. I am also interested in how this kind of
> specification can
>   remain strongly verifiable while still being practical to adopt across
> existing
>   agent frameworks and implementation paths.
>
>   For the first meeting, I am currently available at:
>
>    May 23, 03:00 UTC
>    May 27, 03:00 UTC
>
>
>   If needed, I will also do my best to accommodate nearby times.
>
>
>
>   If useful to the group, I would also be happy to continue contributing
> to
>   discussions around repository structure, document collaboration, and
> early
>   work-item organization.
>
>
>
>   I look forward to working with everyone on this effort.
>
>
>   Best regards,
>
>   Jinghan Zhang
>
>
> ----------回复的邮件信息----------
> Erik 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:
>
>    1.
>
>    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.
>    2.
>
>    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.
>    3.
>
>    Identify our first work item or items together. Member-driven. The
>    chairs facilitate; members drive.
>    4.
>
>    Establish a regular meeting cadence. Monthly is the typical CG
>    default; we can adjust.
>
> Two asks before the first meeting:
>
>    1. Introduce yourself on this thread — name, organization, and what
>    aspects of verifiable signals for AI agents interest you most.
>    2. 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 Newton
> Co-chair, AIVS Community Group
>
>
>
>
> Erik Newton
>
>