Bigger picture with the Decentralized identifiers

Article four – Putting all the pieces together

This article summarizes DIDs and VCs’ fundamental principles, describes the use in the real world, and provides bonus materials for tech-savvy readers.

Prerequisites

Introduction

In recent years, various projects have contributed to the adoption of blockchain and its most popular derivative, cryptocurrencies. However, the reason why this technology should thrive in the future – and also the reason why cryptocurrencies were invented in the first place – is DeFi.

For cryptocurrency users, anonymity on the blockchain is one of the major features. For cryptocurrency regulators, anonymity represents a double-edged sword that protects the users’ identities, but hinders business adoption and provides the means for fraudulent activities such as money laundering.

Admittedly, the blockchain does have loopholes that can be illegally misused, but it also provides the ingredients needed for mending this issue. In the right hands, the use of blockchain innovations, such as:

Decentralized Identifiers (DIDs)
Self Sovereign Identities (SSI)
Verifiable Credentials (VCs)
and Tokenization

will help to acquire the needed permissionless trust in the form of Trust Network.

As an example application of these technologies that follows W3C and Rosseta, LTO Network is used in this article as a layer, where the projects build on the top of which can utilize technologies with massive impact on global cybersecurity and cyberprivacy.

This article will describe the fundamentals of the DIDs and their use in a structure called a web of trust, and also mention the collaboration with ChainLink, a provider of reliable and tamper-proof decentralized oracles, as well as Sphereon, a prodigy of data authenticity and integrity.

Summarization

A decentralized identifier (DID) is a character string that connects real-world identity with the world of blockchain, where a name and address of a user or a company are represented just as a public wallet address. The difference between our plastic driver’s license and its digital version, the Verifiable Credentials, is the one additional row of information; the DID string that connects our digital driver’s license to a blockchain.

VCs are always issued by an issuer, who in our society, is somebody with implicit trust, and hierarchically above us. A university providing a student ID issued to a person is a good example of such an issuer. The university has the student’s information (similar to information a user provides during the know-your-customer/client process (KYC) and also a record that the person is really a student, so the university can issue this VC to a student. This VC then gets signed with the key pair only the student is in full control of. In other words, the VC creates a link between the student and their university, where the public key claims users ownership over their credentials.

Using identifiers as thighs we control and bear the responsibility for the manipulation with them amounts to what is called Self-sovereign identity (SSI). That is to say, SSIs are a method where users store and manage their own credentials.

For a self-sovereign identity that represents a lifetime portable digital identity that does not depend on any centralized authority, we need a new class of identifiers that fulfills all four requirements: persistence, global resolvability, cryptographic verifiability, and decentralization.

The basis of a functional SSI is an identity certificate, publically available on the global network. This provides individuals and businesses a way to identify and legitimize themselves. At the same time, this ensures their privacy, as the certificate only discloses information they select.

For example, a business can verify their identity using the KYC procedure using a Certification Authority (CA), which provides the other party with a signed copy of the credentials.

LTO provides multiple node images, like the anchoring node, which provides additional services on top of the LTO public blockchain. For SSIs, LTO will deliver a new node image, the identity node, which supports the W3C Decentralized Identifiers (DID) and Verifiable Credentials specification.

VCs are designed to prove that you are who you are or that what you claim about yourself is true. The verification of this claim is handled by a VC stored in a user’s digital wallet. The terminal that reads the information from the VC’s DID and verifies them against a blockchain- stored public key, which is bound to a specific verifiable credential. The information about the public key and the method to resolve this public key is information stored directly in the DID string, which is a part of the VC. This way, the verification is performed, but the user’s information is kept in private. The terminal only cares about the VC status, not about your name or address where you live. That’s a problem for the issuer.

To illustrate, imagine that you want to buy liquor in a grocery store. The shop assistant is obligated by law to ensure you are 18 or older, and the only “bulletproof” way to confirm this is to show them your ID. However, the ID also contains a lot of information that the shop assistant does not need, and that you may not be comfortable disclosing, like your address of residence. On the other hand, if you could use your VC instead, your age would be confirmed digitally by the terminal, and you would not need to show any other information about yourself.

On the other hand, the DID is a perfect solution if you are for instance a company that wants to keep its information public, so that everybody can see who they are dealing with without any Google searching and thinking about company credibility. This time, the company’s DID is not a part of the VC that keeps the info private. Instead, the certificate is issued to this company by the CA, and bound to the company’s DID. With DIDs set up like this, the company can act in various networks, from a chain of trust or hierarchical networks, to a variation of a web of trust. By the way, the certificate I was just writing about is the x509 type.

The principal reason for the existence of DID

The need for persistent identifiers, which are identifiers that can be assigned once to an entity and never need to change.

Keep DeFi legally operational (does not apply to anonymous DeFi projects)

Use of the blockchain technology for:

User privacy and security
Verification of identities and claims bound to the identities

Benefits

Globally unique identifier and cybersecurity and cyberprivacy enhancer

At a superficial level, a DID is simply a new type of globally unique identifier. But at a deeper level, they are the core component of an entirely new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. This decentralized public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world).[1]

LTO Network Permissioned model for the fair-play playing field

Other on-chain identity solutions use a permissioned model that appoints trust anchors. A trust anchor is an authoritative party for which trust is assumed and not derived. These trusted parties, typically banks and big corporations, are responsible for validating identities and keeping the network secure. The downside to this appointment is that it creates a barrier to entrance and potentially an uneven playing field.

These barriers can create spots for corruption and cartels. For instance, if the 5 biggest insurance agencies are controlling the network, they may prevent a new (disrupting) insurance agency from joining.

LTO Network is and will stay permissionless; there are no roles and network rules are only enforced through the consensus mechanism. Trust is established by utilizing existing methods and allowing it to emerge from the network naturally.

Verifiable credentials beat the need for verifying the information about identities online

The combination of a DID with a certificate issued by a CA creates a great tool for companies that want to cooperate in trust networks and their identity is claimed by the certificate issued by a CA.
Combining a DID with a CA-issued certificate (type x509) keeps the company credentials public, thus saving their customers and clients time with manual searching for the company credibility and avoiding the need for verifying the information about identities somewhere else.

Providing versatile options while defining how a trust network is structured

With LTO Network and the use of decentralized identifiers, it is really easy to build a solution that matches the need of a customer. While some corporations need a chain of trust where all VC information is kept private, some enterprises would benefit more from a hierarchy type of a public trust network, using endorsements of identities to generate the needed trust, such as in a web of trust.

These structures can be configured to suit a company’s requirements and needs, and they can work twice as fast as classical networks.

The possible structures:

1. Chain of trust

A hierarchical trust network, which does not fit well the idea of a fair playing field for everybody promoted by blockchain. A chain of trust starting from the root certificate authority, also known as a trust anchor, followed by intermediate CAs and ends with the certificate owner. Still usable for companies that require a hierarchy order of certificate validation.

2. Web of trust

A web of trust is an alternative to the chain of trust. It’s a decentralized trust model that doesn’t rely on a hierarchy of trust anchors. Instead, trust is obtained through endorsements of peers. Anyone can initiate a new trust network on LTO Network by endorsing others using LTO association transactions.

Use-case

DeFi and real estate tokenization

When a real estate is converted to an NFT token and converted to crypto using blockchain for information storing and securing, VC with the house’s estimated price issued by a notary is attached to this real estate NFT.

When the claim about the real estate’s estimated price needs to be verified, how can a user be sure that the issuer is an official notary and not just a random person living next door to the target property?

Using VC, we can create a trust chain model in which all the data are kept private. Certification authority (CA) declares a certificate of identity claim to the notary. This certificated notary then issues a VC for a real estate with a value of the property included in the real estate DID.

In DeFi, if a house, tokenized to an NFT, is used to borrow cryptocurrencies, the lenders need to be sure that the owner of the NFT can actually claim the place as their ownership. Otherwise, the NFT is worthless. A VC with the information about this NFT is a key for just this kind of easy verification.

Also, thanks to the regulations, it is just a matter of time before all DeFi participants will have to be verified. VCs are a perfect solution to solve this problem.

Solving the problem of privacy using derived DIDs

DIDs and verifiable credentials help to replace anonymity with privacy, by connecting blockchain addresses to real-world identities. This puts the user in control of when and how to share personal information.

It is not advisable to use DIDs of private identities for multiple purposes. Correlating information might allow a malicious party to deduce your credentials, undermining privacy. A typical solution is to generate a new key pair for each use. LTO provides an alternative of generating many derived DIDs from a single public key. This is done by using a `hmac` hash instead of a regular hash to generate the address.

Imagine a CEO who provided some rewards to freelance writers that helped him to support his project in its early days. He used his main public address (wallet) for the distribution. From this day, the writers knew his address and could spot him 3 years later as he was sending a huge portion of tokens dedicated to the team to an exchange. Even though he is not doing anything wrong and simply wants to sell tokens at the end of the vesting period, this information could be used against him to create unnecessary FUD or speculations caused by a deduction of information, which undermines address owner privacy.

It’s not advisable to use DIDs of private identities for multiple purposes. Correlating information might allow a party to deduce information, undermining privacy. A typical solution is to generate a new key pair for each use. LTO provides an alternative of generating many derived DIDs from a single public key. This is done by using a `hmac` hash instead of a regular hash to generate the address. An `hmac` hash function takes a secret, which must be known in addition to the public key to create the hash. The secret isn’t published on the blockchain but added to the DID URL (pointer) as a query parameter.

The Derived DIDs can also be used to support combining DIDs with federated identities, like those provided by SAML. The public key taken from the certificate of the SAML server can be used to create DIDs for each of its users.

Creating unique trust networks on top of LTO Network and their blockchain solution for VCs and DIDs

A trust network built on top of LTO can utilize all the benefits that come with the unique LTO hybrid blockchain approach and solutions available with the usage of decentralized identifiers.

LTO Network uniquely provides a permissionless model for SSI. It allows applications to leverage existing trust models, like CA-signed certificates, removing the need for the network to establish trust anchors. Using associations, it is possible to create a custom trust network for each project, either with a strict hierarchy or as a web of trust, depending on the project needs.

On top of that, DIDs work perfectly in a structure called the trust network. A trust network is a more generic term for a logical network where identities can specify trust associations using endorsements.

This means that subjects with DIDs can verify other subjects in the network, based on the association between them. This way, identities endorse other identities, thus generating trust elements that emerge from these mutual endorsements. If we map the connection of these identities that support, approve, and endorse each other, we will obtain the web of trust. For more information about the web of trust, read the bonus chapter at the end of this article.

The end

Even though this series of articles may feel like an arcane tome from time to time, I hope that you enjoyed the reading, and perhaps even feel inclined to educate yourself about these topics even more.

If you have made it this far, congratulations, and I firmly believe that you are on the right path.

For further details, feel free to read the official LTO documentation, the content of which you should now be more likely to understand.

LTO – Identity paper

LTO – Identities tech paper

Footnotes

[1] W3C – Verifiable credentials

[Bonus chapters]

Chain of trust

A chain of trust is designed to allow multiple users to create and use a software on a system, which would be more difficult if all the keys were stored directly in hardware. It starts with hardware that will only boot from software that is digitally signed. The signing authority will only sign boot programs that enforce security, such as only running programs that are themselves signed, or only allowing signed code to have access to certain features of the machine. This process may continue for several layers.

The easiest way to grasp the basic idea here is to imagine a situation in which you need to use a corporate laptop to get something done. To get you into the system, the following chain of approvals need to happen:

A user turns on the laptop and uses their password to unhash the laptop’s disk. Without the accessible disk, the system is not able to boot.
When a system boots, the user logs in to the system using their credentials.
The user needs to activate VPN to create a protected virtual tunnel to the company.
For turning on the VPN toll the user needs to have administrator privileges and Two-factor authentication.
Using SU-privilege commands, the user accesses the company network.
The user uses their private keys to unlock their access to the company network.
Changes done in the company network need to be signed with the user private key.

Missing a simple item from the list will stop your progress since you break the chain of trust.

In computer security, digital certificates are verified using a chain of trust. The trust anchor for the digital certificate is the root certificate authority (CA).

The certificate hierarchy is a structure of certificates that allows individuals to verify the validity of a certificate’s issuer. Certificates are issued and signed by certificates that reside higher in the certificate hierarchy, so the validity and trustworthiness of a given certificate is determined by the corresponding validity of the certificate that signed it.

The chain of trust of a certificate chain is an ordered list of certificates, containing an end-user subscriber certificate and intermediate certificates (that represents the intermediate CA), that enables the receiver to verify that the sender and all intermediate certificates are trustworthy. This process is best described on the page Intermediate certificate authority. See also X.509 certificate chains for a description of these concepts in a widely used standard for digital certificates.

Web of trust

A trust anchor is an authoritative party for which trust is assumed and not derived. These trusted parties, typically banks and big corporations, are responsible for validating identities and keeping the network secure. The downside to this appointment is that it creates a barrier to the entrance and potentially an unlevel playing field. This means that permissioned models create opportunities for creating a cartel, where for example, the 5 biggest insurance agencies control the network, they may prevent a new (disrupting) insurance agency from joining.

Web of trust is a model that eliminates such an intention by design. It is a model where identities are present as DIDs. In this web identities endorse other identities in a way that trust that lays on the shoulder of trust anchors in the chain of trust, emerges from these endorsements.

A web of trust is a type of trust network, which is the network where identities endorse other identities. Identities (as DIDs) have trust-relationships (as associations) and form a logical network; the trust network.

In the image above, you see the identities of people that know each other and have direct trust between themselves (marked red). Also, marked blue, there are identities that do not have direct connections with you since they could be, for example, friends of a friend, and you have never met them in person. Still, the fact that your friend has a direct trust with these identities marks a slight indirect trust to you, since you think that a friend of your friend can reasonably be trusted as well.

Four levels of trust

Unknown – Those keys whose trust is not known at this point
None – The owner is known to improperly sign other keys
Marginal – The owner understands the implications of key singing and properly validates keys before signing them
Full – The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own

Delegating the trust

In a web of trust, a key can be trusted when:

It is signed by enough “valid” keys, which means:

You have signed it personally
It has been signed by one fully trusted key
It has been signed by three marginally trusted keys

Diagram

Each project built on LTO can specify parameters that configure the validity of binding or trustworthiness of binding between neighbor identities.

In the example above, names in circles represent users’ public keys, and from Keely’s perspective, they all have trust and validity.

Parameters for specifying trustworthiness in a web of trust diagram:

`Complete needed` – 1

`Marginals needed` – 3

The higher these numbers are, the more skeptical the diagram is for validating trust between users. These values are the default values and can be adjusted.
Arrows point to the person whose key is signed. Alice signs the keys of Bob and Eve and the whole diagram is rooted at Keely, who “fully” trusts Alice and signs her key. This makes Alice’s key valid.

The above settings {1;3} means that a key in this web of trust can be trusted if:

It is signed by enough amount of valid keys, meaning:

You have signed it personally
It has been signed by one fully trusted key
It has been signed by three marginally trusted keys

The path of signed keys leading from the « K » key back to your own key is within four (1+3) steps/hops.

Keely set the `Complete needed` parameter to 1, which means that only the identities in a distance of 1 from Alice, her `introducer`, will be qualified as fully trusted. Keely and Alice have full mutual trust, and thanks to her introduction, Bob and Eve are found valid in this diagram since they are `1` « hop » away from Alice.

If Carol wants to be valid, the `Martial needed` would have to be set to 2, and Keely would have to have marginally trust with Bob and Eve.

Note that there is a signature chained to Davem, but it is not strong enough to consider him fully valid. Therefore he is marginally valid and with an unknown trust.

Company example

Imagine that you have a direct trust with the CEO, CTO, and CMO of a company. Then, the right hand of the CEO, the COO, requests some information from you. Your problem is not sharing the information, but you do not know if that identity could be trusted. But since you know that the COO identity is endorsed by the CEO, CTO, and CMO, the true direct trust bounds of yours, you know that the COO has been validated by other peers in the network, and thus can be trusted. Now imagine that a friend of a friend that has indirect trust with another friend of the friend requests some information from you. In that case, you know that sharing the info with that identity could be a bad idea, which means it will be automatically forbidden by the web of trust.

Also, if the CEO approves something, it has the same value as 3 sub-CEO approvals, and you are ready to go, skipping the unnecessary bureaucracy.

In the blockchain web of trust, instead of names and labels, an identity is formed from a user’s public address, which is calculated from the public key, the first half of a regular key pair each person has.

A public key that is shared openly and a private key that is held by the owner. The owner’s private key will decrypt any information encrypted with its public key. In the web of trust, each user has a ring with a group of people’s public keys.

Users encrypt their information with the recipient’s public key, and only the recipient’s private key will decrypt it. Each user then digitally signs the information with their private key, so when the recipient verifies it against the user’s own public key, they can confirm that it is the user in question. Doing this will ensure that the information came from the specific user and has not been tampered with, and only the intended recipient can read the information (because only they know their private key).

Thanks to the web of trust, we can be sure that we can trust the identity with strongly endorsed trust from the network a user is a part of, and thanks to the certificate, we can accept the claim that the identity is true.