Code change:
PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL 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 of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
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.
NAME 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.
A note from the 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.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM

Related discussion:
text: Identifier DID-CORE) of the signer, as a string. "did:web:example.com" is an example of a DID. <del> Feed (label: "TBD", temporary: "392"): The Issuer's name for the Artifact, as a string. </del> <ins> Subject (label: "TBD", temporary: "392"): The Subject to which the Statement refers, as a bytestring, chosen by the Issuer. </ins> Content type (label: "3"): Media type of payload, as a string. For example, "application/spdx+json" is the media type of SDPX in JSON encoding. Registration Policy info (label: "TBD", temporary: "393"): A map <del> of additional attributes to help enforce Registration Policies. </del> <ins> containing key/value pairs set by the Issuer which are sealed on Registration and non-opaque to the Transparency Service.  The key/ value pair semantics are specified by each Issuer or are specific to the Issuer and Feed tuple.  Examples include: the sequence number of signed statements on a feed, Issuer metadata, or a reference to other transparent statements (e.g., augments, replaces, new-version, CPE-for). </ins> Key ID (label: "4"): Key ID, as a bytestring.