ssi-service
Introduction
The Self Sovereign Identity Service (SSIS) facilitates all things relating to DIDs
and Verifiable Credentials -- in a box! The service is a part of a larger
Decentralized Web Platform architecture which you can learn more about in our
collaboration repo. The SSI Service is a HTTP-API driven web service
that wraps the ssi-sdk. The core functionality of the SSIS includes,
but is not limited to: interacting with the standards around Verifiable Credentials, Credential Revocations, requesting
Credentials, exchanging Credentials, data schemas for Credentials and other verifiable data, messaging using
Decentralized Web Nodes, and usage of Decentralized Identifiers. Using these core standards, the SSIS enables robust
functionality to facilitate all verifiable interactions such as creating, signing, issuing, curating, requesting,
revoking, exchanging, validating, verifying credentials in varying degrees of complexity.
For more information, see the vision document.
Configuration
Configuration is managed using
a TOML file. 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.
Build & Test
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, and test in sequence with:
mage cbt
Continuous Integration
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.
Deployment
The service is packaged as a Docker container, runnable in a wide variety of
environments. 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:
cd build && docker-compose up --build
Health and Readiness Checks
You should then be able to send requests as follows:
Note: port 3000 is used by default, specified in config.toml
, for the SSI Service process. If you're running
via mage run
or docker compose, the port to access will be 8080
.
The command below will give you a health check, if the status is OK then you are up.
~ curl localhost:3000/health
{"status":"OK"}
The command below will tell if you all the services (credential, did, and schema) are up and ready.
~ curl localhost:8080/readiness
{
"status": {
"status": "ready",
"message": "all service ready"
},
"serviceStatuses": {
"credential": {
"status": "ready"
},
"did": {
"status": "ready"
},
"schema": {
"status": "ready"
}
}
}
HTTP Endpoints
You can find more HTTP endpoints by checking out the swagger docs at: http://localhost:8002/docs
Note: Your port by differ, the range of the ports for swagger are between 8002
and 8080
.
Vision, Features, and Development
The vision for the project is laid out in this document.
The project follows a proposal-based improvement format called SIPs, outlined here..
Please open a discussion
or issue if you are interested in helping shape the future of the
project.
What's Supported?
Project Resources
Resource |
Description |
VISION |
Outlines the project vision |
SIPs |
Proposals for improving the SSI Service |
VERSIONING |
Project versioning strategy |
CODEOWNERS |
Outlines the project lead(s) |
CODE_OF_CONDUCT |
Expected behavior for project contributors, promoting a welcoming environment |
CONTRIBUTING |
Developer guide to build, test, run, access CI, chat, discuss, file issues |
GOVERNANCE |
Project governance |
SECURITY |
Vulnerability and bug reporting |
LICENSE |
Apache License, Version 2.0 |