Original text:
Receipts for the software and configuration of the service, as measured in its attestation report. <del> 5.2.2. The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL </del> 5.2.3. <del> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would provide limited to no value to Verifiers.  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 non-opaque content (payload) of Signed Statements. </del> Registration Policies refers to the checks that are performed before <del> a Signed Statement is registered given a set of input values.  This specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </del>  As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As

Reviewer comments:
Adjustments regarding registration policies.
NAME I have made significant changes since your last review, including cutting out a lot of redundant text, and shuffling sections and section headers while eliminating the redundancy. I am dismissing your approval based on that, please give this another review.
Apologies for the scope creep of this PR ("massive"). This is all intended to be presentable on Monday.
NAME and NAME : i shall review it later today!
Subject to addressing the issues opened by this PR: This PR can be taken forward!The biggest issue now that x5t is required is that the issuer for x509-signed claims is not specified. This needs to be solved before we can merge this

Revised text:
Receipts for the software and configuration of the service, as measured in its attestation report.  5.2.3.  Registration Policies refers to the checks that are performed before  <ins> a Signed Statement is added to an append only log, and a corrosponding receipt becomes available. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As