- This section outlines the core concept utilized by the status list - mechanism described in this document. At the most basic level, status - information for all verifiable credentials issued by an issuer - are expressed as simple binary values. The issuer keeps a bitstring - list of all verifiable credentials it has issued. Each - verifiable credential is associated with a position in the list. If - the binary value of the position in the list is 1 (one), the - verifiable credential is revoked, if it is 0 (zero) it is not revoked. +This section outlines the core concept utilized by the status list +mechanism described in this document. At the most basic level, status +information for all verifiable credentials issued by an issuer +are expressed as simple binary values. The issuer keeps a bitstring +list of all verifiable credentials it has issued. Each +verifiable credential is associated with a position in the list. If +the binary value of the position in the list is 1 (one), the +verifiable credential is revoked, if it is 0 (zero) it is not revoked.
- One of the benefits of using a bitstring is that it is a highly compressible - data format since, in the average case, large numbers of credentials will - remain unrevoked. This will ensure long sections of bits that are the same - value and thus highly compressible using run-length compression techniques - such as GZIP [[RFC1952]]. The default bitstring size is 16KB (131,072 entries), - and when only a handful of verifiable credentials are revoked, the - compressed bitstring size is reduced down to a few hundred bytes. +One of the benefits of using a bitstring is that it is a highly compressible +data format since, in the average case, large numbers of credentials will +remain unrevoked. This will ensure long sections of bits that are the same +value and thus highly compressible using run-length compression techniques +such as GZIP [[RFC1952]]. The default bitstring size is 16KB (131,072 entries), +and when only a handful of verifiable credentials are revoked, the +compressed bitstring size is reduced down to a few hundred bytes.
- 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 utilizes a minimum bitstring length of 131,072 (16KB). This - population size ensures an adequate amount of herd privacy in the average case. - If better herd privacy is required, the bitstring can be made to be larger. +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 utilizes a minimum bitstring length of 131,072 (16KB). This +population size ensures an adequate amount of herd privacy in the average case. +If better herd privacy is required, the bitstring can be made to be larger.
- `reference` is especially important when interpertation of the - status for a credential may involve some understanding of the business case - involved. +`reference` is especially important when interpretation of the status for a +credential may involve some understanding of the business case involved.
-The Working Group is still discussing the unification of a design between status lists with a single state (such as "revoked" or "suspended") and status lists with multiple states (exposed via a series of status messages). We are seeking implementer feedback on what a unified design should look like from an ease of implementation, privacy, and security standpoint. -
-
- {
- "@context": [
- "https://www.w3.org/ns/credentials/v2"
- ],
- "id": "https://example.com/credentials/status/3",
- "type": ["VerifiableCredential", "BitstringStatusListCredential"],
- "issuer": "did:example:12345",
- "validFrom": "2021-04-05T14:27:40Z",
- "credentialSubject": {
- "id": "https://example.com/status/3#list",
- "type": "BitstringStatusList",
- "ttl": 500,
- "statusPurpose": "status",
- "reference": "https://example.org/status-dictionary/",
- "size": 2,
- "statusMessages": [
- {"status":"0x0", "value":"valid"},
- {"status":"0x1", "value":"invalid"},
- {"status":"0x2", "value":"pending_review"},
- ...
- ],
- "encodedList": "H4sIAAAAAAAAA-3BMQEAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
- }
- }
+
+The Working Group is still discussing the unification of a design between status
+lists with a single state (such as "revoked" or "suspended") and status lists
+with multiple states (exposed via a series of status messages). We are seeking
+implementer feedback on what a unified design should look like from an ease of
+implementation, privacy, and security standpoint.
+
+
+{
+ "@context": [
+ "https://www.w3.org/ns/credentials/v2"
+ ],
+ "id": "https://example.com/credentials/status/3",
+ "type": ["VerifiableCredential", "BitstringStatusListCredential"],
+ "issuer": "did:example:12345",
+ "validFrom": "2021-04-05T14:27:40Z",
+ "credentialSubject": {
+ "id": "https://example.com/status/3#list",
+ "type": "BitstringStatusList",
+ "ttl": 500,
+ "statusPurpose": "status",
+ "reference": "https://example.org/status-dictionary/",
+ "size": 2,
+ "statusMessages": [
+ {"status":"0x0", "value":"valid"},
+ {"status":"0x1", "value":"invalid"},
+ {"status":"0x2", "value":"pending_review"},
+ ...
+ ],
+ "encodedList": "H4sIAAAAAAAAA-3BMQEAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
+ }
+}
@@ -820,31 +818,30 @@ Bitstring Expansion Algorithm
Media Types
- When dereferencing `statusListCredential`,
- the content type of the `statusListCredential` might
- be any media type registered for the purpose of expressing a
- verifiable credential with one or more proofs.
+ When dereferencing `statusListCredential`, the content type of the
+ `statusListCredential` might be any media type registered for the purpose of
+ expressing a verifiable credential with one or more proofs.
- For example, a verifiable credential secured with
- Data Integrity Proofs might have content type `application/vc+ld+json`,
- whereas a verifiable credential secured with
- SD-JWT might have content-type `application/sd-jwt`.
+ For example, a verifiable credential secured with Data Integrity Proofs might
+ have content type `application/vc+ld+json`, whereas a verifiable credential
+ secured with SD-JWT might have content-type `application/sd-jwt`.
- Some implementations might choose to support less specific media types such as
- `application/ld+json` or `application/json`.
+Some implementations might choose to support less specific media types such as
+`application/ld+json` or `application/json`.
- When dereferencing over HTTP,
- the use of the accept
- and content-type headers,
- might allow some implementations to negotiate for the proof format
- used to secure the `statusListCredential`.
+When dereferencing over HTTP, the use of the accept
+and content-type headers, might allow
+some implementations to negotiate for the proof format used to secure the
+`statusListCredential`.
- Some implementations might use the 415 Unsupported Media Type
- status code to signal that they do not support the requested media type.
+Some implementations might use the 415
+Unsupported Media Type status code to signal that they do not support the
+requested media type.
@@ -896,24 +893,27 @@ Content Distribution Networks
-
-Malicious Issuers and Verifiers
-
-In general, the herd 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.
-
-
+
+ Malicious Issuers and Verifiers
+
+In general, the herd 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
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
information from presented credentials with a malicious issuer.
-
-
-
+
+
+
@@ -964,7 +964,8 @@ Bitstring Encoding
-For example, if a bitstring is 131,072 bits in size (16KB), the first index will be 0, and the last index will be 131,071. +For example, if a bitstring is 131,072 bits in size (16KB), the first index will +be 0, and the last index will be 131,071.
Implementations SHOULD consume and/or assign indexes randomly.