The Hedera Hashgraph ecosystem has been extremely busy regarding the decentralized development of Hedera’s developer tools/services. Additionally, Hedera’s involvement in standards bodies and associated working groups, such as W3C, have created further alignment in those developments. Looking through the Hedera blog, you’ll read about all of the work being done throughout the ecosystem. Some example industries that ecosystem partners are targeting include sustainability, digital health, gaming, pharmaceutical, and many others.
While vertical solutions are important, horizontal solutions are just as imperative. A great example of a horizontal solution gaining popularity is the Hedera DID Method for Decentralized Identifiers (DIDs) and Verified Credentials (VCs). Up until now, the only way to implement the Hedera DID Method was through the Java DID SDK but many applications are built using other languages, such as JavaScript. We at Envision Blockchain are happy to announce the release of the open-source Hedera JavaScript DID SDK and continued maintenance into the foreseeable future.
A brief history of Decentralized Identifiers (DIDs) and Verified Credentials (VCs)
Before we properly introduce the Hedera JavaScript DID SDK, let’s take a step back and lay the foundation for DIDs and VCs. Some readers may be hearing about DIDs and VCs for the first time — but these identity concepts are nothing new. Data related to births was recorded as far back as the 1500s. In the early 1900s, we saw the first issuances of driver’s licenses and social security cards. And as the world evolved through digitization, so did the way we manage those identities. Digital identification on individuals and devices needed to be met with security and standards. Enter the idea of Decentralized Identifiers (DIDs) and Verified Credentials (VCs).
As written in the W3C Decentralized Identifiers (DIDs) v1.0 documentation, “Decentralized Identifiers (DIDs) are a new type of globally unique identifier that are designed to enable individuals and organizations to generate their own identifiers using systems they trust. These new identifiers enable entities to prove control over them by authenticating using cryptographic proofs such as digital signatures. Since the generation and assertion of Decentralized Identifiers is entity-controlled, each entity can have as many DIDs as necessary to maintain their desired separation of identities, personas, and interactions.”
Attached to DIDs described above are Verified Credentials (VCs). When writing about VCs, W3C explains in the Verifiable Credentials Data Model 1.0 document, “In the physical world, a credential might consist of information related to identifying a subject, information related to the issuing authority, information related to the type of credential, information related to specific attributes about the subject, and evidence related to how the credential was derived. Verified Credentials (VCs) can represent all the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes VCs more tamper-evident and more trustworthy than their physical counterparts. Holders of VCs can generate verifiable presentations (VPs) and then share these VPs with verifiers to prove they possess VCs with certain characteristics. Both VCs and VPs can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance.”
The Hedera JavaScript DID SDK
Now that you have some background on DIDs and VCs, let’s get back to the Hedera JavaScript DID SDK. When in an implementation scenario, it’s good to have options for your development team. The only way originally to implement the Hedera DID method was using the Java DID SDK. According to this blog post from General Assembly, “What makes Javascript so popular”, there are over 1.8 billion websites in the world, and JavaScript is used on 95% of them. JavaScript is also by far the most used language, according to Github’s 2020 Octoverse Report. We anticipate the release of the Hedera JavaScript DID SDK to be appealing to an extremely large JavaScript development community to roll up their sleeves and get busy hacking away.
If you’re already familiar with the Hedera Java SDK, you can keep scrolling to read about the differences. However, if you are reading about this for the first time, here is a quick recap of what the Hedera JavaScript SDK allows you to do:
Creation of identity networks within appnets, that is: creation and initialization of the artifacts mentioned above.
Generation of decentralized identifiers for Hedera DID Method and creation of their basic DID documents.
Creation (publishing), update, deletion, and resolution of DID documents in appnet identity networks.
Issuance, revocation and status verification of Verifiable Credentials.
Just like the Hedera Java DID SDK, the JavaScript SDK does not impose any particular way of how the DID or verifiable credential documents are constructed. Each appnet creator can choose their own way of creating those documents and if these are valid JSON-LD files adhering to W3C standards, they will be handled by the SDK. Let’s look at what is similar and different between the Java and JavaScript SDKs:
You’ll notice that both Java and JavaScript SDK still contain similar Hedera DID Method libraries:
In the /Identity library you’ll notice the same files (Java on the left and JavaScript on the right):
The main difference, of course, is the language-specific implementation of the Hedera DID method. An example can be shown below when diving into the DID Document Base (Java on the top and JavaScript on the bottom).