Session Date/Time: 31 Jul 2023 15:00

SCITT

Summary

This meeting served as a post-IETF reflections call, summarizing key discussions and outcomes from the recent IETF meeting and hackathon. Significant progress was noted on the hackathon's FDA use case. Key topics included the need to align the SCITT emulator with the specification, the decision to separate the API definition into a new document ("Scrappy"), discussions around identity and multi-region receipts, reflections on a side meeting about Gordian Envelopes and KeyTrans, and an extensive discussion on "trust labels" and QR codes. Action items were identified for advancing the API specification, implementing feeds, and collaboratively drafting a document on QR code use cases.

Key Discussion Points

IETF Meeting and Hackathon Reflections: Participants expressed overall satisfaction with the IETF meeting and hackathon. The hackathon successfully developed an FDA use case, providing valuable learning experiences.
SCITT Emulator and Specification Alignment: The current SCITT emulator was noted to use outdated terminology and requires alignment with the evolving specification. John indicated he is maintaining it and plans to update it in parallel with the new API specification to ensure it mirrors and tests the specification.
API Document Split (Scrappy): A decision was made to split the "candidate API" section from the architecture document into a new, independent work product, tentatively named "Scrappy." This new document will allow for more focused development, including detailing expected error codes and API correctness. Hank confirmed a draft of this document already exists and could see an initial submission soon.
Identity and Submission Documents: Ray highlighted the need to explore how identity is incorporated into the core SCITT architecture, suggesting he would develop a submission document for an election application similar to Dick's vendor submission file, with a focus on separating the identity component.
Multi-Region Receipts: A new scenario emerged concerning physical supply chains in nationalistic mechanisms, suggesting a potential need for a mechanism to handle more than one receipt from different SCITT instances across global regions. Dick plans to start a mailing list thread to discuss this.
Gordian Envelopes Side Meeting: A side meeting discussed integrating privacy and collective disclosure mechanisms using CBOR-native structures. The authors were seeking to embed strong privacy protections, which was viewed as potentially outside SCITT's core focus on notarization. Participants suggested modularizing their approach and providing a clear rationale for specific deterministic CBOR structures. Hank and Kirsten will distribute a summary of this unofficial meeting.
Key Transparency (KeyTrans): The KeyTrans Birds of a Feather (BoF) meeting was canceled due to perceived sufficient consensus on the mailing list for chartering. KeyTrans is primarily focused on group key transparency for messaging services, using Merkle trees and Verifiable Random Functions (VRF) for privacy. Concerns were raised about potential scope creep if KeyTrans were to extend into domains like supply chains.
Trust Registry and Existing Practices: Dick emphasized the importance of ensuring the integrity of the SCITT trust registry and accommodating existing software supply chain practices, such as PGP and X.509 digital signatures.
Trust Statements and URLs: The discussion highlighted the need for the SCITT API to provide URLs to registered trust statements, allowing consumers to directly retrieve information from the trust registry, similar to a "registry of deeds."
Cozy Receipts Status: The call for adoption for the cose-receipts draft, which profiles on cose-committer, has been issued. This is a direct dependency for SCITT work.
Feeds in SCITT: Various perspectives on the definition and implementation of "feeds" were discussed. John is integrating feeds into the SCITT emulator client to test different approaches (e.g., specifying by name or by name and properties). Ori highlighted the need for the API to sort out URL structures for consuming feeds, considering interactions with artifact repositories and the potential use of QR codes.
Authenticated Remote Signer Use Case: Ori raised the question of whether an authenticated remote signer use case should be explicitly part of the SCITT ecosystem, as current API clients often sign locally. This affects interoperability testing and the source of confidence in signing keys.
Trust Labels and QR Codes: There was a significant discussion about "trust labels" (e.g., EU CE Mark, US Cyber Security Mark) and their proposed use with QR codes on products or websites. Dick underscored SCITT's capability to support both static and dynamic labels through URL pointers. Neil expressed concern about the term "trust" being used for potentially static labels, advocating for dynamic, verifiable claims to avoid misleading the public. The group agreed on the importance of SCITT enabling dynamic compliance claims.
Company Identification: The ongoing discussion about robust company identification remains a complex challenge with diverse opinions.

Decisions and Action Items

Decision: The "candidate API" definition will be split from the architecture document into a new, independent work product, tentatively named "Scrappy."
Action Item: Hank and Kirsten will produce and distribute a summary of the Gordian Envelopes side meeting.
Action Item: John will prioritize implementing feeds in the SCITT emulator client to test different approaches and align with specification progress.
Action Item: Hank will work on the initial submission of the "Scrappy" API document, aiming for early September, to facilitate parallel development.
Action Item: Hannes will distribute his detailed review of the architecture document, ideally via GitHub Pull Requests or issues.
Action Item: Hannes will post the cose-receipts call for adoption to the SCITT mailing list.
Action Item: Dick (with potential collaboration from Hank and others) will lead the effort to draft a short document or contribution to the use case document, outlining the background of regulatory proposals for "trust labels" and how SCITT can provide interoperable, verifiable solutions using QR codes. This document should also engage external parties like the FCC and EU regulators.

Next Steps

Continue active development and refinement of the "Scrappy" API document.
Further implement and test "feed" structures within the SCITT emulator.
Continue discussions and exploration into robust company identification mechanisms.
Collaboratively draft the document on QR codes and trust labels in the context of SCITT.
The chairs will coordinate the next interim meeting, and participants are encouraged to suggest specific agenda topics such as API progress, architecture document updates, or detailed feed discussions.