Clarify the role of verifiers in preventing replay attacks.

Co-authored-by: Manu Sporny <msporny@digitalbazaar.com>
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

index.html

@@ -6009,12 +6009,23 @@ <h4>Replay Attack</h4>
         <p>
 A [=verifier=] might wish to ensure that a [=verifiable presentation=] is
 not used more than a certain number of times. For example, a [=verifiable
-credential=] representing an event ticket, might allow entry to multiple
+credential=] representing an event ticket might allow entry to multiple
 individuals if presented multiple times, undermining the purpose of the ticket
-from the perspective of its issuer. To prevent against such attacks,
-[=holders=] can make use of techniques such as including a
-<a href="https://en.wikipedia.org/wiki/Cryptographic_nonce">nonce</a> during
-presentation, or adding an expiry timestamp to reduce the window of attack.
+from the perspective of its [=issuer=]. To prevent such replay attacks, 
+[=verifiers=] require [=holders=] to include additional security measures
+in their [=verifiable presentations=]. Examples include the following:
+          <ul>
+            <li>
+A <a href="https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication">challenge</a> 
+provided by the [=verifier=], which the [=holder=] incorporates into
+a [=verifiable presentation=]. The [=verifier=] enforces challenge
+uniqueness to prevent replay attacks.
+            </li>
+            <li>
+A <a href="#validity-period">validity period</a>, limiting the window 
+during which the [=verifiable presentation=] is valid.
+            </li>
+          </ul>
         </p>
         <h4>Spoofing Attack</h4>