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

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

## Summary

The SCITT WG discussed preparations for IETF 118, with a focus on resolving key issues related to the "feed" concept within the specification. The primary goal for IETF 118 is to demonstrate the ability for applications to find, search, and index related claims, building on the success of proving individual receipt structures. Two specific Pull Requests (PRs 107 and 108) proposing clarifications and alternative encodings for the "feed" mechanism were reviewed. Discussions highlighted the need for a flexible base specification that can be extended by profiles to address complex scenarios involving multiple statement issuers and SCITT instances, while also clarifying the role of "feed" in non-equivocation and consistency.

## Key Discussion Points

*   **IETF 118 Scheduling**: A virtual interim meeting immediately preceding IETF 118 will not be held due to its proximity to draft submission deadlines and the start of the main meeting.
*   **Importance of "Feed" Concept**: There was a strong sense that a mechanism for linking related statements (referred to as a "feed") is necessary. This is crucial for logically grouping statements about an artifact from various entities, finding previous/next statements in a process, or identifying the latest version of superseded statements, all contributing to assessing trust in real-world artifacts.
*   **Non-Equivocation and Feeds**: The role of "feed" in achieving non-equivocation was debated. While a feed helps find related statements, a participant argued that it doesn't guarantee non-equivocation on its own, as a full copy of all statements and an honest providing machine are required. The suggestion was made to use generic metadata for querying, with "feeds" potentially being constructed from such metadata.
*   **Consistency Across Issuers/SCITT Instances**: A significant challenge was identified in how different issuers across potentially multiple SCITT instances can consistently define and group statements about the same artifact. Concerns were raised about the lack of structure in a simple string-based "feed" and the difficulty for consumers to "stitch together" information if issuers don't consistently use the same SCITT instance or identifier.
*   **Profile-Driven Flexibility**: A sense of those present indicated that the base specification should provide a flexible "feed" type (e.g., extensible in CDDL), allowing specific usage patterns and coordination mechanisms to be defined in profiles or guidance documents rather than being prescribed in the core architecture.
*   **Clarification of Registration Info vs. Policy**: Ambiguity exists in the current specification regarding "registration info" (from the issuer) and "registration policy" (from the transparency service). It was suggested that `reg_info` could be split into artifact-specific metadata and registration process attributes.
*   **PR 107 (John's)**: This PR proposes clarifications and a tidy-up of the existing "feed" concept, emphasizing its role in grouping statements about artifacts. The initial feedback indicated that it helps clarify the intended purpose.
*   **PR 108 (Ai's)**: This PR proposes replacing the custom "feed" element with existing COSE/CWT claims in the protected header.
    *   **Proposal**: Use the `iss` (issuer, tag 1) and `sub` (subject, tag 2) claims from the IANA CWT registry. The `sub` claim is seen as consistent with the issuer's intent for "feed" (identifier for the artifact about which claims are made).
    *   **Benefits**: Reuses existing, registered code points, avoids defining new ones, is compatible with various content types, and provides a clear layering for future claims (e.g., `hw_oemid`).
    *   **Concerns**: While using `sub` standardizes the claim name, it's still a text string and doesn't inherently solve the problem of consistent identifier choice or collision management across different issuers or transparency services, which may need to expose categories or topics to aid discovery.

## Decisions and Action Items

*   **Decision**: There will be no virtual interim meeting for SCITT immediately before IETF 118 (starting November 6th).
*   **Action Item**: Han to double-check the setup of the SCITT meeting series regarding the IETF 118 schedule.
*   **Action Item**: Participants are strongly encouraged to review and provide comments on Pull Requests 107 and 108 in the main spec repository to facilitate their progression.
*   **Action Item**: Yogesh will raise an issue in the main spec repository to address the ambiguity and clarify the distinction between "registration info" (provided by the issuer) and "registration policy" (defined by the transparency service).
*   **Action Item**: Consider adding more specific use cases related to finding and linking claims (e.g., checking artifact validity, finding the latest version, tracking vulnerabilities across multiple SCITT instances) to the use cases document to better inform the architectural choices.

## Next Steps

*   Continue the discussion on PRs 107 and 108, aiming to converge on a solution that provides clarity and flexibility for linking related statements, potentially by combining or integrating aspects of both.
*   Integrate work on access control mechanisms (as developed by John Anderson) for demonstration at the IETF 118 hackathon, with further refinement planned between IETF 118 and 119.
*   Address the identified ambiguities in the specification, particularly concerning registration information and policies.