Session Date/Time: 12 Feb 2024 16:00

SCITT

Summary

This virtual interim meeting focused on reviewing the SCITT architecture draft (version 05) and discussing key technical points in preparation for a last call targeting IETF 119. Primary topics included the scope of registration policy and initialization, the nature of verifiable data structures and receipt persistence, and the process of receipt verification. Several action items were assigned to refine the draft based on these discussions.

Key Discussion Points

General and Logistics

The meeting operates under the IETF's Note Well.
Participant names are recorded by the system, negating the need for manual blue sheets.
The working group's focus is on bringing the draft to a last call at IETF 119, prioritizing time-based progress and quality.
A shift in review focus from GitHub issues/PRs to DataTracker drafts was noted, though GitHub remains a follow-up location.
The chair reiterated the IETF motto of "rough consensus and running code," encouraging resolution of long-standing issues, aided by existing implementations.

Draft 05 Status

Appreciation was expressed for the authors and editors in preparing draft-05, acknowledging simplifications and remaining discussion points.
The draft-05 reflects efforts to trim and refine the specification, potentially "swinging the pendulum far" on some definitions.

Registration Policy and Initialization

Background: An issue was raised regarding the prior "overboard" definition of registration policy, which led to an undefined and circular problem. The intent of recent PRs was to reduce policy.
Initialization Concerns (Hank): While policy was reduced, some remains, particularly concerning Ledger initialization (e.g., how to "kickstart" the first entries, such as the initial key material for the transparency service owner). This refers to a "key before signature" axiom. The question is whether this is an application problem or requires policy in the spec.
Configuration Idea (John): At IETF 118, the concept of a "configuration" was introduced to include elements like the service's public key and registration policy. This was seen as a way to encapsulate "key before signature" or "policy before enforcement" without over-specifying Merkel tree details.
Optional Policy (Steve): If registration policy is thin, should it be possible for an instance not to create one, allowing a nil registration policy that verifiers can choose to accept or reject?
Explicit Empty Policy (John): It was argued that an explicit "empty policy" is more useful than silence or nil for the spec's shape, defining how services can publish their policies, and aiding users in deciding whether to interact with a service.
Conclusion (Hank): There is room for improvement. If an easier way to reduce policy without "too much policy" remains, it should be explored.

Verifiable Data Structures and Receipt Persistence

Registration Process (Hank): Registration involves processing a signed statement, adding a digest to an append-only log, and creating a receipt. The "transparent statement" is created outside the transparency service by embedding the receipt into the signed statement.
Verifiable Data Structures (John): The core concept is the "verifiable data structure" (VDS), which produces receipts for bytes. While RFC 9162 uses hashes, other VDS could store more complex data. The normative reference should be to a VDS that supports inclusion proofs. "Adjacent services" handle operations beyond fundamental receipt production. The fundamental operation is a signed statement in, asynchronous receipt out.
Asynchronous Receipts (Robin): It would be useful to avoid requiring receipts to be part of an immediate request loop. The architecture should accommodate fetching receipts asynchronously, potentially much later (e.g., a year), provided the receipt is provably identical to what would have been issued at the time. This offers flexibility.

Receipt Verification / Round Trip

User Check (Ray): It is essential for users to be able to check an item against the transparency service to confirm it matches what was originally put in. Does a receipt stand alone, or does it require a round trip to the TS for authentication?
Verifiable Data Structures (John): Receipts generated by VDS are almost stand-alone. Verification requires a small number of facts (e.g., the correct transparency service state, the correct tree). The choice of how to obtain and trust these facts is application-specific and depends on the threat model (e.g., an "evil Corp" scenario where a TS could lie years later). The architecture should not preclude systems from indexing or returning/comparing items, but might not need to normatively codify the exact mechanism due to varying use cases.
Root of Trust (Ray): Clarification was sought on how a standalone blob of data could verify itself without reference to another root of trust (e.g., a public key registrar).
Application Specificity (John): The "extra piece of information" needed for verification (the TS state) and the trust placed in its source are use-case specific. Specifying a single approach for all scenarios is difficult.

Issuer Live Verification (Revisited)

Requirement Clarification (Robin): Is there a requirement for the transparency service to perform "live verification" of the signed statement issuer before adding the statement to the log?
No Initial Expectation (Hank): Absent other explicit policy (e.g., configuration, API-defined rules), there is initially zero expectation on the transparency service for such agency verification. The minimum expectation is that the item will be added to the verifiable data structure.
Editorial Cleanup (John): This aligns with ongoing discussions on the mailing list suggesting some "hangover" text related to this topic can be removed.

IETF 119 / Hackathon Planning

Brisbane Planning (Ray): The possibility of starting to plan for IETF 119 and its hackathon was raised.
Candidate Draft (John): The primary goal for 119 is to have a candidate draft. Discussions should avoid opening new significant issues. Hackathon outcomes are always welcome.
Use Case Implementation (Ray): Ray plans to write up a specific use case with actual code to clarify understanding of the data structures, with assistance from Hank.

Decisions and Action Items

Registration Policy / Initialization PRs:
- ACTION: John W. to create an editorial PR for the registration policy and initialization section, aiming for clarity and reduced ambiguity.
- ACTION: AJ to create a PR focusing on the potential removal or significant reframing of the initialization conversation.
Asynchronous Receipt Latency Issue:
- ACTION: Robin to create a GitHub issue for accommodating asynchronous receipt fetching/conveyance, including potential security implications for the Scrappy document.

Next Steps

The primary focus is on resolving the open issues and implementing the agreed-upon PRs related to registration policy and initialization.
Continue preparing the draft for IETF 119 to meet the last call deadline.
Participants are encouraged to engage with the PRs, issues, and mailing list.
Ray will develop a code-based use case to further clarify the data structures.