├── .github ├── PULL_REQUEST_TEMPLATE.md └── workflows │ ├── echidna.yml │ ├── gh-pages.yml │ └── validate.yml ├── .gitignore ├── .pr-preview.json ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── NOTE ├── 2024-01-23 │ └── index.html ├── 2024-02-01 │ └── index.html └── 2024-09-17 │ └── index.html ├── README.md ├── common.js ├── index.html ├── specifications ├── bitstring-status-list.json ├── citizenship-vocabulary.json ├── comprehensive-learner-record-v2.json ├── credential-schema.json ├── di-bbs.json ├── di-ecdsa.json ├── di-eddsa.json ├── european-digital-credentials.json ├── european-learning-model-evidence.json ├── ida-evidence.json ├── jades.json ├── jws-2020.json ├── multibase-base58btc.json ├── multibase-base64url.json ├── multihash-sha2.json ├── multihash-sha3.json ├── multikey-bbs.json ├── multikey-ecdsa.json ├── multikey-eddsa.json ├── oci-dscsa-schema.json ├── open-badges-v3-credential-schema.json ├── open-badges-v3-credential-status.json ├── open-badges-v3-evidence.json ├── open-badges-v3-refresh-service.json ├── open-badges-v3.json ├── precondition-policy.json ├── traceability-vocabulary.json ├── train-tou.json ├── truage-v1-refresh-service.json ├── vc-ethr-revocation-registry.json ├── vc-jose-cose.json ├── vc-json-schema.json └── vdl-vocabulary.json ├── tooling ├── README.md ├── generate-index.js ├── package.json ├── specification-entry.yml └── validate.js └── w3c.json /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ## Instructions for Pull Requests 2 | 3 | Please read these instructions thoroughly in order to ensure that your pull request is processed in a timely manner. This document contains detailed instructions for adding your specification to the directory. If your pull request concerns some other change to the repository, you may delete all of the text in this text box and write up a more relevant description. 4 | 5 | Once you submit your request, your pull request will be reviewed by the directory maintainers. Changes regarding the required criteria may be requested. If there are no objections or changes requested, your entry will be merged after a minimum of 7 days and a maximum of 30 days. 6 | 7 | ## Adding Your Specification 8 | 9 | In order to add your specification to this directory, you must add a JSON file to the [./specifications](./specifications) directory. 10 | 11 | Here is an example specification entry: 12 | 13 | ```jsonc 14 | { 15 | // These fields are required 16 | "name": "Example VC", 17 | "summary": "Used to demonstrate examples for Verifiable Credentials.", 18 | "specification": "https://example.github.io/example-spec/", 19 | // categories include: vc, credentialStatus, credentialSchema, 20 | // refreshService, termsOfUse, evidence, and proof 21 | "category": "vc", 22 | "maintainerEmail": "maintainer@community.example", 23 | // These fields are optional 24 | "maintainerName": "Example Community Group", 25 | "maintainerWebsite": "https://example.github.io/", 26 | // RDF vocabularies in yml2vocab format 27 | "vocabulary": ["https://example.github.io/vocabularies/example.yml"] 28 | } 29 | ``` 30 | 31 | Your Pull Request will be automatically validated, please ensure that all of the automated tests pass (no errors reported) or your submission will not be reviewed. Common reasons for failed validation includes invalidly formatted JSON files and missing mandatory fields. 32 | -------------------------------------------------------------------------------- /.github/workflows/echidna.yml: -------------------------------------------------------------------------------- 1 | # .github/workflows/pr-push.yml 2 | name: Publish to Echidna 3 | on: 4 | push: 5 | branches: [main] 6 | jobs: 7 | main: 8 | name: Build, Validate and Deploy 9 | runs-on: ubuntu-20.04 10 | steps: 11 | - name: Begin spec-prod... 12 | uses: actions/checkout@v2 13 | - name: Setup Node 16... 14 | uses: actions/setup-node@v1 15 | with: 16 | node-version: 16.x 17 | - name: Install vc-specs-directory tooling... 18 | working-directory: tooling 19 | run: npm i 20 | - name: Validate vc-specs-directory DID method entries 21 | working-directory: tooling 22 | run: npm run validate 23 | - name: Generate vc-specs-directory registry index 24 | working-directory: tooling 25 | run: npm run generate-index 26 | - uses: w3c/spec-prod@v2 27 | with: 28 | W3C_ECHIDNA_TOKEN: ${{ secrets.W3C_TR_TOKEN }} 29 | W3C_WG_DECISION_URL: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-04-12-vcwg#resolution1 30 | W3C_BUILD_OVERRIDE: | 31 | shortName: vc-extensions 32 | specStatus: NOTE 33 | -------------------------------------------------------------------------------- /.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 | publish: 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/@v3 28 | - name: Setup Node 16 29 | uses: actions/setup-node@v3 30 | with: 31 | node-version: 16 32 | - name: Install vc-specs-directory tooling... 33 | working-directory: tooling 34 | run: npm i 35 | - name: Validate vc-specs-directory DID method entries 36 | working-directory: tooling 37 | run: npm run validate 38 | - name: Generate vc-specs-directory registry index 39 | working-directory: tooling 40 | run: npm run generate-index 41 | - name: Setup Github Pages 42 | uses: actions/configure-pages@v2 43 | - name: Upload artifact 44 | uses: actions/upload-pages-artifact@v1 45 | with: 46 | # Upload entire repository 47 | path: '.' 48 | - name: Deploy to GitHub Pages 49 | id: deployment 50 | uses: actions/deploy-pages@v1 51 | -------------------------------------------------------------------------------- /.github/workflows/validate.yml: -------------------------------------------------------------------------------- 1 | name: Validate VC Specs Directory 2 | on: 3 | pull_request: {} 4 | 5 | jobs: 6 | validate-directory: 7 | runs-on: ubuntu-latest 8 | steps: 9 | - name: Checkout source code... 10 | uses: actions/checkout@v2 11 | - name: Setup Node 16... 12 | uses: actions/setup-node@v2 13 | with: 14 | node-version: 16.x 15 | - name: Install vc-specs-directory tooling... 16 | working-directory: tooling 17 | run: npm i 18 | - name: Validate vc-specs-directory entries 19 | working-directory: tooling 20 | run: npm run validate 21 | - name: Generate vc-specs-directory index 22 | working-directory: tooling 23 | run: npm run generate-index 24 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | specifications/index.json 2 | tooling/node_modules 3 | 4 | -------------------------------------------------------------------------------- /.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 the repo. 2 | # Unless a later match takes precedence, these people will be requested for 3 | # review when someone opens a pull request. 4 | * @msporny @apuchitnis @stenreijers @esaung @michallis @richardwinputra @adam-burns @Steffytan @rajivrajani @genaris @harleyjackthomas @ajile-in @KDean-Dolphin -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors under the 2 | [W3C Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software). 3 | -------------------------------------------------------------------------------- /NOTE/2024-01-23/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 14 | 27 | 47 | 48 | VC Specifications Directory 49 | 50 | 51 | 52 | 110 | 111 | 112 | 113 | 143 | 144 | 148 | 149 | 163 | 170 | 218 | 219 |
220 |

222 |

VC Specifications Directory

The Verifiable Credential Specifications Directory

223 |

W3C Group Note

224 |
225 | More details about this document 226 |
227 |
This version:
228 | https://www.w3.org/TR/2024/NOTE-vc-specs-dir-20240123/ 229 |
230 |
Latest published version:
231 | https://www.w3.org/TR/vc-specs-dir/ 232 |
233 |
Latest editor's draft:
https://w3c.github.io/vc-specs-dir/
234 |
History:
235 | https://www.w3.org/standards/history/vc-specs-dir/ 236 |
237 | Commit history 238 |
239 | 240 | 241 | 242 | 243 | 244 |
Editor:
245 | Manu Sporny (Digital Bazaar) 246 |
247 | 248 |
Author:
249 | Manu Sporny (Digital Bazaar) 250 |
251 |
Feedback:
252 | GitHub w3c/vc-specs-dir 253 | (pull requests, 254 | new issue, 255 | open issues) 256 |
public-vc-wg@w3.org with subject line [vc-specs-dir] … message topic … (archives)
257 | 258 |
Related Documents
259 | Verifiable Credentials Data Model 260 |
261 |
262 |
263 | 264 | 265 |

266 | Copyright 267 | © 268 | 2024 269 | 270 | World Wide Web Consortium. 271 | W3C® 272 | liability, 273 | trademark and 274 | permissive document license rules apply. 275 |

276 |
277 |
278 |

Abstract

279 |

280 | This document serves as an unofficial directory for all known Verifiable 281 | Credential specifications whether they are released by a global standards 282 | setting organization, a community group, an open source project, or an 283 | individual. 284 |

285 |
286 | 287 |

Status of This Document

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

292 | 293 |

294 | Comments regarding this document are welcome. Please file issues 295 | directly on 296 | GitHub, 297 | or send them 298 | to public-vc-wg@w3.org ( 299 | subscribe, 300 | archives). 301 |

302 | 303 |

304 | This document was published by the Verifiable Credentials Working Group as 305 | a Group Note using the 306 | Note track. 307 |

This Group Note is endorsed by 308 | the Verifiable Credentials Working Group, but is not endorsed by 309 | W3C itself nor its 310 | Members.

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

316 | 317 | The 318 | W3C Patent 319 | Policy 320 | does not carry any licensing requirements or commitments on this 321 | document. 322 | 323 | 324 |

325 | This document is governed by the 326 | 03 November 2023 W3C Process Document. 327 |

328 | 329 | 330 |

1. Introduction

This section is non-normative.

331 | 332 | 333 |

334 | This document serves as an unofficial directory for all known Verifiable 335 | Credential specifications whether they are released by a global standards 336 | setting organization, a community group, an open source project, or an 337 | individual. 338 |

339 | 340 |

1.1 Adding a Specification Entry

341 | 342 |

343 | The Verifiable Credentials Data Model is designed to be extended by 3rd party 344 | specifications to address a variety of real world use cases. Examples of 345 | extensions include, but are not limited to, new types of Verifiable Credentials 346 | and ways of expressing credential status, schema validation, evidence, 347 | refreshing, terms of use, and cryptographic suites for securing credentials. 348 |

349 |

In 350 | order to add a new specification to this directory, an implementer submits a 351 | modification request for this directory, as a pull request on the repository 352 | where this directory is hosted. 353 |

354 | 355 | Here is an example: 356 | 357 |

358 |

359 |
360 | Example 1 361 | 
{
362 |   "name": "Example VC",
363 |   "summary": "Used to demonstrate examples for Verifiable Credentials.",
364 |   "specification": "https://example.github.io/example-spec/",
365 |   "category": "vc",
366 |   "maintainerEmail": "maintainer@community.example",
367 |   "maintainerName": "Example Community Group",
368 |   "maintainerWebsite": "https://example.github.io/",
369 |   "vocabulary": ["https://example.github.io/vocabularies/example.yml"]
370 | }
371 |
372 |

373 |

374 | The modification request MUST adhere to the following policies: 375 |

376 |
    377 |
  1. 378 | Any addition to the directory MUST conform to Section 379 | 1.1.1 Specification Entry Format. 380 |
    2. 381 |
  2. 382 | If there are copyright, trademark, or any intellectual property rights 383 | concerns, the addition and use MUST be authorized in writing by the intellectual 384 | property rights holder under a 385 | F/RAND 386 | license. Examples include specifications that use trademarked brand names, 387 | property names that utilize the titles of copyrighted works, and patented 388 | technology that would cause the use of the extension to require licensing a 389 | patent. 390 |
    3. 391 |
  3. 392 | Any addition MUST NOT create unreasonable legal, security, moral, or privacy 393 | issues that will result in direct harm to others. Examples of unacceptable 394 | additions include any containing racist language, technologies used to 395 | persecute minority populations, and unconsented pervasive tracking. 396 |
    4. 397 |
398 | 399 |

400 | The Editors of this directory MUST consider all of the policies above when 401 | reviewing additions to the directory and MUST reject directory entries if they 402 | violate any of the policies in this section. Entities registering additions can 403 | challenge rejections first with the W3C Verifiable Credentials Working Group and 404 | then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff 405 | need not be consulted on changes to the directory, but do have the final 406 | authority on directory contents. This is to ensure that W3C can adequately 407 | respond to time sensitive legal, privacy, security, moral, or other pressing 408 | concerns without putting an undue operational burden on W3C Staff. 409 |

410 | 411 |

412 | Any submission to the directory that meets all of the criteria listed above will 413 | be accepted for inclusion. The specifications listed in this directory enumerate 414 | all known specifications, without choosing between them. 415 |

416 | 417 |

1.1.1 Specification Entry Format

418 | 419 |

420 | The specification entry format MUST conform to the 421 | 422 | JSON Schema for a specification entry. Each field is documented below: 423 |

424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 436 | 437 | 438 | 439 | 443 | 444 | 445 | 446 | 450 | 451 | 452 | 453 | 462 | 463 | 464 | 465 | 469 | 470 | 471 | 472 | 476 | 477 | 478 | 479 | 483 | 484 | 485 | 486 | 491 | 492 | 493 |
FieldDescription
name 433 | A short human readable name for the specification. For example: Status List 434 | (v2021). 435 |
summary 440 | A one sentence description for the specification. For example: A credential 441 | status list with herd privacy characteristics. 442 |
specification 447 | An URL that resolves to a human readable specification. For example: 448 | https://w3c.github.io/vc-status-list-2021/. 449 |
category 454 | The Verifiable Credential extension category of the specification, which can 455 | be one of the following values: credentialStatus, credentialSchema, 456 | evidence, media-type, securing, refreshService, termsOfUse, or vc. 457 | For example: credentialStatus. 458 |
Note

459 | The extensions might define a @type. See [JSON-LD11]. 460 |

461 |
maintainerName 466 | A person or organization which responds to contact requests. For example: 467 | W3C Verifiable Credentials Working Group. 468 |
maintainerEmail 473 | An email to send contact requests. For example: 474 | public-vc-wg@w3.org. 475 |
maintainerWebsite 480 | An website to send contact requests. For example: 481 | https://www.w3.org/groups/wg/vc. 482 |
vocabulary 487 | An array of URLs that contain machine-readable vocabulary information in 488 | yml2vocab or JSON-LD format. For example: 489 | ["https://raw.githubusercontent.com/w3c/vc-status-list-2021/main/contexts/v1.jsonld"]. 490 |
494 |
495 |
496 | 497 |

1.2 Conformance

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.

498 | The key words MUST and MUST NOT in this document 499 | are to be interpreted as described in 500 | BCP 14 501 | [RFC2119] [RFC8174] 502 | when, and only when, they appear in all capitals, as shown here. 503 |

504 | 505 |
506 | 507 | 508 | 509 |

2. Property-based Extensions

510 | 511 | 512 |

2.1 Credential Status

513 | 514 | 515 | 516 | 517 | 518 | 519 | 520 | 521 | 522 |
SpecificationDescription
Bitstring Status List v1.0A credential status list with herd privacy characteristics.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech Revocation List Status MethodA simple list-based mechanism for publishing and checking the revocation status of a verifiable credential
Maintainer: 1EdTech (email) (website)
Ethr Revocation 2022An Ethereum, EIP-5539 compliant and registry-based revocation mechanism for Verifiable Credentials
Maintainer: Spherity GmbH (email) (website)
523 | 524 |
525 |

2.2 Credential Schema

526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | 534 | 535 |
SpecificationDescription
Verifiable Credentials JSON SchemaEnables JSON Schemas to be applied as a validation method to any portions of Verifiable Credentials
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech JSON Schema Validator 2019Credential data schema validation method for verifiable credentials using JSON Schema
Maintainer: 1EdTech (email) (website)
Validating Verifiable Credentials with JSON SchemaThis specification defines a JSON Schema based credential schema validation scheme for use with the credential schema property of Verifiable Credentials
Maintainer: Transmute (email) (website)
536 | 537 |
538 |

2.3 Evidence

539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 |
SpecificationDescription
OIDF eKYC and IDA EvidenceEvidence property that conforms to the OpenID Connect for Identity Assurance specification
Maintainer: David Chadwick (email) (website)
1EdTech Verifiable Credential Refresh ServiceDescriptive metadata about evidence related to an achievement assertion.
Maintainer: 1EdTech (email) (website)
549 | 550 |
551 |

2.4 Proof

552 | 553 | 554 | See Section 4. Securing Mechanisms. 555 | 556 |
557 |

2.5 Refresh Service

558 | 559 | 560 | 561 | 562 | 563 | 564 | 565 | 566 | 567 |
SpecificationDescription
1EdTech Verifiable Credential Refresh ServiceRefresh service for refreshing an expired or modified verifiable credential.
Maintainer: 1EdTech (email) (website)
568 | 569 |
570 |

2.6 Terms of Use

571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 |
SpecificationDescription
Precondition PolicyTerms of Use for Chain Reaction Revocation
Maintainer: Taisei Igarashi (email) (website)
TRAIN Terms of UseTerms of Use for an Issuer to indicate that they are a member of one or more TRAIN/ETSI list of trusted issuers
Maintainer: David Chadwick (email) (website)
581 | 582 |
583 |
584 |

3. Type-based Extensions

585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 |
SpecificationDescription
Comprehensive Learner Record v2Education credentials for sharing an individual's set of achievements and skills issued by multiple learning providers.
Maintainer: 1EdTech (email) (website)
DSCSA Authorized Trading PartnersAn architecture supporting the Authorized Trading Partner (ATP) requirements of the U.S. Drug Supply Chain Security Act (DSCSA), allowing for authentication and information exchange between DSCSA-defined ATPs and related stakeholders to establish mutual verification of identity and ATP status.
Maintainer: Open Credentialing Initiative (OCI) (email) (website)
Open Badges v3Education credentials for sharing achievements and skills.
Maintainer: 1EdTech (email) (website)
Traceability VocabularyThis specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain traceability. Verifiable Credentials using these terms can be used to help determine the legitimacy of organizations, and the status of the products and materials in global trade.
Maintainer: W3C Credentials Community Group (email) (website)
595 | 596 |
597 | 598 |

4. Securing Mechanisms

599 | 600 | 601 | 602 | 603 | 604 | 605 | 606 | 607 | 608 |
SpecificationDescription
BBS Cryptosuite (v2023)Securing Verifiable Credentials with Selective Disclosure using BBS Signatures.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity ECDSA Cryptosuites v1.0Achieving Data Integrity using ECDSA with NIST-compliant curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity EdDSA Cryptosuites v1.0Achieving Data Integrity using EdDSA with twisted Edwards elliptic curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
JSON Web Signatures for Data Integrity ProofsThis document has been withdrawn due to resolutions from the working group.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
Securing Verifiable Credentials using JOSE and COSEThis specification defines how to secure credentials and presentations conforming to the Verifiable Credentials Data Model, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE).
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
609 | 610 |
611 | 612 |

5. Media Type Extensions

613 | 614 | 615 | 616 | 617 | 618 | 619 | 620 | 621 | 622 |
SpecificationDescription
623 | 624 |
625 | 626 | 627 | 628 |

A. References

A.1 Normative references

629 | 630 |
[RFC2119]
631 | 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 632 |
[RFC8174]
633 | 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 634 |
635 |

A.2 Informative references

636 | 637 |
[JSON-LD11]
638 | JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/ 639 |
640 |
-------------------------------------------------------------------------------- /NOTE/2024-02-01/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 14 | 27 | 47 | 48 | VC Specifications Directory 49 | 50 | 51 | 52 | 110 | 111 | 112 | 113 | 143 | 144 | 148 | 149 | 163 | 170 | 218 | 219 |
220 |

222 |

VC Specifications Directory

The Verifiable Credential Specifications Directory

223 |

W3C Group Note

224 |
225 | More details about this document 226 |
227 |
This version:
228 | https://www.w3.org/TR/2024/NOTE-vc-specs-dir-20240201/ 229 |
230 |
Latest published version:
231 | https://www.w3.org/TR/vc-specs-dir/ 232 |
233 |
Latest editor's draft:
https://w3c.github.io/vc-specs-dir/
234 |
History:
235 | https://www.w3.org/standards/history/vc-specs-dir/ 236 |
237 | Commit history 238 |
239 | 240 | 241 | 242 | 243 | 244 |
Editor:
245 | Manu Sporny (Digital Bazaar) 246 |
247 | 248 |
Author:
249 | Manu Sporny (Digital Bazaar) 250 |
251 |
Feedback:
252 | GitHub w3c/vc-specs-dir 253 | (pull requests, 254 | new issue, 255 | open issues) 256 |
public-vc-wg@w3.org with subject line [vc-specs-dir] … message topic … (archives)
257 | 258 |
Related Documents
259 | Verifiable Credentials Data Model 260 |
261 |
262 |
263 | 264 | 265 |

266 | Copyright 267 | © 268 | 2024 269 | 270 | World Wide Web Consortium. 271 | W3C® 272 | liability, 273 | trademark and 274 | permissive document license rules apply. 275 |

276 |
277 |
278 |

Abstract

279 |

280 | This document serves as an unofficial directory for all known Verifiable 281 | Credential specifications whether they are released by a global standards 282 | setting organization, a community group, an open source project, or an 283 | individual. 284 |

285 |
286 | 287 |

Status of This Document

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

292 | 293 |

294 | This document is not a formal registry nor is it intended to become a 295 | 296 | Registry Track document per the W3C Process. 297 |

298 | 299 |

300 | Comments regarding this document are welcome. Please file issues 301 | directly on 302 | GitHub, 303 | or send them 304 | to public-vc-wg@w3.org ( 305 | subscribe, 306 | archives). 307 |

308 | 309 |

310 | This document was published by the Verifiable Credentials Working Group as 311 | a Group Note using the 312 | Note track. 313 |

This Group Note is endorsed by 314 | the Verifiable Credentials Working Group, but is not endorsed by 315 | W3C itself nor its 316 | Members.

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

322 | 323 | The 324 | W3C Patent 325 | Policy 326 | does not carry any licensing requirements or commitments on this 327 | document. 328 | 329 | 330 |

331 | This document is governed by the 332 | 03 November 2023 W3C Process Document. 333 |

334 | 335 | 336 |

1. Introduction

This section is non-normative.

337 | 338 | 339 |

340 | This document serves as an unofficial directory for all known Verifiable 341 | Credential specifications whether they are released by a global standards 342 | setting organization, a community group, an open source project, or an 343 | individual. 344 |

345 | 346 |

1.1 Adding a Specification Entry

347 | 348 |

349 | The Verifiable Credentials Data Model is designed to be extended by 3rd party 350 | specifications to address a variety of real world use cases. Examples of 351 | extensions include, but are not limited to, new types of Verifiable Credentials 352 | and ways of expressing credential status, schema validation, evidence, 353 | refreshing, terms of use, and cryptographic suites for securing credentials. 354 |

355 |

In 356 | order to add a new specification to this directory, an implementer submits a 357 | modification request for this directory, as a pull request on the repository 358 | where this directory is hosted. 359 |

360 | 361 | Here is an example: 362 | 363 |

364 |

365 |
366 | Example 1 367 | 
{
368 |   "name": "Example VC",
369 |   "summary": "Used to demonstrate examples for Verifiable Credentials.",
370 |   "specification": "https://example.github.io/example-spec/",
371 |   "category": "vc",
372 |   "maintainerEmail": "maintainer@community.example",
373 |   "maintainerName": "Example Community Group",
374 |   "maintainerWebsite": "https://example.github.io/",
375 |   "vocabulary": ["https://example.github.io/vocabularies/example.yml"]
376 | }
377 |
378 |

379 |

380 | The modification request MUST adhere to the following policies: 381 |

382 |
    383 |
  1. 384 | Any addition to the directory MUST conform to Section 385 | 1.1.1 Specification Entry Format. 386 |
    2. 387 |
  2. 388 | If there are copyright, trademark, or any intellectual property rights 389 | concerns, the addition and use MUST be authorized in writing by the intellectual 390 | property rights holder under a 391 | F/RAND 392 | license. Examples include specifications that use trademarked brand names, 393 | property names that utilize the titles of copyrighted works, and patented 394 | technology that would cause the use of the extension to require licensing a 395 | patent. 396 |
    3. 397 |
  3. 398 | Any addition MUST NOT create unreasonable legal, security, moral, or privacy 399 | issues that will result in direct harm to others. Examples of unacceptable 400 | additions include any containing racist language, technologies used to 401 | persecute minority populations, and unconsented pervasive tracking. 402 |
    4. 403 |
404 | 405 |

406 | The Editors of this directory MUST consider all of the policies above when 407 | reviewing additions to the directory and MUST reject directory entries if they 408 | violate any of the policies in this section. Entities registering additions can 409 | challenge rejections first with the W3C Verifiable Credentials Working Group and 410 | then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff 411 | need not be consulted on changes to the directory, but do have the final 412 | authority on directory contents. This is to ensure that W3C can adequately 413 | respond to time sensitive legal, privacy, security, moral, or other pressing 414 | concerns without putting an undue operational burden on W3C Staff. 415 |

416 | 417 |

418 | Any submission to the directory that meets all of the criteria listed above will 419 | be accepted for inclusion. The specifications listed in this directory enumerate 420 | all known specifications, without choosing between them. 421 |

422 | 423 |

1.1.1 Specification Entry Format

424 | 425 |

426 | The specification entry format MUST conform to the 427 | 428 | JSON Schema for a specification entry. Each field is documented below: 429 |

430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 442 | 443 | 444 | 445 | 449 | 450 | 451 | 452 | 456 | 457 | 458 | 459 | 468 | 469 | 470 | 471 | 475 | 476 | 477 | 478 | 482 | 483 | 484 | 485 | 489 | 490 | 491 | 492 | 497 | 498 | 499 |
FieldDescription
name 439 | A short human readable name for the specification. For example: Status List 440 | (v2021). 441 |
summary 446 | A one sentence description for the specification. For example: A credential 447 | status list with herd privacy characteristics. 448 |
specification 453 | An URL that resolves to a human readable specification. For example: 454 | https://w3c.github.io/vc-status-list-2021/. 455 |
category 460 | The Verifiable Credential extension category of the specification, which can 461 | be one of the following values: credentialStatus, credentialSchema, 462 | evidence, media-type, securing, refreshService, termsOfUse, or vc. 463 | For example: credentialStatus. 464 |
Note

465 | The extensions might define a @type. See [JSON-LD11]. 466 |

467 |
maintainerName 472 | A person or organization which responds to contact requests. For example: 473 | W3C Verifiable Credentials Working Group. 474 |
maintainerEmail 479 | An email to send contact requests. For example: 480 | public-vc-wg@w3.org. 481 |
maintainerWebsite 486 | An website to send contact requests. For example: 487 | https://www.w3.org/groups/wg/vc. 488 |
vocabulary 493 | An array of URLs that contain machine-readable vocabulary information in 494 | yml2vocab or JSON-LD format. For example: 495 | ["https://raw.githubusercontent.com/w3c/vc-status-list-2021/main/contexts/v1.jsonld"]. 496 |
500 |
501 |
502 | 503 |

1.2 Conformance

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.

504 | The key words MUST and MUST NOT in this document 505 | are to be interpreted as described in 506 | BCP 14 507 | [RFC2119] [RFC8174] 508 | when, and only when, they appear in all capitals, as shown here. 509 |

510 | 511 |
512 | 513 | 514 | 515 |

2. Property-based Extensions

516 | 517 | 518 |

2.1 Credential Status

519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 |
SpecificationDescription
1EdTech Revocation List Status MethodA simple list-based mechanism for publishing and checking the revocation status of a verifiable credential
Maintainer: 1EdTech (email) (website)
Bitstring Status ListA credential status list with herd privacy characteristics.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
Ethr Revocation 2022An Ethereum, EIP-5539 compliant and registry-based revocation mechanism for Verifiable Credentials
Maintainer: Spherity GmbH (email) (website)
529 | 530 |
531 |

2.2 Credential Schema

532 | 533 | 534 | 535 | 536 | 537 | 538 | 539 | 540 | 541 |
SpecificationDescription
Verifiable Credentials JSON SchemaEnables JSON Schemas to be applied as a validation method to any portions of Verifiable Credentials
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech JSON Schema Validator 2019Credential data schema validation method for verifiable credentials using JSON Schema
Maintainer: 1EdTech (email) (website)
Validating Verifiable Credentials with JSON SchemaThis specification defines a JSON Schema based credential schema validation scheme for use with the credential schema property of Verifiable Credentials
Maintainer: Transmute (email) (website)
542 | 543 |
544 |

2.3 Evidence

545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 |
SpecificationDescription
OIDF eKYC and IDA EvidenceEvidence property that conforms to the OpenID Connect for Identity Assurance specification
Maintainer: David Chadwick (email) (website)
1EdTech Verifiable Credential Refresh ServiceDescriptive metadata about evidence related to an achievement assertion.
Maintainer: 1EdTech (email) (website)
555 | 556 |
557 |

2.4 Proof

558 | 559 | 560 | See Section 4. Securing Mechanisms. 561 | 562 |
563 |

2.5 Refresh Service

564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 |
SpecificationDescription
1EdTech Verifiable Credential Refresh ServiceRefresh service for refreshing an expired or modified verifiable credential.
Maintainer: 1EdTech (email) (website)
574 | 575 |
576 |

2.6 Terms of Use

577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 |
SpecificationDescription
Precondition PolicyTerms of Use for Chain Reaction Revocation
Maintainer: Taisei Igarashi (email) (website)
TRAIN Terms of UseTerms of Use for an Issuer to indicate that they are a member of one or more TRAIN/ETSI list of trusted issuers
Maintainer: David Chadwick (email) (website)
587 | 588 |
589 |
590 |

3. Type-based Extensions

591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | 600 |
SpecificationDescription
Comprehensive Learner Record v2Education credentials for sharing an individual's set of achievements and skills issued by multiple learning providers.
Maintainer: 1EdTech (email) (website)
DSCSA Authorized Trading PartnersAn architecture supporting the Authorized Trading Partner (ATP) requirements of the U.S. Drug Supply Chain Security Act (DSCSA), allowing for authentication and information exchange between DSCSA-defined ATPs and related stakeholders to establish mutual verification of identity and ATP status.
Maintainer: Open Credentialing Initiative (OCI) (email) (website)
Open Badges v3Education credentials for sharing achievements and skills.
Maintainer: 1EdTech (email) (website)
Traceability VocabularyThis specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain traceability. Verifiable Credentials using these terms can be used to help determine the legitimacy of organizations, and the status of the products and materials in global trade.
Maintainer: W3C Credentials Community Group (email) (website)
601 | 602 |
603 | 604 |

4. Securing Mechanisms

605 | 606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 |
SpecificationDescription
BBS Cryptosuite (v2023)Securing Verifiable Credentials with Selective Disclosure using BBS Signatures.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity ECDSA Cryptosuites v1.0Achieving Data Integrity using ECDSA with NIST-compliant curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity EdDSA Cryptosuites v1.0Achieving Data Integrity using EdDSA with twisted Edwards elliptic curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
JSON Web Signatures for Data Integrity ProofsThis document has been withdrawn due to resolutions from the working group.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
Securing Verifiable Credentials using JOSE and COSEThis specification defines how to secure credentials and presentations conforming to the Verifiable Credentials Data Model, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE).
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
615 | 616 |
617 | 618 |

5. Media Type Extensions

619 | 620 | 621 | 622 | 623 | 624 | 625 | 626 | 627 | 628 |
SpecificationDescription
629 | 630 |
631 | 632 | 633 | 634 |

A. References

A.1 Normative references

635 | 636 |
[RFC2119]
637 | 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 638 |
[RFC8174]
639 | 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 640 |
641 |

A.2 Informative references

642 | 643 |
[JSON-LD11]
644 | JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/ 645 |
646 |
-------------------------------------------------------------------------------- /NOTE/2024-09-17/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 12 | 25 | 45 | 46 | Verifiable Credential Extensions 47 | 48 | 49 | 50 | 94 | 95 | 96 | 97 | 127 | 128 | 129 | 132 | 133 | 151 | 158 | 206 | 207 |
208 |

210 |

Verifiable Credential Extensions

A list of extensions for Verifiable Credentials

211 |

W3C Group Note

212 |
213 | More details about this document 214 |
215 |
This version:
216 | https://www.w3.org/TR/2024/NOTE-vc-extensions-20240917/ 217 |
218 |
Latest published version:
219 | https://www.w3.org/TR/vc-extensions/ 220 |
221 |
Latest editor's draft:
https://w3c.github.io/vc-extensions/
222 |
History:
223 | https://www.w3.org/standards/history/vc-extensions/ 224 |
225 | Commit history 226 |
227 | 228 | 229 | 230 | 231 | 232 |
Editor:
233 | Manu Sporny (Digital Bazaar) 234 |
235 | 236 |
Author:
237 | Manu Sporny (Digital Bazaar) 238 |
239 |
Feedback:
240 | GitHub w3c/vc-extensions 241 | (pull requests, 242 | new issue, 243 | open issues) 244 |
public-vc-wg@w3.org with subject line [vc-extensions] … message topic … (archives)
245 | 246 |
Related Documents
247 | Verifiable Credentials Data Model 248 |
249 |
250 |
251 | 252 | 253 |

254 | Copyright 255 | © 256 | 2024 257 | 258 | World Wide Web Consortium. 259 | W3C® 260 | liability, 261 | trademark and 262 | permissive document license rules apply. 263 |

264 |
265 |
266 |

Abstract

267 |

268 | This document serves as an unofficial list of all known Verifiable Credential 269 | specifications whether they are released by a global standards setting 270 | organization, a community group, an open source project, or an individual. 271 |

272 |
273 | 274 |

Status of This Document

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

279 | 280 |

281 | This document is not a formal registry nor is it intended to become a 282 | 283 | Registry Track document per the W3C Process. 284 |

285 | 286 |

287 | Comments regarding this document are welcome. Please file issues 288 | directly on 289 | GitHub, 290 | or send them 291 | to public-vc-wg@w3.org ( 292 | subscribe, 293 | archives). 294 |

295 | 296 |

297 | This document was published by the Verifiable Credentials Working Group as 298 | a Group Note using the 299 | Note track. 300 |

This Group Note is endorsed by 301 | the Verifiable Credentials Working Group, but is not endorsed by 302 | W3C itself nor its 303 | Members.

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

309 | 310 | The 311 | W3C Patent 312 | Policy 313 | does not carry any licensing requirements or commitments on this 314 | document. 315 | 316 | 317 |

318 | This document is governed by the 319 | 03 November 2023 W3C Process Document. 320 |

321 | 322 | 323 |

1. Introduction

This section is non-normative.

324 | 325 | 326 |

327 | This document serves as an unofficial directory for all known Verifiable 328 | Credential specifications whether they are released by a global standards 329 | setting organization, a community group, an open source project, or an 330 | individual. 331 |

332 | 333 |

1.1 Adding a Specification Entry

334 | 335 |

336 | The Verifiable Credentials Data Model is designed to be extended by 3rd party 337 | specifications to address a variety of real world use cases. Examples of 338 | extensions include, but are not limited to, new types of Verifiable Credentials 339 | and ways of expressing credential status, schema validation, evidence, 340 | refreshing, terms of use, and cryptographic suites for securing credentials. 341 |

342 |

In 343 | order to add a new specification to this directory, an implementer submits a 344 | modification request for this directory, as a pull request on the repository 345 | where this directory is hosted. 346 |

347 | 348 | Here is an example: 349 | 350 |

351 |

352 |
353 | Example 1 354 | 
{
355 |   "name": "Example VC",
356 |   "summary": "Used to demonstrate examples for Verifiable Credentials.",
357 |   "specification": "https://example.github.io/example-spec/",
358 |   "category": "vc",
359 |   "maintainerEmail": "maintainer@community.example",
360 |   "maintainerName": "Example Community Group",
361 |   "maintainerWebsite": "https://example.github.io/",
362 |   "vocabulary": ["https://example.github.io/vocabularies/example.yml"]
363 | }
364 |
365 |

366 |

367 | The modification request MUST adhere to the following policies: 368 |

369 |
    370 |
  1. 371 | Any addition to the directory MUST conform to Section 372 | 1.1.1 Specification Entry Format. 373 |
    2. 374 |
  2. 375 | If there are copyright, trademark, or any intellectual property rights 376 | concerns, the addition and use MUST be authorized in writing by the intellectual 377 | property rights holder under a 378 | F/RAND 379 | license. Examples include specifications that use trademarked brand names, 380 | property names that utilize the titles of copyrighted works, and patented 381 | technology that would cause the use of the extension to require licensing a 382 | patent. 383 |
    3. 384 |
  3. 385 | Any addition MUST NOT create unreasonable legal, security, moral, or privacy 386 | issues that will result in direct harm to others. Examples of unacceptable 387 | additions include any containing racist language, technologies used to 388 | persecute minority populations, and unconsented pervasive tracking. 389 |
    4. 390 |
391 | 392 |

393 | The Editors of this directory MUST consider all of the policies above when 394 | reviewing additions to the directory and MUST reject directory entries if they 395 | violate any of the policies in this section. Entities registering additions can 396 | challenge rejections first with the W3C Verifiable Credentials Working Group and 397 | then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff 398 | need not be consulted on changes to the directory, but do have the final 399 | authority on directory contents. This is to ensure that W3C can adequately 400 | respond to time sensitive legal, privacy, security, moral, or other pressing 401 | concerns without putting an undue operational burden on W3C Staff. 402 |

403 | 404 |

405 | Any submission to the directory that meets all of the criteria listed above will 406 | be accepted for inclusion. The specifications listed in this directory enumerate 407 | all known specifications, without choosing between them. 408 |

409 | 410 |

1.1.1 Specification Entry Format

411 | 412 |

413 | The specification entry format MUST conform to the 414 | 415 | JSON Schema for a specification entry. Each field is documented below: 416 |

417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 429 | 430 | 431 | 432 | 436 | 437 | 438 | 439 | 443 | 444 | 445 | 446 | 455 | 456 | 457 | 458 | 462 | 463 | 464 | 465 | 469 | 470 | 471 | 472 | 476 | 477 | 478 | 479 | 484 | 485 | 486 |
FieldDescription
name 426 | A short human readable name for the specification. For example: Status List 427 | (v2021). 428 |
summary 433 | A one sentence description for the specification. For example: A credential 434 | status list with herd privacy characteristics. 435 |
specification 440 | An URL that resolves to a human readable specification. For example: 441 | https://w3c.github.io/vc-status-list-2021/. 442 |
category 447 | The Verifiable Credential extension category of the specification, which can 448 | be one of the following values: credentialStatus, credentialSchema, 449 | evidence, media-type, securing, refreshService, termsOfUse, or vc. 450 | For example: credentialStatus. 451 |
Note

452 | The extensions might define a @type. See [JSON-LD11]. 453 |

454 |
maintainerName 459 | A person or organization which responds to contact requests. For example: 460 | W3C Verifiable Credentials Working Group. 461 |
maintainerEmail 466 | An email to send contact requests. For example: 467 | public-vc-wg@w3.org. 468 |
maintainerWebsite 473 | An website to send contact requests. For example: 474 | https://www.w3.org/groups/wg/vc. 475 |
vocabulary 480 | An array of URLs that contain machine-readable vocabulary information in 481 | yml2vocab or JSON-LD format. For example: 482 | ["https://raw.githubusercontent.com/w3c/vc-status-list-2021/main/contexts/v1.jsonld"]. 483 |
487 |
488 |
489 | 490 |

1.2 Conformance

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.

491 | The key words MUST and MUST NOT in this document 492 | are to be interpreted as described in 493 | BCP 14 494 | [RFC2119] [RFC8174] 495 | when, and only when, they appear in all capitals, as shown here. 496 |

497 | 498 |
499 | 500 | 501 | 502 |

2. Property-based Extensions

503 | 504 | 505 |

2.1 Credential Status

506 | 507 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | 515 |
SpecificationDescription
Bitstring Status List v1.0A credential status list with herd privacy characteristics.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech Revocation List Status MethodA simple list-based mechanism for publishing and checking the revocation status of a verifiable credential
Maintainer: 1EdTech (email) (website)
Ethr Revocation 2022An Ethereum, EIP-5539 compliant and registry-based revocation mechanism for Verifiable Credentials
Maintainer: Spherity GmbH (email) (website)
516 | 517 |
518 |

2.2 Credential Schema

519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 |
SpecificationDescription
Verifiable Credentials JSON SchemaEnables JSON Schemas to be applied as a validation method to any portions of Verifiable Credentials
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech JSON Schema Validator 2019Credential data schema validation method for verifiable credentials using JSON Schema
Maintainer: 1EdTech (email) (website)
Validating Verifiable Credentials with JSON SchemaThis specification defines a JSON Schema based credential schema validation scheme for use with the credential schema property of Verifiable Credentials
Maintainer: Transmute (email) (website)
529 | 530 |
531 |

2.3 Evidence

532 | 533 | 534 | 535 | 536 | 537 | 538 | 539 | 540 | 541 |
SpecificationDescription
European Learning Model Evidence ExtensionEvidence Class in the European Learning Model used to link evidence of permission to issue due to mandate or accreditation.
Maintainer: European Commission (email) (website)
OIDF eKYC and IDA EvidenceEvidence property that conforms to the OpenID Connect for Identity Assurance specification
Maintainer: David Chadwick (email) (website)
1EdTech Verifiable Credential Refresh ServiceDescriptive metadata about evidence related to an achievement assertion.
Maintainer: 1EdTech (email) (website)
542 | 543 |
544 |

2.4 Proof

545 | 546 | 547 | See Section 4. Securing Mechanisms. 548 | 549 |
550 |

2.5 Refresh Service

551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 |
SpecificationDescription
1EdTech Verifiable Credential Refresh ServiceRefresh service for refreshing an expired or modified verifiable credential.
Maintainer: 1EdTech (email) (website)
Conexxus Age Token Refresh Service (VerifiableCredentialRefresh2021)Refresh service for retrieving a new batch of single use age tokens.
Maintainer: Conexxus (email) (website)
561 | 562 |
563 |

2.6 Terms of Use

564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 |
SpecificationDescription
Precondition PolicyTerms of Use for Chain Reaction Revocation
Maintainer: Taisei Igarashi (email) (website)
TRAIN Terms of UseTerms of Use for an Issuer to indicate that they are a member of one or more TRAIN/ETSI list of trusted issuers
Maintainer: David Chadwick (email) (website)
574 | 575 |
576 |
577 |

3. Type-based Extensions

578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 |
SpecificationDescription
Comprehensive Learner Record v2Education credentials for sharing an individual's set of achievements and skills issued by multiple learning providers.
Maintainer: 1EdTech (email) (website)
European Digital Credentials for LearningApplication profile of the European Learning Model v2, specifying implementation of Digital Credentials as Verifiable Credentials.
Maintainer: European Commission (email) (website)
DSCSA Authorized Trading PartnersAn architecture supporting the Authorized Trading Partner (ATP) requirements of the U.S. Drug Supply Chain Security Act (DSCSA), allowing for authentication and information exchange between DSCSA-defined ATPs and related stakeholders to establish mutual verification of identity and ATP status.
Maintainer: Open Credentialing Initiative (OCI) (email) (website)
Open Badges v3Education credentials for sharing achievements and skills.
Maintainer: 1EdTech (email) (website)
Traceability VocabularyThis specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain traceability. Verifiable Credentials using these terms can be used to help determine the legitimacy of organizations, and the status of the products and materials in global trade.
Maintainer: W3C Credentials Community Group (email) (website)
588 | 589 |
590 | 591 |

4. Securing Mechanisms

592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | 600 | 601 |
SpecificationDescription
BBS Cryptosuite (v2023)Securing Verifiable Credentials with Selective Disclosure using BBS Signatures.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity ECDSA Cryptosuites v1.0Achieving Data Integrity using ECDSA with NIST-compliant curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity EdDSA Cryptosuites v1.0Achieving Data Integrity using EdDSA with twisted Edwards elliptic curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
JAdESSpecification for JAdES digital signatures, specifying signatures methods under baselines B, T, LT, and LTA. These signature specifications have legal validity across the European Union as per the eIDAS directive. They are in use by the European Digital Credentials for Learning and the European Blockchain Services Infrastructure.
Maintainer: European Commission (email) (website)
JSON Web Signatures for Data Integrity ProofsThis document has been withdrawn due to resolutions from the working group.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
Securing Verifiable Credentials using JOSE and COSEThis specification defines how to secure credentials and presentations conforming to the Verifiable Credentials Data Model, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE).
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
602 | 603 |
604 | 605 |

5. Media Type Extensions

606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 |
SpecificationDescription
616 | 617 |
618 | 619 | 620 | 621 |

A. References

A.1 Normative references

622 | 623 |
[RFC2119]
624 | 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 625 |
[RFC8174]
626 | 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 627 |
628 |

A.2 Informative references

629 | 630 |
[JSON-LD11]
631 | JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/ 632 |
633 |
-------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![W3C Logo](https://www.w3.org/Icons/w3c_home) 2 | 3 | [![Echidna Auto-publish](https://github.com/w3c/vc-specs-dir/actions/workflows/auto-publish.yml/badge.svg)](https://github.com/w3c/vc-specs-dir/actions/workflows/auto-publish.yml) 4 | 5 | # Verifiable Credential Extensions 6 | 7 | This repository contains a list created by the 8 | [W3C Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) 9 | (VC WG) for the purpose of discovering specifications known to exist in the 10 | Verifiable Credentials Ecosystem. 11 | 12 | An Editor's Draft of this repository is available at 13 | https://w3c.github.io/vc-extensions/. 14 | 15 | ## Adding New Entries to the List 16 | 17 | In order to add a new specification to this list, you must add a JSON file 18 | to the [./specifications](./specifications) directory and 19 | [open a pull request](https://github.com/w3c/vc-extensions/pulls) 20 | to add the file to this repository. 21 | 22 | Here is an [example specification entry](https://w3c.github.io/vc-extensions/specifications/example.json): 23 | 24 | ```jsonc 25 | { 26 | // These fields are required 27 | "name": "Example VC", 28 | "summary": "Used to demonstrate examples for Verifiable Credentials.", 29 | "specification": "https://example.github.io/example-spec/", 30 | // categories include: vc, credentialStatus, credentialSchema, 31 | // refreshService, termsOfUse, evidence, and proof 32 | "category": "vc", 33 | "maintainerEmail": "maintainer@community.example", 34 | // These fields are optional 35 | "maintainerName": "Example Community Group", 36 | "maintainerWebsite": "https://example.github.io/", 37 | // RDF vocabularies in yml2vocab format 38 | "vocabulary": ["https://example.github.io/vocabularies/example.yml"] 39 | } 40 | ``` 41 | 42 | Your Pull Request will be automatically validated, please ensure 43 | that all of the automated tests pass (no errors reported) or 44 | your submission will not be reviewed. Common reasons for failed 45 | validation includes invalidly formatted JSON files and missing 46 | mandatory fields. There will be a checklist that you are expected 47 | to complete and attest to its accuracy. Once you submit your request, 48 | your pull request will be reviewed by the directory maintainers. Changes 49 | regarding the required criteria may be requested. If there are no 50 | objections or changes requested, your specification will be 51 | added after a minimum of 7 days and a maximum of 30 days. 52 | 53 | ## Adding Anything Else to this List 54 | 55 | Use the standard fork, branch, and pull request workflow to propose changes to 56 | the directory. Please make branch names informative—by including the issue or 57 | bug number for example. 58 | 59 | Editorial changes that improve the readability of the directory or correct 60 | spelling or grammatical mistakes are welcome. 61 | 62 | Non-editorial changes MUST go through a review and approval process that is 63 | [detailed in the directory](https://w3c.github.io/vc-extensions/#the-management-process). 64 | 65 | Please read [CONTRIBUTING.md](CONTRIBUTING.md), about licensing contributions. 66 | 67 | ## Code of Conduct 68 | 69 | W3C functions under a [code of conduct](https://www.w3.org/Consortium/cepc/). 70 | 71 | ## VC Working Group Repositories 72 | 73 | - [W3C VC Working Group](https://www.w3.org/groups/wg/vc) 74 | - [W3C VC Use Cases](https://github.com/w3c/vc-use-cases) 75 | - [W3C VC Data Model](https://github.com/w3c/vc-data-model) 76 | -------------------------------------------------------------------------------- /common.js: -------------------------------------------------------------------------------- 1 | /* Build specification tables using JSON data */ 2 | async function buildSpecificationTables(config) { 3 | const {document} = window; 4 | const response = await fetch('specifications/index.json'); 5 | if(response.status !== 200) { 6 | throw new Error('Failed retrieve specifications index.json file.'); 7 | } 8 | const allSpecs = await response.json(); 9 | 10 | // summarize each API endpoint 11 | for(const spec of allSpecs) { 12 | const tableRow = document.createElement('tr'); 13 | const {name, summary, specification, category, maintainerEmail, 14 | maintainerName, maintainerWebsite, vocabulary} = spec; 15 | let maintainerInfo = maintainerName; 16 | if(maintainerEmail) { 17 | maintainerInfo += ` (email)`; 18 | } 19 | if(maintainerWebsite) { 20 | maintainerInfo += ` (website)`; 21 | } 22 | tableRow.innerHTML = 23 | `${name}` + 24 | `${summary}
Maintainer: ${maintainerInfo}`; 25 | 26 | const tableBody = document.getElementById(category + '-table'); 27 | tableBody.appendChild(tableRow); 28 | } 29 | } 30 | 31 | window.buildSpecificationTables = buildSpecificationTables; 32 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Verifiable Credential Extensions 5 | 10 | 11 | 12 | 13 | 74 | 102 | 103 | 104 |
105 |

106 | This document serves as an unofficial list of all known Verifiable Credential 107 | specifications whether they are released by a global standards setting 108 | organization, a community group, an open source project, or an individual. 109 |

110 |
111 | 112 |
113 | 114 |

115 | This document is not a formal registry nor is it intended to become a 116 | 117 | Registry Track document per the W3C Process. 118 |

119 | 120 |

121 | Comments regarding this document are welcome. Please file issues 122 | directly on 123 | GitHub, 124 | or send them 125 | to public-vc-wg@w3.org ( 126 | subscribe, 127 | archives). 128 |

129 | 130 |
131 | 132 | 133 |
134 |

Introduction

135 | 136 |

137 | This document serves as an unofficial directory for all known Verifiable 138 | Credential specifications whether they are released by a global standards 139 | setting organization, a community group, an open source project, or an 140 | individual. 141 |

142 | 143 |
144 |

Adding a Specification Entry

145 |

146 | The Verifiable Credentials Data Model is designed to be extended by 3rd party 147 | specifications to address a variety of real world use cases. Examples of 148 | extensions include, but are not limited to, new types of Verifiable Credentials 149 | and ways of expressing credential status, schema validation, evidence, 150 | refreshing, terms of use, and cryptographic suites for securing credentials. 151 |

152 |

In 153 | order to add a new specification to this directory, an implementer submits a 154 | modification request for this directory, as a pull request on the repository 155 | where this directory is hosted. 156 |

157 | 158 | Here is an example: 159 | 160 |

161 | 

162 | {
163 |   "name": "Example VC",
164 |   "summary": "Used to demonstrate examples for Verifiable Credentials.",
165 |   "specification": "https://example.github.io/example-spec/",
166 |   "category": "vc",
167 |   "maintainerEmail": "maintainer@community.example",
168 |   "maintainerName": "Example Community Group",
169 |   "maintainerWebsite": "https://example.github.io/",
170 |   "vocabulary": ["https://example.github.io/vocabularies/example.yml"]
171 | }
172 |
173 |

174 |

175 | The modification request MUST adhere to the following policies: 176 |

177 |
    178 |
  1. 179 | Any addition to the directory MUST conform to Section 180 | . 181 |
    2. 182 |
  2. 183 | If there are copyright, trademark, or any intellectual property rights 184 | concerns, the addition and use MUST be authorized in writing by the intellectual 185 | property rights holder under a 186 | F/RAND 187 | license. Examples include specifications that use trademarked brand names, 188 | property names that utilize the titles of copyrighted works, and patented 189 | technology that would cause the use of the extension to require licensing a 190 | patent. 191 |
    3. 192 |
  3. 193 | Any addition MUST NOT create unreasonable legal, security, moral, or privacy 194 | issues that will result in direct harm to others. Examples of unacceptable 195 | additions include any containing racist language, technologies used to 196 | persecute minority populations, and unconsented pervasive tracking. 197 |
    4. 198 |
199 | 200 |

201 | The Editors of this directory MUST consider all of the policies above when 202 | reviewing additions to the directory and MUST reject directory entries if they 203 | violate any of the policies in this section. Entities registering additions can 204 | challenge rejections first with the W3C Verifiable Credentials Working Group and 205 | then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff 206 | need not be consulted on changes to the directory, but do have the final 207 | authority on directory contents. This is to ensure that W3C can adequately 208 | respond to time sensitive legal, privacy, security, moral, or other pressing 209 | concerns without putting an undue operational burden on W3C Staff. 210 |

211 | 212 |

213 | Any submission to the directory that meets all of the criteria listed above will 214 | be accepted for inclusion. The specifications listed in this directory enumerate 215 | all known specifications, without choosing between them. 216 |

217 | 218 |
219 |

Specification Entry Format

220 |

221 | The specification entry format MUST conform to the 222 | 223 | JSON Schema for a specification entry. Each field is documented below: 224 |

225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 237 | 238 | 239 | 240 | 244 | 245 | 246 | 247 | 251 | 252 | 253 | 254 | 263 | 264 | 265 | 266 | 270 | 271 | 272 | 273 | 277 | 278 | 279 | 280 | 284 | 285 | 286 | 287 | 292 | 293 | 294 |
FieldDescription
name 234 | A short human readable name for the specification. For example: `Status List 235 | (v2021)`. 236 |
summary 241 | A one sentence description for the specification. For example: `A credential 242 | status list with herd privacy characteristics.` 243 |
specification 248 | An URL that resolves to a human readable specification. For example: 249 | `https://w3c.github.io/vc-status-list-2021/`. 250 |
category 255 | The Verifiable Credential extension category of the specification, which can be 256 | one of the following values: `credentialStatus`, `credentialSchema`, `evidence`, 257 | `media-type`, `multibase`, `multihash`, `multikey`, `securing`, 258 | `refreshService`, `termsOfUse`, or `vc`. For example: `credentialStatus`. 259 |

260 | The extensions might define a `@type`. See [[JSON-LD11]]. 261 |

262 |
maintainerName 267 | A person or organization which responds to contact requests. For example: 268 | `W3C Verifiable Credentials Working Group`. 269 |
maintainerEmail 274 | An email to send contact requests. For example: 275 | `public-vc-wg@w3.org`. 276 |
maintainerWebsite 281 | An website to send contact requests. For example: 282 | `https://www.w3.org/groups/wg/vc`. 283 |
vocabulary 288 | An array of URLs that contain machine-readable vocabulary information in 289 | yml2vocab or JSON-LD format. For example: 290 | `["https://raw.githubusercontent.com/w3c/vc-status-list-2021/main/contexts/v1.jsonld"]`. 291 |
295 |
296 |
297 | 298 |
299 | 300 |
301 | 302 | 303 | 304 |
305 |

Property-based Extensions

306 | 307 |
308 |

Credential Status

309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 |
SpecificationDescription
318 | 319 |
320 |
321 |

Credential Schema

322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 |
SpecificationDescription
331 | 332 |
333 |
334 |

Evidence

335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 |
SpecificationDescription
344 | 345 |
346 |
347 |

Proof

348 | 349 | See Section . 350 | 351 |
352 |
353 |

Refresh Service

354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 |
SpecificationDescription
363 | 364 |
365 |
366 |

Terms of Use

367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 |
SpecificationDescription
376 | 377 |
378 |
379 |
380 |

Type-based Extensions

381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 |
SpecificationDescription
390 | 391 |
392 | 393 |
394 |

Multibase

395 | 396 | 397 | 398 | 399 | 400 | 401 | 402 | 403 |
SpecificationDescription
404 |
405 | 406 |
407 |

Multihash

408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 |
SpecificationDescription
417 |
418 | 419 |
420 |

Multikey

421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 |
SpecificationDescription
430 |
431 | 432 |
433 |

Securing Mechanisms

434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 |
SpecificationDescription
443 | 444 |
445 | 446 |
447 |

Media Type Extensions

448 | 449 | 450 | 451 | 452 | 453 | 454 | 455 | 456 |
SpecificationDescription
457 | 458 |
459 | 460 | 461 | 462 | -------------------------------------------------------------------------------- /specifications/bitstring-status-list.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Bitstring Status List v1.0", 3 | "summary": "A credential status list with herd privacy characteristics.", 4 | "specification": "https://w3c.github.io/vc-bitstring-status-list/", 5 | "category": "credentialStatus", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc", 9 | "vocabulary": ["https://raw.githubusercontent.com/w3c/vc-bitstring-status-list/main/contexts/v1.jsonld"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/citizenship-vocabulary.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Citizenship Vocabulary", 3 | "summary": "This specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to national citizenship. Verifiable Credentials using the citizenship vocabulary can be used to express permanent resident cards, employment authorization documents, naturalization certificates, and citizenship certificates.", 4 | "specification": "https://w3id.org/citizenship/", 5 | "category": "vc", 6 | "maintainerEmail": "public-credentials@w3.org ", 7 | "maintainerName": "W3C Credentials Community Group", 8 | "maintainerWebsite": "https://www.w3.org/community/credentials/", 9 | "vocabulary": ["https://w3id.org/citizenship/"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/comprehensive-learner-record-v2.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Comprehensive Learner Record v2", 3 | "summary": "Education credentials for sharing an individual's set of achievements and skills issued by multiple learning providers.", 4 | "specification": "https://www.imsglobal.org/spec/clr/v2p0", 5 | "category": "vc", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/", 9 | "vocabulary": ["https://purl.imsglobal.org/spec/clr/v3p0/context.json"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/credential-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Verifiable Credentials JSON Schema", 3 | "summary": "Enables JSON Schemas to be applied as a validation method to any portions of Verifiable Credentials", 4 | "specification": "https://www.w3.org/TR/vc-json-schema/", 5 | "category": "credentialSchema", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/di-bbs.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "BBS Cryptosuite (v2023)", 3 | "summary": "Securing Verifiable Credentials with Selective Disclosure using BBS Signatures.", 4 | "specification": "https://www.w3.org/TR/vc-di-bbs/", 5 | "category": "securing", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc", 9 | "vocabulary": ["https://raw.githubusercontent.com/w3c/vc-data-integrity/main/vocab/security/vocabulary.yml"] 10 | } 11 | 12 | -------------------------------------------------------------------------------- /specifications/di-ecdsa.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "The Data Integrity ECDSA Cryptosuites v1.0", 3 | "summary": "Achieving Data Integrity using ECDSA with NIST-compliant curves.", 4 | "specification": "https://www.w3.org/TR/vc-di-ecdsa/", 5 | "category": "securing", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc", 9 | "vocabulary": ["https://raw.githubusercontent.com/w3c/vc-data-integrity/main/vocab/security/vocabulary.yml"] 10 | } 11 | 12 | -------------------------------------------------------------------------------- /specifications/di-eddsa.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "The Data Integrity EdDSA Cryptosuites v1.0", 3 | "summary": "Achieving Data Integrity using EdDSA with twisted Edwards elliptic curves.", 4 | "specification": "https://www.w3.org/TR/vc-di-eddsa/", 5 | "category": "securing", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc", 9 | "vocabulary": ["https://raw.githubusercontent.com/w3c/vc-data-integrity/main/vocab/security/vocabulary.yml"] 10 | } 11 | 12 | -------------------------------------------------------------------------------- /specifications/european-digital-credentials.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "European Digital Credentials for Learning", 3 | "summary": "Application profile of the European Learning Model v2, specifying implementation of Digital Credentials as Verifiable Credentials.", 4 | "specification": "https://europa.eu/europass/elm-browser/documentation/rdf/ap/edc/documentation/edc-generic-no-cv.html", 5 | "category": "vc", 6 | "maintainerEmail": "EMPL-ELM-SUPPORT@ec.europa.eu", 7 | "maintainerName": "European Commission", 8 | "maintainerWebsite": "https://ec.europa.eu", 9 | "vocabulary": ["http://data.europa.eu/snb/model/context/edc-ap"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/european-learning-model-evidence.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "European Learning Model Evidence Extension", 3 | "summary": "Evidence Class in the European Learning Model used to link evidence of permission to issue due to mandate or accreditation.", 4 | "specification": "https://europa.eu/europass/elm-browser/documentation/rdf/ap/edc/documentation/edc-generic-no-cv.html", 5 | "category": "evidence", 6 | "maintainerEmail": "EMPL-ELM-SUPPORT@ec.europa.eu", 7 | "maintainerName": "European Commission", 8 | "maintainerWebsite": "https://ec.europa.eu" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/ida-evidence.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "OIDF eKYC and IDA Evidence", 3 | "summary": "Evidence property that conforms to the OpenID Connect for Identity Assurance specification", 4 | "specification": "https://docs.google.com/document/d/1htujrb-_1kh8tkV4MXYRmZ44m_D7yFrY09aFJkAz7io/", 5 | "category": "evidence", 6 | "maintainerEmail": "d.w.chadwick@truetrust.co.uk", 7 | "maintainerName": "David Chadwick", 8 | "maintainerWebsite": "https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html" 9 | } -------------------------------------------------------------------------------- /specifications/jades.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "JAdES", 3 | "summary": "Specification for JAdES digital signatures, specifying signatures methods under baselines B, T, LT, and LTA. These signature specifications have legal validity across the European Union as per the eIDAS directive. They are in use by the European Digital Credentials for Learning and the European Blockchain Services Infrastructure.", 4 | "specification": "https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf", 5 | "category": "securing", 6 | "maintainerEmail": "EMPL-ELM-SUPPORT@ec.europa.eu", 7 | "maintainerName": "European Commission", 8 | "maintainerWebsite": "https://www.etsi.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/jws-2020.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "JSON Web Signatures for Data Integrity Proofs", 3 | "summary": "This document has been withdrawn due to resolutions from the working group.", 4 | "specification": "https://www.w3.org/TR/vc-jws-2020", 5 | "category": "securing", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc", 9 | "vocabulary": ["https://raw.githubusercontent.com/w3c/vc-data-integrity/main/vocab/security/vocabulary.yml"] 10 | } 11 | 12 | -------------------------------------------------------------------------------- /specifications/multibase-base58btc.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "base58-btc", 3 | "summary": "The base58 Bitcoin multibase format is used to encode binary values in a way that is easy to read for humans. The format omits the usage of characters that are easily confused with one another such as the character for the number one '1', capital 'I' (eye), and the lowercase 'l' (ell) character.", 4 | "specification": "https://www.w3.org/TR/controller-document/#multibase-0", 5 | "category": "multibase", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multibase-base64url.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "base64url", 3 | "summary": "The base64 URL format is used to encode binary values in a way that can be efficiently processed and embedded in URLs without requiring URI encoding.", 4 | "specification": "https://www.w3.org/TR/controller-document/#multibase-0", 5 | "category": "multibase", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multihash-sha2.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "SHA-2", 3 | "summary": "The second version of the Secure Hash Algorithms are widely supported, NIST-approved cryptographic hashing algorithms.", 4 | "specification": "https://www.w3.org/TR/controller-document/#multihash", 5 | "category": "multihash", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multihash-sha3.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "SHA-3", 3 | "summary": "The third version of the Secure Hash Algorithms are more modern, NIST-approved cryptographic hashing algorithms.", 4 | "specification": "https://www.w3.org/TR/controller-document/#multihash", 5 | "category": "multihash", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multikey-bbs.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "BLS 12-381", 3 | "summary": "The Boneh, Lynn, and Shacham (BLS) Multikey format is a used to produce unlinkable digital signatures as a part of the Boneh, Boyen, and Shacham (BBS) cryptographic digital signature scheme.", 4 | "specification": "https://www.w3.org/TR/controller-document/#Multikey", 5 | "category": "multikey", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multikey-ecdsa.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "ECDSA", 3 | "summary": "The ECDSA Multikey types are widely supported, NIST-approved, and FIPS-validated cryptographic key formats.", 4 | "specification": "https://www.w3.org/TR/controller-document/#Multikey", 5 | "category": "multikey", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/multikey-eddsa.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "EdDSA", 3 | "summary": "The EdDSA Multikey type is a widely supported, NIST-approved, and FIPS-validated cryptographic key format.", 4 | "specification": "https://www.w3.org/TR/controller-document/#Multikey", 5 | "category": "multikey", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/oci-dscsa-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "DSCSA Authorized Trading Partners", 3 | "summary": "An architecture supporting the Authorized Trading Partner (ATP) requirements of the U.S. Drug Supply Chain Security Act (DSCSA), allowing for authentication and information exchange between DSCSA-defined ATPs and related stakeholders to establish mutual verification of identity and ATP status.", 4 | "specification": "https://open-credentialing-initiative.github.io/schemas/specification/latest/index.html", 5 | "category": "vc", 6 | "maintainerEmail": "info@oc-i.org", 7 | "maintainerName": "Open Credentialing Initiative (OCI)", 8 | "maintainerWebsite": "https://oc-i.org" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/open-badges-v3-credential-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "1EdTech JSON Schema Validator 2019", 3 | "summary": "Credential data schema validation method for verifiable credentials using JSON Schema", 4 | "specification": "https://www.imsglobal.org/spec/vccs/v1p0/", 5 | "category": "credentialSchema", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/open-badges-v3-credential-status.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "1EdTech Revocation List Status Method", 3 | "summary": "A simple list-based mechanism for publishing and checking the revocation status of a verifiable credential", 4 | "specification": "https://www.imsglobal.org/spec/vcrl/v1p0/", 5 | "category": "credentialStatus", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/open-badges-v3-evidence.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "1EdTech Verifiable Credential Refresh Service", 3 | "summary": "Descriptive metadata about evidence related to an achievement assertion.", 4 | "specification": "https://www.imsglobal.org/spec/vccr/v1p0", 5 | "category": "evidence", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/open-badges-v3-refresh-service.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "1EdTech Verifiable Credential Refresh Service", 3 | "summary": "Refresh service for refreshing an expired or modified verifiable credential.", 4 | "specification": "https://www.imsglobal.org/spec/vccr/v1p0", 5 | "category": "refreshService", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/open-badges-v3.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Open Badges v3", 3 | "summary": "Education credentials for sharing achievements and skills.", 4 | "specification": "https://www.imsglobal.org/spec/ob/v3p0", 5 | "category": "vc", 6 | "maintainerEmail": "contact@imsglobal.org", 7 | "maintainerName": "1EdTech", 8 | "maintainerWebsite": "https://www.1edtech.org/", 9 | "vocabulary": ["https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.1.json"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/precondition-policy.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Precondition Policy", 3 | "summary": "Terms of Use for Chain Reaction Revocation", 4 | "specification": "https://gist.github.com/MizukiSonoko/87a11fbcea64b13ccc6873fcbe14cd1a", 5 | "category": "termsOfUse", 6 | "maintainerEmail": "sonoko@mizuki.io", 7 | "maintainerName": "Taisei Igarashi", 8 | "maintainerWebsite": "https://mizuki.io" 9 | } -------------------------------------------------------------------------------- /specifications/traceability-vocabulary.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Traceability Vocabulary", 3 | "summary": "This specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain traceability. Verifiable Credentials using these terms can be used to help determine the legitimacy of organizations, and the status of the products and materials in global trade.", 4 | "specification": "https://w3id.org/traceability/", 5 | "category": "vc", 6 | "maintainerEmail": "public-credentials@w3.org ", 7 | "maintainerName": "W3C Credentials Community Group", 8 | "maintainerWebsite": "https://www.w3.org/community/credentials/", 9 | "vocabulary": ["https://w3id.org/traceability/v1"] 10 | } 11 | -------------------------------------------------------------------------------- /specifications/train-tou.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "TRAIN Terms of Use", 3 | "summary": "Terms of Use for an Issuer to indicate that they are a member of one or more TRAIN/ETSI list of trusted issuers", 4 | "specification": "https://dl.gi.de/handle/20.500.12116/38702", 5 | "category": "termsOfUse", 6 | "maintainerEmail": "d.w.chadwick@truetrust.co.uk", 7 | "maintainerName": "David Chadwick", 8 | "maintainerWebsite": "https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train-source-code" 9 | } -------------------------------------------------------------------------------- /specifications/truage-v1-refresh-service.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Conexxus Age Token Refresh Service (VerifiableCredentialRefresh2021)", 3 | "summary": "Refresh service for retrieving a new batch of single use age tokens.", 4 | "specification": "https://www.conexxus.org/resources/conexxus-age-verification-specification-v11", 5 | "category": "refreshService", 6 | "maintainerEmail": "info@conexxus.org", 7 | "maintainerName": "Conexxus", 8 | "maintainerWebsite": "https://conexxus.org/" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/vc-ethr-revocation-registry.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Ethr Revocation 2022", 3 | "summary": "An Ethereum, EIP-5539 compliant and registry-based revocation mechanism for Verifiable Credentials", 4 | "specification": "https://spherity.github.io/vc-ethr-revocation-registry/", 5 | "category": "credentialStatus", 6 | "maintainerEmail": "lauritz.leifermann@spherity.com", 7 | "maintainerName": "Spherity GmbH", 8 | "maintainerWebsite": "https://www.spherity.com" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/vc-jose-cose.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Securing Verifiable Credentials using JOSE and COSE", 3 | "summary": "This specification defines how to secure credentials and presentations conforming to the Verifiable Credentials Data Model, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE).", 4 | "specification": "https://www.w3.org/TR/vc-jose-cose/", 5 | "category": "securing", 6 | "maintainerEmail": "public-vc-wg@w3.org", 7 | "maintainerName": "W3C Verifiable Credentials Working Group", 8 | "maintainerWebsite": "https://www.w3.org/groups/wg/vc" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/vc-json-schema.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Validating Verifiable Credentials with JSON Schema", 3 | "summary": "This specification defines a JSON Schema based credential schema validation scheme for use with the credential schema property of Verifiable Credentials", 4 | "specification": "https://transmute-industries.github.io/vc-json-schema/", 5 | "category": "credentialSchema", 6 | "maintainerEmail": "orie@transmute.industries", 7 | "maintainerName": "Transmute", 8 | "maintainerWebsite": "https://transmute.industries" 9 | } 10 | -------------------------------------------------------------------------------- /specifications/vdl-vocabulary.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "Driver's License Vocabulary", 3 | "summary": "This specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to driver's licenses and identity cards. Verifiable Credentials using the driver's license vocabulary can be used to express driver's licenses and identity cards.", 4 | "specification": "https://w3id.org/vdl/", 5 | "category": "vc", 6 | "maintainerEmail": "public-credentials@w3.org ", 7 | "maintainerName": "W3C Credentials Community Group", 8 | "maintainerWebsite": "https://www.w3.org/community/credentials/", 9 | "vocabulary": ["https://w3id.org/vdl/"] 10 | } 11 | -------------------------------------------------------------------------------- /tooling/README.md: -------------------------------------------------------------------------------- 1 | ## Tooling 2 | 3 | This directory contains command line tooling and support scripts for the 4 | Verifiable Credential Specification Directory. 5 | 6 | ### Setup Tooling 7 | 8 | ``` 9 | npm i 10 | ``` 11 | 12 | ### Validate 13 | 14 | ``` 15 | npm run validate 16 | ``` 17 | 18 | ### Generate Directory Index 19 | 20 | This command is run in CI, the index file produced is git ignored. 21 | 22 | This file is used by the Respec build plugin to build the directory 23 | in client side javascript at page load time. 24 | 25 | ``` 26 | npm run generate-index 27 | ``` 28 | -------------------------------------------------------------------------------- /tooling/generate-index.js: -------------------------------------------------------------------------------- 1 | 2 | const fs = require('fs'); 3 | const path = require('path'); 4 | 5 | // set directories and paths 6 | const specificationsDir = path.join(__dirname, '../specifications'); 7 | const indexFile = path.join(specificationsDir, 'index.json'); 8 | 9 | // Process all spec files and generate an index file 10 | (async () => { 11 | 12 | const allSpecs = []; 13 | process.stdout.write('Processing:'); 14 | fs.readdirSync(specificationsDir).forEach(filename => { 15 | // skip index file 16 | if(filename === 'index.json') { 17 | return; 18 | } 19 | 20 | const specFile = path.join(specificationsDir, filename); 21 | const specData = fs.readFileSync(specFile, 'utf-8'); 22 | process.stdout.write(' ' + filename); 23 | 24 | try { 25 | const specJson = JSON.parse(specData); 26 | allSpecs.push(specJson); 27 | } catch(e) { 28 | console.error('\n\n❌ ERROR: Failed to parse', filename, e); 29 | process.exit(1); 30 | } 31 | }); 32 | 33 | if(allSpecs.length > 0) { 34 | fs.writeFileSync(indexFile, JSON.stringify(allSpecs, null, 2), 'utf-8'); 35 | console.log('\n\nGenerated /specifications/index.json.'); 36 | } else { 37 | console.error('\n\n❌ ERROR: No files found in specifications directory'); 38 | process.exit(1); 39 | } 40 | 41 | })(); 42 | -------------------------------------------------------------------------------- /tooling/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "vc-spec-directory-tooling", 3 | "version": "0.0.1", 4 | "description": "Verifiable Credentials Directory tooling commands", 5 | "private": true, 6 | "main": "index.js", 7 | "dependencies": { 8 | "ajv": "^8.6.3", 9 | "js-yaml": "^4.1.0" 10 | }, 11 | "scripts": { 12 | "validate": "node ./validate.js", 13 | "generate-index": "node ./generate-index.js" 14 | }, 15 | "author": "Manu Sporny (https://manu.sporny.org/)", 16 | "contributors": [ 17 | "Orie Steele (https://github.com/OR13)" 18 | ], 19 | "license": "W3C" 20 | } 21 | -------------------------------------------------------------------------------- /tooling/specification-entry.yml: -------------------------------------------------------------------------------- 1 | --- 2 | title: Verifiable Credential Specification Entry 3 | description: This schema defines the shape of Verifiable Credential specification entries in the directory. 4 | type: object 5 | additionalProperties: false 6 | required: 7 | - name 8 | - summary 9 | - specification 10 | - category 11 | - maintainerEmail 12 | properties: 13 | name: 14 | description: A short human readable name for the specification. 15 | type: string 16 | maxLength: 100 17 | summary: 18 | description: A one sentence description for the specification. 19 | type: string 20 | maxLength: 500 21 | specification: 22 | description: An URL that resolves to a human readable specification. 23 | type: string 24 | maxLength: 512 25 | pattern: ^https?:\/\/ 26 | category: 27 | description: The Verifiable Credential extension category of the specification. 28 | type: string 29 | enum: 30 | - credentialStatus 31 | - credentialSchema 32 | - evidence 33 | - media-type 34 | - multibase 35 | - multihash 36 | - multikey 37 | - securing 38 | - refreshService 39 | - termsOfUse 40 | - vc 41 | maintainerName: 42 | description: A person or organization which responds to contact requests 43 | type: string 44 | maxLength: 512 45 | maintainerEmail: 46 | description: An email to send contact requests 47 | type: string 48 | maxLength: 512 49 | maintainerWebsite: 50 | description: An website to send contact requests 51 | type: string 52 | maxLength: 512 53 | pattern: ^https?:\/\/ 54 | vocabulary: 55 | description: An array of URLs that contain machine-readable vocabulary information in yml2vocab or JSON-LD format. 56 | type: array 57 | items: 58 | type: string 59 | maxLength: 512 60 | pattern: ^https?:\/\/ 61 | example: { 62 | # These fields are required 63 | "name": "Example VC", 64 | "summary": "Used to demonstrate examples for Verifiable Credentials.", 65 | "specification": "https://example.github.io/example-spec/", 66 | # categories include: vc, credentialStatus, credentialSchema, 67 | # refreshService, termsOfUse, evidence, and proof 68 | "category": "vc", 69 | "maintainerEmail": "maintainer@community.example", 70 | # These fields are optional 71 | "maintainerName": "Example Community Group", 72 | "maintainerWebsite": "https://example.github.io/", 73 | # RDF vocabularies in yml2vocab format or JSON-LD Contexts 74 | "vocabulary": ["https://example.github.io/vocabularies/example.yml"] 75 | } 76 | -------------------------------------------------------------------------------- /tooling/validate.js: -------------------------------------------------------------------------------- 1 | 2 | const Ajv = require("ajv") 3 | const yaml = require('js-yaml'); 4 | const fs = require('fs'); 5 | const path = require('path'); 6 | const ajv = new Ajv({ strict: false }); 7 | 8 | const vcSpecDir = path.join(__dirname, '../specifications'); 9 | const schema = yaml.load(fs.readFileSync('./specification-entry.yml', 'utf8')); 10 | const validate = ajv.compile(schema) 11 | 12 | const getAllSpecEntries = () =>{ 13 | const files = fs.readdirSync(vcSpecDir); 14 | const entries = files.filter((file) => { 15 | // ignore the index file. 16 | return file !== 'index.json'; 17 | }).map((file) => { 18 | const fileContent = 19 | fs.readFileSync(path.join(vcSpecDir, file)).toString(); 20 | let vcSpec = { 21 | error: 'specifications/' + file 22 | }; 23 | try { 24 | vcSpec = JSON.parse(fileContent); 25 | } catch(e) { 26 | console.error('❌ Failed to parse specification entry: ' + 27 | 'specifications/' + file); 28 | } 29 | return vcSpec; 30 | }).sort((a, b)=>{ 31 | return a.name > b.name ? 1 : -1; 32 | }) 33 | return entries; 34 | } 35 | 36 | const validateSpecEntry = (entry) => { 37 | const valid = validate(entry) 38 | if(!valid) { 39 | console.error('Entry:', JSON.stringify(entry, null, 2)); 40 | console.error('Error:', JSON.stringify(validate.errors, null, 2)); 41 | } 42 | return valid; 43 | } 44 | 45 | (async ()=>{ 46 | console.log('Validating specification directory...'); 47 | const entries = getAllSpecEntries(); 48 | entries.forEach((entry) => { 49 | const valid = validateSpecEntry(entry) 50 | if(!valid){ 51 | console.error(' ❌ invalid specification entry: ' + 52 | JSON.stringify(entry, null, 2)); 53 | process.exit(1); 54 | } 55 | }) 56 | console.log(' ✅ specification directory is valid.'); 57 | })(); 58 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [98922], 3 | "contacts": ["iherman"], 4 | "repo-type": "note", 5 | "shortName": "vc-extensions" 6 | } 7 | --------------------------------------------------------------------------------