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