Code change:
5.2.2. A Transparency Services that accepts to register any valid Signed <del> Statement offered by an Issuer would end up providing only limited value to Verifiers.  In consequence, a baseline transparency guarantee policing the Registration of Signed Statements is required to ensure completeness of audit, which can help detect equivocation. Most advanced SCITT scenarios rely on the Transparency Service performing additional domain-specific checks before a Signed Statement is accepted: Transparency Services may only allow trusted authenticated users to register Signed Statements, Transparency Services may try to check that a new Signed Statement is consistent with previous Signed Statements from the same Issuers or that Signed Statements are registered in the correct order and cannot be re- played; some Transparency Services may even interpret and validate the payload of Signed Statements. In general, Registration Policies are applied at the discretion of the Transparency Services, and Verifiers use Receipts as witnesses that confirm that the Registration Policy of the Transparency Services was satisfied at the time of creating a Transparent Statement via Signed Statement Registration.  Transparency Service implementations SHOULD make their full Registration Policy public and auditable, e.g. by recording stateful policy inputs at evaluation time in the Registry to ensure that policy can be independently validated later.  From an interoperability point of view, the policy that was applied by the Transparency Services is opaque to the Verifier, which is forced to trust the associated Registration Policy.  If the policy of the Transparency Services evolves over time, or is different across Issuers, the assurances derived from Receipt validation may not be uniform across all Signed Statements over time. To help Verifiers interpret the semantics of Signed Statement Registration, the SCITT Architecture defines a standard mechanism to include signals the Signed Statement itself which policies have been applied by the Transparency Service from a defined set of Registration Policies with standardized semantics.  Each policy that is expected to be enforced by the Transparency Service is represented by an entry in the Registration Policy info map ("reg_info") in the COSE Envelope of the Signed Statement.  The key of the map entry corresponds to the name of the policy, while its value (including its type) is policy-specific.  For instance, the "register_by" policy defines the maximum timestamp by which a Signed Statement can be registered, hence the associated value contains an unsigned integer. While this design ensures that all Verifiers get the same guarantee regardless of where a Transparent Statement is registered, its main downside is that it requires the Issuer to include the necessary policies in the Envelope when the Signed Statement is produced. Furthermore, it makes it impossible to register the same Signed Statement on two different Transparency Services, if their required Registration Policies are incompatible. </del> <ins> Statement offered by anonymous Issuers would only provide limited value, or no value, to verifiers.  As a consequence, some form of "authorization" is needed before registration of Signed Statements to ensure completeness of audit.  More advanced use case will rely on the Transparency Service performing additional domain-specific checks before a Signed Statement is accepted.  For example, some Transparency Services may validate the content of Signed Statements. We use the term "registration policies" to refer to the checks that are performed before a Signed Statement is registered given a set of input values.  This baseline specification leaves the implementation of the registration policy to the provider of the Transparency Services and its users. As a minimum we expect that a deployment authenticates the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate, a raw public key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate. A provider of a Transparency Service is, however, expected to indicate what registration policy is used in a given deployment and inform its users about changes to the registration policy. </ins> 5.2.3.

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later