I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

The review assignment came on 13 April with a deadline for review set to the same date, 
so I have had 0 days to complete the review. Thus I only quickly read the document through 
and thus might have missed something.

The document defined REST API that supports SCITT architecture. 

Issues.
1. Section 2
   In my opinion, Section 2 "Authentication" is misplaced. I'm a bit surprised 
   to see this text as a dedicated section, I believe it must be part os the "Security Considerations" section,
   which discusses the general scope.
2. Section 5.3.1.1
   The text first states that "denial of service attacks are very hard to defend against completely" (the statement
   I agree with) and then "In principle DoS attacks are easily mitigated...". It is not clear for me how the described
   mitigation works - it relies on a behavious of a honest client, while DoS attacks on Transparency Service
   will be performed by malicious clients. Am I missing something?
3. Section 5.3.1.4
   On message insertion attack: "Transparency Services MAY also implement additional protections such
   as anomaly detection or rate limiting in order to mitigate the impact of any breach."
   It is not clear for me how "rate limiting" can help in case of message insertion attack.
3. Section 5.3.2.1
   I don't think the text "If the semantic content of the payload are time-dependent and
   susceptible to replay attacks in this way then timestamps MAY be
   added to the protected header signed by the Issuer." provides adequate guidance.
   For me this reads as "if this is a problem, you are free add timestamps (or not to add them)".
   I think that MUST is more appropriate here. 

Nits.
1. It is better to expand "SCITT", "SCRAPI" on first use.
2. Section 5.3.1.1
   In the text "Beyond this, implementers of Transparency Services MUST implement
   general good practice around network attacks, flooding, rate limiting
   etc." I think that "flooding" is an example of an attack and "rate limiting"
   is an example of defense. Can this sentence be rephrased to clearly separate 
   attacks from defense practices?