SCITT Working Group — IETF 126 Minutes

Meeting: IETF 126, Vienna
Date: Friday, 24 July 2026
Time: 09:00 local
Chairs: Nicole Bates, Jon Geater
Minutes taker: No note taker was assigned during the session. These minutes were
reconstructed after the meeting from the recording, official slides, chat log, and
poll record. Names and document numbers were normalized against the official agenda
and slides.
Note Well: Presented by the chairs at the start of the session. Session recorded;
remote participants asked to state their name before speaking and to use the Meetecho queue.

Agenda

1. Introduction and administrivia — Chairs
2. Core specifications update — Henk Birkholz
3. CCF VDS profile and joint-statements extension — Amaury Chamayou
4. MMR profile call for adoption — Jon Geater
5. Hackathon report — Steven Mih
6. New use cases — Anton Sokolov, Evangelos Haleplidis, Gregor Bransky
7. Future of the Working Group — Chairs

Because Henk Birkholz was delayed at the start, the chairs moved Amaury Chamayou's
presentation ahead of the core-specification update. These minutes follow the order
as presented.

1. Introduction — Chairs

Nicole Bates opened the session with the Note Well, recording notice, and hybrid-participation
instructions, and reviewed the agenda. Jon Geater asked presenters to keep to time and
noted the chairs would curate the queue if needed.

2. CCF Profile and Joint Statements — Amaury Chamayou (Microsoft)

CCF VDS profile

Amaury summarized the CCF Verifiable Data Structure (VDS) profile, now awaiting IESG review.
CCF cannot simply reuse the RFC 9162 tree profile because each CCF leaf binds three elements:

• the registered statement's data hash (as in RFC 9162);
• an internal transaction hash covering CCF governance and hardware-attestation operations,
  bound together with the data so that a full audit of every ledger operation is possible; and
• internal evidence, which permits early durable persistence of signatures (important for a
  distributed system that must not lose or fork log entries) while a commitment mechanism
  prevents a node from issuing an apparently final receipt before consensus has completed.

The commitment technique (reveal-after-commit) avoids the cost of a double signature or
re-encryption. The resulting COSE Receipt is structurally familiar; only the VDS identifier
and proof reconstruction differ. Verification was deliberately simplified (e.g., boolean
direction bits so the verifier need not perform size calculations).

Joint statements (multi-issuer) extension

Developed with Yogesh Deshpande, this is a strict extension of RFC 9943 for multi-issuer
"joint statements." This work is separate from the CCF VDS profile and follows its own
draft and review track:

• a single issuer continues to use COSE_Sign1;
• multiple independent issuers may use COSE_Sign;
• the Transparency Service verifies every signature and applies its registration policy
  separately to each issuer;
• receipt format and existing implementations are unchanged;
• registration commits to the encoded ordering of the signatures, so later reordering
  invalidates the transparency proof.

Discussion

• Henk Birkholz asked whether this was a crypto-resilience proposal; Amaury clarified it
  concerns multiple issuers.
• A Telefónica participant asked whether independently timed signatures required COSE
  countersignatures. Amaury explained that COSE_Sign still allows signatures to be added
  incrementally — each participant signs the common payload, whereas countersignatures sign
  another signature. They agreed to compare their differing data models offline.
• David Rogers and Carsten Bormann volunteered to review the draft. Carsten offered the same
  cross-validation approach applied to RFC 9942, and Amaury noted the draft would also
  exercise his new cross-document validation tooling.

3. Core Specifications — Henk Birkholz

Henk reported the following published:

• RFC 9943 — SCITT Architecture
• RFC 9942 — COSE Receipts
• RFC 9995 — COSE Hash Envelope

Five non-normative EDN examples in RFC 9943 contain invalid syntax (principally unquoted
strings and incorrect null notation). Henk committed to submitting an erratum within
14 days. In chat, Orie Steele noted the lesson that EDN examples should be validated in CI.

SCRAPI (the HTTP registration and receipt-resolution API) has cleared IESG review and
entered the RFC Editor queue. One notable review outcome was returning to 2xx responses for
operations still in progress.

Henk characterized COSE Receipts as SCITT's principal interoperability boundary: services
may use different internal Verifiable Data Structures while returning a common receipt
envelope. RFC 9995 fills the gap for detached resources by binding an explicit digest,
location, and media type rather than requiring the payload inside COSE.

No substantive microphone questions followed.

4. MMR Profile — Call for Adoption — Jon Geater (on behalf of Robin Bryce)

Speaking without his chair hat, Jon asked SCITT to formally "rehome" the Merkle Mountain
Range (MMR) COSE Receipt profile, originally presented to the COSE WG alongside the CCF
profile. MMRs provide fast, conflict-free appends, natural ordering, simple auditor
replication, and flexible storage or pruning without specialized hardware, while still
supporting inclusion and consistency proofs. They are especially suitable for high-throughput
distributed writers.

The forthcoming -03 draft is functionally complete, aligned with the CCF profile and the
SCITT architecture, and backed by two complete independent implementations plus several
additional implementations. The main unresolved technical issue is cryptographic agility
beyond the current hash algorithm.

Discussion

No objections were raised. Henk called it an excellent optimization and strongly supported
adoption. Carsten Bormann, Amaury Chamayou, Alistair Woodman, and Henk Birkholz volunteered
to review.

Poll

• Question: "Do you agree to review the MMR draft?"
• Result (in-room): 4 yes, 0 no, 3 no opinion (34 present).
• Scope: This measured willingness to review, not formal adoption consensus.
• Next step: Chairs said the adoption process would continue on the mailing list.

5. Hackathon Report — Steven Mih

Steven reported interoperability work among seven independent parties and four codebases,
including byte/digest agreement and composable evidence. One test registered a
COSE_Sign1 statement with two different Transparency Services — a CCF service and an
RFC 9162 log — and independently verified both resulting receipt profiles.

The proposed output was a canonical, payload-neutral binding profile for signed statements,
derived from Agent Action Capsule work but excluding agent semantics. A JSON record
declares a canonicalization suite and payload digest, is signed with COSE_Sign1, and is
made transparent using RFC 9942 receipts. Steven argued that teams repeatedly reimplement
this plumbing and that standardizing it would let them compete at the semantic layer.

Concrete interoperability defects found:

• evidence references must be digest-pinned rather than trusted by name;
• the VDS identifier must come from the protected header;
• implementations diverged between ad-hoc sorted JSON and JCS;
• CCF registration policy exposed gaps around Ed25519, did:x509, and issuer binding.

Discussion

Henk praised the proposal as an excellent intermediate step but raised a concern: SCITT has become a versatile payload-opaque "sidecar," while its charter promised practical help to software-supply-chain consumers. He said the WG still cannot readily answer a stakeholder asking how to obtain and use a trustworthy SBOM. Steven considered the binding work in charter but agreed the broader boundary belonged in the final discussion. Jon, Henk, and Alistair volunteered to review the forthcoming draft.

6. New Use Cases

6.1 Composed appraisal without trust laundering — Anton Sokolov

Anton distinguished a valid SCITT history record from valid current platform evidence. A
SCITT receipt can prove that an exact action record was registered, while a RATS appraisal
may separately fail (e.g., due to a stale nonce). A matching digest is only a join key, not
inherited trust. A composed claim therefore requires both legs to succeed; otherwise the
verifier should preserve the valid historical record, deny the platform-backed claim, and
report which appraisal failed. His broader question: should SCITT own the "interoperable evidence seam"
(registration-policy conventions, portable receipts, digest-bound composition) while leaving
agent delegation and domain semantics elsewhere? Nicole asked whether this composition work
was in Steven and Anton's draft; Steven said the initial draft covered only the payload-neutral
SCITT side, so the chairs deferred rechartering questions to the final agenda item.

6.2 AI Model Bill of Materials — Evangelos Haleplidis

The EU CoEvolution project is developing an AI MBOM spanning provenance, model ownership and
dependencies, ethical/legal compliance, risk assessments, defenses, and robustness testing
across the model lifecycle. Its current representation is a linked collection of CycloneDX BOM
documents. Evangelos proposed making each document a signed SCITT statement registered with a
Transparency Service, allowing the aggregate MBOM to serve as verifiable credentials for an AI
model. No substantive audience questions followed.

6.3 Compliance-critical supply-chain communication — Gregor Bransky

Gregor connected SCITT to the CRA, EO 14028, NIST SSDF, SEC cyber-disclosure rules, SLSA, and
related initiatives, proposing decentralized, globally interoperable communication among
open-source projects, downstream manufacturers, and market-surveillance authorities. Ideas
included repository "standards badges," authenticated authority communications, signed hashes
of security messages, and identifiers linking downstream stakeholders to upstream projects. He
placed security/privacy guardrails and technical applicability in scope while excluding
interference with FOSS governance or business models. Ben Curtis asked whether Gregor was
coordinating with Linux Foundation efforts already serving kernel developers and offered an
introduction; Gregor said related discussions were underway through the ORC / code-and-compliance
community.

7. Future of the Working Group — Chairs

Jon framed three options:

1. Finish the remaining profiles and maintenance, then wind down.
2. Recharter to include new domains such as hardware, AI, and broader supply-chain evidence.
3. Keep the charter but curate application conventions and related payload work so users can
   discover interoperable ways to apply SCITT.

Discussion

• Anton Sokolov favored option 3 immediately as a low-cost landing place whose results
  could later provide evidence for rechartering.
• Carsten Bormann argued all three were partly true: core maintenance remained, use-case
  work was valuable, and existing mechanisms — especially IANA media types — should be reused
  rather than creating a new registry. He warned that a "profile" can become an interoperability
  preventer.
• Orie Steele warned that SCITT had created substantial optionality: additional profiles or
  media types do not automatically create ecosystems in which multiple issuers and verifiers
  interoperate. He characterized the delivered technology as generic, Certificate-Transparency-style
  cryptography for arbitrary digital formats, while the charter's software-specific promise
  remained largely unaddressed.
• Amaury Chamayou responded that the VDS "profiles" were better described as algorithms;
  multiple algorithms do not necessarily fragment interoperability because statements and
  receipts retain common envelopes, and verifiers already support several. Payload profiles are
  a harder proposition because they carry application semantics.
• Henk Birkholz argued the WG was not done: it should not define SBOM formats, but neither
  should it keep treating them as meaningless opaque blobs. Rechartering or new milestones might
  be needed to connect SCITT practically to existing SBOM and AI-BOM ecosystems.
• David Rogers cautioned that following every software, hardware, firmware, and AI BOM
  format would become unmanageable; the WG should remain format-agnostic and perhaps collect
  examples instead. Henk replied that a useful middle ground was required.
• Orie Steele suggested that the WG's problem statement itself may be the problem — i.e.,
  the difficulty may lie less in the technology delivered than in how the charter frames the
  problem to be solved.

Chairs' proposed landing

Summarizing the comments, the outcome of the vote, and the hard boundaries of the charter —
including Orie Steele's observation that the problem statement itself may be the problem — Jon
Geater proposed that the WG can carry on and accept these use cases in. The constraint this
imposes is that the use cases must be split out (as already presented in today's presentations)
and must not include aspects that are not strictly software supply chain. The benefit is that
the WG avoids a large amount of administrative work while establishing the application-layer
interoperability conventions that several participants noted are currently missing.

Jon clarified what makes this direction different from prior work: it means going into the
payloads. The WG would begin defining what comes out of a verification — something it has not
previously done. This is explicitly layered on top of the architecture's opaque payloads,
allowing the WG to be more helpful at the application layer without changing the underlying
transparency substrate.

Poll

• Question: "Do we believe this work on application-level interop belongs in the SCITT WG?"
• Result (in-room): 11 yes, 6 no, 5 no opinion (36 present).
• Clarification request: Steven Mih and Carsten Bormann said the question was ambiguous and requested clarification or another vote.
• Chair summary: Jon acknowledged the ambiguity and said the result suggested interest in cautiously documenting conventions above SCITT's opaque-payload layer, without the WG taking ownership of each application domain.
• Scope: The result indicated direction, not strong consensus.

The meeting ended without a rechartering decision.

Action Items and Next Steps

• Henk Birkholz: submit an erratum for the five invalid non-normative EDN examples in
  RFC 9943 (within 14 days).
• Chairs: send Monday mailing-list traffic including formal review calls, reminders to
  named volunteers, and an MMR profile adoption call.
• MMR profile reviewers: Carsten Bormann, Amaury Chamayou, Alistair Woodman, Henk Birkholz.
• Joint-statements extension reviewers: David Rogers, Carsten Bormann.
• CCF VDS profile track: continues on its separate IESG review path.
• Hackathon binding-profile reviewers: Jon Geater, Henk Birkholz, Alistair Woodman.
• Chairs / WG: once the Hackathon draft is published, decide between adoption and a focused
  design / tiger-team process.
• WG participants: consider adding CI validation of EDN examples for future documents.

Closing note (Orie Steele): future work and any new charter should identify specific
building blocks backed by demonstrated interoperability needs, rather than granting an
open-ended mandate to create them.

Sources

• Generated transcript
• Official slides
• Chat log
• Poll record
• Recording