**Session Date/Time:** 23 Oct 2023 15:00

# [SCITT](../wg/scitt.html)

## Summary

The SCITT working group met to discuss the status of key document submissions ahead of an upcoming deadline and to plan the agenda for the IETF meeting. A significant portion of the discussion focused on the architecture document's terminology, specifically the roles of "consumer," "verifier," and "relying party," and the scope of the "transparency service" within the core SCITT architecture versus the application layer. The working group also decided to initiate a Working Group Last Call for the use case document and began outlining potential presentations for the IETF session.

## Key Discussion Points

*   **Architecture Draft Submission (PR #118):**
    *   Editor Steve extended thanks for help on the architecture document, confirming rigorous scrubbing for consistency, including:
        *   Converging terminology to "transparency service" and "append-only log" from "registry" and "ledger."
        *   Integrating changes to use COSE Web Token (CWT) claims and subject, as discussed in the previous meeting.
        *   Resolving duplicated sections and merging independent edits, particularly regarding "shoulds" to "musts."
        *   The PR (number 118 for IETF 118) makes extensive editorial changes, including capitalization, alphabetizing terminology, and adjusting text for formatting.
        *   Examples were added for clarity, and text was trimmed to fit character limits.
        *   The document is prepared for submission by 5 PM Pacific Time today.
*   **Role Terminology Discussion ("Consumer" vs. "Verifier" vs. "Relying Party"):**
    *   Dick raised concerns about replacing "consumer" with "verifier," arguing that many users simply wish to view information from a transparency service without performing a verification action. He suggested adding "organizations, consumers, or users" to account for this.
    *   Ray supported "issuers" and "verifiers," noting "consumer" is an overloaded term. He clarified that the architecture document's focus on the authenticity layer makes "verifier" appropriate.
    *   Han strongly advocated for "relying party," explaining it better encapsulates the diverse ways actors use information and decide whether to rely on it, potentially involving context beyond technical verification.
    *   Hank suggested that the architecture document specifically addresses the *authenticity level* (issuers, verifiers) and that the broader "consumer" interaction belongs to a higher, application layer. He recommended adding a composed view to the architecture to clarify these layers.
    *   Roy and Ori emphasized that the append-only log is for transparency and validation, not intended as a direct query system for end-users. Tools would abstract this access.
    *   John (chair) reinforced the importance of maintaining a strict separation between the horizontal technology building blocks defined in the SCITT architecture and the application layer that handles user-facing interactions.
*   **Transparency Service vs. Registration Service:**
    *   Dick suggested that if the SCITT architecture's scope is primarily focused on getting material *into* the log and verifying its authenticity, then "registration service" might be a clearer term than "transparency service" to avoid implying broader data access functionality for general consumers. This concern aligned with Hank's layered architecture view.
*   **Use Case Document Status:**
    *   Steve confirmed that an updated use case document was submitted a few weeks ago, reflecting changes since the last IETF meeting.
    *   Discussion initiated about starting a Working Group Last Call (WGLC) for this document.
*   **SCITT API (Scrappy) Document Status:**
    *   Ori reported that while the Scrappy document received a pull request for updates, it is not yet ready for Working Group adoption. He preferred to progress it outside the WG and was not planning to submit a new revision today, hoping for more substantial improvements first. Hest expressed a desire to see a current submission for hackathon use.
*   **IETF Meeting Agenda Planning (Prague):**
    *   Proposed agenda items include: Architecture document update, SCITT API considerations (Ori to present), and possibly a short recap of use cases.
    *   Discussion arose about including consistency proofs on the agenda, which are covered in the COSE spec but have not been explicitly a focus for SCITT receipts. Roy and Steve highlighted their value for lightweight auditing and potential for broader implementation support. Steve offered to find an engineer to present on this topic.
    *   Hest offered to present on all documents if no other volunteers came forward, and suggested having a significant portion of the session dedicated to open, guided discussion.

## Decisions and Action Items

*   **Decisions:**
    *   The architecture draft (PR #118) will be submitted by Steve by 5 PM Pacific Time today.
    *   A Working Group Last Call (WGLC) for the use case document will be initiated in approximately three weeks.
*   **Action Items:**
    *   **Steve:** Submit the architecture draft (PR #118) by 5 PM Pacific Time today.
    *   **Chairs/Editors:** Continue the discussion on the terminology for actor roles ("verifier," "relying party," "consumer") and the scope of the "transparency service" for the architecture document. This may involve subsequent PRs or discussions at the IETF meeting.
    *   **Ori:** Consider sharing a diff of the Scrappy editor's draft for review.
    *   **Steve/Hank/Ori/Designated Volunteer:** Prepare a presentation on the concept and value of consistency proofs for the upcoming IETF meeting.
    *   **Yoges:** Prepare a 5-10 minute recap presentation on the SCITT use cases for the upcoming IETF meeting.
    *   **Chairs:** Finalize and publish the agenda for the SCITT session at the IETF meeting, incorporating the agreed-upon presentations and discussion topics.

## Next Steps

*   The working group will proceed with the Working Group Last Call for the use case document.
*   Ongoing discussion and refinement of key terminology in the architecture document will continue, particularly concerning actor roles and the precise scope of services.
*   Preparation for the IETF meeting in Prague will involve drafting presentations and potentially pre-reading documents under WGLC.