Original text:
the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed Statements what Artifact it is referring to.  This information is <del> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </del>  5.1.3. <del> Besides Issuer, Feed and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </del>  (content type) Envelope header.  However, this set of mandatory metadata is not sufficient to express many important Registration Policies.  For example, a Registry may only allow a Signed Statement

Reviewer comments:
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

Revised text:
the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed Statements what Artifact it is referring to.  This information is  <ins> stored in the Subject header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. </ins> 5.1.3.  <ins> Besides Issuer, Subject and kid, the only other mandatory metadata in a Signed Statement is the type of the Payload, indicated in the "cty" </ins> (content type) Envelope header.  However, this set of mandatory metadata is not sufficient to express many important Registration Policies.  For example, a Registry may only allow a Signed Statement