Skip to content

Latest commit

 

History

History
60 lines (38 loc) · 3.86 KB

README.md

File metadata and controls

60 lines (38 loc) · 3.86 KB
Raw

Example Appnet Implementation

About

This project is an example of how appnets can build identity networks on top of Hedera and utilize Hedera DID Method and Verifiable Credentials Registry. It is not a production-grade reference implementation, as this appnet exchanges and exposes private keys of issuers and credential owners via its API interface for demonstration purposes. It also does not use any persistent storage, clears all its data upon shutdown and listens to DID and VC topics from startup, ignoring past messages - so that each execution has a 'clean' demo state.

Usage

The appnet server can be started by the following command directly from the root folder of this repository:

gradle :appnet-api-server:run

The appnet runs on localhost port 5050 be default. It does not expose any user interface, instead there is a collection of Postman requests available here that demonstrate a full end-to-end flow of DID documents generation, publishing, update and deletion, as well as verifiable credential generation, issuance and revocation.

There are three types of requests in this collection:

  • DID - reference requests of Appnet Relay Service as defined in Hedera DID Method Specification
  • VC - reference requests of Appnet Relay Service as defined in Verifiable Credentials Registry
  • DEMO - additional requests for demonstration purposes. These in real-world application would be implemented differently, in secure environment (e.g. in a client wallet application).

The collection is ready to be run end-to-end and automatically captures responses from previous requests as input for the next.

Configuration

The following environment variables are required to be set up before running the application:

  • OPERATOR_ID - Your testnet account ID.
  • OPERATOR_KEY - Your testnet account ID private key
  • MIRROR_NODE_ADDRESS - Address of the mirror node this application should connect to

Additionally the following configuration of already initialized identity network can be provided. If it is missing, the application will create identity network artifacts upon startup and print them into system console. A new Hedera file containing the address book and two topic IDs will be created.

If the file id below alone is provided, it will be used to fetch the VC and DiD topic IDs from the Hedera Network

  • EXISTING_ADDRESS_BOOK_FILE_ID (e.g. 0.0.19087)

If the below is provided, topic IDs won't be fetched from the network, saving the cost of a file query

  • EXISTING_ADDRESS_BOOK_JSON (e.g. {"appnetName":"Example appnet using Hedera Identity SDK","didTopicId":"0.0.19085","vcTopicId":"0.0.19086","appnetDidServers":["http://localhost:5050/"]})

Finally, the following two optional parameters may be set (they will default to 10 if unset). They determine how frequently DiDs and VCs are persisted to file. If for example the value is 5, then every 5 VC operations, the state of the VCs will be persisted. Providing a large number may improve performance due to fewer file operations, however upon restart, catching up with mirror node to rebuild state to its latest may take longer.

  • DID_PERSIST_INTERVAL - how frequently should DiDs be persisted to file
  • VC_PERSIST_INTERVAL - how frequently should VCs be persisted to file

Persisted data resides in the persistedCredentialIssuers.ser, persistedDiDs.ser, persistedSignatures.ser and persistedVCs.ser of the application's folder. They are binary files and not human readable.