Original text:
Transparency Services.  To register a Signed Statement, the service performs the following steps: <del> Client authentication.  This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. Issuer identification.  The Transparency Service MUST store evidence of the DID resolution for the Issuer protected header of the Envelope and the resolved key manifest at the time of Registration for auditing.  This MAY require that the service resolves the Issuer DID and record the resulting document, or rely on a cache of recent resolutions. Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the Issuer DID document. </del>  <del> Envelope validation.  The service MUST check that the Envelope includes a Statement payload and the protected headers listed above.  The service MAY additionally verify the Statement payload format and content. Apply Registration Policy: for named policies, the Transparency Service must check that the required Registration info attributes are present in the Envelope and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and MAY use information contained in the attributes of named policies. </del>  Commit (register) the new Signed Statement to the Registry <del> Sign and return the Receipt. </del>  The last two steps MAY be shared between a batch of Signed Statements recorded in the Registry.

Reviewer comments:
A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)

Revised text:
Transparency Services.  To register a Signed Statement, the service performs the following steps:  <ins> This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. </ins>  <ins> The Transparency Service MUST store evidence of the DID resolution for the Issuer protected header of the Envelope and the resolved key manifest at the time of Registration for auditing.  This MAY require that the service resolves the Issuer DID and record the resulting document, or rely on a cache of recent resolutions. As described in COSE signature, using the signature algorithm and verification key of the Issuer DID document The service MUST check that the Envelope includes a Statement payload and the protected headers listed above The service MAY additionally verify the Statement payload format and content. for named policies, the Transparency Service must check that the required Registration info attributes are present in the Envelope and apply the check described in Table 1.  A Transparency Service MUST reject Signed Statements that contain an attribute used for a named policy that is not enforced by the service.  Custom Signed Statements are evaluated given the current Registry state and the entire Envelope, and MAY use information contained in the attributes of named policies. </ins> Commit (register) the new Signed Statement to the Registry  <ins> Sign and return the Receipt </ins> The last two steps MAY be shared between a batch of Signed Statements recorded in the Registry.