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: key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate. <del> 5.2.4. </del> <ins> Hints for discovering the trust anchors, MUST be placed in the protected header of signed statements as described in SECTION TBD. Before a policy is used to decide if a Signed Statement is added to the append only log, the policy MUST be added.  Before a Signed Statement is added to the append only log, the trust anchor used to verify it MUST be added.  In order to add a trust anchor, the anchor must be converted to a Signed Statement with a content type.  During initialization of a Transparency serivce, the first Signed Statements registered will be for trust anchor material, that is not validated by any registration policy.  This trust anchor material will then be used to verify subsequent Signed Statements. This specification leaves the implementation of the Registration Policy to the operator of the Transparency Service. </ins> <del> There are many different candidate verifiable data structures that may be used to implement an Append-only Log, such as chronological Merkle Trees, sparse/indexed Merkle Trees, full blockchains, and many other variants.  The Transparency Service is only required to support concise Receipts (i.e., whose size grows at most logarithmically in the number of entries in the Append-only Log) that can be encoded as a Signed Inclusion Proof. It is possible to offer multiple signature algorithms for the COSE signature of receipts' Signed Inclusion Proofs, or to change the signing algorithm at later points.  However, the verifiable data structure cannot easily be changed without breaking the consistency of the Append-only Log.  It is possible to maintain separate Registries for each algorithm in parallel but the Transparency Service is then responsible for proving their mutual consistency. 5.2.4.1. A Transparency Service is append-only.  Once a Signed Statement is registered and becomes a Transparent Statement, it cannot be modified, deleted, or reordered within the Append-only Log.  In particular, once a Receipt is returned for a given Signed Statement, the registered Signed Statement and any preceding entry in the Append-only Log becomes immutable, and the Receipt provides universally-verifiable evidence of this property. 5.2.4.2. There is no fork in the Append-only Log.  Everyone with access to its contents sees the same sequence of entries, and can check its consistency with any Receipts they have collected.  Transparency Service implementations MAY provide a mechanism to verify that the state of the Append-only Log, encoded in an old Receipt, is consistent with the current Append-only Log state. 5.2.4.3. Everyone with access to the Transparency Service can check the correctness of its contents.  In particular: the Transparency Service defines and enforces deterministic Registration Policies that can be re-evaluated based solely on the contents of the Append-only Log at the time of Registration, and must then yield the same result the ordering of entries, their cryptographic contents, and the Transparency Services' governance may be non-deterministic, but they must be verifiable a Transparency Service MAY store evidence about the resolution of identifiers, identity documents, and key material. a Transparency Service MAY additionally support verifiability of client authentication and access control 5.2.4.4. Transparency Services MAY document their governance rules and procedures for operating the Transparency Service and updating its code. </del> <ins> 5.2.4. </ins> <del> Example: relying on Transparent Statements about code updates, secured on its own Append-only Log, or on some auxiliary Transparency Service. </del> <ins> The security properties of the append only log are determined by the choice of verifiable data structure used to produce receipts. </ins> <del> Governance procedures, their auditing, and their transparency are implementation specific. </del> <ins> In addition to Receipts, some verifiable data structures might support additional proof types, such as proofs of consistency, or proofs of non inclusion. </ins> <del> Governance may be based on a consortium of members that are jointly responsible for the Transparency Services, or automated based on the contents of an auxiliary governance Transparency Service. </del> <ins> 5.2.4.1. </ins> <del> Governance typically involves additional records in the Append- only Log to enable its auditing.  The Transparency Service may contain both Transparent Statements and governance entries. </del> <ins> Transparency Services can be deployed along side other database or object storage technologies. </ins> <del> Issuers, Verifiers, and third-party Auditors may review the Transparency Service governance before trusting the service, or on a regular basis. </del> <ins> For example, a Transparency Service that is supporting a software package management system, might be referenced from the APIs exposed for package management, for example, providing an ability to request a fresh receipt for a given software package, or to request a list of signed statements and artifacts associatd with a software package. </ins> 5.3.