Code change:
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

Related discussion:
text: Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. <del> 5.1.4. SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a Signed Statement. Each implementation of a Transparency Service MAY support additional metadata, specific to its implementation through additional "Reserved for Private Use" [1] keys within the "CWT_Claims" header. </del> 5.2. The role of Transparency Service can be decomposed into several major <del> functions.  The most important is maintaining an Append-only Log, the verifiable data structure that records Signed Statements, and enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints for Registration of Signed Statements and Receipt issuance.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the Transparency Service.  Each of these components MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service.  For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).  The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance (pBFT PBFT) and may be used to protect against malicious or vulnerable replicas.  Threshold signatures may be use to protect the service key, etc. Beyond the trusted components, Transparency Services may operate additional endpoints for auditing, for instance to query the history of Signed Statements registered by a given Issuer via a certain Subject.  Implementations of Transparency Services SHOULD avoid using the service identity and extending the Transparency Service in auditing endpoints, except if it is necessary to compute an Append- only Log consistency proofs.  Other evidence to support the correctness and completeness of the audit response MUST be computed from the Append-only Log. </del> <ins> functions.  The most important function is to maintain a Registration Policy for the Append-only Log that is the verifiable data structure that records Signed Statements.  All Transparency Services MUST expose APIs for Registration of Signed Statements and Receipt issuance.  Transparency Services may support additional APIs for auditing, for instance to query the history of Signed Statements. </ins> 5.2.1. <ins> The log is empty when the service is intialized.  The first entry is a signed statement for key material.  The second set of entries are signed statements for additional domain specific policy.  The third set of entries are signed statements for artifacts. 5.2.2. </ins> Every Transparency Service MUST have a public service identity, <del> associated with public/private key pairs for signing on behalf of the service.  In particular, this identity must be known by Verifiers when validating a Receipt. </del> <ins> associated with public/private key pairs for signing Receipts on behalf of the service.  In particular, this identity must be known by Verifiers when validating a Receipt. </ins> This identity MUST be stable for the lifetime of the service, so that all Receipts remain valid and consistent.  The Transparency Service