Requirements

The SDK should be able to support keys presented in multibase format. Supporting means able to resolve and mange keys in multibase format.

Draft

Some of the public nodes are not production ready and may not be available at all times. The SDK should provide an option to manually select the Hedera Node to interact with. Also some clients may want to interact with nodes that are geographically closer to them or have ownership of the nodes.

Draft

Any operation or transaction performed using the SDK should be able to be serialized. Serializing a transaction or operation involves converting it into a format that can be stored or transmitted.

Draft

Any operation or transaction performed using the SDK should be able to be frozen. Freezing a transaction or operation involves blocking the possibility of further editing, thus putting it in a state ready to be signed and executed. In this way, we will be able to avoid consistency problems.

Draft

Any operation or transaction performed using the SDK should be able to be signed with external keys. Signing a transaction or operation with external keys involves using a key pair that is not managed by the SDK. This way, we will be able to sign transactions or operations with keys stored in a hardware wallet or any other external key management system.

Draft

Any operation or transaction performed using the SDK should be able to be signed with private keys. Signing a transaction or operation with provided private keys. This will help be more compatible with previous SDK version and provide more flexibility to the users.

Draft

The SDK should support an Ed25519VerificationKey2018 verification key type. Support should be provided for resolving the DID Document.

Draft

The SDK should support an Ed25519VerificationKey2020 verification key type. Support should be provided for resolving, creating, updating, and revoking the verification key from the DID Document.

Draft

The SDK should provide a method to resolve a DID Document from Hedera Hashgraph Decentralized Identifier (DID) method. Resolver should be fully compatible with the DID specification.

Draft

The SDK should provide a way to resolve a DID Document in JSON-LD format. JSON-LD representation of a DID Document is a standard way to represent a DID Document in a machine-readable format. The SDK should add proper JSON-LD context to the resolved DID Document.

Draft

The SDK should provide an option to dereference a DID Document service. Dereferencing a service means resolving the service endpoint to a specific URL. The resolved URL should be fully compatible with the DID specification. Dereferencing should be supported by DID URL. Optional user can pass additional parameter relativeRef to resolve the service endpoint with relative reference. Resolved service endpoint should be a valid URL.

Example of a DID URL with relative reference:

or

Draft

The SDK should provide a way to resolve a DID Document in JSON format. JSON representation of a DID Document is a standard way to represent a DID Document in a machine-readable format. The SDK should be compatible with the JSON format of the DID Document.

Draft

The SDK should provide an option to resolve a DID Document in Concise Binary Object Representation (CBOR) format in hexadecimal encoding. The resolved DID Document should be fully compatible with the DID specification.

Draft

The SDK should provide an option to dereference a DID Document fragment. Dereferencing a fragment means resolving the fragment of a DID Document and not just the whole document. Fragment can be a service, verification method or any verification relationship. The resolved fragment should be fully compatible with the DID specification. Dereferencing should be supported by DID URL. Resolved fragment should be a valid service type of verification method type.

Example of a DID URL with fragment:

or

Draft

The SDK should provide an option to manage the services of a DID Document. Clients should be able to add and revoke services from the DID Document. The SDK should be compatible with the Hedera DID method specification.

Draft

Register a DID and associated DID document, according to a Hedera DID method specification. Clients should be able to register a DID using provided Private Key or be able to delegate the signing to the external service.

Draft

Update the DID Document with multiple operations in a single transaction. Clients should be able to make multiple updates to the DID Document in a single transaction and be able to rollback the transaction if any of the operations fail. The SDK should provide an option to batch update the DID Document in a secure and verifiable manner. Updating the DID Document should be done in a way that is compatible with the Hedera DID method specification.

Draft

Transfer the ownership of a DID from one entity to another. Transfer of ownership should be done in a secure and verifiable manner. Changing the ownership of a DID should be done in a way that is compatible with the Hedera DID method specification.

Draft

Deactivate a DID and associated DID document, according to a Hedera DID method specification. Clients should be able to deactivate a DID using provided Private Key or be able to delegate the signing to the external service.

Draft

The SDK should provide an option to manage the verification relationships of a DID Document. Clients should be able to add and revoke verification relationships from the DID Document. Verification relationships are used to establish a trust relationship between a DID and a verification method. Supported verification relationships include authentication, assertionMethod, keyAgreement, capabilityInvocation, and capabilityDelegation. Accepting aliases for these relationships should be presented. The SDK should be compatible with the Hedera DID method specification.

Draft

The SDK should provide an option to manage the verification method of a DID Document. Clients should be able to add and revoke verification methods from the DID Document. The SDK should be compatible with the Hedera DID method specification.

Draft

The SDK should work in both Node.js and browser environments. The SDK should be tested in both environments to ensure compatibility. The SDK should work without any issues in both environments.

Draft

N/A

The SDK should support both CommonJS and ES Modules. Therefor correct building of the SDK is required to support both module types. Correct package.json configuration is required to support both module types. The SDK should be tested with both module types to ensure compatibility.

Draft

The SDK should support Node.js version 20 and above. Support for older versions of Node.js is not required. The SDK should be tested with all the latest versions of Node.js to ensure compatibility. Support means that the SDK should work without any issues on the supported versions of Node.js. Major issues that prevent the SDK from working on the supported versions of Node.js should be fixed.

Draft

Testing is an important part of the development process. The SDK should be tested in all the supported environments to ensure compatibility. The SDK should be tested with all the supported versions of Node.js to ensure compatibility. The SDK should be tested with both CommonJS and ES Modules to ensure compatibility. 80% code coverage should be achieved in the testing process. Unit tests and integration tests should be written to test the SDK. Each module of the SDK should be tested to ensure that it works as expected.

Draft

N/A