From e46d8d688730d182ec8c08f229e7688113e1a848 Mon Sep 17 00:00:00 2001 From: Enrico Marconi <31142849+UMR1352@users.noreply.github.com> Date: Tue, 14 May 2024 16:51:57 +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ß --- .../docs/references/specifications/revocation-timeframe-2024.mdx | 1 - 1 file changed, 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 b12b00dfa25..9b3ec59a8f0 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 @@ -22,7 +22,6 @@ in order to address its linkability security concerns, at least when used in com `RevocationBitmap2022` allows for a simple and straightforward way for an issuer to invalidate an issued VC before its expiration. While this method prevents the analysis of usage by the issuer through hosting the revocation information on-chain comes with a high risk of linkability, which is especially relavant for bitmaps stored on-chain - where the storage space limits the maximum size for -the revocation bitmap, reducing herd privacy. To address this privacy concern, `RevocationTimeframe2024` was designed as an extension that builds on top of `RevocationBitmap2022`, therefore sharing most of its logic.