⚠️ This repository is not actively being maintained. If you are interested in adopting it, please open an issue. ⚠️

The Self Sovereign Identity Service (SSIS) is a RESTful web service that facilitates all things relating to DIDs, Verifiable Credentials and their related standards-based interactions. Most of the functionality in this service relies upon the SSI primitives exposed in the SSI-SDK project.

• Lifecycle management for Decentralized Identifiers
  • Multiple local, web, and blockchain methods supported
• Create and manage Verifiable Credentials
  • Multiple securing mechanisms
  • Data schemas using JSON Schema
  • Lifecycle management with credential status (revocation, suspension, etc.)
• More robust DID and Verifiable Credential interactions such as...
  • Enabling the application of credentials
  • Verifying sets of credentials with custom logic
  • Linking a DID to a web domain
  • Integration into your existing systems with webhooks
  • Trust management
• And much more!

The vision for the project is laid out in this document.

The project follows a proposal-based improvement format called SIPs, outlined here.

Please join Discord, or open an issue if you are interested in helping shape the future of the project.

API documentation is generated using Swagger. The most recent docs can be found here.

When running the service you can find API documentation at: http://localhost:8080/swagger/index.html

Note: Your port may differ; swagger docs are hosted on the same endpoint as the ssi service itself.

We have a set of tutorials and how-to documents, instructing you on how to create a DID, issue your first credential, and more! The docs can be found in our docs here.

This project uses mage, please view CONTRIBUTING for more information.

After installing mage, you can build and test the SDK with the following commands:

mage build
mage test

A utility is provided to run clean, build, lint, and test in sequence with:

mage cblt

CI is managed via GitHub Actions. Actions are triggered to run for each Pull Request, and on merge to main. You can run CI locally using a tool like act.

The service is packaged as a Docker container, runnable in a wide variety of environments.

There are pre-build images built by GitHub Actions on each merge to the main branch, which you can access here.

Docker Compose is used for simplification and orchestration. To run the service, you can use the following command, which will start the service on port 8080:

mage run

Or, you can run docker-compose yourself, building from source:

cd build && docker-compose up --build

To use the pre-published images:

cd build && docker-compose up -d

Managed via: TOML file. Configuration documentation and sample config files can be found here.

There are sets of configuration values for the server (e.g. which port to listen on), the services (e.g. which database to use), and each service. Each service may define specific configuration, such as which DID methods are enabled for the DID service.

More information on configuration can be found in the configuration section of our docs.

The SSI server uses the Gin framework, which allows various kinds of middleware. Look in pkg/middleware/Authentication.go and pkg/middleware/Authorization.go for details on how you can wire up authentication and authorization for your use case.

Note: port 3000 is used by default, specified in config folder. An example would be dev.toml, for the SSI Service process. If you're running via mage run or docker compose, the port to access will be 8080.

Run for health check (status: OK, then you are up):

 ~ curl localhost:3000/health | jq

{
    "status": "OK"
}

Run to check if all services are up and ready (credential, did, and schema):

~ curl localhost:8080/readiness | jq

{
  "status": {
    "status": "ready",
    "message": "all services ready"
  },
  "serviceStatuses": {
    "credential": {
      "status": "ready"
    },
    "did": {
      "status": "ready"
    },
    "issuance": {
      "status": "ready"
    },
    "keystore": {
      "status": "ready"
    },
    "manifest": {
      "status": "ready"
    },
    "operation": {
      "status": "ready"
    },
    "presentation": {
      "status": "ready"
    },
    "schema": {
      "status": "ready"
    },
    "webhook": {
      "status": "ready"
    }
  }
}