From a48af1a8ae3a05557f266990fee609b307ec3189 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 11 May 2024 08:22:45 -0400 Subject: [PATCH] Update CR's to include decoy values warning. --- CR/2024-05-09/index.html | 94 +++++++++++++++++----------------------- CR/2024-CR1/index.html | 65 +++++++++++++-------------- 2 files changed, 70 insertions(+), 89 deletions(-) diff --git a/CR/2024-05-09/index.html b/CR/2024-05-09/index.html index 5d2093a..0916014 100644 --- a/CR/2024-05-09/index.html +++ b/CR/2024-05-09/index.html @@ -1,6 +1,6 @@ - + + @@ -209,7 +197,7 @@ { "type": "Person", "name": "Manu Sporny", - "url": "http://manu.sporny.org/", + "url": "https://www.linkedin.com/in/manusporny/", "worksFor": { "name": "Digital Bazaar", "url": "https://www.digitalbazaar.com/" @@ -227,10 +215,10 @@ { "type": "Person", "name": "Mike Prorock", - "url": "https://mesur.io/", + "url": "https://www.mesur.io/", "worksFor": { "name": "mesur.io", - "url": "https://mesur.io/" + "url": "https://www.mesur.io/" } }, { @@ -671,7 +659,7 @@ "editors": [ { "name": "Manu Sporny", - "url": "http://manu.sporny.org/", + "url": "https://www.linkedin.com/in/manusporny/", "company": "Digital Bazaar", "companyURL": "https://www.digitalbazaar.com/", "w3cid": 41758 @@ -685,9 +673,9 @@ }, { "name": "Mike Prorock", - "url": "https://mesur.io/", + "url": "https://www.mesur.io/", "company": "mesur.io", - "companyURL": "https://mesur.io/", + "companyURL": "https://www.mesur.io/", "w3cid": 130636 }, { @@ -778,11 +766,11 @@

Bitstring Status List v1.0

Editors:
- Manu Sporny (Digital Bazaar) + Manu Sporny (Digital Bazaar)
Dave Longley (Digital Bazaar)
- Mike Prorock (mesur.io) + Mike Prorock (mesur.io)
Mahmoud Alkhraishi (Mavennet)
@@ -1158,7 +1146,7 @@

Bitstring Status List v1.0

verifiable credential as defined in [VC-DATA-MODEL-2.0].

-
(Feature at Risk) Issue 1: Bitstring entry sizes greater than 1 are at risk.

+

(Feature at Risk) Issue: Bitstring entry sizes greater than 1 are at risk.

The Working Group is currently seeking implementer feedback regarding the utility of bitstring entries that have sizes greater than one. Supporting such entries adds complexity to the solution, and it's not clear whether there @@ -1307,7 +1295,7 @@

Bitstring Status List v1.0

MUST be a URL or an array of URLs [URL] which dereference to material related to the status. Implementers using a statusPurpose of message are strongly encouraged to provide a statusReference. -
Note: Details around reference

+

Note: Details around reference

statusReference is especially important when interpretation of the status for a credential may involve some understanding of the business case involved.

@@ -1448,7 +1436,7 @@

Bitstring Status List v1.0

BitstringStatusListCredential.

-
(Feature at Risk) Issue 2: TTL conflicts with `validUntil`

+

(Feature at Risk) Issue: TTL conflicts with `validUntil`

The Working Group is considering the removal of the ttl ("time to live") feature because its semantics conflict with the semantics of the validUntil feature of verifiable credentials. When a verifier performs @@ -1635,7 +1623,7 @@

Bitstring Status List v1.0

MUST be raised.

-
(Feature at Risk) Issue 3: Attempting alignment with IETF Token Status List specification

+

(Feature at Risk) Issue: Attempting alignment with IETF Token Status List specification

The Working Group is seeking feedback related to implementer desire to align with the IETF OAuth Working Group @@ -1805,7 +1793,7 @@

Bitstring Status List v1.0

issuer.

-
Note: Issuer validation is use case dependent

+

Note: Issuer validation is use case dependent

It is expected that a verifier will ensure that it trusts the issuer of a verifiable credential, as well as the issuer of the associated BitstringStatusListCredential, @@ -2032,11 +2020,10 @@

Bitstring Status List v1.0

-In some cases, such as when presenting a verifiable credential that -contains a global identifier (such as a driver's license identification number), -adding one or more global identifier(s) for status list information does not -increase correlation harm, since a single globally unique identifier is all that -is required for correlation. +In some cases, such as when presenting a verifiable credential that contains a global identifier (such as a driver's license +identification number), adding one or more global identifier(s) for status list +information does not increase correlation harm, since a single globally unique +identifier is all that is required for correlation.

@@ -2100,24 +2087,21 @@

Bitstring Status List v1.0

Issuer use of decoy values in status lists has been explored as a mechanism to increase the privacy of subjects. While algorithms for employing decoy -values are out of scope for this specification, implementers are advised that -the use of decoy values does not improve privacy and can harm privacy in -most cases. -

-

-When indexes of status list entries are allocated in a random fashion, which is -the suggested mode of operation for this specification, adding decoys harms -privacy because it reduces the true group size by the number of decoys added -to the group. A random allocation of indexes inherently hides the true size of -the group without reducing it, ensuring that decoys are not necessary. -

-

-There might be use cases where decoy values provide benefits. Implementers are -cautioned that no such use cases were clearly identifiable by the group that -created this specification. Therefore, the use of decoys is discouraged for -most if not all use cases, as random allocation of status list entry indexes -provides adequate protection. +values are out of scope for this specification, implementers are advised that...

+ +
Issue 150: Describe decoy entries as a privacy mitigation before-CRpr existsprivacy-needs-resolutioneditorial

+The Working Group is currently discussing what sort of guidance to provide +for decoy values. It has been suggested that decoy values are, in general, +harmful to this specification's privacy characteristics. However, the group +has not provided a complete analysis and thorough review for that assertion. +The analysis might result in some use cases where decoy values are helpful, or +might conclude that decoy values are, in general, harmful. Further +thought is currently being put into the language around decoy values and +it is expected that this language will be finalized during the Candidate +Recommendation phase. +

+

5.6 Malicious Issuers and Verifiers

This section is non-normative.

@@ -2365,7 +2349,7 @@

Bitstring Status List v1.0

+}

@@ -2390,7 +2374,7 @@

Bitstring Status List v1.0

revocation", "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA" } -} +}

@@ -2446,7 +2430,7 @@

Bitstring Status List v1.0

-
(Feature at Risk) Issue 4: Efficiency argument is weak

+

(Feature at Risk) Issue: Efficiency argument is weak

The "space efficiency" argument for this feature is weak. One list with two types of status entries must, presumably, be twice as long as a list with one type of status entries, to ensure proper privacy protections. One privacy benefit of @@ -2526,9 +2510,9 @@

Bitstring Status List v1.0

[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VC-DATA-INTEGRITY]
- Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 15 March 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/ + Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 28 April 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/
[VC-DATA-MODEL-2.0]
- Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 16 April 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/ + Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 7 May 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/
@@ -2791,4 +2775,4 @@

Bitstring Status List v1.0

+})() \ No newline at end of file diff --git a/CR/2024-CR1/index.html b/CR/2024-CR1/index.html index a025cc5..0916014 100644 --- a/CR/2024-CR1/index.html +++ b/CR/2024-CR1/index.html @@ -1,6 +1,6 @@ - + + @@ -826,7 +827,7 @@

Bitstring Status List v1.0

implementation report. @@ -1145,7 +1146,7 @@

Bitstring Status List v1.0

verifiable credential as defined in [VC-DATA-MODEL-2.0].

-
(Feature at Risk) Issue 1: Bitstring entry sizes greater than 1 are at risk.

+

(Feature at Risk) Issue: Bitstring entry sizes greater than 1 are at risk.

The Working Group is currently seeking implementer feedback regarding the utility of bitstring entries that have sizes greater than one. Supporting such entries adds complexity to the solution, and it's not clear whether there @@ -1294,7 +1295,7 @@

Bitstring Status List v1.0

MUST be a URL or an array of URLs [URL] which dereference to material related to the status. Implementers using a statusPurpose of message are strongly encouraged to provide a statusReference. -
Note: Details around reference

+

Note: Details around reference

statusReference is especially important when interpretation of the status for a credential may involve some understanding of the business case involved.

@@ -1435,7 +1436,7 @@

Bitstring Status List v1.0

BitstringStatusListCredential.

-
(Feature at Risk) Issue 2: TTL conflicts with `validUntil`

+

(Feature at Risk) Issue: TTL conflicts with `validUntil`

The Working Group is considering the removal of the ttl ("time to live") feature because its semantics conflict with the semantics of the validUntil feature of verifiable credentials. When a verifier performs @@ -1622,7 +1623,7 @@

Bitstring Status List v1.0

MUST be raised.

-
(Feature at Risk) Issue 3: Attempting alignment with IETF Token Status List specification

+

(Feature at Risk) Issue: Attempting alignment with IETF Token Status List specification

The Working Group is seeking feedback related to implementer desire to align with the IETF OAuth Working Group @@ -1792,7 +1793,7 @@

Bitstring Status List v1.0

issuer.

-
Note: Issuer validation is use case dependent

+

Note: Issuer validation is use case dependent

It is expected that a verifier will ensure that it trusts the issuer of a verifiable credential, as well as the issuer of the associated BitstringStatusListCredential, @@ -2019,11 +2020,10 @@

Bitstring Status List v1.0

-In some cases, such as when presenting a verifiable credential that -contains a global identifier (such as a driver's license identification number), -adding one or more global identifier(s) for status list information does not -increase correlation harm, since a single globally unique identifier is all that -is required for correlation. +In some cases, such as when presenting a verifiable credential that contains a global identifier (such as a driver's license +identification number), adding one or more global identifier(s) for status list +information does not increase correlation harm, since a single globally unique +identifier is all that is required for correlation.

@@ -2087,24 +2087,21 @@

Bitstring Status List v1.0

Issuer use of decoy values in status lists has been explored as a mechanism to increase the privacy of subjects. While algorithms for employing decoy -values are out of scope for this specification, implementers are advised that -the use of decoy values does not improve privacy and can harm privacy in -most cases. -

-

-When indexes of status list entries are allocated in a random fashion, which is -the suggested mode of operation for this specification, adding decoys harms -privacy because it reduces the true group size by the number of decoys added -to the group. A random allocation of indexes inherently hides the true size of -the group without reducing it, ensuring that decoys are not necessary. -

-

-There might be use cases where decoy values provide benefits. Implementers are -cautioned that no such use cases were clearly identifiable by the group that -created this specification. Therefore, the use of decoys is discouraged for -most if not all use cases, as random allocation of status list entry indexes -provides adequate protection. +values are out of scope for this specification, implementers are advised that...

+ +
Issue 150: Describe decoy entries as a privacy mitigation before-CRpr existsprivacy-needs-resolutioneditorial

+The Working Group is currently discussing what sort of guidance to provide +for decoy values. It has been suggested that decoy values are, in general, +harmful to this specification's privacy characteristics. However, the group +has not provided a complete analysis and thorough review for that assertion. +The analysis might result in some use cases where decoy values are helpful, or +might conclude that decoy values are, in general, harmful. Further +thought is currently being put into the language around decoy values and +it is expected that this language will be finalized during the Candidate +Recommendation phase. +

+

5.6 Malicious Issuers and Verifiers

This section is non-normative.

@@ -2352,7 +2349,7 @@

Bitstring Status List v1.0

+}

@@ -2377,7 +2374,7 @@

Bitstring Status List v1.0

revocation", "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA" } -} +}

@@ -2433,7 +2430,7 @@

Bitstring Status List v1.0

-
(Feature at Risk) Issue 4: Efficiency argument is weak

+

(Feature at Risk) Issue: Efficiency argument is weak

The "space efficiency" argument for this feature is weak. One list with two types of status entries must, presumably, be twice as long as a list with one type of status entries, to ensure proper privacy protections. One privacy benefit of @@ -2513,9 +2510,9 @@

Bitstring Status List v1.0

[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VC-DATA-INTEGRITY]
- Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 15 March 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/ + Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 28 April 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/
[VC-DATA-MODEL-2.0]
- Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 16 April 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/ + Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 7 May 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/