Original text:
(COSE) STD96 header parameters that carry the TimestampToken (TST) output of RFC 3161, thus allowing existing and widely deployed trust infrastructure to be used with COSE structures used for signing <del> (COSE_Sign and COSE_Sign1). </del>  1.1.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

Reviewer comments:
In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >

Revised text:
(COSE) STD96 header parameters that carry the TimestampToken (TST) output of RFC 3161, thus allowing existing and widely deployed trust infrastructure to be used with COSE structures used for signing  <ins> ("COSE_Sign" and "COSE_Sign1"). </ins> 1.1. <ins> This section discusses two use cases, each representing one of the two modes of use defined in modes. A first use case is a digital document signed alongside a trustworthy timestamp.  This is a common case in legal contracts.  In such scenario, the document signer wants to reinforce the claim that the document existed on a specific date.  To achieve this, the document signer acquires a fresh TST for the document from a TSA, combines it with the document, and then signs the bundle.  Later on, a relying party consuming the signed bundle can be certain that the document existed at the time specified by the TSA.  The relying party does not have to trust the signer's clock, which may have been maliciously altered or simply inaccurate. This usage scenario motivates the "Timestamp then COSE" mode defined in sec-timestamp-then-cose. A second use case is the notarization of a signed document by registering it at a Transparency Service.  This is common for accountability and auditability of issued documents.  Once a document is registered at a Transparency Service's append-only log, it cannot be changed.  In certain cases, the registration policy of a Transparency Service may require adding a trustworthy timestamp to the document at the time of registration.  This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain point in time. To achieve this, the Transparency Service acquires a TST from a TSA, bundles it alongside the signed document, and then registers it.  A relying party that wants to ascertain the time of registration of a given document does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in sec-cose-then-timestamp. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in