SCITT Components

scenarios/fuel-pump.md

@@ -0,0 +1,6 @@
+# Hardware-Fuel Pump Scenario
+
+> TODO: 
+> - Builds on the IETF fuel pump scenario
+> - Shows how SCITT supports specific instances of a product, where software has multiple copies that are all exactly the same, while hardware is multiple instances that evolve on their own (fuel pump drift between hot and cold climates)
+> 

scenarios/redirection-revocation.md

@@ -0,0 +1,10 @@
+# SCITT Redirection and Revocation
+
+> TODO: 
+> - When should revocation actually be used?
+> - How to provide granularity, so revocation doesn't become a global DOS of the software supply chain
+> - Identity theft, vs. individual artifact problems
+> - H2 handle a new version is available
+> - H2 handle an artifact is considered problematic, and for what circumstances is it problematic
+> - H2 end of life of support, vs. it's "expired", and what does "expired mean"
+> - Tease out elements of the Asbestos scenario from [Roles and Responsibilities of Signing, SBoMs, and Security Scanners](https://stevelasker.blog/2022/01/11/roles-and-responsibilities-of-signing-sboms-and-security-scanners/)

scenarios/sbom.md

@@ -0,0 +1,4 @@
+# The SBOM Scenario
+
+> NOTE: intended to utilize the existing SBOM doc, with pointers to how it leverages the SCITT foundations, enabling us to iterate on the specifics of what SCITT provides and why
+

scitt-components.md

@@ -0,0 +1,26 @@
+# SCITT Components
+
+SCITT provides a set of components enabling Supply Chain, Integrity, Transparency and Trust. 
+(See [What Is SCITT][WHAT_IS_SCITT])
+But what are the scenarios that SCITT enables?
+This collection of docs will describe the core components of SCITT, and how it can be enabled and extended to support a breadth of use cases.
+
+As SCITT is in active design through the [IETF SCITT working group][SCITT_IETF_WG], these documents aim to facilitating various design discussions, based on a set of SCITT primitives and scenarios that benefit from the SCITT primitives.
+
+## Table of Contents
+
+The following is a list of documents we'll round out to enable discussions:
+
+- [What is SCITT][WHAT_IS_SCITT]: a quick overview
+- [One or Many Instances of SCITT](./scitt-components/one-or-many-instances.md): design goals and philosophy
+- [Original and Updated Claims & Evidence](scitt-components/categories-of-claims-evidence.md): How SCITT supports a continual stream of updates
+- [Indexing Content Types](scitt-components/scitt-indexing.md): How SCITT is extensible to enable new, evolving content types
+- [RBAC](scitt-components/scitt-rbac.md): How SCITT enables limited access
+- [Claims and Endorsement Format](scitt-components/claim-endorsement-spec.md): Discussion why SCITT needs a simplified format for the claims, with links to the evidence
+- Scenarios SCITT Enables
+  - [SBOM](scenarios/sbom.md): Evidence, initiated at creation time
+  - [Revocation](scenarios/redirection-revocation.md): Claims that are continual updated as info of the product is learned.
+  - [Fuel Pump Certification](scenarios/fuel-pump.md): hardware scenario where multiple instances of a product (the serial number) have individual claims and evidence
+
+[SCITT_IETF_WG]:  https://datatracker.ietf.org/group/scitt/
+[WHAT_IS_SCITT]:  https://ietf-scitt.github.io/scitt-web/

scitt-components/categories-of-claims-evidence.md

@@ -0,0 +1,13 @@
+# Categories of Claims and Evidence
+
+There are two main categories of information about any supply chain:
+
+1. What was known when the product was created?
+1. What has been learned, since the product was created?
+
+## TODO:
+
+Describe the types of information that is
+
+- known at creation time. Including information that would be publicly disclosed, what might be kept for auditors, and what is kept in case bad stuff happens, and details are needed to remediate
+- 

scitt-components/claim-endorsement-spec.md

@@ -0,0 +1,9 @@
+# Claims & Endorsement Specification
+
+> TODO: 
+> - Why a spec for a claim is important, enabling query capabilities
+> - Delta of a claim vs. evidence
+> - Assumed it's the content of the COSE payload
+> - Discussion for known claim values, likely with namespaces, enabling consumers to identify if a product is good for production, vs build, energy vs. gaming, financial vs. government, high security vs. critical security
+> - Why simple name/value pairs are too simple
+> - Why SBOM/in-toto formats are perfect for evidence types, but too complex to be the format for the claims placed on the ledger

scitt-components/one-or-many-instances.md

@@ -0,0 +1,15 @@
+# One or Many Instances of SCITT
+
+This document frames the design philosophy for multiple instances of SCITT, and how they interoperate with each other.
+
+## Topics to Cover
+
+- One global instance for all package types (public and private)
+  - The simplicity with the pros and cons
+- Instances aligned with the distribution of projects & products
+  - A single instance for each software vendor/oss project?
+  - Instances of SCITT alongside the existing package managers/distribution points
+- Private instances, for companies to manage their internal development
+- How SCITT information is promoted across instances, and maintained as a constant stream of updates
+- Public and Private networks
+- Public and restricted access

scitt-components/scitt-indexing.md

@@ -0,0 +1,10 @@
+# Indexing Specific Content Types
+
+> TODO:
+> - SCITT must provide some level of indexing to find the most basic information (does artifact _**a**_ have claim _**b**_, but only return claims if it was submitted by identities _**x,y,z**_)
+> - How will SCITT support new content types, who's evidence is stored in associated storage? Some SCITT instances will support SPDX, others CycloneDX. What happens when a new format appears (VEX as an example). Can the "vex team" implement a new indexer that any SCITT instance can add? Can SCITT provide an extensibility model enabling this pattern?
+
+> Assumptions:
+> - SCITT doesn't store evidence on the ledger
+> - SCITT has associated storage, or at least a PURL to find the evidence on some storage system
+> - SCITT should provide query capabilities to query ont he info in the SCITT ledger, with extensibility to AND information that is stored externally. The returned results would provide PURLs (assumed to be a purl) to the location of the storage. This enables various subsystems to store content types, with SCITT adding value as a central indexing system, without owning the content

scitt-components/scitt-rbac.md

@@ -0,0 +1,5 @@
+# SCITT Role Based Access Control
+
+> TODO:
+> - Why we need limited access to information submitted to SCITT 
+> - Will SCITT support partitioned access within a SCITT instance, or will a SCITT instance be limited and only approved content is promoted to another SCITT instance that has broader access?