**Session Date/Time:** 14 Aug 2023 15:00

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

## Summary

The meeting focused heavily on the API's content type and representation, particularly the trade-offs between CBOR/COSE for efficiency and cryptographic integrity versus JSON/YAML for developer experience and tooling compatibility. While the core authenticity structures (COSE) are to remain untouched, there was significant debate regarding the API's protocol messages. Progress was reported on the SCITT emulator, and a new proposal for an extended Vendor Response File (VRF) structure was introduced. Concerns were raised regarding the working group's charter scope in relation to query/storage capabilities and specific software supply chain document formats.

## Key Discussion Points

*   **API Content Type and Representation:**
    *   An extensive discussion took place regarding the format of API messages, specifically whether to use CBOR/COSE, JSON, or YAML.
    *   Ori and Ray highlighted developer challenges with raw binary (CBOR/COSE) formats, especially with common API tooling (e.g., OpenAPI) and web platform binary support. They argued that JSON/YAML "armored" representations could significantly improve implementer experience and adoption, even if it adds payload expense or API complexity.
    *   Hank and Neil stressed the importance of a single, canonical representation for authenticity and cryptographic structures (COSE) to ensure uniformity, avoid canonicalization problems, and maintain interoperability of verifiable data structures. Hank noted that CBOR diagnostic notation (CBOR-DIAG) already offers a human-readable "JSON++" equivalent.
    *   Ori made a strong statement advocating for a mandatory-to-implement CBOR API with optional YAML for debug/diagnostic purposes, but no JSON, to drive interoperability and clear expectations for production-grade APIs.
    *   Ray advocated for "plain Jane JSON" at the API submission/retrieval layer, citing widespread industry adoption (e.g., AWS) and the EU COVID QR code example (JSON -> CBOR -> Base45 -> QR code) where human readability is achieved at different layers.
    *   Hannes emphasized the need for a clear decision to avoid supporting two different encodings.

*   **SCITT Emulator Progress:**
    *   John reported that the hackathon implementation is committed and working.
    *   Acknowledged that terminology in the emulator's code needs updating to align with the latest spec changes (e.g., "transparent" and "signed").
    *   Mentioned that the archivist implementation within the emulator wraps CBOR structures in "armored JSON" for transmission across service interfaces, offering a practical example for future discussion.

*   **Data Packaging and Vendor Response File (VRF):**
    *   Ray proposed extending the Vendor Response File (VRF) structure (originally introduced by Dick) to include more comprehensive identity and data artifact information. The goal is to move beyond a minimalistic hash value in the Merkle tree to enable better searchability and context for SCITT-organized data.
    *   Dick provided context for the current VRF design, explaining it accommodates "systems integrators" who manage multiple software packages under contract.

*   **Charter Scope Concerns:**
    *   Roy raised a concern that discussions around ad-hoc query capabilities, general storage, and specific software supply chain document formats (often controlled by CISA/NIST) might be "skirting the charter very closely." The current charter focuses on submission and audit capabilities for transparency statements.

*   **External Engagement Opportunity:**
    *   Yogesh highlighted a request for feedback from US government organizations (CISA, NCD) on securing open-source software, suggesting an opportunity to contribute SCITT's perspective and advertise the technology.

## Decisions and Action Items

*   **Action Item (John):** Verify the recurring meeting setup in the IETF data tracker. (Note: This was resolved during the meeting; John confirmed the recurring weekly meeting is now fixed.)
*   **Action Item (Hannes):** Send a message to the mailing list to facilitate further discussion and gather a sense of the group on API format preferences (CBOR-only, optional YAML, JSON) to guide a clear decision.
*   **Action Item (Ray):** Prepare a concrete document or proposal outlining the suggested extensions to the data packaging / Vendor Response File (VRF) structure for group review and discussion.
*   **Action Item (Hannes):** Contact Dick to discuss the Vendor Response File (VRF) in more detail.
*   **Action Item (John):** Update the terminology within the SCITT emulator code to align with the latest specification changes (e.g., "transparent," "signed").

## Next Steps

*   **Next Meeting Agenda Items:**
    *   Dedicated discussion on the **feed structure**.
    *   Review of **GitHub Pull Requests (PRs) and open issues**, potentially with a screen share to go through them.
    *   Further discussion on the **API**, specifically focusing on the structure and content of responses received after submitting a payload to a registry.
*   **General Progress:** Group members are encouraged to review existing documents and contribute to document advancement during the summer period.
*   **Charter Review:** Acknowledge and potentially address the charter scope concerns raised by Roy regarding query/storage capabilities and specific document formats.
*   **External Outreach:** Consider preparing feedback to US government organizations (CISA, NCD) on securing open-source software, leveraging SCITT's relevance.