Summary

  • W3C published Bitstring Status List v1.1 as a First Public Working Draft on 24 September; the existing v1.0 remains a Recommendation.
  • The new TerseBitstringStatusListEntry stores a base URL and a 32-bit index. A specified conversion reconstructs a conventional status-list reference using a verifier-supplied status purpose.
  • A shorter reference is not a privacy or validity verdict: the list’s proof, freshness and actual population still matter.

The proposed saving is on the credential, not in the decision. In the W3C Verifiable Credentials Working Group’s new draft, a terse status entry can hold just a base URL and an unsigned 32-bit index. A verifier turns those fields into a conventional Bitstring Status List entry before checking whether a credential is suspended, revoked or carries another status. The compressed reference is useful precisely because many credentials can point into shared lists; it does not remove the operator and verifier choices around those lists.

This is the first public working draft of version 1.1, dated 24 September. W3C’s 2025 Bitstring Status List v1.0 is already a Recommendation. The large shared bitstring, the privacy rationale for avoiding a one-credential-one-lookup endpoint, and the possibility that the list’s issuer differs from the credential’s issuer are inherited features, not newly bestowed by this publication. Nor does the draft itself indicate W3C-member endorsement or replace the Recommendation.

The distinctive addition is a conversion contract. Section 2.3 fixes the terse index space at 32 bits and specifies lists of 2²⁶ entries, yielding 2⁶ possible list positions. Those are rules for deriving a location, not a report that 64 lists have been deployed. In Section 3.5 the verifier divides the terse index by the list length to identify the list, takes the remainder as the entry’s position, and constructs a URL from base address, status purpose and list number.

One input is conspicuously absent from the compact entry. It does not carry statusPurpose; the verifier supplies that when reconstructing the full entry. The draft notes that the terse entry is typically what is digitally signed and that signature verification ought to precede conversion. Saving bytes has therefore separated the signed pointer from part of the question asked of it. A relying system needs a defensible rule for which purpose it requests, not merely a parser that reproduces the index arithmetic.

The ordinary status-list check still requires retrieving the list and verifying its proofs. A holder can present a signed list with the credential, limiting live contact with its publisher, but a verifier may seek a newer copy. A list’s optional ttl suggests when to refresh and does not extend its validity period. The draft’s privacy discussion also warns that a capacious list is not, by itself, a crowd: few real issued credentials can leave holders distinguishable. These conditions are especially relevant when a smaller credential representation encourages more constrained uses.

Sources