Compound User Story / Sequence Diagram

As a consumer, I want to understand if I should trust an artifact
As a producer, I want to be assured that the integrity of my artifacts has been reviewed by a trusted 3rd party.

sequenceDiagram
    participant Issuer
    participant Notary
    Note left of Issuer: I take responsibility for the artifacts I produce
    Issuer ->> Notary: These are the policies I am committed to meeting
    Issuer ->> Notary: I stand by my claims about my artifact
    loop Claims Check
        Notary ->> Notary: Review relevant claims and policies
    end
    Notary ->> Issuer: Here is my endorsement and receipt
    Consumer->>Notary: Is this artifact safe to use?
    loop Endorsement Check
        Notary->>Notary: Review relevant claims and endorsements
    end
     Notary ->> Consumer: You can trust this artifact, the endorsement is still valid
     Note right of Consumer: I have confidence in the artifacts I consume

We need documentation around SCITT and RATS focusing on how they interact, overlap and what specific problems they solve (use case documentation)
Issue created for tracking

Under Terminology we define:

Statement:- any serializable information about an Artifact. To help interpretation of Statements, they must be tagged with a media type (as specified in [RFC6838]). For example, a statement may represent a Software Bill Of Materials (SBOM) that lists the ingredients of a software Artifact, or some endorsement or attestation about an Artifact.

Haven't we been using Evidence as the term? Users submit claims, which have optional evidence to support the claim.

When specific and detailed claims are provided an advanced policy might be applied.

If only shallow / simple claims are provided, there is not much of an opportunity to apply advanced policies.

The architecture document currently defines 'artifact' as the 'physical or non-physical item that is moving along the supply chain'. In other forums, different terms are used, for example: 'supplied good', 'product', 'asset'.

We discussed a future revision where claim and receipt are visualized next to each other.

https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/pull/23/files#r1001967472

At IETF-115, discussions involved:

• Leverage existing IETF and/or W3C definitions and terms, or at least not conflict and cause confusion with existing terms.
• Minimize the concept count

Existing Standards Terminology

• IETF: Remote Attestation Procedures Architecture (RATS)
• IETF: SCITT Architecture
• IETF: RFC7519

Proposal

Claim conflicts with RATS and W3C

Comparison of terms across orgs as the object changes state:

Instead of transitioning from statement to claim to transparent claim, what if we used statement as the base concept:

• Statement --> Signed Statment --> Transparent Statement

The architecture I-D, and other docs use Registry and Transparency Service (TS) interchangeably.

This issue is about consistent naming, and what we should use for an implementation that hosts the SCITT standards.
As we've discussed various terms, I'm pasting a "thousand words" to highlight conceptual components.

How do we finish this sentence:
The user will submit a signed statement/claim (see issue #34) to the ___

1. The thing we're trying to name here, which is an implementation of a service.
2. The eNotary component that evaluates the Registration Policy (3) before proceeding
3. The Registration Policy, as the gatekeeper for what may be submitted to the ledger.
4. The eNotary counter signing key/service
5. The ledger, where statements/claims are persisted
6. The ledger of a ___ (1) may be implemented through various "ledger databases", such as Azure CCF, QLDB, Trillian

This issue is to discuss what we call (1)
Please "vote" with a comment, representing a number, and any supporting thoughts:

1. Transparency Service (with no acronym)
2. Registry
3. SCITT Implementation
4. Transparency Service (TS as a acronym)
5. write in your own

This issue deals with documenting overlap between SCITT and RATS Terminology and identifying core differences

On the call reviewing: IETF RATs Overview

Orie said:

In W3C VCs “Issuers" produce both “attestations (claims in their words) and evidence (evidence in their words).

Orie said:

I think a “SCITT Notary" is a "RATs Verifier”

Monty said:

I would think SCITT defining the distribution of Reference Values (RV) in the RATS model. The Notary "certifies" that the RV is valid. Verifiers take as input (as shown on slide 6) the RVs from SCITT.

Henk said:

In "RATS round 1", the registry (replicated nodes) take on the role of Attester, I think
In "RATS round 2", the issuers take on the role of Attester, I think

A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report.
The current definition likely needs to expand a bit to account for:

• What are the versions of a specific artifact
• What are all the statements for a version of an artifact
• What is the latest statement for a specific contentType of a specific versioned artifact: (eg: what's the latest VEX for the net-monitor:v1 software?
• If the contentType is a referenced statement by reference, which stores SBOMs, VEX, Scan Reports, how do we drill into each if they all use the same payload contentType of satementByReference?

Tracking the freezing this repo, (with the archive flag) as this work has moved to draft-ietf-scitt-architecture

At IETF 115 there were discussions on having some kind of standard way to deal with statements by reference. Here are also the two relevant slides from https://datatracker.ietf.org/doc/slides-115-scitt-combined-scitt-presentations/:

Simply using COSE detached payloads as defined in the RFC would not be sufficient as the payload would still be required during signature validation when registering the signed statement.

Instead, having a specific content type for referencing external statements may be useful. Note that this format by itself would be a statement.

RFC 9054 gives two examples for such hash structures:

COSE_Hash_V = (
    1 : int / tstr, # Algorithm identifier
    2 : bstr, # Hash value
    ? 3 : tstr, # Location of object that was hashed
    ? 4 : any   # object containing other details and things
    )

and

COSE_Hash_Find = [
    hashAlg : int / tstr,
    hashValue : bstr
]

SUIT's digest container defines this as:

SUIT_Digest = [
  suit-digest-algorithm-id : suit-cose-hash-algs,
  suit-digest-bytes : bstr,
  * $$SUIT_Digest-extensions   ; described as optional extra values required by a hash alg (?)
]

Would having a variant of one of the above as a CBOR content type address this issue?
Should location of the referenced content be included? How? Should location hints be globally unique? Resolvable?
Should a SCITT transparency service know about this content type and at least validate its CDDL schema?

At the moment the architecture diagram looks a bit unclear. Adapt to and make it compile (and look nice) with aasvg would be a good enhancement.

Case 0

• Public Read
• Private Write

Case 1

• Private Read
• Private Write

When holding an endorsement, one might be be able to verify directly in a public read, or rely on an auditor in the case of a private read scenario.

Is there a need for reg-info to be compact?
Currently we use text string labels in the reg-info map, which are less compact than integer labels.

Reading the architecture doc, I see TS, meant to refer to a Transparency Service. I keep reading this as Time Stamp service.
Could/should we replace TS with SCITT, as that is the term we're using.

The current definition of a statement says:

Statement:
any serializable information about an Artifact. To help interpretation of Statements, they must be tagged with a media type (as specified in [RFC6838]). For example, a statement may represent a Software Bill Of Materials (SBOM) that lists the ingredients of a software Artifact, or some endorsement or attestation about an Artifact.

The proposal is to assure the SBOM, as an example content that is being added to the registry, has a means to be stored outside the ledger, but verified by the ledger.
On submission to the ledger, the SBOM is referenced, but not directly embedded in the statement. This allows the registry to optionally index the content. A particular instance may put the content on the ledger, or store it alongside the ledger.