Condense items 2-4 in S4.3 registration section for #279

draft-ietf-scitt-architecture.md

@@ -570,9 +570,8 @@ To register a Signed Statement, the Transparency Service performs the following
 
 1. **Client authentication:** A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers.
 Authentication and authorization are implementation-specific and out of scope of the SCITT architecture.
-1. **Issuer Verification:** The Transparency Service MUST perform signature verification, as defined in {{Section 4.4 of RFC9052}}, and MAY perform additional checks as part of its Registration Policy.
-1. **Signature verification:** The Transparency Service MUST verify the signature of the Signed Statement, as described in {{RFC9360}}, using the signature algorithm and verification key of the Issuer.
-1. **Signed Statement validation:** The Transparency Service MUST check that the Signed Statement includes the required protected headers.
+1. **TS Signed Statement Verification and Validation:** The Transparency Service MUST perform signature verification per {{Section 4.4 of RFC9052}} and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per {{RFC9360}}.
+The Transparency Service MUST also check the Signed Statement includes the required protected headers.
 The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types.
 1. **Apply Registration Policy:** The Transparency Service MUST check the attributes required by a Registration Policy are present in the protected headers.
   Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies.