├── .github └── workflows │ ├── auto-publish.yml │ ├── gh-pages.yml │ └── lint-vocab.yml ├── .pr-preview.json ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── EXPLAINER.md ├── LICENSE.md ├── README.md ├── common.js ├── contexts ├── 2021 │ └── v1.jsonld └── v1.jsonld ├── diagrams ├── BitstringStatusListConcept.svg └── bitstring-layout.svg ├── errata.html ├── index.html ├── terms.html ├── transitions ├── 2023 │ └── FPWD │ │ ├── diagrams │ │ ├── StatusList2021.svg │ │ └── bitstring-layout.svg │ │ └── index.html ├── 2024 │ └── CR1 │ │ ├── diagrams │ │ ├── BitstringStatusListConcept.svg │ │ └── bitstring-layout.svg │ │ └── index.html └── 2025 │ ├── PR │ ├── diagrams │ │ ├── BitstringStatusListConcept.svg │ │ └── bitstring-layout.svg │ └── index.html │ └── REC │ ├── diagrams │ ├── BitstringStatusListConcept.svg │ └── bitstring-layout.svg │ └── index.html ├── vocab ├── README.md ├── template.html ├── vocabulary.drawio ├── vocabulary.svg └── vocabulary.yml └── w3c.json /.github/workflows/auto-publish.yml: -------------------------------------------------------------------------------- 1 | # .github/workflows/auto-publish.yml 2 | name: Publish to W3C 3 | on: 4 | pull_request: {} 5 | push: 6 | branches: [main] 7 | jobs: 8 | main: 9 | name: Build, Validate and Deploy 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/checkout@v3 13 | - uses: w3c/spec-prod@v2 14 | with: 15 | TOOLCHAIN: respec 16 | W3C_ECHIDNA_TOKEN: ${{ secrets.W3C_TR_TOKEN }} 17 | W3C_WG_DECISION_URL: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-04-12-vcwg#resolution1 18 | W3C_BUILD_OVERRIDE: | 19 | shortName: vc-bitstring-status-list 20 | specStatus: CRD 21 | -------------------------------------------------------------------------------- /.github/workflows/gh-pages.yml: -------------------------------------------------------------------------------- 1 | name: Publish to Github Pages 2 | on: 3 | push: 4 | branches: [main] 5 | # Allows workflow to be triggered manually from the Actions tab 6 | workflow_dispatch: 7 | 8 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 9 | permissions: 10 | contents: read 11 | pages: write 12 | id-token: write 13 | 14 | # Allow one concurrent deployment 15 | concurrency: 16 | group: "pages" 17 | cancel-in-progress: true 18 | 19 | jobs: 20 | deploy: 21 | environment: 22 | name: github-pages 23 | url: ${{ steps.deployment.outputs.page_url }} 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: Checkout 27 | uses: actions/checkout/@v4 28 | - name: Setup Node.js 29 | uses: actions/setup-node@v4 30 | with: 31 | node-version: 22 32 | - name: Generate vocabulary 33 | run: | 34 | npm info yml2vocab 35 | npm install --verbose yml2vocab 36 | ./node_modules/.bin/yml2vocab -v vocab/vocabulary.yml -t vocab/template.html 37 | rm -rf node_modules 38 | - name: Setup Github Pages 39 | uses: actions/configure-pages@v5 40 | - name: Upload artifact 41 | uses: actions/upload-pages-artifact@v3 42 | with: 43 | # Upload entire repository 44 | path: '.' 45 | - name: Deploy to GitHub Pages 46 | id: deployment 47 | uses: actions/deploy-pages@v4 48 | -------------------------------------------------------------------------------- /.github/workflows/lint-vocab.yml: -------------------------------------------------------------------------------- 1 | name: Lint the RDF vocabulary 2 | on: 3 | pull_request: 4 | paths: 5 | - 'vocab/security/vocabulary.yml' 6 | - 'vocab/security/template.html' 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: Setup environment 13 | uses: actions/checkout/@v3 14 | - name: Setup Node 20 15 | uses: actions/setup-node@v3 16 | with: 17 | node-version: 20 18 | - name: Lint Security Vocabulary 19 | run: | 20 | npm install yml2vocab 21 | npm update yml2vocab 22 | ./node_modules/.bin/yml2vocab -v vocab/vocabulary.yml -t vocab/template.html 23 | -------------------------------------------------------------------------------- /.pr-preview.json: -------------------------------------------------------------------------------- 1 | { 2 | "src_file": "index.html", 3 | "type": "respec" 4 | } 5 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # These owners will be the default owners for everything in 2 | # the repo. Unless a later match takes precedence, 3 | # they will be requested for review when someone opens a 4 | # pull request. 5 | * @msporny @mkhraisha @mprorock 6 | 7 | # See CODEOWNERS syntax here: https://help.github.com/articles/about-codeowners/#codeowners-syntax 8 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered 4 | by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 5 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Verifiable Credentials Working Group 2 | 3 | Contributions to this repository are intended to become part of 4 | Recommendation-track documents governed by the 5 | [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) and 6 | [Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software). 7 | To make substantive contributions to specifications, you must either participate 8 | in the relevant W3C Working Group or make a non-member patent licensing 9 | commitment. 10 | 11 | If you are not the sole contributor to a contribution (pull request), please 12 | identify all contributors in the pull request comment. 13 | 14 | To add a contributor (other than yourself; that's automatic), mark them one per 15 | line as follows: 16 | 17 | ``` 18 | +@github_username 19 | ``` 20 | 21 | If you added a contributor by mistake, you can remove them in a comment with: 22 | 23 | ``` 24 | -@github_username 25 | ``` 26 | 27 | If you are making a pull request on behalf of someone else but you had no part 28 | in designing the feature, you can remove yourself with the above syntax. 29 | -------------------------------------------------------------------------------- /EXPLAINER.md: -------------------------------------------------------------------------------- 1 | # Bitstring Status List Explained 2 | 3 | ## Authors 4 | 5 | - Mahmoud Alkhraishi (Mavennet) 6 | - Manu Sporny (Digital Bazaar) 7 | - Dave Longley (Digital Bazaar) 8 | - Orie Steele (Transmute) 9 | - Mike Prorock (mesur.io) 10 | 11 | ## Participate 12 | 13 | - [Issue tracker](https://github.com/w3c/vc-bitstring-status-list/issues) 14 | - [Discussion forum](https://lists.w3.org/Archives/Public/public-vc-wg/) 15 | 16 | ## Introduction 17 | 18 | This specification describes a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials. 19 | 20 | ## Goals 21 | 22 | Provide a location for an issuer of a 23 | [Verifiable Credential](https://www.w3.org/TR/vc-data-model-2.0/) to link to a 24 | location where a verifier can check to see if a credential has been suspended or 25 | revoked. 26 | 27 | ## How does it work? 28 | 29 | At the most basic level, status information for all verifiable credentials 30 | issued by an issuer are expressed as simple binary values. The issuer keeps a 31 | bitstring list of all verifiable credentials it has issued. Each verifiable 32 | credential is associated with a position in the list. If the binary value of the 33 | position in the list is 1 (one), the verifiable credential is revoked; if it is 34 | 0 (zero), it is not revoked. The verifier can then check the status of a 35 | verifiable credential by looking up the position of the verifiable credential in 36 | the bitstring list. This is the basic model used for Revocation and Suspension. 37 | 38 | A status list may have multiple states, exposed via a series of status messages. 39 | These status messages are intended to be extensible and interoperable with 40 | existing status message vocabularies. The status messages are intended to be 41 | machine-readable. The status messages are intended to be used by verifiers to 42 | determine the status of a verifiable credential. 43 | 44 | ## Examples 45 | 46 | ### Example 1: Single State StatusList Credential 47 | 48 | A `StatusList` credential contains a list with a singular purpose: "revocation". 49 | The list is a bitstring, where each bit represents the status of a verifiable 50 | credential. The list is encoded as a base64url-encoded bitstring. The bitstring 51 | is decoded to a list of booleans. The list of booleans is then used to determine 52 | the status of a verifiable credential, as shown. 53 | 54 | ```JSON 55 | { 56 | "@context": [ 57 | "https://www.w3.org/ns/credentials/v2" 58 | ], 59 | "id": "https://example.com/credentials/status/3", 60 | "type": ["VerifiableCredential", "BitstringStatusListCredential"], 61 | "issuer": "did:example:12345", 62 | "validFrom": "2021-04-05T14:27:40Z", 63 | "credentialSubject": { 64 | "id": "https://example.com/status/3#list", 65 | "type": "BitstringStatusList", 66 | "statusPurpose": "revocation", 67 | "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA" 68 | } 69 | } 70 | ``` 71 | 72 | An issuer can then issue a credential with a `credentialStatus` field that utilizes the issued `statusListCredential`. 73 | 74 | ```JSON 75 | { 76 | "@context": [ 77 | "https://www.w3.org/ns/credentials/v2" 78 | ], 79 | "id": "https://example.com/credentials/23894672394", 80 | "type": ["VerifiableCredential"], 81 | "issuer": "did:example:12345", 82 | "validFrom": "2021-04-05T14:27:42Z", 83 | "credentialStatus": { 84 | "id": "https://example.com/credentials/status/3#94567", 85 | "type": "BitstringStatusListEntry", 86 | "statusPurpose": "revocation", 87 | "statusListIndex": "94567", 88 | "statusListCredential": "https://example.com/credentials/status/3" 89 | }, 90 | "credentialSubject": { 91 | "id": "did:example:6789", 92 | "type": "Person" 93 | } 94 | } 95 | ``` 96 | 97 | ### Example 2: Multiple State StatusList Credential 98 | 99 | A `StatusList` credential may optionally contain a list of status messages. The following example defines statuses for "`0x0`", "`0x1`", and "`0x2`": 100 | 101 | ```JSON 102 | { 103 | "@context": [ 104 | "https://www.w3.org/ns/credentials/v2" 105 | ], 106 | "id": "https://example.com/credentials/status/3", 107 | "type": ["VerifiableCredential", "BitstringStatusListCredential"], 108 | "issuer": "did:example:12345", 109 | "validFrom": "2021-04-05T14:27:40Z", 110 | "credentialSubject": { 111 | "id": "https://example.com/status/3#list", 112 | "type": "BitstringStatusList", 113 | "ttl": 500, 114 | "statusPurpose": "status", 115 | "reference": "https://example.org/status-dictionary/", 116 | "size": 2, 117 | "statusMessage": [ 118 | {"status":"0x0", "message":"valid"}, 119 | {"status":"0x1", "message":"invalid"}, 120 | {"status":"0x2", "message":"pending_review"} 121 | ], 122 | "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA" 123 | } 124 | } 125 | ``` 126 | 127 | An example credential issued to use a multiple state `statusList` looks 128 | identical to one issued for a single use. 129 | 130 | ## Detailed design discussion 131 | 132 | There are a variety of privacy and performance considerations that are made when 133 | designing, publishing, and processing status lists. The following are some of 134 | the considerations that are being discussed by the Working Group. 135 | 136 | ### Privacy Considerations 137 | 138 | #### Correlation between holder, time, and verifier 139 | 140 | A privacy concern arises when there is a one-to-one mapping between a verifiable 141 | credential and a URL where its status is published. This type of mapping enables 142 | the website that publishes the URL to correlate the holder, time, and verifier, 143 | whenever the status is checked. This could enable the issuer to discover the 144 | type of interaction the holder is having with the verifier, such as providing an 145 | age verification credential when entering a bar. Being tracked by the issuer of 146 | a driver's license when entering an establishment violates a privacy expectation 147 | that many people have today. 148 | 149 | #### Malicious Issuers and Verifiers 150 | 151 | The group privacy protections offered by this specification can generally be 152 | circumvented by malicious issuers and verifiers. Its privacy benefits can only 153 | be realized when issuers and verifiers intend to avoid tracking or sharing the 154 | presentation of particular credentials. 155 | 156 | A malicious issuer might intentionally attack group privacy by creating a unique 157 | status list per credential issued in order to establish a 1-1 mapping to track 158 | when a verifier processes a specific credential. Similarly, they could establish 159 | another a 1-1 mapping by using a different cryptographic key for every 160 | credential issued that is tracked in a status list. 161 | 162 | A malicious verifier might intentionally attack group privacy by sharing 163 | information from presented credentials with a malicious issuer. 164 | 165 | ### Performance Considerations 166 | 167 | There are various performance considerations that are explored when designing 168 | status lists. One such consideration is the bandwidth and processing burden a 169 | published list places both on the server and on the client fetching the 170 | information. Bundling the statuses of large sets of credentials into a single 171 | list can help with group privacy. However, doing so can place an impossible 172 | burden on both server and client if the size of the status information is as 173 | much as a few hundred bytes per credential across a population of hundreds of 174 | millions of holders. 175 | 176 | ### Addressing Privacy and Performance 177 | 178 | The specification proposes a highly compressible, bitstring-based status list 179 | mechanism with strong privacy-preserving characteristics, that is compatible 180 | with the architecture of the Web, is highly space-efficient, and lends itself 181 | well to content distribution networks. For example, using this specification to 182 | achieve a number of beneficial privacy and performance goals, it is possible to 183 | construct a status list to handle 100,000 verifiable credentials at a maximum 184 | size of roughly 12,500 bytes. When only a few hundred of these credentials have 185 | been revoked, the size of the list is less than a few hundred bytes while 186 | providing privacy for a group of 100,000 individuals. 187 | 188 | * It is possible for verifiers to increase the privacy of holders whose 189 | verifiable credentials are being checked by caching status lists that have 190 | been fetched from remote servers. By caching the content locally, less 191 | correlatable information can be inferred from verifier-based access patterns 192 | on the status list. 193 | 194 | * The use of content distribution networks (CDNs) by issuers can increase the 195 | privacy of holders by reducing or eliminating requests for the status lists 196 | directly from the issuer. Often, a request for a revocation list can be served 197 | by an edge device and thus be faster and reduce the load on the server, as 198 | well as cloaking verifiers and holders from issuers. 199 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All Reports in this Repository are licensed by Contributors under the [W3C Software and Document 2 | License](https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document). 3 | 4 | Contributions to Specifications are made under the 5 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/). 6 | 7 | Contributions to Software, including sample implementations, are under the 8 | [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Verifiable Credential Bitstring Status List 2 | 3 | This specification describes a privacy-preserving, space-efficient, and 4 | high-performance mechanism for publishing the status information 5 | associated with Verifiable Credentials. 6 | 7 | [VC Bitstring Status List](https://w3c.github.io/vc-bitstring-status-list/) 8 | 9 | We encourage contributions meeting the [Contribution 10 | Guidelines](CONTRIBUTING.md). While we prefer the creation of issues 11 | and Pull Requests in the GitHub repository, discussions often occur 12 | on the 13 | [public-credentials](http://lists.w3.org/Archives/Public/public-credentials/) 14 | mailing list as well. 15 | 16 | ## Other useful links 17 | 18 | * [Public group email archive](https://lists.w3.org/Archives/Public/public-credentials/) 19 | -------------------------------------------------------------------------------- /common.js: -------------------------------------------------------------------------------- 1 | /* globals omitTerms, respecConfig, $, require */ 2 | /* exported linkCrossReferences, restrictReferences, fixIncludes */ 3 | 4 | var ccg = { 5 | // Add as the respecConfig localBiblio variable 6 | // Extend or override global respec references 7 | localBiblio: { 8 | "REST": { 9 | title: "Architectural Styles and the Design of Network-based Software Architectures", 10 | date: "2000", 11 | href: "http://www.ics.uci.edu/~fielding/pubs/dissertation/", 12 | authors: [ 13 | "Fielding, Roy Thomas" 14 | ], 15 | publisher: "University of California, Irvine." 16 | }, 17 | "string-meta": { 18 | title: "Requirements for Language and Direction Metadata in Data Formats", 19 | href: "https://w3c.github.io/string-meta/", 20 | authors: [ 21 | "Addison Phillips", 22 | "Richard Ishida" 23 | ], 24 | status: "Editors-DRAFT", 25 | publisher: "Internationalization Working Group" 26 | }, 27 | "LD-PROOFS": { 28 | title: "Linked Data Proofs", 29 | href: "https://w3c-dvcg.github.io/ld-proofs/", 30 | authors: [ 31 | "Manu Sporny", 32 | "Dave Longley" 33 | ], 34 | status: "CG-DRAFT", 35 | publisher: "Digital Verification Community Group" 36 | }, 37 | "LD-SIGNATURES": { 38 | title: "Linked Data Signatures", 39 | href: "https://w3c-dvcg.github.io/ld-signatures/", 40 | authors: [ 41 | "Manu Sporny", 42 | "Dave Longley" 43 | ], 44 | status: "CG-DRAFT", 45 | publisher: "Digital Verification Community Group" 46 | }, 47 | "LDS-RSA2018": { 48 | title: "The 2018 RSA Linked Data Signature Suite", 49 | href: "https://w3c-dvcg.github.io/lds-rsa2018/", 50 | authors: [ 51 | "Manu Sporny", 52 | "Dave Longley" 53 | ], 54 | status: "CG-DRAFT", 55 | publisher: "Digital Verification Community Group" 56 | }, 57 | // aliases to known references 58 | "HTTP-SIGNATURES": { 59 | aliasOf: "http-signatures" 60 | }, 61 | 'HASHLINK': { 62 | title: 'Cryptographic Hyperlinks', 63 | href: 'https://tools.ietf.org/html/draft-sporny-hashlink', 64 | authors: ['Manu Sporny'], 65 | status: 'Internet-Draft', 66 | publisher: 'Internet Engineering Task Force (IETF)' 67 | }, 68 | 'DID-CORE': { 69 | title: 'Decentralized Identifier Specification v1.0', 70 | href: 'https://w3c.github.io/did-spec/', 71 | // authors: [], 72 | status: 'ED-DRAFT', 73 | publisher: 'DID Working Group' 74 | }, 75 | 'ZCAP': { 76 | title: 'Authorization Capabilities for Linked Data', 77 | href: 'https://w3c-ccg.github.io/zcap-ld/', 78 | authors: [ 79 | "Christopher Lemmer Webber", 80 | "Manu Sporny", 81 | "Mark S. Miller" 82 | ], 83 | status: 'CG-DRAFT', 84 | publisher: 'Credentials Community Group' 85 | }, 86 | 'OHTTP': { 87 | title: 'Oblivious HTTP ', 88 | href: 'https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp', 89 | authors: ['Martin Thomson', 'Christopher A. Wood'], 90 | status: 'Working Group Draft', 91 | publisher: 'IETF Oblivious HTTP Application Intermediation' 92 | }, 93 | 'IPFS': { 94 | title: 'InterPlanetary File System (IPFS)', 95 | href: 'https://en.wikipedia.org/wiki/InterPlanetary_File_System', 96 | publisher: 'Wikipedia' 97 | } 98 | } 99 | }; 100 | require(["core/pubsubhub"], (respecEvents) => { 101 | "use strict"; 102 | 103 | console.log("RESPEC EVENTS", respecEvents); 104 | 105 | respecEvents.sub('end-all', (message) => { 106 | console.log("END EVENT", message); 107 | // remove data-cite on where the citation is to ourselves. 108 | const selfDfns = document.querySelectorAll("dfn[data-cite^='" + respecConfig.shortName.toUpperCase() + "#']"); 109 | for (const dfn of selfDfns) { 110 | delete dfn.dataset.cite; 111 | } 112 | 113 | // Update data-cite references to ourselves. 114 | const selfRefs = document.querySelectorAll("a[data-cite^='" + respecConfig.shortName.toUpperCase() + "#']"); 115 | for (const anchor of selfRefs) { 116 | anchor.href= anchor.dataset.cite.replace(/^.*#/,"#"); 117 | delete anchor.dataset.cite; 118 | } 119 | 120 | }); 121 | 122 | }); 123 | 124 | // Removes dfns that aren't referenced anywhere in the spec. 125 | // To ensure a definition appears in the Terminology section, use 126 | // and link to it! 127 | // This is triggered by postProcess in the respec config. 128 | function restrictRefs(utils, content, url){ 129 | 130 | // Get set of ids internal dfns referenced in the spec body 131 | const internalDfnLinks = document.querySelectorAll("a.internalDFN"); 132 | 133 | let internalDfnIds = new Set(); 134 | for (const dfnLink of internalDfnLinks) { 135 | const dfnHref = dfnLink.href.split("#")[1]; 136 | internalDfnIds.add(dfnHref); 137 | } 138 | 139 | // Remove unused dfns from the termlist 140 | const termlist = document.querySelector(".termlist"); 141 | const linkIdsInDfns = []; 142 | for (const child of termlist.querySelectorAll("dfn")){ 143 | if (!internalDfnIds.has(child.id)){ 144 | let dt = child.closest("dt"); 145 | let dd = dt.nextElementSibling; 146 | 147 | // Get internal links from dfns we're going to remove 148 | // because these show up in the dfn-panels later and then 149 | // trigger the local-refs-exist linter (see below) 150 | const linksInDfn = dd.querySelectorAll("a.internalDFN"); 151 | for (link of linksInDfn) { 152 | linkIdsInDfns.push(link.id); 153 | } 154 | 155 | termlist.removeChild(dt); 156 | termlist.removeChild(dd); 157 | } 158 | } 159 | 160 | // Remove unused dfns from the dfn-panels 161 | // (these are hidden, but still trigger the local-refs-exist linter) 162 | // (this seems like a hack, there's probably a better way to hook into respec 163 | // before it gets to this point) 164 | const dfnPanels = document.querySelectorAll(".dfn-panel"); 165 | for (const panel of dfnPanels) { 166 | if (!internalDfnIds.has(panel.querySelector(".self-link").href.split("#")[1])){ 167 | panel.parentNode.removeChild(panel); 168 | } 169 | 170 | // Remove references to dfns we removed which link to other dfns 171 | const panelLinks = panel.querySelectorAll("li a"); 172 | for (const link of panelLinks) { 173 | if (linkIdsInDfns.includes(link.href.split("#")[1])) { 174 | link.parentNode.removeChild(link); 175 | } 176 | } 177 | } 178 | 179 | } 180 | 181 | function _esc(s) { 182 | return s.replace(/&/g,'&') 183 | .replace(/>/g,'>') 184 | .replace(/"/g,'"') 185 | .replace(/ s.trim()).map(s => s.search(/[^\s]/)); 195 | const leastIndent = Math.min(...indents); 196 | return lines.map(s => s.slice(leastIndent)).join("\n"); 197 | } 198 | 199 | function updateExample(doc, content) { 200 | // perform transformations to make it render and prettier 201 | return _esc(reindent(unComment(doc, content))); 202 | } 203 | 204 | function unComment(doc, content) { 205 | // perform transformations to make it render and prettier 206 | return content 207 | .replace(//, '') 209 | .replace(/< !\s*-\s*-/g, '') 211 | .replace(/-\s*-\s*>/g, '-->'); 212 | } 213 | -------------------------------------------------------------------------------- /contexts/2021/v1.jsonld: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@protected": true, 4 | 5 | "StatusList2021Credential": { 6 | "@id": 7 | "https://w3id.org/vc/status-list#StatusList2021Credential", 8 | "@context": { 9 | "@protected": true, 10 | 11 | "id": "@id", 12 | "type": "@type", 13 | 14 | "description": "http://schema.org/description", 15 | "name": "http://schema.org/name" 16 | } 17 | }, 18 | 19 | "StatusList2021": { 20 | "@id": 21 | "https://w3id.org/vc/status-list#StatusList2021", 22 | "@context": { 23 | "@protected": true, 24 | 25 | "id": "@id", 26 | "type": "@type", 27 | 28 | "statusPurpose": 29 | "https://w3id.org/vc/status-list#statusPurpose", 30 | "encodedList": "https://w3id.org/vc/status-list#encodedList" 31 | } 32 | }, 33 | 34 | "StatusList2021Entry": { 35 | "@id": 36 | "https://w3id.org/vc/status-list#StatusList2021Entry", 37 | "@context": { 38 | "@protected": true, 39 | 40 | "id": "@id", 41 | "type": "@type", 42 | 43 | "statusPurpose": 44 | "https://w3id.org/vc/status-list#statusPurpose", 45 | "statusListIndex": 46 | "https://w3id.org/vc/status-list#statusListIndex", 47 | "statusListCredential": { 48 | "@id": 49 | "https://w3id.org/vc/status-list#statusListCredential", 50 | "@type": "@id" 51 | } 52 | } 53 | } 54 | } 55 | } 56 | -------------------------------------------------------------------------------- /contexts/v1.jsonld: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@protected": true, 4 | 5 | "id": "@id", 6 | "type": "@type", 7 | 8 | "BitstringStatusListCredential": "https://www.w3.org/ns/credentials/status#BitstringStatusListCredential", 9 | 10 | "BitstringStatusList": { 11 | "@id": "https://www.w3.org/ns/credentials/status#BitstringStatusList", 12 | "@context": { 13 | "@protected": true, 14 | 15 | "id": "@id", 16 | "type": "@type", 17 | 18 | "encodedList": { 19 | "@id": "https://www.w3.org/ns/credentials/status#encodedList", 20 | "@type": "https://w3id.org/security#multibase" 21 | }, 22 | "statusPurpose": 23 | "https://www.w3.org/ns/credentials/status#statusPurpose", 24 | "ttl": "https://www.w3.org/ns/credentials/status#ttl" 25 | } 26 | }, 27 | 28 | "BitstringStatusListEntry": { 29 | "@id": 30 | "https://www.w3.org/ns/credentials/status#BitstringStatusListEntry", 31 | "@context": { 32 | "@protected": true, 33 | 34 | "id": "@id", 35 | "type": "@type", 36 | 37 | "statusListCredential": { 38 | "@id": 39 | "https://www.w3.org/ns/credentials/status#statusListCredential", 40 | "@type": "@id" 41 | }, 42 | "statusListIndex": 43 | "https://www.w3.org/ns/credentials/status#statusListIndex", 44 | "statusPurpose": 45 | "https://www.w3.org/ns/credentials/status#statusPurpose", 46 | "statusMessage": { 47 | "@id": "https://www.w3.org/ns/credentials/status#statusMessage", 48 | "@context": { 49 | "@protected": true, 50 | 51 | "id": "@id", 52 | "type": "@type", 53 | 54 | "message": "https://www.w3.org/ns/credentials/status#message", 55 | "status": "https://www.w3.org/ns/credentials/status#status" 56 | } 57 | }, 58 | "statusReference": { 59 | "@id": "https://www.w3.org/ns/credentials/status#statusReference", 60 | "@type": "@id" 61 | }, 62 | "statusSize": { 63 | "@id": "https://www.w3.org/ns/credentials/status#statusSize", 64 | "@type": "https://www.w3.org/2001/XMLSchema#integer" 65 | } 66 | } 67 | } 68 | } 69 | } 70 | -------------------------------------------------------------------------------- /diagrams/bitstring-layout.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /errata.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 7 | 8 | 9 | Open Errata for the Bitstring Status List v1.0 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 22 | 23 | 24 |
25 | 26 |
27 |

Open Errata for the Bitstring Status List v1.0

28 |
29 |
Latest errata update:
30 |
31 |
Number of recorded errata:
32 |
33 |
Link to all errata:
34 |
35 |
36 | 37 |
38 |

How to Submit an Erratum?

39 |

Errata are introduced and stored in the issue list of the group‘s GitHub repository. The workflow to add a new erratum is as follows:

40 | 48 | 49 |

This report contains a reference to all open issues with the label Errata.

50 | 51 |

If you have problems following this process, but you want nevertheless to report an error, you can also contact the staff contact of the Working Group, ivan.

52 |
53 |
54 | 55 |
56 | 57 |
58 | 59 |
60 |

Open Errata on the “Bitstring Status List v1.0”

61 |
62 |
Latest Published Version:
63 |
https://www.w3.org/TR/vc-bitstring-status-list/
64 |
Editor’s draft:
65 |
https://github.com/w3c/vc-bitstring-status-list
66 |
Latest Publication Date:
67 |
15 May 2025
68 |
69 |
70 |

Substantive Issues

71 |
72 |
73 |

Editorial Issues

74 |
75 |
76 |
77 | 78 | 89 | 90 | 91 | -------------------------------------------------------------------------------- /terms.html: -------------------------------------------------------------------------------- 1 |

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

4 | 5 |
6 |
claim
7 |
8 | An assertion made about a subject. 9 |
10 |
credential
11 |
12 | A set of one or more claims made by an issuer. A 13 | verifiable credential is a 14 | tamper-evident credential that has authorship that can be cryptographically 15 | verified. Verifiable credentials can be used to build 16 | verifiable presentations, which can also be cryptographically verified. 17 | The claims in a credential can be about different subjects. 18 |
19 |
data minimization
20 |
21 | The act of limiting the amount of shared data strictly to the minimum 22 | necessary to successfully accomplish a task or goal. 23 |
24 |
decentralized identifier
25 |
26 | A portable URL-based identifier, also known as a DID, 27 | associated with an entity. These identifiers are most often used in a 28 | verifiable credential and are associated with subjects such that a 29 | verifiable credential itself can be easily ported from one 30 | repository to another without the need to reissue the credential. 31 | An example of a DID is did:example:123456abcdef. 32 |
33 |
decentralized identifier document
34 |
35 | Also referred to as a DID document, this is a document 36 | that is accessible using a verifiable data registry and contains 37 | information related to a specific decentralized identifier, such as the 38 | associated repository and public key information. 39 |
40 |
derived predicate
41 |
42 | A verifiable, boolean assertion about the value of another attribute in a 43 | verifiable credential. These are useful in zero-knowledge-proof-style 44 | verifiable presentations because they can limit information disclosure. 45 | For example, if a verifiable credential contains an attribute 46 | for expressing a specific height in centimeters, a derived predicate 47 | might reference the height attribute in the verifiable credential 48 | demonstrating that the issuer attests to a height value meeting the 49 | minimum height requirement, without actually disclosing the specific height 50 | value. For example, the subject is taller than 150 centimeters. 51 |
52 |
digital signature
53 |
54 | A mathematical scheme for demonstrating the authenticity of a digital message. 55 |
56 |
entity
57 |
58 | A thing with distinct and independent existence, such as a person, 59 | organization, or device that performs one or more roles in the ecosystem. 60 |
61 |
graph
62 |
63 | A network of information composed of subjects and their relationship 64 | to other subjects or data. 65 |
66 |
holder
67 |
68 | A role an entity might perform by possessing one or more 69 | verifiable credentials and generating presentations from them. 70 | A holder is usually, but not always, a subject of the verifiable 71 | credentials they are holding. Holders store their credentials in 72 | credential repositories. 73 |
74 |
identity
75 |
76 | The means for keeping track of entities across contexts. Digital 77 | identities enable tracking and customization of entity interactions 78 | across digital contexts, typically using identifiers and attributes. Unintended 79 | distribution or use of identity information can compromise privacy. Collection 80 | and use of such information should follow the principle of 81 | data minimization. 82 |
83 |
identity provider
84 |
85 | An identity provider, sometimes abbreviated as IdP, is a system 86 | for creating, maintaining, and managing identity information for 87 | holders, while providing authentication services to 88 | relying party applications within a federation or distributed network. 89 | In this case the holder is always the subject. Even if the 90 | verifiable credentials are bearer credentials, it is assumed the 91 | verifiable credentials remain with the subject, and if they are 92 | not, they were stolen by an attacker. This specification does not use this term 93 | unless comparing or mapping the concepts in this document to other 94 | specifications. This specification decouples the identity provider 95 | concept into two distinct concepts: the issuer and the holder. 96 |
97 |
issuer
98 |
99 | A role an entity can perform by asserting claims about one or 100 | more subjects, creating a verifiable credential from these 101 | claims, and transmitting the verifiable credential to a 102 | holder. 103 |
104 |
presentation
105 |
106 | Data derived from one or more verifiable credentials, issued by one or 107 | more issuers, that is shared with a specific verifier. A 108 | verifiable presentation 109 | is a tamper-evident presentation encoded in such a way that authorship of the 110 | data can be trusted after a process of cryptographic verification. Certain 111 | types of verifiable presentations might contain data that is synthesized from, 112 | but do not contain, the original verifiable credentials (for example, 113 | zero-knowledge proofs). 114 |
115 |
repository
116 |
117 | A program, such as a storage vault or personal verifiable credential 118 | wallet, that stores and protects access to holders' 119 | verifiable credentials. 120 |
121 |
selective disclosure
122 |
123 | The ability of a holder to make fine-grained decisions about what 124 | information to share. 125 |
126 |
subject
127 |
128 | A thing about which claims are made. 129 |
130 |
user agent
131 |
132 | A program, such as a browser or other Web client, that mediates the 133 | communication between holders, issuers, and verifiers. 134 |
135 |
validation
136 |
137 | The assurance that a verifiable credential or a 138 | verifiable presentation meets the needs of a verifier and other 139 | dependent stakeholders. This specification is constrained to verifying 140 | verifiable credentials and verifiable presentations regardless of 141 | their usage. Validating verifiable credentials or 142 | verifiable presentations is outside the scope of this specification. 143 |
144 |
verifiable data registry
145 |
146 | A role a system might perform by mediating the creation and verification 147 | of identifiers, keys, and other relevant data, such as 148 | verifiable credential schemas, revocation registries, issuer public keys, 149 | and so on, which might be required to use verifiable credentials. Some 150 | configurations might require correlatable identifiers for subjects. Some 151 | registries, such as ones for UUIDs and public keys, might just act as namespaces 152 | for identifiers. 153 |
154 |
verification
155 |
156 | The evaluation of whether a verifiable credential or verifiable presentation 157 | is an authentic and timely statement of the issuer or presenter, respectively. 158 | This includes checking that: the credential (or presentation) conforms to the specification; the proof method is 159 | satisfied; and, if present, the status check succeeds. 160 | 161 |
162 |
verifier
163 |
164 | A role an entity performs by receiving one or more 165 | verifiable credentials, optionally inside a 166 | verifiable presentation for processing. Other specifications might refer 167 | to this concept as a relying party. 168 |
169 |
URI
170 |
171 | A Uniform Resource Identifier, as defined by [[RFC3986]]. 172 |
173 |
174 | -------------------------------------------------------------------------------- /transitions/2023/FPWD/diagrams/bitstring-layout.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /transitions/2024/CR1/diagrams/bitstring-layout.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /transitions/2025/PR/diagrams/bitstring-layout.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /transitions/2025/REC/diagrams/bitstring-layout.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /vocab/README.md: -------------------------------------------------------------------------------- 1 | # Generate RDFS vocabulary files 2 | 3 | The script in the directory generates RDFS vocabulary files in JSON and Turtle formats, plus a human readable HTML file containing the vocabulary in RDFa, based on a simple vocabulary definition in a YAML file. This is done using the [yml2vocab](https://github.com/w3c/yml2vocab); more details about the script can also be found in the [yml2vocab readme file](https://github.com/w3c/yml2vocab). 4 | 5 | The generation of the final files is done via a github action (see `/.github/workflows/generate-vocab-files.yml`). 6 | 7 | ## Content of the directory 8 | 9 | - `README.md`: this file. 10 | - `vocabulary.yml`: the core vocabulary specification. _Any change on the vocabulary must be made by modifying this file;_ see the separate [description](https://github.com/w3c/yml2vocab) of the underlying YAML format. 11 | - `template.html`: an HTML template file used by the script; it is the skeleton of the final HTML format based on [ReSpec](https://respec.org/docs/). If the file is modified, care should be taken not to change the core structure and the various, possibly empty, HTML elements with `@id` values. The script fills those elements with content when generating the `vocabulary.html` file (and removes any sections that remain empty after processing). 12 | -------------------------------------------------------------------------------- /vocab/template.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 22 | 55 | 104 | 105 | 106 |
107 |

This document describes the , i.e., 108 | the . 109 |

110 |

Alternate versions of the vocabulary definition exist in 111 | Turtle and 112 | JSON-LD. 113 |

114 |
115 |
Published:
116 |
Version Info:
117 |
1.0
118 |
See Also:
119 |
120 |
121 |
122 |

123 | This vocabulary has been defined by the 124 | 125 | W3C Verifiable Credentials Working Group and provides the official RDFS 126 | vocabulary for 127 | 128 | Bitstring Status Lists. Comments regarding this document are welcome. 129 | Please file issues directly on 130 | GitHub, or 131 | send them to 132 | public-vc-comments@w3.org 133 | ( 134 | subscribe, 135 | 136 | archives). 137 |

138 |
139 |
140 |

Specification of terms

141 |

142 | In general, the terms — i.e., the properties and classes — used in 143 | the VCDM are formally specified in Recommendation Track documents published by 144 | the W3C Verifiable Credentials Working 145 | Group. In each case of such external definition, the term's description in 146 | this document contains a link to the relevant specification. Additionally, the 147 | `rdfs:definedBy` property in the RDFS representation(s) refers to the formal 148 | specification. 149 |

150 |

151 | In some cases, a local explanation is necessary to complement, or to replace, 152 | the definition found in an external specification. For instance, this is so when 153 | the term is needed to provide a consistent structure to the RDFS vocabulary, 154 | such as when the term defines a common supertype for class instances that are 155 | used as objects of specific properties. For such cases, 156 | the extra definition is included in the current 157 | document (and the `rdfs:comment` property is used to include them in the RDFS 158 | representations). 159 |

160 |
161 |
162 |
Overview diagram of the vocabulary (without the`xsd` 163 | datatypes). The terms prefixed by cred: or sec: are not defined in this vocabulary; 164 | they have only been added to the diagram for the sake of clarity.
165 | A separate, stand-alone SVG version of the diagram, as well as a textual description, 167 | are also available. 168 |
169 |
170 |
171 |
172 |

Namespaces

173 |

This specification makes use of the following namespaces:

174 |
175 |
176 |
177 | 178 |
179 |

@context files

180 |

The following @context files make use of the terms defined in this specification:

181 | 183 |
184 | 185 |
186 |

Regular terms

187 |
188 |

Property definitions

189 |
190 | 191 |
192 |

Class definitions

193 |
194 | 195 |
196 |

Datatype definitions

197 |
198 | 199 |
200 |

Definitions for individuals

201 |
202 |
203 | 204 |
205 |

Deprecated terms

206 | 207 |

All terms in this section are deprecated, and are only kept in this 208 | vocabulary for backward compatibility. 209 |

New applications should not use them. 210 |

211 | 212 |
213 |

Deprecated properties

214 |
215 | 216 |
217 |

Deprecated classes

218 |
219 | 220 |
221 |

Deprecated properties

222 |
223 | 224 |
225 |

Deprecated individuals

226 |
227 |
228 | 229 |
230 |

Diagram description

231 |
232 | Overview diagram of the vocabulary (without the `xsd` datatypes). The terms prefixed by cred: or 233 | sec: are not defined in this vocabulary; they have only been added to the diagram for the sake of clarity. 234 |

235 | The diagram uses boxes, ellipses, and connecting lines with different "styles" 236 | (border color, end marker, line type) to differentiate their semantic meaning: 237 | "Property", "Class", and "Datatype" are identified by the shape of the 238 | graph node (e.g., an ellipse signifies a "Class"); "Superclass", "Domain Of", or "Range" relationships 239 | are identified by the style of the connecting line. 240 | These style names are used in the explanation text that follows, below. 241 |

242 |

243 | The diagram is roughly divided into three sections — left, middle, and right. 244 | To make this description easier to understand, these sections will be respectively referred to 245 | as the "Classes", "Properties", and "Values" sections. 246 | Shapes in the three sections are connected by lines of different styles. 247 |

248 |
249 |

Classes Section

250 | 251 |

252 | The section contains three ellipses, labeled as "cred:CredentialStatus", 253 | "BitstringStatusListEntry", and "BitstringStatusList". It also contains 254 | a box, styled as "Property" and labeled as "cred:credentialStatus". 255 |

256 | 257 |

258 | The "cred:CredentialStatus" ellipse, is connected to the ellipse, 259 | labeled as "cred:CredentialStatus", with a line styled "Range". 260 | The ellipse labeled as "BitstringStatusListEntry" is connected to the 261 | ellipse, labeled as "cred:CredentialStatus", with a line styled as 262 | "Superclass". 263 |

264 | 265 |

266 | The ellipses labeled as "BitstringStatusListEntry" and "BitstringStatusList" are 267 | also connected to a number of boxes, all styled as "Property", with lines styled as 268 | "Domain Of"; see the "Properties" section below for further details. 269 |

270 |
271 |
272 |

Properties Section

273 | 274 |

275 | The section contains a number of boxes, each styles as "Property". The labels of 276 | these boxes are "statusListIndex", "statusListCredential", "statusPurpose", 277 | "statusMessage", "ttl", "statusReference", "statusSize", and "encodedList". 278 | There is also a small, unlabeled circle, which serves as an intersection point for connector 279 | lines. 280 |

281 | 282 |

283 | The ellipse labeled as "BitstringStatusListEntry", described in the previous section, is 284 | connected to the "statusListIndex", and "statusListCredential" boxes with lines styled as "Domain Of". 285 | The ellipse labeled as "BitstringStatusList", also described in the previous section, 286 | is connected to the "statusMessage", "ttl", "statusReference", "statusSize", 287 | and "encodedList" boxes, also with lines styled as "Domain Of". 288 |

289 | 290 |

291 | Both the ellipses labeled as "BitstringStatusListEntry" and "BitstringStatusList" are connected to the 292 | intersection point with a line styled as "Domain Of", and the intersection point is connected to the 293 | box labeled as "statusPurpose with a line styled as "Domain Of". 294 |

295 |
296 |
297 |

Values Section

298 | 299 |

300 | The section contains and ellipse, labeled as "BitstringStatusListCredential", which is connected to 301 | another ellipse, labeled as "cred:VerifiableCredential", with a line styled as "Superclass". 302 | The box labeled as "statusListCredential", described in the previous section, is connected to the ellipse, 303 | labeled as "BitstringStatusListCredential", with a line styled as "Range". 304 |

305 | 306 |

307 | Another ellipse, labeled as "BistringStatusMessage", is connected to two boxes with lines styled 308 | as "Domain Of". The boxes are styled as "Property" and are labeled with "status" and "message". 309 | The box labeled as "statusMessage", described in the previous section, is connected to the ellipse, 310 | labeled as "BistringStatusMessage", with a line styled as "Range". 311 |

312 | 313 |

314 | The box labeled as "statusSize", described in the previous section, is connected to a box, styled 315 | as "Datatype", and labeled as "xsd:positiveInteger", with a line styled as "Range". 316 |

317 | 318 |

319 | The box labeled as "encodedList", described in the previous section, is connected to a box, styled 320 | as "Datatype", and labeled as "sec:multibase", with a line styled as "Range". 321 |

322 |
323 |
324 |
325 | 326 | 327 | 328 | 329 | 330 | -------------------------------------------------------------------------------- /vocab/vocabulary.yml: -------------------------------------------------------------------------------- 1 | vocab: 2 | - id: cs 3 | value: https://www.w3.org/ns/credentials/status# 4 | context: https://www.w3.org/ns/credentials/status/v1 5 | 6 | prefix: 7 | - id: cred 8 | value: https://w3.org/2018/credentials# 9 | 10 | - id: sec 11 | value: https://w3id.org/security# 12 | 13 | ontology: 14 | - property: dc:title 15 | value: Bitstring Status List Vocabulary 16 | 17 | - property: dc:description 18 | value: RDFS [[RDF-SCHEMA]] vocabulary used by the [[[VC-BITSTRING-STATUS-LIST]]] [[VC-BITSTRING-STATUS-LIST]] 19 | 20 | - property: rdfs:seeAlso 21 | value: https://www.w3.org/TR/vc-bitstring-status-list/ 22 | 23 | class: 24 | - id: BitstringStatusList 25 | label: Bitstring status list class 26 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#bitstringstatuslist 27 | context: [vocab,https://www.w3.org/ns/credentials/v2] 28 | 29 | - id: BitstringStatusListEntry 30 | label: Bitstring status list entry class 31 | upper_value: cred:CredentialStatus 32 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#bitstringstatuslistentry 33 | context: [vocab,https://www.w3.org/ns/credentials/v2] 34 | 35 | - id: BitstringStatusListCredential 36 | label: Bitstring status list credential class 37 | upper_value: cred:VerifiableCredential 38 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#bitstringstatuslistcredential 39 | context: [vocab,https://www.w3.org/ns/credentials/v2] 40 | 41 | - id: BitstringStatusMessage 42 | label: Bitstring status message class 43 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusMessage 44 | context: [vocab,https://www.w3.org/ns/credentials/v2] 45 | 46 | property: 47 | - id: statusPurpose 48 | label: The purpose of the status list 49 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusPurpose 50 | domain: 51 | - cs:BitstringStatusList 52 | - cs:BitstringStatusListEntry 53 | range: xsd:string 54 | context: [vocab,https://www.w3.org/ns/credentials/v2] 55 | 56 | - id: statusListIndex 57 | label: The position of the entry in the status list 58 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusListIndex 59 | domain: cs:BitstringStatusListEntry 60 | range: xsd:string 61 | context: [vocab,https://www.w3.org/ns/credentials/v2] 62 | 63 | - id: statusListCredential 64 | label: The location of the status list credential 65 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusListCredential 66 | domain: cs:BitstringStatusListEntry 67 | range: cs:BitstringStatusListCredential 68 | context: [vocab,https://www.w3.org/ns/credentials/v2] 69 | 70 | - id: encodedList 71 | label: The encoded status list bitstring 72 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#encodedList 73 | domain: cs:BitstringStatusList 74 | range: sec:multibase 75 | context: [vocab,https://www.w3.org/ns/credentials/v2] 76 | 77 | - id: ttl 78 | label: Time to live in milliseconds 79 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#ttl 80 | domain: cs:BitstringStatusList 81 | range: xsd:string 82 | context: [vocab,https://www.w3.org/ns/credentials/v2] 83 | 84 | - id: statusSize 85 | label: Bitstring entry size in bits 86 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusSize 87 | domain: cs:BitstringStatusList 88 | range: xsd:positiveInteger 89 | context: [vocab,https://www.w3.org/ns/credentials/v2] 90 | 91 | - id: statusMessage 92 | label: Status message 93 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusMessage 94 | domain: cs:BitstringStatusList 95 | range: cs:BitstringStatusMessage 96 | context: [vocab,https://www.w3.org/ns/credentials/v2] 97 | 98 | - id: status 99 | label: Hexadecimal value of a status message 100 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#status 101 | range: xsd:string 102 | domain: cs:BitstringStatusMessage 103 | context: [vocab,https://www.w3.org/ns/credentials/v2] 104 | 105 | - id: message 106 | label: Human-readable message of a status value 107 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#message 108 | range: xsd:string 109 | domain: cs:BitstringStatusMessage 110 | context: [vocab,https://www.w3.org/ns/credentials/v2] 111 | 112 | - id: statusReference 113 | label: Reference documentation for status messages 114 | defined_by: https://www.w3.org/TR/vc-bitstring-status-list/#statusReference 115 | domain: cs:BitstringStatusList 116 | range: URL 117 | context: [vocab,https://www.w3.org/ns/credentials/v2] 118 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [ 3 | "98922" 4 | ], 5 | "contacts": [ 6 | "msporny", "dlongley", "iherman" 7 | ], 8 | "shortName": "vc-status-list-2021", 9 | "repo-type": "rec-track" 10 | } 11 | --------------------------------------------------------------------------------