Code change:
Retains the concepts and many of the same words as before, but addresses concerns form the mailing list and interim call
I've merged in suggestions. Please re-review, with LGTM or actionable suggestions.
yesLGTM

Related discussion:
text: 4.1.1. <del> The Append-only Log is empty when the Transparency Service is initialized.  The first entry that is added to the Append-only Log MUST be a Signed Statement including key material.  The second set of entries are Signed Statements for additional domain-specific Registration Policy.  The third set of entries are Signed Statements for Artifacts.  From here on a Transparency Service can check Signed Statements on registration via policy (that is at minimum, key material and typically a Registration Policy) and is therefore in a reliable state to register Signed Statements about Artifacts or a new Registration Policy. </del> <ins> Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is accepted to be registered to the Append-only Log. </ins> <del> 4.1.2. </del> <ins> Transparency Services MUST maintain Registration Policies which govern whether or not a given Signed Statement is eligible for registration. Registration Policies MUST be made transparent and available to all clients of the Transparency Service by registering them as Signed Statements on the Append-only Log. </ins> <del> Registration Policies refer to the checks that are performed before a Signed Statement is registered to an Append-only Log, and a corresponding Receipt becomes available. As a minimum, a Transparency Service MUST authenticate the Issuer of Signed Statements, which requires a trust anchor in the form of an already registered Signed Statement including key material (see ts- initialization).  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."  Typical representations of a trust anchor include certificates or raw public keys. The "x5t" and "kid" Claims in the protected header of Signed Statements can be used as hints for discovering trust anchors. Before a Registration Policy is used to decide if a Signed Statement is registered, the policy MUST be registered.  Before a Signed Statement is registered, the trust anchor used to verify it MUST be registered (e.g., via a registered Registration Policy).  In order to register a trust anchor, the trust anchor MUST be converted to a Signed Statement with a matching content type Claim.  During initialization of a Transparency Service, the first Signed Statements registered will be for a trust anchor that is not validated by any Registration Policy. Transparency Services MUST specify their supported signature algorithms in their Registration Policies. </del> <ins> Transparency Services MUST reject any attempt to register Signed Statements until at least one Registration Policy is registered. </ins> This specification leaves implementation, encoding and documentation of Registration Policies to the operator of the Transparency Service. <ins> 4.1.1.1. Transparency Services MUST, at a minimum, perform the following checks before registering a Signed Statement: * Authenticate the Issuer of the Signed Statement To authenticate the Issuer of the Signed Statement the Transparency Service MUST refer to a 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." Typical representations of a trust anchor include certificates or raw public keys.  The "x5t" and "kid" Claims in the protected header of Signed Statements can be used as hints for discovering trust anchors. Before a Signed Statement is registered, the trust anchor used to verify its Issuer MUST be registered with the Transparency Service. * Inclusion of Issuer trust anchors in a registered Registration Policy * Submission of Issuer trust anchors as a Signed Statement 4.1.2. Since a Registration Policy is required prior to the registration of any Signed Statements, a means is required to configure the first Registration Policy that is not the standard issuance of a Signed Statement.  Transparency Services MUST support at least one of these methods: * A built-in default Registration Policy * Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks * An out-of-band authenticated management interface </ins> 4.1.3. The security properties of the Append-only Log are determined by the