Code change:
Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR. Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger. Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".

Related discussion:
text: 4.1.1.1. During registration, a Transparency Service MUST, at a minimum, <del> authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its currently configured trust anchors, using the "x5t" (34), "x5chain"(33) or "kid"(4) protected headers of the Signed Statement as hints.  For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t", to one of the root certificates most recently registered as a trust anchor of the Transparency Service. </del> <ins> syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to RFC9052. The Issuer identity MUST be bound to the Signed Statement by including an identifier in the protected header. If the protected header includes multiple identifiers, all those that are registered by the Transparency Service MUST be checked. For instance, when using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by "x5t", to one of the root certificates most recently registered as a trust anchor of the Transparency Service. </ins> The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of