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

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

## Summary

This SCITT interim meeting focused primarily on preparation for IETF 118, including hackathon plans and upcoming document submission deadlines. A significant portion of the discussion revolved around the ongoing Pull Request (PR) activity, specifically the controversial "feed" concept and its definition and purpose within the SCITT architecture. While one minor PR was approved, the core discussion on "feed" remained inconclusive due to differing interpretations and ran out of time.

## Key Discussion Points

*   **IETF 118 Preparation:**
    *   The group acknowledged that IETF 118 is the last interim before document submission deadlines. Critical documents for submission (Use Cases, Scrappy, Architecture) need to be in a fit state by next Monday (approx. 7 days).
    *   A call for presenters for the IETF 118 session was made.
    *   **Suggested presentation topics for IETF 118:**
        *   Intersection of SCITT with the proposed SPICE BoF.
        *   An update on Hank's "Epoch" work (security domain freshness indicators, potentially using signed timestamps, relevant to SCITT statements).
        *   A general update on SCITT-COSY.
    *   **Future Work Areas:**
        *   "Endorsements" were highlighted as a potential next area of focus, particularly for addressing customer needs for auditor-reviewed statements beyond self-attestation, which has been discussed in previous meetings.
        *   "Registration policies" were also mentioned as a related topic for future consideration.
    *   **Key Transparency Alignment:**
        *   Orie, a co-chair of the Key Transparency Working Group (now formed, past BoF state), confirmed that no explicit alignment is needed from SCITT at this point. Key Transparency has a different mental model, privacy aspects (requiring a variant of a Merkle tree), and a focus on username-to-public-key binding, which differs from SCITT's broader scope and opinionated use of CBOR/COSE.
*   **Hackathon Plans for IETF 118:**
    *   The primary target is to implement Scrappy on multiple platforms, focusing on identification and fetching statement receipts through a usable API.
    *   Other suggested activities include:
        *   Implementing and testing APIs, adjusting interfaces, and exploring tangential pieces like QR codes/data UIs.
        *   Command-line tooling for visualizing conceptual messages and envelopes.
        *   A tabletop exercise to define user functions (e.g., enter, notarize, retrieve trustworthiness information) for practical implementation and adoption.
        *   Updating or replacing the existing (stale) SCITT API emulator (e.g., integrating `skid.xyz` examples).
    *   Participants were reminded that SCITT's IETF 118 session is on Monday morning, implying hackathon-related presentation materials need to be ready by Sunday night.
*   **PRs and Document Submission Discussion (Focus on "Feed"):**
    *   **PR #110 ("cram down format fixes"):** This PR, described as editorial and fixing brittleness, was approved for immediate submission.
    *   **Discussion on "Feed" (PR #104 vs. PR #111):** An extensive discussion took place regarding the "feed" concept, with several differing viewpoints:
        *   **Ambiguity:** Concern was raised that the concept of "feed" is not obvious, its scope and purpose are unclear, and there's no clear consensus on its interpretation.
        *   **Submitter vs. Viewer Responsibility:** Ray argued that submitters (issuers) should only define immutable attributes of the artifact, not how viewers group statements. Viewer-side grouping ("feeds") should be a higher-level, less immutable concept.
        *   **"Purpose" Requirement:** Silvan strongly advocated for an immutable "purpose" field in the signed statement header. This "purpose" (or "topic") would allow an issuer to sequence statements on the same topic and enable consumers to track these sequences, avoiding identity confusion. He noted that "feed" in this context refers to a time-based sequence of statements on a given purpose.
        *   **Registration Info vs. Feed:** Cedric suggested that if consensus on "feed" interpretation cannot be reached, it could be incorporated into the more general "registration info" structure, which already contains additional issuer-set information. Ray agreed that "reg info" could handle various descriptors, eliminating the need for a separate "feed" field.
        *   **Data Type:** PR #111 proposed changing "feed" from `tstr` to `bstr` to allow for structured correlation identifiers. This was seen as a local improvement if "feed" is retained.
        *   **Terminology:** Charlie expressed "heartburn" over the term "feed," suggesting it implies a time-based stack, while "purpose" is orthogonal. He preferred terms like "collection" or "selection" (in an SQL sense) for grouping, which are crucial for implementations and issuer-independent.
        *   **Traceability:** Silvan countered that "feed" *is* about time-based sequencing and is critical for traceability, stating that reassembling purpose from key-value pairs in `reg info` would "miss the point."
    *   **Conclusion on "Feed":** The discussion on "feed" was inconclusive, with diverse perspectives on its necessity, definition, location, and optimal terminology. The group ran out of time before a decision could be reached.

## Decisions and Action Items

*   **Decisions:**
    *   PR #110 ("cram down format fixes") was approved and will be merged for the upcoming document submission.
*   **Action Items:**
    *   Hannis to upload past meeting notes to the IETF website.
    *   Chairs to solicit volunteers for IETF 118 presentations via the mailing list.
    *   All participants to continue the discussion on the "feed" concept (PR #104 vs. #111) on the SCITT mailing list.
    *   Hackathon participants to prepare materials for their activities, especially given the Monday morning session slot at IETF 118.

## Next Steps

*   Intensify discussion on the "feed" concept (PR #104 vs. #111) on the mailing list to work towards consensus or an agreed path forward for document submission.
*   Finalize preparations for IETF 118 presentations and the hackathon, focusing on practical API implementation, tooling, and potentially a tabletop exercise for user functions.
*   Consider "endorsements" and "registration policies" as potential areas for deeper engagement following the core document submissions.