From 328264dfd993e4ff4404c31b374fa164e1393e03 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 30 Dec 2023 11:08:41 -0500 Subject: [PATCH 1/2] Rename "herd" to "group" privacy. --- index.html | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/index.html b/index.html index ee13f09..1e77ce0 100644 --- a/index.html +++ b/index.html @@ -207,7 +207,7 @@

Introduction

burden it places from a bandwidth and processing perspective, both on the server and the client fetching the information. In order to meet privacy expectations, it is useful to bundle the status of large sets of credentials into a single -list to help with herd privacy. However, doing so can place an impossible +list to help with group privacy. However, doing so can place an impossible burden on both the server and client if the status information is as much as a few hundred bytes in size per credential across a population of hundreds of millions of holders. @@ -222,7 +222,7 @@

Introduction

constructed for 100,000 verifiable credentials that is roughly 12,500 bytes in size in the worst case. In a case where a few hundred credentials have been revoked, the size of the list is less than a -few hundred bytes while providing privacy in a herd of 100,000 individuals. +few hundred bytes while providing privacy in a group of 100,000 individuals.

@@ -255,8 +255,8 @@

Conceptual Framework

Another benefit of using a bitstring is that it enables large numbers of verifiable credential statuses to be placed in the same list. This specification uses a minimum list length of 131,072. This -size ensures an adequate amount of herd privacy in the average case. -If better herd privacy is required, the bitstring can be made larger. +size ensures an adequate amount of group privacy in the average case. +If better group privacy is required, the bitstring can be made larger.

@@ -1061,7 +1061,7 @@

Revocation Bitstring Length

This document specifies a minimum revocation bitstring length of 131,072, or 16KB uncompressed. This is enough to give holders an adequate amount of -herd privacy if the number of verifiable credentials issued is large enough. +group privacy if the number of verifiable credentials issued is large enough. However, if the number of issued verifiable credentials is a small population, the ability to correlate an individual increases because the number of allocated slots in the bitstring is small. Correlating this information with, for example, @@ -1098,20 +1098,20 @@

Content Distribution Networks

Malicious Issuers and Verifiers

-In general, the herd privacy protections offered by this specification can be +In general, the group privacy protections offered by this specification can be circumvented by malicious issuers and verifiers. Its privacy benefits can only be realized when issuers and verifiers intend to avoid tracking or sharing the presentation of particular credentials.

-A malicious issuer might intentionally attack herd privacy by creating a +A malicious issuer might intentionally attack group privacy by creating a unique status list per credential issued in order to establish a 1-1 mapping to track when a verifier processes a specific credential. Similarly, they could establish another a 1-1 mapping by using a different cryptographic key for every credential issued that is tracked in a status list.

-A malicious verifier might intentionally attack herd privacy by sharing +A malicious verifier might intentionally attack group privacy by sharing information from presented credentials with a malicious issuer.

From 3d1e94ba4153a1e2fe1f6456ec68ab98d4483ed4 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Tue, 2 Jan 2024 15:42:12 -0500 Subject: [PATCH 2/2] Fix spacing and grammar in "group privacy" change. Co-authored-by: Ted Thibodeau Jr --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 1e77ce0..6d975a7 100644 --- a/index.html +++ b/index.html @@ -1105,9 +1105,9 @@

Malicious Issuers and Verifiers

A malicious issuer might intentionally attack group privacy by creating a -unique status list per credential issued in order to establish a 1-1 mapping to track +unique status list per credential issued in order to establish a one-to-one mapping to track when a verifier processes a specific credential. Similarly, they could establish -another a 1-1 mapping by using a different cryptographic key for every credential +another a one-to-one mapping by using a different cryptographic key for every credential issued that is tracked in a status list.