From 0f057f5b69b0cd0030bbb3f1d1ac27f95f07c3e9 Mon Sep 17 00:00:00 2001 From: Enrico Marconi <31142849+UMR1352@users.noreply.github.com> Date: Tue, 14 May 2024 16:48:34 +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 7f4404090f6..f9f32599914 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 @@ -41,7 +41,7 @@ The downside of this mechanism is that the holder of a credential using `Revocat to update the signature - i.e. re-issue the credential - at the end of the credential's validity timeframe. Furthermore, given as how a credential's validity timeframe proves the validity of the credential itself, the updates made by the issuer to the credential's status - i.e revoking or unrevoking it - won't be reflected on the credential until the start of a new validity timeframe. For this reason, -issuers should choose a validity timeframe's length with respect to how frequently they expect to change the credential's status; +issuers should choose a validity timeframe length with respect to how frequently they expect to change the credential's status; frequent updates deems shorter validity timeframes. :::note