This vc-api app is a NestJs implementation of the W3C Credentials Community Group VC API Specification. Nest is a Typescript framework for server-side applications.
See tutorials.
The following is a C4 Component diagram of the VC-API app. The diagram was generated from the EnergyWeb IcePanel.
Credential exchanges are the processes by which credentials are moved between wallet/agent and issuer/verifer. For more information on these processes, see the exchanges documentation.
The Verifiable Credentials specification uses contexts to ensure that the meanings of terms in a credential are shared by all parties. For more information about this, see the context documentation.
Install using the rush commands described in the root README.
Alternatively to npm, pnpm can be used for the commands below.
# development
$ npm run start
# watch mode
$ npm run start:dev
# production mode
$ npm run start:prodAfter starting the vc-api app,
the Swagger/OpenAPI test page can be see at {appURL}/api (http://localhost:3000/api if running locally)
Alternatively to npm, pnpm can be used for the commands below.
# unit tests
$ npm run test:unit
# e2e tests
$ npm run test:e2e
# test coverage
$ npm run test:covAn implementation of the W3C Credentials Community Group VC API Specification. This spec provides a data model and HTTP protocols to issue, verify, present, and exchange verifiable credentials on the Web. The W3C Credentials Community Group also publishes use cases for VC API.
Not all of the endpoints available from this VC-API app are standard. In particular, there are several endpoints related to exchanges that are outside of the specification.
| Profile | Endpoint | Standard | Spec Link |
|---|---|---|---|
| Issuing | Issue Credential | Yes | https://w3c-ccg.github.io/vc-api/#issue-credential |
| Verifying | Verify Credential | Yes | https://w3c-ccg.github.io/vc-api/#verify-credential |
| Verifying | Verify Presentation | Yes | https://w3c-ccg.github.io/vc-api/#verify-presentation |
| Presenting | Prove Presentation | Yes | https://w3c-ccg.github.io/vc-api/#prove-presentation |
| Presenting | Initiate Exchange | Yes | https://w3c-ccg.github.io/vc-api/#initiate-exchange |
| Presenting | Continue Exchange | Yes | https://w3c-ccg.github.io/vc-api/#continue-exchange |
| Presenting | Configure Exchange | No | |
| Presenting | Query Submissions | No | |
| Presenting | Submit Submission Review | No | |
| Presenting | Create Presentation from Credentials | No |
The proof types supported during Proof generation (e.g. issuance and presentation) are listed below.
Currently only Data Integrity (JSON-LD) proofs are supported.
The "Related DID" is mentioned because the verification method used to generate the proof is selected from the issuer property for VCs or holder property for VPs.
The following proof types are supported:
| Proof Type | Related DID | Test Status |
|---|---|---|
| Ed25519Signature2018 | did:key | Covered by automated tests |
| EcdsaSecp256k1Signature2019 | did:ethr | Not yet covered by automated tests |
The DID Module in the vc-api offers the generation of DIDs and tracking the data resolvable in their DID documents.
The table below shows which DID methods are available.
| DID Method | Notes |
|---|---|
| key | Only Ed25519 (with Ed25519VerificationKey2018 verification method) |
| ethr | Only implicit DID resolution. No chain data resolution supported |
The key module is kept separate from the DID module because it's plausible that key module will be provided by a different service (i.e. a dedicated KMS) at some point.
The table below shows which key types are available for each operation.
| Operations | Key Type |
|---|---|
| Import | Ed25519 |
| Generate | Ed25519, ES256K |
| Export | Any key stored |
The key module allows for the import and export of key pairs. A tutorial demonstrating this available here: Key Export/Import Tutorial
Currently, the app uses an in-memory DB for now for app execution and tests. The rationale for this for executions that, as the app is only being used in a demo context, it is not necessary to persist data between executions. The rationale for this for tests (rather than mocking the db) is that it speeds test writing time, elimates mocking boilerplate and possibly buggy DB mocks.
This project is licensed under the GNU General Public License v3.0 or later - see the LICENSE file for details NestJs is MIT licensed.
