**Session Date/Time:** 22 May 2023 15:00

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

## Summary

This virtual interim meeting of the SCITT working group primarily focused on a new open issue regarding "URLs for transparent statements" (issue #46) raised by Cedric. The discussion delved into the purpose, benefits, and challenges of standardizing a method for referring to previously registered transparent statements, touching upon discoverability, data compactness, offline verification, and the implications for various use cases, including federated transparency services and air-gapped environments. While no formal decisions were made, the discussion provided significant clarity and identified several action items for further refinement and mailing list discussions.

## Key Discussion Points

*   **Meeting Logistics:** The chairs noted a last-minute change to the meeting time and a known Google Calendar bug affecting some users. The standard IETF rules, including IPR, apply.
*   **Agenda Hacking: Key Transparency (KT) WG:** John raised an urgent point about the Key Transparency working group, currently in chartering discussion. It appears KT's use cases might largely sit on top of SCITT, suggesting a need to ensure alignment of primitives between the two efforts.
*   **Open Issues Triage:** Steve mentioned existing open issues, including Merkle tree proofs (issue #45), and the need to triage older issues carried over from previous work. Issues with no activity could be closed, with an option for reactivation.
*   **Discussion on "URLs for transparent statements" (Issue #46):**
    *   **Purpose:** Cedric introduced issue #46, proposing a standard way to refer to a previously registered transparent statement. This is crucial for multi-statement registration policies and federation across multiple transparency services.
    *   **Proposal:** The proposed syntax combines a locator with a commit hash.
    *   **Discoverability Models:** Cedric outlined two models: an opaque, hash-based approach (where an external index resolves the hash) and an explicit model (where the locator identifies the specific transparency service). A core concern is preventing the locator from being interpreted as a promise of perpetual availability or rich query support by the transparency service.
    *   **Dick Brook's Input:** Dick highlighted the need to identify different "declaration types" for statements related to the same object, suggesting registration policies could define these. Cedric clarified the proposal's scope is for identifying a *specific* registered statement, not a general query language.
    *   **Use Cases and Compactness:** Johannes questioned the federation use case beyond compactness. Cedric explained that referring to a commitment is more transparent and secure than replicating full statements, especially for recursive references (statements referring to other statements) or replacing older statements (e.g., firmware updates).
    *   **Full Statement vs. Reference:** Hank initially misinterpreted the reference as applying only to the payload but later understood it refers to the *full-fledged transparent statement* (signed statement + receipt). He noted the utility for different algorithm layouts and potential for DID Web-like identification.
    *   **Permanence and Staleness:** Concerns were raised regarding the expectation that transparency services would forever preserve references. Hank suggested maintenance processes for stale statements. Cedric proposed that persistence requirements (e.g., "persist for five years") could be semantics within specific headers in the registration information, managed by registration policies, not inherent to the reference itself.
    *   **Air-gapped and Offline Systems:** Charlie argued against a reference-only approach for scenarios not reliant on internet connectivity (e.g., historical artifacts, physical goods, air-gapped software). He advocated for an *option* to include the full attestation data within the statement. Cedric clarified that local verification of a reference is possible if both the referring and referred statements are available offline (e.g., by recomputing a hash), but he strongly opposed putting full copies of other statements directly into the log due to scalability and security concerns.
    *   **Historicity and Incremental Data:** Ray presented use cases requiring tracking incremental data (e.g., election results, software versions, test reports). He proposed a "meta-submission" concept where a later submission refers to earlier ones, and suggested the need for non-obscure metadata (manufacturer, product ID) to enable discovery of related entries in the ledger, especially for legal and compliance needs (e.g., recalling specific software versions).
    *   **Technical Details on URI Schemes:** Johannes raised a technical point about using the DID Web URI scheme, suggesting it might be more appropriate to use a URN or define a new URI scheme, as DID Web is primarily for identifying DIDs, not statements.

## Decisions and Action Items

**No formal decisions were made regarding the issue during the meeting.** The discussion helped clarify the scope and implications of the proposal.

**Action Items:**

*   **Cedric:** Refine the description of issue #46, particularly clarifying the motivation for references beyond just compactness, and emphasizing that local verification of references does not inherently require online lookups.
*   **Ray:** Submit written comments to the mailing list detailing his use cases concerning incremental data, "meta-submissions," and the need for non-obscure metadata (like manufacturer and product ID) for discoverability and historicity in the ledger.
*   **Johannes:** Provide specific technical comments on the mailing list regarding the appropriate URI scheme for referring to statements (e.g., exploring URNs or new URI schemes instead of DID Web).

## Next Steps

*   Continue the technical discussion on "URLs for transparent statements" on the SCITT mailing list, incorporating the refined proposal and new use cases.
*   Further explore the implications of SCITT's architecture for handling air-gapped environments, data historicity, and discoverability of information within potentially opaque statements.
*   Monitor and engage with the Key Transparency WG chartering process to ensure alignment of primitives and use cases.