{"id":19571577,"url":"https://github.com/block-core/blockcore-did-server","last_synced_at":"2025-04-27T03:32:27.741Z","repository":{"id":63732476,"uuid":"566088339","full_name":"block-core/blockcore-did-server","owner":"block-core","description":"DID Server implementation that supports public sync and sharing","archived":false,"fork":false,"pushed_at":"2023-12-11T22:17:12.000Z","size":374,"stargazers_count":4,"open_issues_count":8,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-10-29T10:01:48.666Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/block-core.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2022-11-15T00:02:59.000Z","updated_at":"2022-11-24T14:29:43.000Z","dependencies_parsed_at":"2023-12-15T22:42:26.377Z","dependency_job_id":"58fcab4e-1713-4814-9a82-5ae0078637f6","html_url":"https://github.com/block-core/blockcore-did-server","commit_stats":{"total_commits":91,"total_committers":1,"mean_commits":91.0,"dds":0.0,"last_synced_commit":"e90f1fb703c89e7aec66d055bde78e0ee78541cd"},"previous_names":[],"tags_count":11,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/block-core%2Fblockcore-did-server","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/block-core%2Fblockcore-did-server/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/block-core%2Fblockcore-did-server/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/block-core%2Fblockcore-did-server/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/block-core","download_url":"https://codeload.github.com/block-core/blockcore-did-server/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":223028527,"owners_count":17076187,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-11T06:19:23.184Z","updated_at":"2024-11-11T06:19:24.473Z","avatar_url":"https://github.com/block-core.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Blockcore DID Server\n\nDID Server that can host a DID Method implementation that supports public sync and sharing.\n\nThis software can be used to implement your own DID Method.\n\nBlockcore uses this software to host the public available \"did:is\" DID Method.\n\n## Installation\n\nYou should use docker-compose, example available here: [chaininfo/docker/BLOCKCORE/IDENTITY/docker-compose.yml](https://github.com/block-core/chaininfo/blob/master/docker/BLOCKCORE/IDENTITY/docker-compose.yml)\n\nThis ensures that you have a persistent storage volume for the database.\n\nYou can also run the server interactively for testing:\n\n```\ndocker run -p 4250:4250 -it blockcore/blockcore-did-server:0.0.8\n```\n\n## Architecture\n\nThe DID Server is a straight forward service that stores and allows updates to DID Documents. All requests to the APIs are in the form of signed JWTs (JWS). The DID Server is also known as [Verifiable Data Registry](https://www.w3.org/TR/did-imp-guide/#verifiable-data-registry).\n\nThe first key in the verificationMethod is required to be the public key that is used to derive the DID, e.g. \"did:is:publickey\".\n\nOperations must be signed with a key in the `authentication` section of the DID Document. All keys in `authentication` can be updated through key rotation.\n\n### Storage\n\nThe DID Server relies on LevelDB for storage. Whenever a new update is performed, the sequence number must be correct and in order.\n\n### Throttling\n\nThe APIs have throttling (rate-limiting) configured by default to reduce spam-attacks, but it doesn't completely mitigate it.\n\n### Allow Listing\n\nThe APIs allows server hosts to run it in allow-listing mode, meaning that the server won't host a DID unless it's part of the allow-list.\n\n### API\n\nThe API for the DID Server is not very complex, they are based around JSON Web Tokens that has to be signed by the keys available in the DID Document.\n\n### Sync\n\nThe data on a single instance of the Blockcore DID Server, can sync with other instances very easily. When a sync happens, the same requests that a normal user performs, is re-run on the other server and same verification happens as when the user originally made the request. This ensures that zero trust is needed between instances of DID Servers.\n\n**Suggested sync model**\n\nServer1 connects to Server2 simply using REST-APIs, no need for specialized protocols.\n\nServer1 performs a date-based query based on local sync-state between Server1 and Server 2.\n\nIf this is an initial sync, Server1 is likely empty and will get list of all DID IDs that exists on the other server.\n\nAll the API calls are based upon paging.\n\nIf the page returns 50 items, the Server1 will retrieve the complete history of DID 1, DID 2, DID 3 in that paging result, before moving on to the next page.\n\nWe record the start time of the sync. When the full sync is completed, we need to do another sync not too long after to get the latest that happened while downloading the full sync.\n\nAfter finishing, the next time Server1 query Server2, it will include \"from-date\" that was last sync start time.\n\nThis means that each server must keep an index and cursor that can be used to travese based upon last inserted date (on the server, not part of the JWS itself).\n\nIs that enough?\n\n## API Schema\n\nAPIs calls are based upon JWS that MUST correspond to the following specifications. All the fields in the example below must be provided and is required, except the \"rules\" field which can be omitted.\n\nDecoded JWS:\n\n```json\n{\n  \"kid\": \"did:is:PMW1Ks7h4brpN8FdDVLwhPDKJ7LdA7mVdd#key0\",\n  \"alg\": \"ES256K\"\n}.{\n  \"version\": 0,\n  \"iat\": 1668606262,\n  \"content\": { }\n}.[Signature]\n```\n\n### \"kid\"\n\nThe \"kid\" is the Key ID available in the current document upon `\"version\": 0` or in the existing (`version - 1`) DID Document.\n\n### \"iat\"\n\nIssued at, this should be the time at which the user generates the DID Document. It is not verified any further.\n\n### \"version\"\n\nVersion 0 indicates that this is a new DID Document and other rules are applied than updates.\nVersion 1 or higher indicates that this is an updated DID Document and other rules are applied.\n\n### \"content\"\n\nThis is the DID Document. Can be empty, which means the user want to delete the DID Document. If a delete is performed the DID Document can never be restored again.\n\n#### Version 0 rules\n\nThere cannot exist any other DID Document already with the same DID Subject.\n\n#### Version 1 rules\n\nThe version must be +1 from the current synced document.\n\n### POST\n\nThe server hosts a generic endpoint at the root that can receive the JWS as a raw binary object through a POST method.\n\n## Request to be forgotten\n\nThere will in the future be a separate API that anyone can use to request a complete history wipe of their DID Document history. This API will allow users to provide an encrypted personal message for the DID Server host (public key discoverable using the .well-known configuration).\n\n## Manual Delete\n\nThe host of the DID Server can always manually delete (and block further sync, added to deny-list) entries in their databases. If access to keys are lost, a user can send a manual request to the service provider and ask to be deleted (wiped) from the database.\n\n## Docker Development\n\nSome of our decisions for `dockerfile` is based of best-practices from here: https://snyk.io/blog/10-best-practices-to-containerize-nodejs-web-applications-with-docker/\n\n```sh\n# Debug the container if needed during development:\ndocker run -it blockcore/blockcore-did-server sh\n```\n\n## Schema Validation\n\nWe rely on the avj library for schema validation and schemas is located in the `schemas` directory.\n\nTo update the precompiled schema validation code, run:\n\n```sh\nnpm run schemas\n```\n\nThis will update the `/src/schemas.ts` file.\n\n# References\n\nhttps://www.w3.org/TR/did-core/\n\nhttps://www.w3.org/TR/did-imp-guide/\n\nhttps://github.com/decentralized-identity/universal-resolver","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fblock-core%2Fblockcore-did-server","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fblock-core%2Fblockcore-did-server","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fblock-core%2Fblockcore-did-server/lists"}