Session Date/Time: 03 Jul 2023 15:00

SCITT

Summary

The SCITT Working Group discussed the status of hackathon planning, outstanding issues with the registration policy text in the architecture document, and architectural boundaries. A significant part of the discussion focused on the nuance of registration policies, particularly how a transparency service's identity configuration changes could be detected by consumers, and the need to avoid "locking up" implementations into specific cryptographic choices. The group also briefly touched upon the formation of the Key Transparency Working Group (Keytrans), highlighting potential synergies and areas for collaboration or non-overlap.

Key Discussion Points

Hackathon Planning: Initial discussions are underway for the hackathon. An outreach to the Federal Drug Administration (FDA) sought validation for proposed hackathon activities relative to their new rules, aiming for general alignment rather than commitment or participation due to bureaucratic barriers. The need to "rehash" hackathon plans was acknowledged.
Introductions: John, co-founder of Gosh.io, introduced himself, highlighting his background in securing software supply chains, blockchain development, and prior experience with standards in DOCSIS and ITU-T.
Agenda Review: The agenda was adjusted to prioritize discussion of the Key Transparency Working Group (Keytrans) due to its ongoing charter approval process and upcoming Birds of a Feather (BOF) session.
Registration Policy and Architectural Boundaries:
- John P.'s Review: John P. presented his findings on the registration policy. He noted that the core definitions of "feed" and "registration policy" in the architecture document are largely aligned with discussions, but numerous side references imply slightly different things and require "surgery" to clarify. He also raised concerns about the implicit "two-sided" nature of policies (server-imposed vs. client hints), the client expressing strong preferences, and the specific mention of rbac (suggesting a broader "access control").
- Cedric's Clarification: Cedric reiterated that only a few registration policies (e.g., signature checking, correct entity) should be normative, while practical use cases will involve many meaningful, but non-normative, policies. He stressed that the registration-info header is for providing input to policies, not for clients to demand specific outcomes. He agreed that rbac was an "accident" and should be generalized to "access control."
- Roy's Concern on Policy Changes: Roy consistently raised a critical concern regarding how a consumer of transparent statements can detect when the transparency service's identity configuration (e.g., which DID methods like Sigstore or DID Web it allows) changes or "weakens." He emphasized that simply trusting the transparency service is insufficient if its underlying policy for accepting identities shifts, and there's no current mechanism in the architecture to audit or track such changes in receipts, especially in disconnected scenarios or federations.
- Responses to Roy: John P. suggested that system-level solutions, such as signed statements from the platform updating its policy or cryptographic proofs within a Merkle tree, could address this, but acknowledged it's a complex area. Hannes drew an analogy to land records registries, supporting the idea of trusting the data in the registry and defining strong SCITT processes. Ori highlighted that policies are crucial for specific business processes but reiterated that the core SCITT architecture focuses on minimal cryptographic requirements, not comprehensive security guarantees for all policy changes. He acknowledged Roy's point about a transparency service lowering its standards being hard to detect.
- John K.'s Architectural Concern: John K. expressed concern that the current draft might "lock up" into particular implementations, citing that his blockchain service uses a modified binary Oracle tree and would be unable to comply if a specific Merkle tree implementation was mandated. Hannes clarified that most recent changes have been cosmetic rather than fundamental shifts that would impose specific implementations.
- Feed Definition Nuance: Ray questioned the definition of "feed" in Section 6.1 (issuer's name for the artifact) versus a broader understanding of a "pub/sub topic." Hank clarified that a feed is indeed a topic related to a product, with potential for hierarchical subtopics in the future, but currently kept simple. He explained that minimal viable registration policies include restricting issuers and DID methods.
- Software Identity: Hannes noted an ongoing debate within CISA and USDHS regarding software identity and its relevance to SCITT's registration policies, emphasizing the need for a unique identifier for software products.
Key Transparency Working Group (Keytrans) Formation:
- There is an ongoing call for approval for the Keytrans WG charter, with a Birds of a Feather (BOF) session planned for IETF 117.
- The Keytrans proposal aims to bind user identities to public keys, with specific privacy requirements often using BRFs (Blind Ring Signatures). It also includes a more elaborate API.
- Hank's Interoperability Concern: Hank expressed concern about avoiding the creation of parallel, non-interoperable structures between SCITT and Keytrans. He suggested finding proponents at IETF 117 to ensure synergy, interoperability, and learning from each other's approaches.
- Cedric's Perspective: Cedric clarified that the current vote is only for the Keytrans charter, not a specific technical document. He suggested viewing Keytrans as a "supply chain for public keys" and exploring similarities with SCITT. He noted that Keytrans' critical need for labeled Merkle trees for lookups (not just inclusion proofs) could distinguish it from SCITT or require extending SCITT's scope.

Decisions and Action Items

Decision: The agenda was modified to prioritize the Key Transparency discussion.
Action Item (Roy): Create a new issue in the GitHub issue tracker to specifically address the problem of detecting changes in a transparency service's identity configuration or policy by relying parties.
Action Item (Hannes): Reach out to Steve to ensure the architecture document is submitted by the deadline (next Monday).
Action Item (Hannes): Create a Pull Request (PR) for the registration policy based on the discussion, focusing on clarifying non-normative examples and cleaning up side references.
Action Item (John P.): Propose text specifically for the "feed" issue, particularly clarifying its scope in relation to registration policies, as part of the broader registration policy PR.
Action Item (John K.): Review the editors' copy of the architecture document (draft-ietf-scitt-architecture.md) to identify and provide feedback on any sections that might "lock up" implementations into specific choices (e.g., particular Merkle tree types).
Action Item (Hannes): Initiate discussion on the mailing list regarding the hackathon plans.

Next Steps

Continue discussions on hackathon planning on the mailing list.
The Working Group will hold another call next Monday to continue these discussions and potentially finalize last-minute fixes for the document submission.