Session Date/Time: 25 Sep 2023 15:00

SCITT

Summary

The SCITT Working Group continued its discussion on the feed structure, a primary item for resolution before IETF 118. Key topics included the separation of identity from feed identifiers, the role of SKITT in searchability versus relying on application-specific indexing, and the need for clear documentation and examples. A sense of those present indicated agreement that a feed should support multiple issuers and that the core SKITT primitive should remain generic, allowing applications to define specific structures and search capabilities.

Key Discussion Points

Feed Structure and Identity:
- A primary concern was separating the identity of the issuer from the feed ID itself to allow independent progress on these concepts.
- Arguments were made for linking who is making a statement (the identity) to the statement, potentially leveraging the kid (Key ID) in the COSE header.
- The idea that a feed is "created by an identity" was proposed, allowing the same identity model used for statements to apply to feeds. This implies a feed ID could be a generic unique string, with its properties (e.g., platform, architecture, version, other IDs) stored as name-value pairs within a special type of statement associated with the feed.
- Participants stressed the need to support various types of identities (individuals, projects, companies) without being overly prescriptive about their nature. Registration policies of a SKITT instance could then dictate which identity types are accepted.
- There was a strong sense that a feed should not be restricted to a single issuer; multiple entities should be able to post statements to a given feed. This is crucial for scenarios like security companies making statements about artifacts produced by another entity.
Searchability and Indexing:
- The discussion around feed structure is largely driven by the need for discoverability and searchability of artifacts within SKITT.
- Concerns were raised about SKITT's ability to handle heavy query loads if it were to implement complex search functionality directly, suggesting it might "groan under the weight of query loads" in an implementation.
- Several participants proposed that searchability and detailed indexing capabilities should reside in a separate, application-specific database or layer built on top of the append-only SKITT log. This would allow SKITT to remain a generic logging primitive while applications define how to search and correlate information relevant to their specific supply chain or use case.
- The example of Key Transparency was mentioned, which includes specific features for search, but its use case (username to public key binding) is more narrowly defined than SKITT's.
Terminology and Communication:
- A participant raised the ongoing confusion around the term "attestation" in the context of U.S. regulations and proposed using "digitally authenticated attestation" when explicit authentication is implied.
- The term "feed" itself was questioned for clarity and universal understanding.
- A request was made to ensure all significant discussions and reference materials (like those shared on Slack) are also posted to the WG mailing list to ensure broad access for all participants. Steve committed to cross-posting his points from Slack to the mailing list.
Documentation and Examples:
- There was a consensus on the urgent need for concrete examples of how feeds can be utilized and what their structure would look like in practice, to be included in the architecture document and Scrappy (the reference implementation).
- A participant (Hank) mentioned a "registration info bundle" as a potential point to define characteristics below a feed identifier, such as sequence numbers or versions, which could be augmented for specific use cases (e.g., software supply chain).

Decisions and Action Items

Decision: A feed must not be restricted to a single issuer; it should be possible for multiple identities/entities to post statements to the same feed.
Action Item: Steve to send the content discussed in the Slack thread regarding feed ID and identity separation to the SCITT mailing list for broader review and discussion.
Action Item: Hans to resolve existing merge conflicts in pending Pull Requests (PRs) related to the architecture document to facilitate further progress on feed structure.
Action Item: Editors to work on incorporating concrete examples of feed utilization into the architecture document and Scrappy.
Action Item: Hans to write up and propose the concept of a "registration info bundle" and its role in defining characteristics below a feed identifier to the mailing list for discussion.
Action Item: Consider a formal discussion on clarifying "attestation" terminology in future meetings.

Next Steps

Further refine the proposed feed structure: a generic string for the feed ID, identity handled through the COSE header, and additional properties described as name-value pairs within a related statement.
Develop PRs for the architecture document to reflect the agreed-upon feed structure and the separation of identity.
Continue exploring the role of did:web as a potential main solution for identity within SKITT.
Evaluate how application-specific search and indexing capabilities can be clearly defined as complementary to, rather than integral parts of, the core SKITT specification.