From a48af1a8ae3a05557f266990fee609b307ec3189 Mon Sep 17 00:00:00 2001
From: Manu Sporny Bitstring Status List v1.0
Editors:
Bitstring Status List v1.0
verifiable credential as defined in [VC-DATA-MODEL-2.0].
+
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 @@
statusPurpose
of message
are
strongly encouraged to provide a statusReference
.
- +
statusReference
is especially important when interpretation of the status for
a credential may involve some understanding of the business case involved.
+
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 @@
+
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
.
+
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 @@
-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 @@
-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...
+ ++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. +
This section is non-normative.
@@ -2365,7 +2349,7 @@+
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 @@