Digital identities — trust infrastructure for digital business models

With the increasing conflation of the digital and the real world, digital identity is becoming more and more important. The term “identity” in common speech is only used to refer to people. Therefore, a person has an identity. This identity develops differently depending on socialization and can be defined in many ways. The discourse on identity and which characteristics it is composed of is broadly conducted in various disciplines.

(You can read the German version of this article here.)

To efficiently link all actors and related entities of a digital business relationship in a comprehensive “digital business model”, the concept of identity needs to be expanded. This involves assigning an identity to companies as well as to physical objects, such as machines, to integrate them into processes — the keyword is industry 4.0.

In this sense, a digital identity stands for an identifiable entity, which is described using identity attributes. An identity attribute can be, for example, a person’s name and a date of birth, a commercial register number for companies and a serial number for machines.

Identities in the evan.network

In the evan.network, there used to be a distinction made between digital identities as a digital representation of people and organizations and digital twins as a digital representation of objects. In the future, this distinction will be abolished and replaced by a uniform term digital identities that can interact with each other as participants in business processes. Prospectively, the evan.network will only differentiate between different types of identities which vary in their structure and the type of associated data.

• Self Sovereign Identity (for humans and organizations)
• Asset Identity (for physical objects)
• External Identity (for identities maintained in third party systems to integrate them into evan.network based processes)

Digital identities are managed in the evan.network under the self-determination maxim (Self Sovereign Identity), which means that the control over the identity as well as over the access to digital identity attributes always remains with the owner of the identity. Technical details about the types of identities can be found in the evan.network github repository.

Identities require trust

Identity is closely linked to trust. The identity attributes and proofs can be used in business relationships, only if they can be trusted. Numerous mechanisms exist to provide identities with trust in the real world. For individuals, there are documents such as identity cards, whereas public registers with the associated notarial processes create the necessary trust for companies. In the digital world, there are still large fields of action needed to create similar trust systems.

A typical model of today is to outsource the trust-building between two or more business partners to a trusted third party, usually a platform operator. The problems associated with the resulting information asymmetry require alternative ways to build trust between acting business partners.

The evan.network makes it possible to close this digital trust gap without creating dependencies and thus form the basis for digital business models between companies at eye level.

Verification Services create trust

Core elements of the trust infrastructure are the evan.network Verification Service as well as the mapping of trust via so-called Verifiable Credentials (VCs), a W3C standard that ensures interoperability of different identity and trust services.

Essentially, it is always about equipping a statement (VC document) of an identity holder (trust holder) with a confirmation, issued by a trustworthy third party (trust issuer). The Verifiable Credentials can then be used by the trust holder to identify themselves to third parties (trust verifiers).

The W3C standard does not determine the way VC documents should be exchanged, so it can also be done directly between the involved partners by any preferred means. This way does not require any central infrastructure, however, in practice, it causes some problems:

• Once verification is issued, it cannot be recalled
• For updates in VC documents, the issuer and the holder cannot ensure that all verifiers are using the latest version
• There is no history of the VC documents, so it cannot be determined which version of a VC document is valid at what time
• All parties involved must agree on uniform procedures for claims description and exchanging the necessary documents
• Each partner involved must implement the infrastructure for issuing and validating the VC documents themselves, which entails a high level of effort in terms of setup and operation

To work around these problems, VC documents can be “anchored”, which means that a reference to a particular document or the entire VC document is stored in a trusted system.

Anchoring of references to verifications

In this case, the VC documents are still exchanged directly between the partners, and the document is also registered by the issuer via the evan.network Verification Service. The issuer can now use the registration to control the validity of the verification and reverse it, if necessary. The trust verifier can check the validity of a VC document via the evan.network Verification Service when receiving it. Thus, the “recall problem” of a verification once issued can be solved, but other problems mentioned above remain, especially such as

• missing history
• no control over the distribution and use of the VC documents by the holder
• high implementation effort

Storing of verifications

One possible solution is to store the VC documents within the trust infrastructure, which also provides mechanisms for managing, sharing and accessing the Verifiable Credentials. This enables the setting up of networks where different companies can cooperate and confidently exchange data using Verifiable Credentials.

Finally, the holder of the Verifiable Credentials can control access to the VC document itself and thus control the use of information. Since no infrastructure standards need to be defined and provided for collaboration, the effort required to operate and onboard new partners is relatively low.

Due to the blockchain-based approach of the evan.network, it is possible to version the Verifiable Credentials. Thus, the respective valid Verifiable Credentials can be proven for each past point in time.

To maintain the concept of self-determined data usage, it is very important to store them on a neutral infrastructure. Otherwise, the danger of creating and strengthening a new central infrastructure with all its disadvantages appears.

The evan.network is a trust infrastructure for digital business relations due to its neutrality ensured by technical and organizational measures.

With the Verification Services, the evan.network offers a W3C compatible approach for the management of identities and verifications combined with comprehensive possibilities for simple creation, administration, and sharing of verifications for all parties involved.

Advanced Verifications

Verification can be performed for all identity types. The digital identity of a company, for example, can confirm that certain machines (Asset Identities) belong to the company or that employees (Self-Sovereign Identities) act on behalf of the company.

Verification by third parties

Verifications are particularly interesting when they are used to transfer trust from the real world to digital identities. Let us illustrate it with a fictional digitization example of a very familiar use case. You need a driving license to rent and use a vehicle. In the real world, the license is presented to lessor’s employees when renting a vehicle. They then check the validity and authenticity of the document. So, how can this process be completely digitalized and automated?

The starting point here is the “I have a driver’s license” assertion made by the digital identity of a prospective renter. Anyone can make this claim, so its use by third parties requires confirmation by a party accepted by everyone, which in this case is a Federal Authority (trust issuer).

Once created, such verification can now be used by a trust holder in various business processes, for example, to rent a vehicle. In this digital process, the lessor of a vehicle proves the validity of the digital driving license (Verifiable Claim) using the Verification Service in the evan.network.

Verification Chains

Let’s assume that the Federal Authority does not want to verify all digital driving licenses by itself. To fulfill the task, the Office collaborates with service providers who are qualified to do so. This process is also done via Verifiable Claims, where a required certificate of the service provider (trust holder) is confirmed by the Federal Authority (trust issuer).

These service providers now act as trust issuers and verify the possession of the driving license to the driver (trust holder).

The vehicle rental company (verifier) can now check in an already known way whether the driver (trust holder) possesses a driving license. However, it must also be possible to ensure that the Office has indeed authorized the trust issuer to confirm his driving license possession. This is what the evan.network Verification Service is used for, as it offers an easy way to create and validate multi-level verifications.

Conclusion

Being sure in the business partner’s identity as well as their assertions form the basis for every business relationship. Today, analog measures for building trust are still extensively implemented in digitized business processes. Trust that is available in its digital form is vital for completely digital business models. The W3C standards on digital identities (DID) and digital trust (Verifiable Claims) will ensure the interoperability of different trust infrastructures in the future.

There are infrastructures needed to digitize trust without creating information asymmetries. This is the core concept of the Verification Service in the evan.network, where the technical and organizational architecture ensures extensive decentralization and neutrality. Thus, the existence of digital cooperative business models that maintain the independence of the partners involved is already a reality today.

The evan.network is a vendor neutral digital infrastructure that uses blockchain to create a trusted cooperation environment where business partners can work together to build and deliver digitized goods and digital services to end customers.

You want to be kept up to date? Then follow us on Twitter or LinkedIn!

You liked the article? Don’t forget to clap!