Adding Usage Scenarios

draft-birkholz-cose-tsa-tst-header-parameter.md

@@ -45,23 +45,47 @@ entity:
 
 --- abstract
 
-This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message.
+This document defines a CBOR Signing And Encrypted (COSE) header parameter for incorporating RFC 3161-based timestamping into COSE message structures (`COSE_Sign` and `COSE_Sign1`).
+This enables the use of established RFC 3161 timestamping infrastructure to prove the creation time of a message.
 
 --- middle
 
 # Introduction
 
 RFC 3161 {{-TSA}} provides a method to timestamp a message digest to prove that it was created before a given time.
 
-This document defines two new CBOR Object Signing and Encryption (COSE) {{-COSE}} 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 (COSE_Sign and COSE_Sign1).
+This document defines two new CBOR Object Signing and Encryption (COSE) {{-COSE}} 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 (`COSE_Sign` and `COSE_Sign1`).
+
+## Use Cases
+
+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 least_ 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, its log entry cannot be changed.
+In certain cases, the registration policy of a Transparency Service may add a trustworthy timestamp to the signed document.
+This is done to lock the signature to a specific point in time.
+To achieve this, the Transparency Service acquires a TST from a TSA when its registration policy is met, bundles it alongside the signed document, and then registers it.
+A relying party that wants to ascertain the authenticity of a document at a certain time 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}}.
 
 ## Requirements Notation
 
 {::boilerplate bcp14-tagged}
 
-# Modes of use
+# Modes of Use {#modes}
 
-There are two different modes of composing COSE protection and timestamping.
+There are two different modes of composing COSE protection and timestamping, motivated by the usage scenarios discussed above.
 
 ## Timestamp then COSE (TTC) {#sec-timestamp-then-cose}