**Session Date/Time:** 04 Nov 2025 16:30

# SCITT

## Summary

The SCITT working group session provided updates on document status, discussed proposals for adopting new receipt profiles, reviewed a use case from the Open Compute Project (OCP) regarding hardware/firmware supply chain security, and delved into a significant discussion about how to handle semantic interconnections and graph-like relationships between transparent statements. A key theme was balancing the current scope of SCITT (focused on opaque payloads and transparent statements) with emerging needs for more structured relationships, while ensuring timely progression of existing drafts.

## Key Discussion Points

*   **Document Status Update:**
    *   **SCITT Architecture:** Moving to RFC status, currently undergoing RPC churning after IESG ballot. The terminology "transparent statement" will remain unchanged despite IESG feedback.
    *   **Cozy Receipts (formerly Merkel Tree Proof ID):** Strong dependency on SCITT Architecture, also in RFC candidate status. It defines verifiable data structures and proof structures, forming the basis for SCITT Receipts.
    *   **Cozy Hash Envelope:** Nearing IESG ballot, provides efficiency for transparently registering hashes of large payloads.
    *   **SCITT Reference API (Scrappy):** Moving to Working Group Last Call (WGLC). There has been discussion regarding the completeness of its endpoints. The current set of endpoints is deemed sufficient for a final round of discussion before IESG ballot, but further feedback on scope and usefulness is requested during WGLC.
*   **Receipt Profiles Adoption Proposal:**
    *   Amory presented two deployed Cozy Receipt implementations: Data Trails (Markle Mountain Range profile) and Microsoft (CCF profile). These profiles extend the verifiable data structures defined in Cozy Receipts.
    *   The **CCF profile** introduces features like sub-leafs for confidential information and commit evidence, which differ from the RFC9162 SHA-256 profile defined in Cozy Receipts.
    *   Amory proposed adopting these profiles within the SCITT working group, citing their relevance and current use in transparency service implementations.
    *   **Discussion on adoption venue (SCITT vs. Cozy):** The chair questioned if these drafts, being refinements of Cozy, might be better suited for the Cozy working group. It was noted that similar drafts were previously proposed in Cozy but lacked sufficient reviews. Ori Steele commented that Cozy Receipts established registries for such profiles, allowing other WGs like SCITT to use them. Nicole Bates supported adoption in SCITT due to the profiles' direct relevance to SCITT's architectural specification.
    *   Amory clarified that the CCF profile presented specifically scopes its features to *public transparency* and integrity for supply chain use cases, which aligns with SCITT's current focus, as opposed to more complex confidential information handling.
    *   Ori Steele emphasized the value of documenting the unique features of these profiles, especially in differentiating SCITT from other transparency logs, and suggested SCITT should not be strictly limited to *public* transparency, as many supply chain use cases involve protected or confidential information. Amory acknowledged this as important future work, but prioritized standardizing currently deployed public-focused implementations to avoid delaying progress.
*   **Open Compute Project (OCP) Use Case:**
    *   Novoaki reported on OCP's interest in SCITT for supply chain security of firmware and potential for hardware.
    *   SCITT Architecture and Scrappy appear to work for OCP firmware use cases.
    *   Questions raised included the increasing variety of statements, the ability to simultaneously provide lifecycle/provenance and hierarchical information, and enhancing convenience for these. These points highlight the need for better semantic interconnection between statements.
*   **Semantic Interconnection of Statements (Graph-like Relationships):**
    *   This was a major recurring discussion. Hank noted that SCITT currently treats payloads as opaque. The working group needs to decide how to handle relationships between statements (e.g., S-bombs linked to VEX documents).
    *   **Proposed locations for relationship semantics:**
        1.  **Cozy Header:** Could contain hints or an extension point to refer to other registered statements. This would be specific to SCITT's envelope.
        2.  **Statement Payload:** Relationships defined within the application-specific payload format itself (e.g., SPDX S-bomb). This is already happening in other standards/WGs.
    *   Ori Steele highlighted that graphs are already built from payload content formats by forensic analysis tools. SCITT offers an *additional* verifiable graph layer. He demonstrated an implementation of Scrappy extensions that add JSON retrieval APIs for graph pieces based on protected headers, without modifying core Scrappy endpoints.
    *   Yogesh and Amory argued for flexibility, allowing relationships in both header and payload. Amory expressed a preference for SCITT to remain relatively simple, focusing on core transparency, and leaving complex, content-specific semantic relationships to the individual formats or other working groups, to avoid "the perfect being the enemy of good."
    *   Hank suggested that a *minimum set of abstract relationships* (e.g., supersedes, replaces) could be defined in the Cozy header. This would help systems retrieve and discover related statements without needing to understand the complex specifics of every payload, which does not scale.
    *   John clarified that there are two distinct problems:
        1.  Linking diverse *payload contents* (e.g., VEX to S-bomb), which may be handled by other WGs.
        2.  Metadata about *SCITT-specific objects* themselves (e.g., "this transparent statement about an S-bomb has been superseded by another"). These should not be solved by the same mechanism.
*   **FDA Use Case (Cybersecurity Labeling):**
    *   Presented by John on behalf of Dick Brooks. FDA has strong interest in traceable supply chains for medical devices, food, and drugs, where hardware and software are often inseparable.
    *   The use case proposes using SCITT transparent statements to anchor canonical URLs for cybersecurity labeling information, making these URLs trustworthy (non-repudiable, untamperable).
    *   It *appears* that SCITT, as currently defined, can support this use case by having vendors register their canonical URLs in signed statements to the transparency service.
    *   The discussion reiterated the question of whether a "linkability attribute" (graph of related statements) is necessary for this use case to function properly, or if floating, separate statements are sufficient.

## Decisions and Action Items

*   **Decision:** The terminology "transparent statement" in the SCITT Architecture draft will not be changed.
*   **Action Item:** Working group members are requested to review the Data Trails and CCF Receipt Profile drafts and provide feedback to the mailing list. The chair will then consider calling for working group adoption.
*   **Action Item:** Working group members are requested to review the Scrappy draft during its upcoming Working Group Last Call, particularly concerning the completeness of its API endpoints for use cases such as FDA cybersecurity labeling.
*   **Decision:** The Scrappy API will be progressed as-is, focusing on its current defined registration and receipt retrieval endpoints. Auxiliary services, such as graph discovery endpoints for more complex relationship queries, can be added as extensions in future work.

## Next Steps

*   **Receipt Profiles:** Continue reviews and discussion on the mailing list for potential adoption.
*   **Scrappy:** Proceed with Working Group Last Call.
*   **Semantic Interconnection:** Continue the discussion on the mailing list regarding how to define and handle semantic relationships between statements, distinguishing between metadata about SCITT objects and content-specific payload relationships. This will inform future work item proposals, potentially leading to new drafts for API extensions or header parameters.
*   **Use Cases:** Continue to explore use cases, such as OCP and FDA, to identify any remaining gaps or requirements for SCITT.