From c738f02596e7fe690c88204835a3ac3b95fdc366 Mon Sep 17 00:00:00 2001 From: Enrico Marconi <31142849+UMR1352@users.noreply.github.com> Date: Tue, 14 May 2024 16:52:51 +0200 Subject: [PATCH] Update docs/build/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Eike Haß --- .../references/specifications/revocation-timeframe-2024.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/build/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx b/docs/build/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx index 07e3bc1c2bd..24a83822a09 100644 --- a/docs/build/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx +++ b/docs/build/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx @@ -33,7 +33,7 @@ the credential's index in the issuers revocation bitmap to avoid linkability. ### Validity Timeframe If the revocation index is concealed to the verifier how can it assert the validity of the presented credential? To solve this issue `RevocationTimeframe2024` introduces the concept of a _validity timeframe_, i.e. a limited span of time -in which the credential is guaranted to be non-revoked. By having a validity timeframe embedded in the credential's status +in which the credential is guaranted to be non-revoked. By having a validity timeframe embedded in the credentials status the verifier can prove the credential's validity by verifying the credential's signature. The downside of this mechanism is that the holder of a credential using `RevocationTimeframe2024` has to contact the credential's issuer