Code change:
On its own, verifying a Transparent Statement does not guarantee that its Envelope or contents are trustworthy.  Just that they have been signed by the apparent Issuer and counter-signed by the Transparency <del> Service.  If the Verifier trusts the Issuer, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </del> <ins> Service.  If the Verifier trusts the Issuer, after validation of the Issuer identity, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or

Related discussion:
text: 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.