SCITT

Summary

The SCITT working group meeting primarily focused on reviewing open issues in the architecture document, particularly regarding inconsistent terminology and ill-defined roles (e.g., issuer vs. client, auditor vs. consumer vs. verifier). There was also significant discussion about a potential liaison with the d-bomb project, comparing their approach to SCITT's, and the need to define API capabilities and implementation policies. The idea of a separate "guidance document" was proposed to elaborate on use cases and roles, without overburdening the core architecture specification.

Key Discussion Points

d-bomb Project Liaison:
- Discussion initiated by Honesto and John regarding the d-bomb project's similarities and differences with SCITT.
- The d-bomb structure looks similar to SCITT's on a high level, but the underlying cryptographic and mechanical approaches (each organization hosting a node, setting up channels) differ significantly from SCITT's concept of sovereign receipts.
- The group expressed interest in inviting a d-bomb representative (Maddie) to present, noting Maddie's willingness. This presentation would help explore potential mappings (e.g., d-bomb channels to SCITT feeds) and understand their approach, particularly their upcoming version 2.
- It was noted that d-bomb could potentially be a vehicle for using SCITT as a transparency service.
Issue Tracker Review: Architecture Document Terminology and Roles:
- Honesto highlighted several open GitHub issues concerning consistency and definition in the architecture document:
  - Harmonizing "auditor, consumer, verifier": These terms are often used interchangeably or without clear distinction, making the document difficult to read.
  - Harmonizing "issuer, client": The "issuer" creates the signed statement, while the "client" interacts with the transparency service to send it. The distinction is not always clear, particularly concerning authentication/authorization mechanisms for the client.
  - Clarifying "signed statement" vs. "envelope": The term "envelope" appears to be a leftover from earlier document versions and adds confusion as the core artifact is a COSE_Sign1 (signed statement).
- Issuer vs. Client Roles:
  - Yogish clarified that an "issuer" is responsible for the claims within a signed statement, while a "client" is authorized to interact with the SCITT service, potentially as a different entity.
  - John emphasized that the distinction is crucial: the "issuer" relates to proof of possession of a signing key for statements, while the "client" relates to application-layer access control for network calls. The current document is vague on client access controls.
  - A suggestion was made to mention the client concept high-level in the architecture document, but detail it in the Scrappy (REST API) document.
- Auditor, Monitor, Verifier, Relying Party Roles:
  - Neil and Yogish emphasized the need for clear definitions of these roles, acknowledging that the document currently lumps them under "end user" or "consumer."
  - Hank suggested that use cases should motivate these role distinctions, and technical differentiation might not always be necessary for every term.
  - Ray suggested a higher-level API would handle these roles, while the lower-level cryptographic log API might not directly care.
  - Neil stressed the importance for the architecture document to address how the ecosystem gains trust in a log, specifically through roles like auditors and monitors who check for coherence and misbehavior, distinct from a relying party interested in a specific claim.
  - Steve suggested describing APIs and policies for implementation (like PCI compliance) to ensure expectations are met beyond just API implementation.
New US SEC Regulations:
- Dick Brooks highlighted new US SEC regulations coming into effect December 2023, describing them as a significant change in the software supply chain regulatory space, potentially larger than s-bomb work.
- The group acknowledged the potential for SCITT's trust registry to play a role in ensuring trustworthiness under these regulations, though no specific answer was available yet.
API Capabilities and Profiles:
- Ray proposed that the API should expose the "capabilities profile" of a SCITT instance, allowing clients to inquire about what the machine can do, similar to older modem interfaces. This would allow for market differentiation and future enhancements.
- John mentioned work from the Digital Twin Consortium (IIC documents on connection profiles) as a potential reference for defining such capabilities without reinventing the wheel.
Guidance Document Proposal:
- Yogish and Hank proposed creating a separate "guidance document" (an informative document accompanying the standards text) to elaborate on roles (auditor, monitor, verifier), use cases, and implementation details, without overloading the main architecture specification. This document could help implementers understand how to use SCITT to build solutions and self-identify with the standard.
New Participant Introduction:
- Casey Crossley (Schneider Electric) was welcomed to the group. She shared her background as a product security officer, leading global governance topics, s-bomb initiatives, and working with governments on product transparency. Her current focus includes implementing trust and transparency layers (like d-bomb and SCITT) for thousands of s-bombs collected by Schneider Electric.

Decisions and Action Items

Decision: The working group will invite a representative from the d-bomb project (Maddie) to present their work, comparing it with SCITT's approach. Scheduling will require at least two weeks' notice.
Action Item: Ray to continue work on the "vendor response file" document, incorporating information from the d-bomb project.
Action Item: Honesto to continue reviewing the architecture document and filing GitHub issues for inconsistencies in terminology ("auditor/consumer/verifier", "issuer/client", "signed statement/envelope") and lack of clear definitions.
Action Item: Yogish and Neil (with community input) to collaborate on drafting text to better distinguish and define roles such as "verifier," "auditor," and "monitor" within the architecture document or a proposed guidance document.
Action Item: John to open an issue in the Scrappy (REST API) document to clarify client authentication and authorization details, distinct from the issuer's identity.
Action Item: John to share hackathon videos (specifically the medical device use case) with Casey Crossley.
Action Item: John to dig out and share IIC documents on connection profiles from the Digital Twin Consortium to inform discussions on API capabilities.
Decision: The working group will consider developing a separate "guidance document" to provide further detail on use cases, roles, and implementation best practices, complementing the core architectural and API specifications.

Next Steps

The next meeting's agenda will prioritize discussion on feed structures and the Scrappy API.
Attendees are encouraged to review the open issues on GitHub and provide feedback to help progress the architecture document.
The group anticipates the d-bomb presentation, once scheduled, to inform future direction.
Work on clarifying roles and API capabilities will continue, potentially leading to a guidance document.

Session Date/Time: 21 Aug 2023 15:00

SCITT

Summary

Key Discussion Points

d-bomb Project Liaison:
- Discussion initiated by Honesto and John regarding the d-bomb project's similarities and differences with SCITT.
- The d-bomb structure looks similar to SCITT's on a high level, but the underlying cryptographic and mechanical approaches (each organization hosting a node, setting up channels) differ significantly from SCITT's concept of sovereign receipts.
- The group expressed interest in inviting a d-bomb representative (Maddie) to present, noting Maddie's willingness. This presentation would help explore potential mappings (e.g., d-bomb channels to SCITT feeds) and understand their approach, particularly their upcoming version 2.
- It was noted that d-bomb could potentially be a vehicle for using SCITT as a transparency service.
Issue Tracker Review: Architecture Document Terminology and Roles:
- Honesto highlighted several open GitHub issues concerning consistency and definition in the architecture document:
  - Harmonizing "auditor, consumer, verifier": These terms are often used interchangeably or without clear distinction, making the document difficult to read.
  - Harmonizing "issuer, client": The "issuer" creates the signed statement, while the "client" interacts with the transparency service to send it. The distinction is not always clear, particularly concerning authentication/authorization mechanisms for the client.
  - Clarifying "signed statement" vs. "envelope": The term "envelope" appears to be a leftover from earlier document versions and adds confusion as the core artifact is a COSE_Sign1 (signed statement).
- Issuer vs. Client Roles:
  - Yogish clarified that an "issuer" is responsible for the claims within a signed statement, while a "client" is authorized to interact with the SCITT service, potentially as a different entity.
  - John emphasized that the distinction is crucial: the "issuer" relates to proof of possession of a signing key for statements, while the "client" relates to application-layer access control for network calls. The current document is vague on client access controls.
  - A suggestion was made to mention the client concept high-level in the architecture document, but detail it in the Scrappy (REST API) document.
- Auditor, Monitor, Verifier, Relying Party Roles:
  - Neil and Yogish emphasized the need for clear definitions of these roles, acknowledging that the document currently lumps them under "end user" or "consumer."
  - Hank suggested that use cases should motivate these role distinctions, and technical differentiation might not always be necessary for every term.
  - Ray suggested a higher-level API would handle these roles, while the lower-level cryptographic log API might not directly care.
  - Neil stressed the importance for the architecture document to address how the ecosystem gains trust in a log, specifically through roles like auditors and monitors who check for coherence and misbehavior, distinct from a relying party interested in a specific claim.
  - Steve suggested describing APIs and policies for implementation (like PCI compliance) to ensure expectations are met beyond just API implementation.
New US SEC Regulations:
- Dick Brooks highlighted new US SEC regulations coming into effect December 2023, describing them as a significant change in the software supply chain regulatory space, potentially larger than s-bomb work.
- The group acknowledged the potential for SCITT's trust registry to play a role in ensuring trustworthiness under these regulations, though no specific answer was available yet.
API Capabilities and Profiles:
- Ray proposed that the API should expose the "capabilities profile" of a SCITT instance, allowing clients to inquire about what the machine can do, similar to older modem interfaces. This would allow for market differentiation and future enhancements.
- John mentioned work from the Digital Twin Consortium (IIC documents on connection profiles) as a potential reference for defining such capabilities without reinventing the wheel.
Guidance Document Proposal:
- Yogish and Hank proposed creating a separate "guidance document" (an informative document accompanying the standards text) to elaborate on roles (auditor, monitor, verifier), use cases, and implementation details, without overloading the main architecture specification. This document could help implementers understand how to use SCITT to build solutions and self-identify with the standard.
New Participant Introduction:
- Casey Crossley (Schneider Electric) was welcomed to the group. She shared her background as a product security officer, leading global governance topics, s-bomb initiatives, and working with governments on product transparency. Her current focus includes implementing trust and transparency layers (like d-bomb and SCITT) for thousands of s-bombs collected by Schneider Electric.

Decisions and Action Items

Decision: The working group will invite a representative from the d-bomb project (Maddie) to present their work, comparing it with SCITT's approach. Scheduling will require at least two weeks' notice.
Action Item: Ray to continue work on the "vendor response file" document, incorporating information from the d-bomb project.
Action Item: Honesto to continue reviewing the architecture document and filing GitHub issues for inconsistencies in terminology ("auditor/consumer/verifier", "issuer/client", "signed statement/envelope") and lack of clear definitions.
Action Item: Yogish and Neil (with community input) to collaborate on drafting text to better distinguish and define roles such as "verifier," "auditor," and "monitor" within the architecture document or a proposed guidance document.
Action Item: John to open an issue in the Scrappy (REST API) document to clarify client authentication and authorization details, distinct from the issuer's identity.
Action Item: John to share hackathon videos (specifically the medical device use case) with Casey Crossley.
Action Item: John to dig out and share IIC documents on connection profiles from the Digital Twin Consortium to inform discussions on API capabilities.
Decision: The working group will consider developing a separate "guidance document" to provide further detail on use cases, roles, and implementation best practices, complementing the core architectural and API specifications.

Next Steps

The next meeting's agenda will prioritize discussion on feed structures and the Scrappy API.
Attendees are encouraged to review the open issues on GitHub and provide feedback to help progress the architecture document.
The group anticipates the d-bomb presentation, once scheduled, to inform future direction.
Work on clarifying roles and API capabilities will continue, potentially leading to a guidance document.