Would be nice to see examples where same origin and different origins are used.

Example 1

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "https://example.com/credentials/status/3", // origin 1
  "type": ["VerifiableCredential", "StatusList2021Credential"],
  "issuer": "did:example:12345",
  "issued": "2021-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "https://example.com/status/3#list", // origin 1
    "type": "StatusList2021",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  },
  "proof": { ... }
}

Example 2

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "https://vendor1.example.com/credentials/status/3", // origin 1
  "type": ["VerifiableCredential", "StatusList2021Credential"],
  "issuer": "did:example:12345",
  "issued": "2021-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "https://vendor2.example.com/status/3#list",  // origin 2
    "type": "StatusList2021",
    "statusPurpose": "revocation",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  },
  "proof": { ... }
}

see pr #65 - need to add an example section

I have multiple concerns about the current proposal.

The current specification states the use of GZIP for compression for the whole bitstring. This algorithm compresses bitstring into a series of Huffman-compressed blocks. I agree this is a reasonable choice from the size-efficiency point of view.

However, I think the current discussion lacks some implementation considerations. This includes where the entire list is kept and how the verifier efficiently accesses a revocation bit. Will the verifier need to retrieve the whole status list? I understand we are discussing this in a technology-neutral manner as far as possible. Still, we need to consider implementation details if we start discussing how to treat bits and compression.

There are two points of view I want to share here.

The expected transaction model does not match blockchain-like storage

This scheme (compressing the entire bitstring) is unsuitable if the maintainer wants to record the status list data onto a blockchain-like ledger. We can't know how frequently the maintainer will update the list. In a worst-case scenario, the maintainer must continuously replace the entire status list on the storage. This is acceptable for a typical file system since replacement of the file contents is almost zero cost. But for a blockchain-like ledger, the cost will be hard to ignore.

From this point of view, I think how the data model looks and how the bits are stored need to be discussed separately.

The memory and storage requirements

It looks like there is an assumption of the model using the list to fetch the entire list, verify, uncompress, and find a bit. From a client who wants a single bit, this is not acceptable if the size of the status list is considerably large. Some numbers are mentioned in the current specification, but are these assumptions safe? Do we need to have another specification support a large number of certificates? For example, with GZIP, the decoder needs to keep the Huffman tree in the block header in memory. Suppose the memory footprint for a verifier runtime on an IoT device needs to be very low. In that case, the verifier code needs to scan the bitstring while decompressing the sequence of blocks one by one, not just decompress and read a bit. Depending on the environment, this can be a real headache.

While the use of bitstring is attractive from a privacy point of view, we need to find a better way to serialize and compress the data.

v2 context will need updates per pr #69

@OR13 wrote:

No context changes that include dead links.

This specification needs a corresponding vocabulary document to be created.

Could we please give commit 343b8b5 a version (for example v0.0.1-predraft) and publish it? Few implementations are using this commit of this document in production and would like to be able to refer our clients, etc. to one document. The plan is to move to the latest version of StatusList2021 once published, but while some non-backward compatible changes are being made, it would be really appreciated if we could version a commit above as an interim solution. Happy to do a PR. Thanks!

https://w3c-ccg.github.io/vc-status-list-2021/#validate-algorithm

Let credentialIndex be the value of the statusListIndex property of the StatusList2021Credential.

However, StatusList2021Credential has no such property. Instead, it should be a reference to the StatusList2021Entry.

This is the same as #10 which shouldn't be closed. The provided examples use https://w3id.org/vc-status-list-2021/v1 as context URL, which resolves to 404.

Should bitstring be initialized randomly, (reduces compression).

Should bitstring be consumed randomly, (implementation burden on the issuer).

Hi!

I am thinking in the following scenario:

• Issued credentials stored in a database with auto-incremental id.
• Id primary keys can have gaps
• Id used as index

If we have some gaps when calculating the status-list, there will be some indexes not assigned to credentials. Is this ok, or the gaps must be avoided?

Thanks

there are multiple ways to secure a VC that is a StatusList2021Credential.

How does the verifier know whether it is JWS or linked data proof, which cryptosuite it is beforehand? In other words, how to ensure that the verifier actually can verify the StatusList2021Credential?

I think it is up to the trust framework/protocol, but implementation guidelines saying that this metadata needs to be obtained should be useful.

Section 2.3 titled StatusList2021Credential includes a credential example which is a RevocationList2021 Credential of type "RevocationList2021"

originally I though this was typo and all of these should have said StatusList2021 since they could be revocation lists or suspensions lists but as I went into to make a PR (I'm new to this group) I realized that this language might be evolving and I don't know which direction its going.

The endianness of the bitstring should be specified.

i.e. Does index "0" of the bitstring refer to the leftmost bit in the first byte (bit mask 0x80) or to the rightmost bit of the first byte (bit mask 0x01)

Each holder's VC has its RLC issued at a different time. The bit string can change from time to time. That means different VC can have a different bit string in their RLCs. If two different RLC's bit strings have a different value in the same index, it doesn't mean any of the bit string is tempered. It only means one bit value may be changed between the time issuing the first RLC and the second RLC.

We need to add text to the specification that notes that the bit order for bitstring, namely in an array of bits from 0..N, the left most bit is index 0, and the right most bit is index N. This is not to be confused with big-endian vs. little-endian byte order.

@OR13 wrote:

I require an updated test vector / example encoded value to validate the GZIP implementation, ideally with a proof that it is indeed deterministic / idempotent.

Agree that having this in the spec would be a good thing. This issue is set up to track that requirement.

It has been suggested that the specification should articulate what HTTP status codes are sent by servers, and expected by clients, when certain operations, such as dereferencing occur. This issue has been created to track that concern.

https://w3c.github.io/vc-status-list-2021/#statuslist2021entry

2 possible issues to confirm:

1. Should the Example 1 title be "Example StatusList2021Entry"
2. Should the context have a 3rd entry, of the actual VC this is supposed to be? Example Citizenship etc if it supported credentialStatus.

... because if it is a status of a VC, entities are already expected to support VCs.

One advantage of it being a VC is that StatusList2021Credential can be downloaded by the Holder and sent to the Verifier when Holder is offline. Though if I am an attacker, I will download a version before my VC gets revoked, and keep sending it... so security considerations that a verifier needs to be careful when accepting a StatusList2021Credential offline should be included. Or include a "statusListCredential" URL inside statusList2021Credential so that there is a circular logic?

https://datatracker.ietf.org/doc/html/rfc3642

Seems wise to refer to it, and either confirm we conform to it, or explicitly state we do not.

I've been talking to partners about revocations and their requirements. I think this represents a new requirement that isn't covered in the specification, so I wanted to raise it here for discussion.

There is a use case where the party holds a credential and wants to re-verify it (since it could be revoked) upon request from a user. But they want to correlate that revocation time to business processes around the credential.
(sorry a bit vague but trying to protect the use case).

So they asked how they can find out the revocation status of a credential at a certain date and time or better yet, find the time/date of the revocation or suspension event by the issuer.

A few ways we though of:

If they are aware of that time they could ask for a StatusList2021Credential at that time and keep it with the credential. This may or may not be possible and the storage of these may be problematic and puts the burden on the verifier.

A query parameter could be added to the Get request for the StatusList2021Credential to query it based on a timestamp. This would allow the caller to know at any specific time whether it was revoked, but would not allow them to find out when it was revoked without some trial and error. The burden would be on the issuer (rightly so) to keep all the old copies of this (or to generate one on the fly) with this information.

A new format for a StatusList could include a date rather than just a bit, but of course this has some significant size ramifications that may affect the size and anonymity.

A resurface of a 2017CredentialStatusList-like implementation with an appropriate timestamp attached to the "claim". Of course this would have anonymity concerns.

Other ideas please!!

I wonder if the draft here could provide any guidance or tradeoffs or maybe even some standard language on appropriate ways to do this.

It would be very helpful if the specification referenced the vc-revocation-list-2020 and defined the differences between the two. I've been trying to scan to figure out the differences, and from what I can see a couple of mentions (and an example) of "SuspensionList" is the only change. Is that correct?

A related question is whether the VC for the list have a type that MUST be "RevocationList2021" as stated, or would it also allow "SuspensionList2021" to align with the addition of allowing SuspensionList in the VC given to the holder?

If that is the case, I would add my name to the question in #2 asking why not add a "call it whatever you want" listtype field so you aren't limited to revoke and suspend.

Thanks!

EU Regulatory and CPPA interpretation of an individual's rights to privacy related to the Right to Erasure present a pathological condition to the general revocation/suspension feature of a Verifiable Credential. Consider the following:

• Bob is a French Citizen, Acme Co is a German Employer
• Bob's VC is revoked by Acme Co (for whatever reason)
• Acme Co recomputes the revocation bitstring associated with the published StatusListCredential and performs the appropriate issuing steps to the trust registry, now verifiers can assert that Bob's VC is revoked.
• Bob still attempts to present his credential and is annoyed its revoked. Bob decides to invoke his GDPR individual privacy rights and demands that Acme Co erase all information they have about Bob. Under the aforementioned regulatory oversight bodies, this includes Bob's statusListIndex related to his VC, and the associated published content relating to or referencing that statusListIndex value
• So, Acme Co is forced to either: (a) comply, and by doing so and recomputing the revocation bitstring again - makes Bob's credential once again verifiable by nature of the Validate Algorithm current implementation ... or (b) decide not to comply with revocation bitstring recomputation, keeps Bob's bit on the string. In which case, Bob tries to present his credential, it shows up as revoked, now Bob can take Acme Co to court and win a settlement (again, under current regulatory interpretation).

Whilst this scenario is admittedly considered an edge case, it is an ongoing regulatory and privacy challenge with immutable data stores and some of the design constructs built into VC specifications. This is a formidable challenge to an implementor's ability to support privacy-preserving and regulatory compliant revocation/suspension.

I've tried considering some options to resolve, but each time I end up disqualifying them. Putting this up to circulate for feedback @msporny

We find the minimum bit length requirement of 131,072 (16 KiB) in the spec is quite arbitrary and limiting, can we make this requirement non-normative instead?

It is clear that the shorter the length the lesser the herd-privacy protection, but there is a case to be made that it is up to the use case and creator to decide the length.

Would it be possible to add a field to note the type of status a status list is for? Like for example: listType: "revocation", where you could put 'suspended', 'pending', or any other status list intent someone wanted?

Somewhat related to the idea of multiple topics broached in #2: have we considered using hexstrings (instead of bitstrings) to capture multiple states per credential or is that an entirely new spec with much more complexity?

The main benefit with this approach is that we could capture multiple states for each credential directly in the list string data structure. One issue I can think of is that it requires a larger uncompressed string to represent the same number of credentials, which may be alright depending on how we design the credential states and the frequency of encountering truthy values in said design. Another issue is that we would have to define all possible statuses in a table, but at least there is modern precedence for this design pattern in the multibase and multicodec work out of Protocol Labs.

Inviting discussion on more pros and cons in this thread as well as general feedback on this approach 👀

I'm requesting a TAG review of Verifiable Credential Status List 2021.

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

• Explainer¹ (minimally containing user needs and example code): Explainer
• Specification URL: Verifiable Credential Status List 2021
• Tests: Test Suite WIP
• User research: N/A
• Security and Privacy self-review²: Security and Privacy Self-Review
• GitHub repo (if you prefer feedback filed there): VC Status List Github
• Primary contacts (and their relationship to the specification):
  • Brent Zundel (@brentzundel), VCWG Chair, Gen
  • Kristina Yasuda (@Sakurann), VCWG Chair, Microsoft
  • Manu Sporny (@msporny), Editor, Digital Bazaar
  • Dave Longley (@dlongley), Editor, Digital Bazaar
  • Orie Steele (@OR13), Editor, Transmute
  • Mike Prorock (@mprorock), Editor, Mesur.io
  • Mahmoud Alkhraishi (@mkhraisha), Editor, Mavennet
• Organization(s)/project(s) driving the specification: W3C Verifiable Credentials Working Group
• Key pieces of existing multi-stakeholder review or discussion of this specification: n/a
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Issue Tracker

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:

The VCWG is planning to take this specification to Candidate Recommendation in September 2023 (at W3C TPAC), reviews before that time frame (ideally, by the end of July 2023) would be ideal.

• The group where the work on this specification is currently being done:
  W3C Verifiable Credentials Working Group
• Major unresolved issues with or opposition to this specification:

The specification is undergoing work to address definition and reference of multiple status beyond suspension and revocation.

• This work is being funded by: The members of the W3C VCWG that are actively participating in the development of these specifications including funding from the US Federal Government, the European Commission, and the Canadian Federal Government

You should also know that this work intersects heavily with the Verifiable Credentials v2.0 work, which is also something that the TAG will be actively reviewing around the same time

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Hi all,
I am working on the velocity network which is a SSI network focussed on individual careers.

We are basing our implementation of revocation on status-list 2021

We were looking at storing the bitlist under an ethereum account each of our issuers has. The zipping and embedding it in a VC elements seem unnecessary if we are using ethereum. The bitlist can be retrieved using an ethereum uri https://github.com/ethereum/EIPs/blob/master/EIPS/eip-681.md. Additionally we are looking at retrieving the status directly from the chain by calling a contract function that also takes the bitlist index, and returns status directly. To my understanding the privacy of the holder is still intact in using either contract function. The blockchain reads cannot be monitored by the issuer.

It has these benefits

• updating single elements or in bulk is supported and more efficient than having to revoke and resign VC each time an update happens
• it will continue to function even if an issuer becoming bankrupt, or closed down as the data is on chain
• it takes advantage of the underlying world-state compression engine (snappy)
• proofs are redundant since an account signing key is required to set or update the account's data.

So i would appreciate any feedback:

• Are these benefit fairly stated?
• We are looking to be standards compliant as much as we can. I dont want to presume to change the standard, but at the same time offhand i dont see an easy way to snap our proposed solution to it.

The constraints on the id property are listed in the Verifiable Credentials Data Model specification [VC-DATA-MODEL].

this is the only place that says that StatusList2021Credential must be [VC-DATA-MODEL] (v1.1).

We should clarify this in the description of Section 2.2 StatusList2021Credential

In what order should multiple status be processed?

How should an issuer set the order in which a verifier processes these?

In the case of suspension and revocation which takes priority?

Does the verifier have to process all the statues? or does it short circuit?

If the credential status index is out of bounds for the list (i.e. it is a negative number, or greater than the size of the list), should that be considered equivalent to if de-referenced to a 0, or to a 1; or should it raise an error?

CRL's support an optional reasonCode field (https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.1) that enables the CA to specify the reason for revocation, so that the validator can determine the severity of the revocation and chose different handling. Having an equivalent here would be extremely helpful.

probably based on url, but should be clarified in the spec text

Is a StatusList2021Credential expected to be issued by the issuer of the verifiable credentials whose revocation status it encodes?

In VC, it defines only one credentialStatus,

{
  "@context": {
    "@version": 1.1,
    "@protected": true,

    "VerifiableCredential": {
      "@id": "https://www.w3.org/2018/credentials#VerifiableCredential",
      "@context": {
        "@version": 1.1,
        "@protected": true,
        // ... omitted ...
        "credentialStatus": {"@id": "cred:credentialStatus", "@type": "@id"},
        // ... omitted ...

Then in StatusList, it defines only one purpose, either "revocation" or "suspension". Is there a possibility one may want to have 2 purposes in one credential?

{
  "@context": {
    "@protected": true,

    "StatusList2021": {
      "@id":
        "https://w3id.org/vc/status-list#StatusList2021",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "statusPurpose":
          "https://w3id.org/vc/status-list#statusPurpose",
        "encodedList": "https://w3id.org/vc/status-list#encodedList"
      }
    }
   // ... omitted ...

first question, what are we trying to version? I heard "objects", but would like to double click - it is a claimset? what do we expect to change?

changing 1 bit, reveals timing information.

There is some confusion about the semantics of the credentialStatus field, whether it refers to the status of the credential or the verifiable credential. (see w3c/vc-data-model#991) Clearly both the underlying credential (e.g. degree certificate) and the digitally signed VC have their own separate validity periods and statuses. This confusion is carried through into the status list specification in that the statusPurpose in not precise enough.
It has been stated that vc-status-list-2021 can apply to both the credential and the verifiable credential, in which case the statusPurpose must clearly specify to which of these this list applies.
The follow values for statusPurpose are suggested

credentialRevocation - the credential has been revoked (even though the cryptographic proof of the verifiable credential is still valid)
proofRevocation - the cryptographic proof of the verifiable credential has been revoked. This does not imply that the enclosed credential has been revoked, only that the verifiable credential has been revoked. The status of the credential is unknown.
credentialSuspension - the credential has been suspended. This may be reversed at a later time.

I am not sure it makes sense to have a proofSuspension. What does this mean and when would it apply?

For this section: https://w3c-ccg.github.io/vc-status-list-2021/#statuslist2021entry

The example should include an "id" field within the "credentialStatus" object to conform with the "id" field's description:
The constraints on the id property are listed in the Verifiable Credentials Data Model specification VC-DATA-MODEL.

The "Status" section of VC-DATA-MODEL requires an "id" field in the "credentialStatus" object: https://www.w3.org/TR/vc-data-model/#status

PR for quick fix: https://github.com/w3c-ccg/vc-status-list-2021/pull/30

Should the type value be RevocationList2021Status or RevocationList2021 (or am I missing something?)

See:

The specification for the id field of StatusList2021Entry states:

It MUST NOT be the URL for the status list.

Can anyone explain why this must not be the case? What is the purpose of the id field if it does not point to the list? The status of the credential is (usually) uniquely identified through statusListIndex and in the given examples id contains the statusListIndex, so it doesn't seem to provide any additional information that isn't already available via the other fields.

Thanks!

The spec provides an example for a Status List 2021 Entry

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:12345",
  "issued": "2021-04-05T14:27:42Z",
  "credentialStatus": {
    "id": "https://example.com/credentials/status/3#94567"
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person"
  },
  "proof": { ... }
}

Here the statusPurpose is defined as a string value with the options of revocation or suspension followed by a single index which is provided as 94567.

Does this mean that revocation and suspension are mutually exclusive. To include them both in the same status list, I need to have two bits for revoked yes, or no, and suspended yes or no.

00 Valid
01 Suspended
10 Revoked
11 (likely) Suspended then revoked

First i would like some clarity on the issue. Is it the intention of the spec to make suspension and revocation mutually exclusive? Such as when the credential is issued, the issuer understands the option that they can either issue a suspend-able credential that can be toggled on or off at will, OR a revocable credential, where revoking a credential a single time will render it invalid. OR is it the intention of the spec to allow these two statuses to be applied to the same credential?

This applies to the list that must be dereferenced.

The object that is dereferenced should be held in cache for the duration, this would enable more power efficient (less energy wasteful) credentials.

Every network request costs power.

What prevents the issuer from hosting several status list bitstrings (one for each credential) and embedding a statusListIndex value that represents one of those bitstrings at issuance time? This loophole would allow a 1:1 mapping between credential and status list, eliminating the herd privacy guarantees that are integral to this spec.

to reduce an attack surface.

and because StatusListCredential is a URL (includes URIs in WHAT WG definition) and it is not always WebPKI..?

if instead of a bit, a size of the status is defined, and a set of codes attached to status values is provided we could easily represent multiple types of status, rather than requiring checking multiple lists

Hello,

The spec mentions that the status list must be distributed as gzip'd bitstream in base64 (section 2.2). However the example contains a - character which is only supported in Base64Url (regular decoding in base64 of this example fails).
Could you clarify whether we should use base64url encoding, or fix the example in the draft documentation?

Best regards,
Arnaud

The current phrasing on compression is "ZLIB compression algorithm [RFC1950]", however upon reading the RFC it looks like ZLIB is a container format and the actual "default" compression algorithm is called deflate.

One would interpret the spec as: use deflate algorithm and ZLIB as the container.

However, the example given in the spec uses GZIP as the container (specifically the string H4sIAAAAAAAAA-3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAP4GcwM92tQwAAA).

So we are seeking clarification so that we can produce an interoperable implementation.

Examples reference URL https://w3id.org/vc-status-list-2021/v1 in @context:
https://github.com/w3c-ccg/vc-status-list-2021/blob/7d8f66b06483a22edfdfcd99bad86c7a56867145/index.html#L308
But that URL resolves to a 404.

Revocation List 2020 used a similar URL: https://w3id.org/vc-revocation-list-2020/v1, which resolves successfully.

There is a context file in this repo currently, but it is for 2020:
https://github.com/w3c-ccg/vc-status-list-2021/blob/7d8f66b06483a22edfdfcd99bad86c7a56867145/contexts/vc-revocation-list-2020/v1.jsonld

Should the 2020 context file in this repo be updated and renamed for 2021, and a similar namespace requested in w3id.org?