From d9f108f183ef34e7af36c14ac7aeed75e09fc0c4 Mon Sep 17 00:00:00 2001 From: Sho Nakatani Date: Sat, 24 Aug 2024 23:35:40 +0900 Subject: [PATCH] Clarify the role of verifiers in preventing replay attacks. Co-authored-by: Manu Sporny Co-authored-by: Dave Longley Co-authored-by: Ted Thibodeau Jr --- index.html | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 2dd456643..b322ceb4d 100644 --- a/index.html +++ b/index.html @@ -6009,12 +6009,23 @@

Replay Attack

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 -nonce 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: +

    +
  • +A challenge +provided by the [=verifier=], which the [=holder=] incorporates into +a [=verifiable presentation=]. The [=verifier=] enforces challenge +uniqueness to prevent replay attacks. +
    • +
  • +A validity period, limiting the window +during which the [=verifiable presentation=] is valid. +
    • +

Spoofing Attack