Session Date/Time: 02 Oct 2023 15:00

SCITT

Summary

The SCITT working group session focused on three main topics: the identity of entities making statements, the ongoing discussion around the definition of "feed" identifiers, and a proposal for a new Scrappy (SCITT Registry API) Open API definition. Key discussions revolved around finding a flexible approach for identity that accommodates diverse use cases without being overly prescriptive, clarifying the structure and purpose of feed identifiers, and moving forward with a concrete API definition to enable implementation and testing.

Key Discussion Points

Entity Identity in SCITT Statements

Isaac's Proposal for Identity: Discussion centered on four options for defining the identity of entities in SCITT:
1. Invent an own scheme (unpopular).
2. Adopt and require an existing scheme (unpopular).
3. Adopt and make optional an existing scheme (unpopular, as it doesn't solve interoperability).
4. Stay silent, allow multiple schemes, and provide plausible examples.
Consensus on Option 4: There was a strong sense of those present to favor Option 4: staying silent on a mandatory identity scheme, accommodating multiple schemes, and providing informative examples rather than normative requirements.
Interoperability Concerns: While acknowledging the need for flexibility, some participants (e.g., Ray, Dick) raised concerns about potential interoperability challenges if SCITT remains entirely silent. They suggested that the transparency service could offer facilities for submitting claims of identity or providing a document concept for identity details (name, location, Dun & Bradstreet number, etc.).
"Company ID" vs. "Entity ID": There was a general agreement to avoid the term "company" in favor of the more generic "entity" to encompass individuals, project teams, and other organizational structures, as products and ownership can shift.
Time-Stamping: Statements in SCITT are time-stamped, which helps address changes in entity identity (e.g., company acquisitions, project evolution) by preserving the context at the time the statement was made.
Linkage to Real-World Identity: The need to enable discovery and linkage between cryptographic/API identities and real-world identities was highlighted, but without mandating that the SCITT Ledger identity be the real-world one.

Feed Definition

Hank's PR on Feed Redefinition: The ongoing PR from Hank highlighted the need for further discussion on the "feed" concept.
Feed as a String: The current understanding is that a feed ID is a string, offering flexibility for different industries to define what it represents (e.g., a specific software release, an individual instance of a physical good, a product family).
Ownership and Authoritativeness: The discussion touched on the distinction between who makes statements about a product and who owns the product, especially in contexts like anti-malware claims or supply chain authenticity.
Feed ID as a Statement: Steve suggested that a feed identifier could itself be a signed SCITT statement, linking its identity to an issuer (e.g., Microsoft claiming ownership of a Windows feed), which could help address squatting concerns through registration policies.
Composite Feed Identifiers: Yogish suggested composite feed identities, combining organizational/vendor identity with product and version information (e.g., Microsoft/ProductX/v1.0), to provide structure while maintaining flexibility.
Physical vs. Digital Products: The discussion acknowledged different tracking needs for digital artifacts (where all copies are identical) versus physical goods (where instances may vary over time or location).

Scrappy Open API Definition (Ori's PR)

Separation from Architecture: Ori presented a proposal to separate the API definition (now called Scrappy) from the main architecture document to allow independent progression.
Core Operations: Scrappy defines interoperability points for clients to interact with a transparency service, supporting core SCITT operations: registering signed statements, retrieving receipts, and discovery/metadata endpoints.
Issuer/Signing Entity Identity Discovery: The API includes endpoints for discovering:
- Key material for the transparency service itself (for receipt verification).
- Keys associated with a specific issuer (assuming a URL-safe issuer identifier).
Statements and Receipts Endpoints: Endpoints /statements for submitting signed statements and /receipts for retrieving receipts were proposed, aligning with existing API definitions in the emulator.
Feeds as Resources: A key aspect is the concept of feeds as resource representations exposed by the transparency service.
- The API defines /feeds endpoints for listing available feeds and viewing details of a specific feed, using URLs for resource identification.
- Examples of Feed Identifiers: Ori provided examples of feed identifiers based on existing industry schemes:
  - CPE Feed: Leveraging Common Platform Enumeration (CPE) identifiers.
  - Pearl Identifier Feed: Using Package URL (PURL) identifiers.
  - GS1 Digital Link Feed: Utilizing GS1 Digital Link, which converts barcodes/QR codes into URLs to discover product information.
- Feed ID in Signed Statements vs. Transparency Service Resources: Ori clarified the distinction: an issuer includes a feed ID in their protected COSE header (which might be a generic string or GUID), and the transparency service then creates discoverable URL-based resources (feeds) from those submitted statements. The issuer might or might not know the exact URL of the transparency service's feed representation at the time of signing.
Access Control: The API hints at the need for access control considerations (e.g., OAuth 2, Scopes) for resources exposed by the transparency service.
URL vs. URI: Dick raised a point about potentially constraining feed identifiers to URLs vs. URIs, which could be broader. Ori explained that transparency service resources will naturally be URL-based due to their location-specific nature, but these can embed other URI schemes.

Decisions and Action Items

Entity Identity: The working group will proceed with the approach of allowing multiple identity schemes for entities, providing informative examples, and avoiding prescriptive enforcement of a single scheme. The term "Entity ID" is preferred over "Company ID."
Scrappy API Definition: Ori's PR for the Scrappy Open API definition will be shared on the mailing list for review and comments. The goal is to approve this PR to enable immediate testing and implementation in the emulator.

Next Steps

Mailing List Discussion: Continue discussion on the mailing list regarding specific aspects of entity identity and feed definition.
Scrappy PR Review: All participants are requested to review Ori's Scrappy API PR (linked in the agenda reminder and to be re-shared on the list) and submit comments directly on the pull request.
Emulator Testing: Once the Scrappy PR is approved, integrate it into the emulator to allow practical testing and feedback.