Markdown Version | Session Recording

Session Date/Time: 27 Feb 2023 16:00

SCITT

Summary

The SCITT working group session focused primarily on the status of the architecture document and a detailed discussion on terminology, particularly around the core components of a SCITT system. Key issues were the preferred term for the operational instance of a SCITT service (e.g., "transparency service," "registry," "e-notary") and the conceptual roles and interactions of components like the notary, ledger, and policy mechanisms.

Key Discussion Points

• Architecture Document Status:
  • The previous architecture document repository has been archived, and all open issues and pull requests have been migrated to the new working group repository.
  • Issues that were already resolved in the old repository were closed during the migration.
  • A specific issue (Issue 15) covers the overhaul of terminology throughout the documents.
• Terminology for Core SCITT Instance:
  • Discussion revolved around various terms used in the drafts: "transparency service" (with/without acronym), "registry," "SCITT implementation," "ledger."
  • A sense of those present indicated "transparency service" was the preferred term for the running instance of the system.
  • Hank highlighted an existing Pull Request (PR) aimed at consolidating terminology, refining terms like "assertion," "statement," and "transparent statement," and addressing the inconsistencies in the use of "registry," "log," "ledger," and "transparency service."
• Roles of Transparency Service, Notary, and Policies:
  • Dick's perspective: Sought clarity on what a "transparency service" (TS) operates or maintains (e.g., a "registry"). Asked if a TS has policies dictating what it records and provides. Raised concerns about the "truthfulness" of recorded statements versus just verifying signatures/identities. Used analogies of specialized registries (deeds, Carfax) to suggest different TS instances might focus on different types of statements.
  • Roy's perspective: Emphasized that the "notary's" role is to verify identity and signature, not the truthfulness or accuracy of the document's content. Stated that the notary captures data used for identity validation (e.g., driver's license snapshot) and allows for auditing. Mentioned that there could be separate policies: one for the notary regarding acceptable identity providers, and a second for Role-Based Access Control (RBAC) related to product ownership and allowed content types.
  • Hank's elaboration: A transparency service is understood to be composed of at least an append-only log, a receipt generator, and a gateway function for registration policies (e.g., based on issuer). The notary is a role, and the application of registration policy and receipt issuance are closely related to ledger operations.
  • Cedric's question: Raised an internal team's concern about the need to distribute and smear across multiple e-notary systems for redundancy and higher volume, potentially requiring an "outer wrapper" for transaction IDs. He questioned the one-to-one relationship between e-notary, policy, and ledger.
  • Steve's response to Cedric: Acknowledged the need to address scalability, redundancy, and migration scenarios, and stated he would follow up internally on the distribution issue and post to the mailing list.
• Ray's Architectural Disagreement:
  • Expressed fundamental disagreement with the current diagram's depiction, particularly regarding the "e-notary" as a flow-through gatekeeper and the "transparency service" encapsulating the submission process.
  • Suggested that identity determination needs more prominence.
  • Proposed distinguishing between a "registry submission service" (with a potentially low threshold for entries, focusing on a root hash and semantic name, alongside associated storage) and a separate "transparency service" whose role is to look at and inspect the ledger and storage area, not to change it.
  • Argued that an overly strict e-notary upfront could become a bottleneck and mislead users into believing everything on the ledger is fully trusted and true, which might not be the intent (i.e., it could be an "evidence collector" rather than a "conclusion collector").
  • Believed "transparency" implies observation and inspection, not submission.
  • Noted the challenge of an append-only ledger growing without bound, necessitating sunsetting or chunking.
• Discussion on Performance and Trust Thresholds:
  • John's point: Suggested that a "fast path" for trusting software could involve running a separate SCITT instance with a restricted policy.
  • Roy's counter-point to Ray/John: Questioned the efficiency of allowing "random stuff" into a ledger and then filtering it later. Raised concerns about replication delays if multiple instances are used as filtering gates, especially for evolving claims like CVEs and VEX reports. Emphasized the distinction between the signature on content and the identity used for RBAC to write to the ledger.
  • Hana's concern: Worried the discussion was drifting from terminology to performance optimizations, potentially delaying progress on the architecture document. Steve acknowledged that performance considerations are already influencing conceptual decisions.
  • Neil's clarification: Agreed with Ray on the nature of a transparency log as a low-level evidence provider. Suggested that the "transparency service" (or log) itself doesn't guarantee "truth," but an external "relying party policy evaluation thing" uses the evidence to make its own trust determinations.

Decisions and Action Items

• All open issues from the old (archived) architecture document repository have been successfully migrated to the new working group repository.
• ACTION: Steve to follow up internally on the question of e-notary distribution, redundancy, and cardinality, and then post an update to the mailing list.
• ACTION: Ray to create a drawing illustrating his alternative architectural perspective, focusing on the distinction between submission and observation/interpretation, and share it with the working group.
• ACTION: Working group members are requested to review Hank's Pull Request (PR) related to terminology overhaul (Issue 15).
• ACTION: Hana to send a reminder to the mailing list for review of Hank's PR.

Next Steps

• Continue the discussion on core terminology and architectural concepts, taking into account the different perspectives presented, particularly Ray's forthcoming diagram.
• Review Hank's terminology PR to work towards a consistent vocabulary.
• Address the scalability and distribution concerns for e-notary instances and their impact on the overall architecture.