Refine Definition of Feed

[SteveLasker]

Copied over from: ietf-scitt/draft-birkholz-scitt-architecture#36

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 SBOM application/spdx+json or application/vnd.cyclonedx+json for the net-monitor:v1 software?
• If the contentType is a referenced statement by reference, which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload contentType of satementByReference?

[raylutz]

I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.

[ad-l]

I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.

This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.

[SteveLasker]

@ad-l, I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it?

Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.

[SteveLasker]

A note from the SCITT call on 9/24/2023
We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.

[OR13]

See:

draft-ietf-scitt-architecture/draft-ietf-scitt-architecture.md

Line 188 in 0383ec2

: an identifier chosen by the Issuer for the Artifact.

Feed: 

: an identifier chosen by the Issuer for the Artifact.
For every Issuer and Feed, the Registry on a Transparency Service contains a sequence of Signed Statements about the same Artifact.
In COSE, Feed is a dedicated header attribute in the protected header of the Envelope.

There are several problems with this definition.

1. It conflates using aggregations over an header parameter, with the header parameter.
2. It confuses how the TS uses the attribute with how the iss uses the attribute (same problem as above).

Suggested changes:

Feed Identifier:

: A feed identifier is chosen be the issuer who secured the signed statement.
Feed identifier MUST NOT be present in unprotected headers.
Feed identifier is registered in CWT Claims Registry as Tag TBD (Requested assignment 42).

Feed Resource:

: A feed resource is made available by a transparency service, 
and exposed via the SCITT API <ref scrapi>.
Transparency services MAY leverage the feed identifier 
used by the issuer to construct the identifier for feed resources on the transparency service.

Registration policies only apply to the feed identifier, they do not apply to the feed resource.

See ietf-scitt/draft-birkholz-scitt-scrapi#2 regarding the Transparency Service exposing the Feed Resource.