**Session Date/Time:** 06 Mar 2023 16:00

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

## Summary

This meeting primarily focused on a detailed architectural diagram presented by Ray, outlining a conceptual SCITT registry and its interactions, with a strong emphasis on terminology and the logical organization of data and services. The discussion highlighted the need to refine the architecture document to reflect these conceptual elements, identify the core responsibilities of a SCITT instance, and distinguish them from external, higher-level services. Key outcomes included a positive reception to the use case document and a decision to merge a terminology overhaul PR in the architecture document to facilitate further review, while acknowledging numerous open issues.

## Key Discussion Points

*   **Use Case Call for Adoption**: The call for adoption for the use case document is concluding with positive feedback. The authors are requested to submit a Working Group version of the document.
*   **Ray's Architectural Diagram Presentation**:
    *   Ray presented a block diagram illustrating a conceptual SCITT registry, aiming to capture the "big picture" and data flow rather than specific APIs.
    *   **Submitter Side**: Concepts included users (potentially OpenID Connect based, with delegated authority), organizations (corporations, unincorporated associations), product lines, models/configurations, and product releases (with semantic versions). A "pre-submission filter" was envisioned as an "e-notary" for validating ownership and authority before ledger submission.
    *   **Ledger/Registry Core**: Described as an append-only secure data table (e.g., AWS QLDB). Entries may have size limitations (e.g., 400MB), implying the need for "bulk storage" (co-located) for larger artifacts and "external storage" for references. A concept of "private storage" for challenge-only comparisons was mentioned. A "certification authority" box was included.
    *   **Registry Viewer Side**: Envisioned "product line aggregations" and "product release aggregations" as logical views over the ledger data to aid user access. "Business-to-business evaluation" and "end-user apps" (e.g., "is the software trustworthy?") were presented as services consuming information from the registry. A "RATS entity" (e.g., IoT device, cloud software) was noted as needing information for verification, potentially from product release aggregations. A "Ledger Registry" or "SCITT Registry Registry" was proposed as a registry of registries.
*   **Discussion on Ray's Diagram and Architecture**:
    *   **Boundaries of a SCITT Instance**: There was discussion on what constitutes the "core" SCITT registry versus external or higher-layer services. It was generally agreed that end-user trustworthiness evaluations and B2B evaluations are services built *on top* of the core SCITT registry, rather than being part of it.
    *   **Terminology and Concepts**: The diagram highlighted key concepts like organizations, product lines, and releases. While some participants suggested these might be too specific and the ledger should be more abstract, Ray emphasized their importance for filtering, user lookups, and defining ownership in a "pre-submission filter" (e-notary) context.
    *   **Data in the Ledger**: Participants debated the extent of data to be stored directly in the ledger. Jonny suggested Rats-related identifiers or evidence should be in the ledger, while the Rats entity itself is external. The idea that the ledger might need to be "a lot bigger" to accommodate various data types was raised.
    *   **Relation to Existing Architecture Document**: Several participants noted that the diagram differed from the existing architecture document. Neil and Steve suggested linking the concepts from Ray's diagram to existing issues in the architecture document's issue tracker (e.g., scalability, feeds) to ensure continuity and prevent loss of discussion points. John specifically suggested leveraging the "feed" concept already in the architecture spec for data differentiation and search.
    *   **Rats Integration**: Hank suggested that Rats roles could benefit many boxes in the diagram, but might be best introduced consistently at a later stage, or perhaps initially removed for simplicity and added more specifically where needed.
*   **Next Steps for Architecture Document Development**:
    *   Discussion around a "vast terminology overhaul" pull request (PR) for the architecture document. There was a sense that merging this PR would clean up the document and make it easier to review, despite numerous outstanding comments and issues associated with it.
    *   Participants acknowledged that merging the PR would still leave many open issues to be addressed iteratively.

## Decisions and Action Items

*   **Decision**: The authors of the Use Case document are requested to submit a Working Group version given the positive feedback.
*   **Decision**: The pull request (PR) for the "vast terminology overhaul" in the architecture document will be merged to facilitate clearer review and progress on the document.
*   **Action Item**: The Chair (Honest) will review the "vast terminology overhaul" PR and engage with contributors to ensure their feedback is captured, making it clear that outstanding comments will be tracked as separate issues after the merge.
*   **Action Item**: Steve, and others who commented on the PR, will help create specific issues in the architecture document's issue tracker for the loose ends and open comments identified in the PR and during today's discussion.
*   **Action Item**: Ray will provide further feedback on the architecture document, informed by his architectural diagram and the detailed discussion from this meeting.
*   **Action Item**: All participants are encouraged to review the "vast terminology overhaul" PR prior to its merge.

## Next Steps

*   The working group will proceed with merging the terminology PR for the architecture document, aiming for a revised draft publication before the upcoming IETF meeting.
*   Efforts will focus on systematically addressing the newly created issues, particularly those related to the transparency service, identity management, and the precise definition of architectural components and their boundaries.
*   Further discussions will refine the architecture document, considering the high-level conceptual views presented today and ensuring a balance between abstraction and practical implementation guidance.