CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 date: Wed, 08 Oct 2025 18:31:59 GMT content-type: text/html; charset=utf-8 content-encoding: gzip content-location: Overview.html last-modified: Sun, 07 Jan 2024 13:22:09 GMT cache-control: max-age=31536000 expires: Thu, 08 Oct 2026 18:31:59 GMT vary: Accept-Encoding,Origin link: ;rel="timegate", ;rel="original" access-control-allow-origin: * memento-datetime: Sun, 07 Jan 2024 13:22:09 GMT x-backend: www-mirrors x-request-id: 98b7b7de78905917 strict-transport-security: max-age=15552000; includeSubdomains; preload content-security-policy: frame-ancestors 'self' https://cms.w3.org/ https://cms-dev.w3.org/; upgrade-insecure-requests cf-cache-status: BYPASS set-cookie: __cf_bm=8VytzJIP4XpgvzZk8HECJtDLvjQSS5YcThJwFdA_qcI-1759948319-1.0.1.1-FY94W4ekNio27.1eKWRkbmumY4ttkA0eCcZK6mcQs2JZ13S_GcrnYO8VvtWg96otEgCX_FUjofxMJ43tNK6F9xAdlkT6lgbVaK8UFtey0cc; path=/; expires=Wed, 08-Oct-25 19:01:59 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None server: cloudflare cf-ray: 98b7b7de78905917-BLR alt-svc: h3=":443"; ma=86400 Bitstring Status List v1.0

Bitstring Status List v1.0

Privacy-preserving status information for Verifiable Credentials

W3C Working Draft 07 January 2024

Abstract

This specification describes a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials through use of bitstrings.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Verifiable Credentials Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

This section is non-normative.

It is often useful for an issuer of verifiable credentials [VC-DATA-MODEL] to link to a location where a verifier can check to see if a credential has been suspended or revoked. There are a variety of privacy and performance considerations that are made when designing, publishing, and processing status lists.

One such privacy consideration happens when there is a one-to-one mapping between a verifiable credential and a URL where the status is published. This type of mapping enables the website that publishes the URL to correlate the holder, time, and verifier when the status is checked. This could enable the issuer to discover the type of interaction the holder is having with the verifier, such as providing an age verification credential when entering a bar. Being tracked by the issuer of a driver's license when entering an establishment violates a privacy expectation that many people have today.

Similarly, there are performance considerations that are explored when designing status lists. One such consideration is where the list is published and the 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 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.

The rest of this document proposes a highly compressible, bitstring-based status list mechanism with strong privacy-preserving characteristics, that is compatible with the architecture of the Web, is highly space-efficient, and lends itself well to content distribution networks. As an example of using this specification to achieve a number of beneficial privacy and performance goals, it is possible to create a status list that can be 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.

This section is non-normative.

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.

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.

diagram showing a
list of boxes at the top of the image with two of them in
red depicting revoked credentials. Text beside the boxes to the
right reads 16 kilobytes. An depiction of the boxes being
GZIP compressed into a cylinder on the bottom of the page shows
that compression has resulted in a final size of 135 bytes. — Figure 1 A visual depiction of the concepts outlined in this section.

This section is non-normative.

The following terms are used to describe concepts in this specification.

claim: An assertion made about a subject.
credential: A set of one or more claims made by an issuer. The claims in a credential can be about different subjects.
Our definition of credential differs from, NIST's definitions of credential.
data minimization: The act of limiting the amount of shared data strictly to the minimum necessary to successfully accomplish a task or goal.
decentralized identifier: A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most often used in a verifiable credential and are associated with subjects such that a verifiable credential itself can be easily ported from one repository to another without the need to reissue the credential. An example of a DID is did:example:123456abcdef.
default graph: The graph containing all claims that are not explicitly part of a named graph.
entity: Anything that can be referenced in statements as an abstract or concrete noun. Entities include but are not limited to people, organizations, physical things, documents, abstract concepts, fictional characters, and arbitrary text. Any entity might perform roles in the ecosystem, if it is capable of doing so. Note that some entities fundamentally cannot take actions, e.g., the string "abc" cannot issue credentials.
graph: A set of claims, forming a network of information composed of subjects and their relationship to other subjects or data. Each claim is part of a graph; this is either explicit in the case of named graphs, or implicit for the default graph.
holder: A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.
identity provider: An identity provider, sometimes abbreviated as IdP, is a system for creating, maintaining, and managing identity information for holders, while providing authentication services to relying party applications within a federation or distributed network. In this case the holder is always the subject. Even if the verifiable credentials are bearer credentials, it is assumed the verifiable credentials remain with the subject, and if they are not, they were stolen by an attacker. This specification does not use this term unless comparing or mapping the concepts in this document to other specifications. This specification decouples the identity provider concept into two distinct concepts: the issuer and the holder.
issuer: A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.
named graph: A graph associated with specific properties, such as verifiableCredential or proof. These properties result in separate graphs that contain all claims defined in the corresponding JSON objects.
repository: A program, such as a storage vault or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials.
subject: A thing about which claims are made.
verifiable credential: A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified.
verifiable data registry: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Some registries, such as ones for UUIDs and public keys, might just act as namespaces for identifiers.
verifiable presentation: A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs).
verification: The evaluation of whether a verifiable credential or verifiable presentation is an authentic and current statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.
verifier: A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The following sections outlines the data model for this document.

When an issuer desires to enable status information for a verifiable credential, they MAY add a credentialStatus property that uses the data model described in this specification.

Property Description

id An optional identifier for the status list entry. The constraints on the id property are listed in the Verifiable Credentials Data Model specification [VC-DATA-MODEL]. If present, the value is expected to be a URL that identifies the status information associated with the verifiable credential. It MUST NOT be the URL for the status list. The value is not used during the verification or validation process, and does not need to be related to the statusListCredential value. If necessary, the value can be used to uniquely identify the BitstringStatusListEntry object, such as when it is stored in a database.

type The type property MUST be BitstringStatusListEntry.

statusPurpose

The purpose of the status entry MUST be a string. While the value of the string is arbitrary, the following values MUST be used for their intended purpose:

Value	Description
`revocation`	Used to cancel the validity of a verifiable credential. This status is not reversible.
`suspension`	Used to temporarily prevent the acceptance of a verifiable credential. This status is reversible.

statusListIndex The statusListIndex property MUST be an arbitrary size integer greater than or equal to 0, expressed as a string. The value identifies the position of the status of the verifiable credential.

statusListCredential The statusListCredential property MUST be a URL to a verifiable credential. When the URL is dereferenced, the resulting verifiable credential MUST have type property that includes the BitstringStatusListCredential value.

Example 1: Example StatusListCredential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2021-04-05T14:27:42Z",
  "credentialStatus": [
    {
      "id": "https://example.com/credentials/status/3#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://example.com/credentials/status/3"
    }, {
      "id": "https://example.com/credentials/status/4#23452",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "suspension",
      "statusListIndex": "23452",
      "statusListCredential": "https://example.com/credentials/status/4"
    }
  ],
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  },
  "proof": { ... }
}

When a status list is published, the result is a verifiable credential that encapsulates the status list. The following section describes the format of the verifiable credential that encapsulates the status list:

Property Description

id The verifiable credential that contains the status list MAY express an id property that matches the value specified in statusListCredential for the corresponding BitstringStatusListEntry (see 2.1 BitstringStatusListEntry).

type The verifiable credential that contains the status list MUST express a type property that includes the BitstringStatusListCredential value.

validFrom The earliest point in time at which the status list is valid. This property is defined in the Verifiable Credentials Data Model specification in Section 4.6: Validity Period.

validUntil The latest point in time at which the status list is valid. This property is defined in the Verifiable Credentials Data Model specification in Section 4.6: Validity Period.

credentialSubject.type The type of the credential subject, which is the status list, MUST be BitstringStatusList.

credentialSubject.statusPurpose

The purpose of the status entry MUST be a string. While the value of the string is arbitrary, the following values MUST be used for their intended purpose:

Value	Description
`revocation`	Used to cancel the validity of a verifiable credential. This status is not reversible.
`suspension`	Used to temporarily prevent the acceptance of a verifiable credential. This status is reversible.
`status`	Used to indicate a status message associated with a verifiable credential. The status message descriptions MUST be defined in `credentialSubject.statusMessages`. `credentialSubject.size` MUST be defined with this `statusPurpose`.

credentialSubject.encodedList The encodedList property of the credential subject MUST be the GZIP-compressed [RFC1952], base-64 encoded [RFC4648] bitstring values for the associated range of verifiable credential status values. The uncompressed bitstring MUST be at least 16KB in size. The bitstring MUST be encoded such that the first index, with a value of zero (0), is located at the left-most bit in the bitstring and the last index, with a value of one less than the length of the bitstring (bitstring_length - 1), is located at the right-most bit in the bitstring. Further information on bitstring encoding can be found in Section 6.1 Bitstring Encoding.

credentialSubject.ttl The ttl indicates the "time to live" in milliseconds. This property MAY be present. If not present, implementers MUST use a value of 300000 for this property. A verifier MUST NOT use a cached BitstringStatusListCredential that was cached for more than the ttl duration prior to the start of verification operation on a verifiable credential. Implementations that publish the status list SHOULD align any protocol-specific caching information, such as the HTTP Cache-Control header, with the value in this field.

credentialSubject.size The size indicates the size of the status entry in bits. size MAY be provided. If size is not present as a property of the credentialStatus, then size MUST be processed as 1. size MUST be an integer greater than zero. If size is provided and is greater than 1, then the property credentialStatus.statusMessages MUST be present, and the number of status messages must equal the number of possible values.

credentialSubject.statusMessages

The statusMessages property MUST be an array. If present, the length of the array must equal the number of possible status states indicated by size. statusMessages MAY be present if size is 1. statusMessages MUST be present if size is greater than 1. If not present, the message value associated with the bit value of 0 is "unset" and the bit value of 1 is "set". If present, elements in the statusMessages array MUST contain at minimum two properties:

status, being a string of the hex value of the status
value, being a string containing the associated message

Implementers MAY add additional values to objects in the statusMessages array. Implementers MAY use the string value of undefined in the value to indicate that a corresponding status is not defined for the associated status value, but that it may be defined in the future. Rules for how to handle various status messages are outside the scope of normative requirements in this document, but it is assumed that implementers will document rules for processing various status codes.

credentialSubject.reference

The reference property provides a point for implementers to include a [URL] to material related to the status. An implementer MAY include the reference property, and if they do, the value MUST be a [URL] or an array of URLs. Implementers using a statusPurpose of status are strongly encouraged to provide a reference.

Note: Details around reference

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

Example 2: Example BitstringStatusListCredential

{
  "@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",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  },
  "proof": { ... }
}

Issue 73: Design of multiple status messages is not finalized. before-CR pr exists

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.

Example 3: Example BitstringStatusListCredential

{
  "@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 following section outlines the algorithms that are used to generate and validate status lists as described by this document.

The following process, or one generating the exact output, MUST be followed when producing a BitstringStatusListCredential:

Let issued credentials be a list of all issued verifiable credentials.
Let RLC be an unsigned BitstringStatusListCredential without the encodedList property set.
Generate a compressed bitstring by passing issued credentials to the Bitstring Generation Algorithm.
Set the encodedList to compressed bitstring.
Generate a proof for the RLC and publish it to the endpoint listed in the verifiable credential.

The following process, or one generating the exact output, MUST be followed when validating a verifiable credential that is contained in a BitstringStatusListCredential:

Let credentialToValidate be a verifiable credential containing a credentialStatus entry that is a BitstringStatusListEntry.
Let status purpose be the value of statusPurpose in the credentialStatus entry in the credentialToValidate.
Dereference the statusListCredential URL, and ensure that all proofs verify successfully. If the dereference fails, or if any of the proof verifications fail, return a validation error.
Verify that the status purpose matches the statusPurpose value in the statusListCredential.
Let compressed bitstring be the value of the encodedList property of the BitstringStatusListCredential.
Let credentialIndex be the value of the statusListIndex property of the BitstringStatusListEntry.
Generate a revocation bitstring by passing compressed bitstring to the Bitstring Expansion Algorithm.
Let status be the value at the position indicated by the credentialIndex times the size in the bitstring.
For statusPurpose of revocation or suspension, return true if status is 1, and return false if status has any other value. For other statusPurpose, return the corresponding value of the status as indicated in the statusMessages array.

The following process, or one generating the exact output, MUST be followed when generating a status list bitstring. The algorithm takes a issuedCredentials list as input and returns a compressed bitstring as output.

Let bitstring be a list of bits with a minimum size of 16KB, where each bit is initialized to 0 (zero).
For each value in bitstring, if there is a corresponding statusListIndex value in a credential in issuedCredentials, set the value to the appropriate status. The position of the value is computed as statusListIndex times the size.
Generate a compressed bitstring by using the GZIP compression algorithm [RFC1952] on the bitstring and then base64-encoding [RFC4648] the result.
Return the compressed bitstring.

The following process, or one generating the exact output, MUST be followed when expanding a compressed status list bitstring. The algorithm takes a compressed bitstring as input and returns a uncompressed bitstring as output.

Let compressed bitstring be a compressed status list bitstring.
Generate an uncompressed bitstring by using the base64-decoding [RFC4648] algorithm on the compressed bitstring and then expanding the output using the GZIP decompression algorithm [RFC1952].
Return the uncompressed bitstring.

This section is non-normative.

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.

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.

Some implementations might use the 415 Unsupported Media Type status code to signal that they do not support the requested media type.

This section is non-normative.

This section details the general privacy considerations and specific privacy implications of deploying this specification into production environments.

This section is non-normative.

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. 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, where the geographic request came from can also help to correlate individuals that have received a credential from the same geographic region.

This section is non-normative.

It is possible for verifiers to increase the privacy of the holder whose verifiable credential is being checked by caching status lists that have been fetched from remote servers. By caching the content locally, less correlatable information can be inferred from verifier-based access patterns on the status list.

This section is non-normative.

The use of content distribution networks by issuers can increase the privacy of holders by reducing or eliminating requests for the status lists from the issuer. Often, a request for a revocation list will be served by an edge device and thus be faster and reduce the load on the server as well as cloaking verifiers and holders from issuers.

This section is non-normative.

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.

This section is non-normative.

There are a number of security considerations that implementers should be aware of when processing data described by this specification. Ignoring or not understanding the implications of this section can result in security vulnerabilities.

While this section attempts to highlight a broad set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security and cryptography professionals when implementing mission critical systems using the technology outlined in this specification.

This section is non-normative.

It is critical that implementers pay particular attention to the way that they encode and decode bitstrings. Failure to do so can result in checking the wrong bitstring index for a given credential, leading to a misinterpretation of its present state (e.g., mistaking a revoked status for an unrevoked status). As stated in Section 2.2 BitstringStatusListCredential, bitstrings are encoded such that the first (zeroth) index refers to the left-most bit of the bitstring array. The diagram below demonstrates the proper layout for an uncompressed bitstring.

Figure 2 A visual depiction of the bitstring layout.

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.

This section is non-normative.

There are a number of accessibility considerations implementers should be aware of when processing data described in this specification. As with any web standards or protocols implementation, ignoring accessibility issues makes this information unusable to a large subset of the population. It is important to follow accessibility guidelines and standards, such as [WCAG21], to ensure all people, regardless of ability, can make use of this data. This is especially important when establishing systems utilizing cryptography, which have historically created problems for assistive technologies.

This section details the general accessibility considerations to take into account when utilizing this data model.

Issue

Write accessibility considerations.

This section is non-normative.

There are a number of internationalization considerations implementers should be aware of when publishing data described in this specification. As with any web standards or protocols implementation, ignoring internationalization makes it difficult for data to be produced and consumed across a disparate set of languages and societies, which would limit the applicability of the specification and significantly diminish its value as a standard.

This section outlines general internationalization considerations to take into account when utilizing this data model.

Issue

Write i18n considerations.

This section is non-normative.

Example 4: A Revocable Verifiable Credential

Verifiable CredentialSecured with Data IntegritySecured with VC-JWT

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2021-04-05T14:27:42Z",
  "credentialStatus": {
    "id": "https://example.com/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "did:example:12345",
  "validFrom": "2021-04-05T14:27:42Z",
  "credentialStatus": {
    "id": "https://example.com/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-01-07T13:21:21Z",
    "verificationMethod": "https://example.edu/issuers/565049/keys/1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2UC1GYR1GfrNTaJdbLN1ra5amsEYTgfkJvC9kXzxhGThc3CNQFpoack
c1f6XJoe38URK3UBNsM2NiTuzEyyYoZgD"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "https://example.com/credentials/23894672394",
    "type": [
      "VerifiableCredential"
    ],
    "issuer": "did:example:12345",
    "validFrom": "2021-04-05T14:27:42Z",
    "credentialStatus": {
      "id": "https://example.com/credentials/status/3#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://example.com/credentials/status/3"
    },
    "credentialSubject": {
      "id": "did:example:6789",
      "type": "Person"
    }
  },
  "iss": "did:example:12345",
  "jti": "https://example.com/credentials/23894672394",
  "sub": "did:example:6789"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZ
GVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2V4YW1wbGUuY29tL2NyZWRlbnRp
YWxzLzIzODk0NjcyMzk0IiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXI
iOiJkaWQ6ZXhhbXBsZToxMjM0NSIsInZhbGlkRnJvbSI6IjIwMjEtMDQtMDVUMTQ6Mjc6NDJaIi
wiY3JlZGVudGlhbFN0YXR1cyI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20vY3JlZGVudGlhb
HMvc3RhdHVzLzMjOTQ1NjciLCJ0eXBlIjoiQml0c3RyaW5nU3RhdHVzTGlzdEVudHJ5Iiwic3Rh
dHVzUHVycG9zZSI6InJldm9jYXRpb24iLCJzdGF0dXNMaXN0SW5kZXgiOiI5NDU2NyIsInN0YXR
1c0xpc3RDcmVkZW50aWFsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jcmVkZW50aWFscy9zdGF0dX
MvMyJ9LCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDpleGFtcGxlOjY3ODkiLCJ0eXBlI
joiUGVyc29uIn19LCJpc3MiOiJkaWQ6ZXhhbXBsZToxMjM0NSIsImp0aSI6Imh0dHBzOi8vZXhh
bXBsZS5jb20vY3JlZGVudGlhbHMvMjM4OTQ2NzIzOTQiLCJzdWIiOiJkaWQ6ZXhhbXBsZTo2Nzg
5In0.0yNVfd7w1agDWIncir_0qkjKnMqutmvT0168xTU-5Fz__-FlVvQL7m1VJYit7qCfi4JH7Q
abs4rvE_o5z-5KMg

Example 5: A Status List Verifiable Credential

Verifiable CredentialSecured with Data IntegritySecured with VC-JWT

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/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",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "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",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC
3AYbSVKsAQAAA"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-01-07T13:21:21Z",
    "verificationMethod": "https://example.edu/issuers/565049/keys/1",
    "proofPurpose": "assertionMethod",
    "proofValue": "zcLMAqPzBAgwWMagodHVEagnYA4RJQhX7dGzfKZCz5nXa5qKRb5JDscr
ExrDGXpVSCBGs7dbnPAXkPJtwqrgCYq5"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/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",
      "statusPurpose": "revocation",
      "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAA
IC3AYbSVKsAQAAA"
    }
  },
  "iss": "did:example:12345",
  "jti": "https://example.com/credentials/status/3",
  "sub": "https://example.com/status/3#list"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZ
GVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2V4YW1wbGUuY29tL2NyZWRlbnRp
YWxzL3N0YXR1cy8zIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkJpdHN0cmluZ1N
0YXR1c0xpc3RDcmVkZW50aWFsIl0sImlzc3VlciI6ImRpZDpleGFtcGxlOjEyMzQ1IiwidmFsaW
RGcm9tIjoiMjAyMS0wNC0wNVQxNDoyNzo0MFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6I
mh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzLzMjbGlzdCIsInR5cGUiOiJCaXRzdHJpbmdTdGF0
dXNMaXN0Iiwic3RhdHVzUHVycG9zZSI6InJldm9jYXRpb24iLCJlbmNvZGVkTGlzdCI6Ikg0c0l
BQUFBQUFBQUEtM0JNUUVBQUFEQ29QVlBiUXdmb0FBQUFBQUFBQUFBQUFBQUFBQUFBSUMzQVliU1
ZLc0FRQUFBIn19LCJpc3MiOiJkaWQ6ZXhhbXBsZToxMjM0NSIsImp0aSI6Imh0dHBzOi8vZXhhb
XBsZS5jb20vY3JlZGVudGlhbHMvc3RhdHVzLzMiLCJzdWIiOiJodHRwczovL2V4YW1wbGUuY29t
L3N0YXR1cy8zI2xpc3QifQ._Iy5C5vhCp_T3c_BLW7Yd_3TO_SfuFhs_VSTyqSfhUzo0NTRWCEy
BpeF47eRT9iuBJb4DKqyfmjzCDmi8NwGZA

[RFC1952]: GZIP file format specification version 4.3. P. Deutsch. IETF. May 1996. Informational. URL: https://www.rfc-editor.org/rfc/rfc1952
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC4648]: The Base16, Base32, and Base64 Data Encodings. S. Josefsson. IETF. October 2006. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4648
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[URL]: URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VC-DATA-MODEL]: Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/

[rfc7231]: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[WCAG21]: Web Content Accessibility Guidelines (WCAG) 2.1. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell. W3C. 21 September 2023. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/

Original Source | Taken Source

Bitstring Status List v1.0

Privacy-preserving status information for Verifiable Credentials

Abstract

Status of This Document

1. Introduction

1.1 Conceptual Framework

1.2 Terminology

1.3 Conformance

2. Data Model

2.1 BitstringStatusListEntry

2.2 BitstringStatusListCredential

3. Algorithms

3.1 Generate Algorithm

3.2 Validate Algorithm

3.3 Bitstring Generation Algorithm

3.4 Bitstring Expansion Algorithm

4. Media Types

5. Privacy Considerations

5.1 Revocation Bitstring Length

5.2 Verifier Caching

5.3 Content Distribution Networks

5.4 Malicious Issuers and Verifiers

6. Security Considerations

6.1 Bitstring Encoding

7. Accessibility Considerations

8. Internationalization Considerations

9. Appendix

9.1 Examples

9.1.1 Revocable Verifiable Credential

9.1.2 Status List Verifiable Credential

A. References

A.1 Normative references

A.2 Informative references