**Session Date/Time:** 20 Feb 2023 16:00

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

## Summary

The SCITT Working Group discussed the recently submitted use case document, gathering feedback to determine its readiness for working group adoption. A strong sense of those present indicated support for moving forward with adoption. The discussion then broadened to the fundamental purpose and scope of SCITT, including what "trust" a SCITT entry conveys, the role of SCITT in supporting different stakeholders (end-users, supply chain partners, auditors), and the implications of having multiple SCITT instances. While the planned topics on identity and terminology were not explicitly addressed due to the extensive discussion on scope, significant progress was made in clarifying foundational concepts.

## Key Discussion Points

### Use Case Document Review and Adoption

*   **Initial Review and Feedback:** Johannes, as chair, opened the discussion by requesting feedback on the recently submitted use case document. Yogesh, a co-author, reported on a recent brainstorming session that incorporated a new firmware update use case focusing on post-boot activities. Yogesh also suggested minor reordering of use cases for improved flow and indicated plans to raise a GitHub issue for this.
*   **Adoption Timing:** Hank questioned whether to proceed with a call for adoption first and address fixes as a working group document, or to wait.
*   **Support for Adoption:** Bob expressed that the document "reads well" and, despite minor suggestions, is a "good basis for going forward" and suggested adoption. Dick concurred, stating it is "good enough" as a "starting point."
*   **Meaning of Adoption:** Cedric inquired about the implications of approving the document at this stage, particularly regarding future refinement. Johannes clarified that adoption would signify it as an "initial version" and a "starting point" for the working group, allowing for future improvements as discussions progress.
*   **Process Overview:** Ray requested a review of the full process following adoption. Johannes outlined the steps: call for adoption (2 weeks), authors resubmit as a working group item, discussion and updates for the next IETF meeting, further feedback, working group last call, shepherd write-up, and submission to the IESG for publication as an RFC.
*   **Qualities of a Good Use Case Document:** Ray further asked what constitutes a quality use case document. Johannes responded that it should inform the debate on architecture and requirements, even if not all use cases are addressed in the first iteration. He also noted the need to describe threats, potentially in the use case or architecture document.
*   **Scope and Content:** Hank added that it's acceptable for use cases to describe scenarios beyond the immediate scope of initial SCITT building blocks, such as API-related aspects, as long as it's documented.

### Defining the Purpose and Scope of SCITT

*   **Who Benefits and What is Trusted?** Dick stated that SCITT should benefit consumers by answering "is a piece of software trustworthy enough?" Bob countered that the "real power of SCITT is amongst supply chain partners," emphasizing business-to-business value.
*   **Evidence vs. Oracle of Trust:** Neil articulated that SCITT should "document evidence which each individual can use to make their own decision," rather than being an "anointed infallible Oracle of trust." This sentiment was supported by others.
*   **Layered Evaluation:** Ray proposed a two-layer model:
    *   A SCITT transparency server that stores "simple claims evidence" (like a RISC processor).
    *   A higher evaluation layer that assesses complex factors (e.g., age of software, company bankruptcy), tailored to specific use cases (e.g., end-user "green button" vs. machine-to-machine supplier checks).
*   **All Stakeholders:** Yogesh reinforced that the ecosystem should assist "all stakeholders," including suppliers dependent on other suppliers, and auditors, not just end-users. He agreed that basic verification (cryptographic proof of statement presence) could be done by SCITT, while policy-driven appraisal of evidence happens offline.
*   **Trusting the Issuer:** Cedric suggested that for many basic policies, the decision hinges on knowing "which issuer is authoritative for that artifact."
*   **Delegated Trust and Identity:** Steve highlighted that end-users often defer trust to entities (e.g., Apple Store, antivirus software). SCITT's role is to provide a "secure pipeline" of information, ensuring the "identity" of the source is verifiable. He also stressed the importance of a "freshness angle" to address evolving threats.
*   **Clarifying "Trust Statement" Semantics:** Dick posed a critical question: "what is that something" a SCITT entry refers to? Does a SCITT entry mean "the evidence is trustworthy" or "the product is trustworthy"? He sought consensus on this "trust boundary."
*   **Varying Trust Criteria:** Steve argued that the "trust statement will probably vary" by industry and specific policy (e.g., government agencies, gaming companies). SCITT should define a "format of a statement" with identity and links, but not dictate the specific quality criteria.
*   **Chair's Perspective on Scope:** John, as co-chair, emphasized the risk of "massively inflat[ing] our scope" by trying to define universal communities of trust. He advocated for a simple charter: SCITT makes facts available to authorized readers and ensures publishers are identifiable. Consumers then draw their own conclusions. He gave examples:
    *   Self-driving cars: Multiple claims from various parties (software, firmware, AI models, researchers finding hacks); the "risk holder" decides relevance.
    *   `npm audit` reports: Publishing a build artifact that states "no vulnerabilities" creates an auditable, non-repudiable record. Even if not 100% true, it provides a "strong basis for decision making" and accountability.
*   **Minimal Semantics vs. Opaque Data:** Hank agreed with John's concern about scope creep, but also stated that purely opaque statements would not address highlighted use cases. He suggested a "minimal amount of understanding" (some non-opaque structured data) is necessary for basic interoperability, possibly drawing from existing semantics (e.g., Sigstore). This would be an iterative process.
*   **Issuer Accountability:** Yogesh reiterated that SCITT ensures a transparent statement and holds the issuer accountable, with interpretation of trustworthiness being policy-driven.

### The Nature of SCITT Registries and Trust Statements

*   **Multiple Instances:** Neil raised the issue of "multiple SCITT Registries," concerned about the potential for malicious instances, how to find authoritative ones, and the reliability of individual companies maintaining their own.
*   **Diverse Ledger Types:** Bob envisioned "four or five different ledgers":
    *   Company-specific (e.g., per product line) for internal evidence.
    *   More public ledgers that endorse and make facts searchable, potentially community-wide.
*   **Federated and Resilient Systems:** Steve supported multiple instances, noting that different vendors, hardware manufacturers, and security companies would run their own. This allows for diverse data sources and resilience (e.g., if a company goes bankrupt, other trusted parties might still provide information).
*   **Basic Policy and Stability:** Cedric acknowledged federation but suggested that for "basic relying party policies," a "singular transparency service" with "reasonably stable and reputable and long-lived" properties might be expected.
*   **Centralized vs. Decentralized Models:** Neil reiterated a preference for a "Sigstore model" (fewer, well-managed public instances) over many company-specific ones due to concerns about supplier uptime. He also suggested a use case reflecting different relying parties making different trust decisions from the same SCITT data.
*   **Confidentiality Concerns:** Ray expressed concern about the "confidentiality" dimension of ledgers (whether entries or whole ledgers are public/confidential), suggesting it might be outside the current use case scope and should be explicitly avoided for now.

## Decisions and Action Items

*   **DECISION:** The working group will proceed with a call for adoption for the use case document ("draft-ietf-scitt-use-cases").
*   **ACTION ITEM:** Johannes (chair) will initiate the formal 2-week call for adoption.
*   **ACTION ITEM:** The authors of "draft-ietf-scitt-use-cases" are requested to resubmit the document as a working group item following a successful adoption call.
*   **ACTION ITEM:** Johannes (chair) will trigger further discussion on the mailing list regarding the architectural and scope questions raised during the meeting, particularly concerning the meaning of "trust" in SCITT entries and the role of multiple instances.

## Next Steps

*   The call for adoption for the use case document will be initiated.
*   The mailing list will be used to continue the in-depth discussion on the fundamental scope of SCITT, including the precise semantics of trust statements and the operational model of SCITT instances (e.g., federated vs. centralized, public vs. confidential). These discussions will inform the ongoing development of the SCITT architecture and requirements.
*   The topics of identity and terminology, which were deferred, will be revisited in future meetings.