Decentralized Identity (DID) leverages the decentralization of blockchain technology to enhance privacy and transparency and eliminate central authority.
Blockchain technology by nature allows the information recorded within it to be accessible by anyone and from anywhere and naturally redundant as well as verified and verifiable by a built-in consensus mechanism. Every change to the information is verified, recorded, and immutable, acting as a single source of truth (a.k.a. Web of trust) for all the agents within the system. This technology removes the single point of failure of traditional databases, making it very difficult to hack and modify (e.g. forged Identities) and thanks to public key cryptography, it can be programmed in a way that only the user with a certain private key can perform updates to a given piece of data, therefore limiting the surface of attack for identity thieves.
With DID, data and assets are stored in the user’s digital identity, placing the sole and full authority squarely in their hands. DID gives them more independence and frees them from invasive authentication and verification. Companies or organizations are also less vulnerable to cyberattacks such as data breaches as they store less user information in their databases.
Benefits of Zippie DID
Multiple Applications with a Single Identity
As mentioned previously, the conventional and convenient way to authenticate users in applications is to have a dedicated user registration and login process. However, this process collects sensitive information from users, increasing their attack surface due to unnecessary data duplication across several applications.
To solve this problem, DID stores user credentials such as name, address, phone number, and email address directly in the user’s digital identity. Rather than registering individually to several applications, users can share the data stored in their DID with organizations and use it for authentication. As they have full control over the use of their credentials online, they can decide exactly what data they want to share while opening a new account. This simplified registration process will never share the user’s authentication data to the application, keeping their data safe and secure.
Less invasive verification
As stated in the previous section, users can use the data from their DID to register into applications. This process will share only the agreed information to the application upon registration. With this, the user data shared in various applications may vary as they require different fields to fill up upon registration.
To further increase user security and privacy, selected user data can be verified without exposing the actual data. For example, the application has a minimum age requirement to use its services. Instead of providing the user’s date of birth, DID can just share that the user is at the appropriate age to use the application. This is achieved through Zero-Knowledge Proofs (ZKP), which validates the accuracy of information without disclosing it to a third party. With ZKP, the user’s sensitive information is protected.
Storing About vs Into an Identity
Traditionally, when the user creates or updates content in their account under an application, the data is stored inside the application’s purpose-built storage services and databases. This means that the user’s data isn’t easily transferable between different applications. If the service or application shuts down or is no longer available, the user data stored within will be out of reach.
To address this, DID allows the application to store user data in an app-specific isolated storage area in the user’s digital identity, accessible through a Peer-to-peer (P2P) network and replicated across high-availability storage providers. Compared to a centralized approach, this network is less susceptible to data loss and allows users to access their wallets, tokens, NFTs and private data even after an application or service ceases to be available.
Therefore, as the user traverses the Web3-enabled internet, their data travels with them and is no longer tethered and bound to centralized application services. To put it simply, it’s being allowed to carry one’s work files in a secure briefcase, rather than being restricted to access the files during working hours.
No downloads required
Similar to the traditional website authorization methods, users don’t need to download 3rd party applications or a browser extension/plugin when accessing Zippie DID. It also works on mobile devices, allowing users to use it anytime, anywhere.
No need for remembering secret recovery phrase/private key
When a new application requests access to a user's DID, Zippie DID creates its own set of private keys within the user's digital identity. With this, each application the user utilizes has its own set of secrets, making the system extremely secure. These secrets cannot be shared between applications, isolating and protecting user assets from accidentally being accessed.
Furthermore, one of the main innovations of Zippie DID is the ability to store cryptographic private keys inside secure user storage areas. This storage is unlocked when a user uses a traditional login or recovery method, removing the need for the user to remember a secret recovery phase or store the private keys themselves.
This private key storage approach makes the onboarding of novice crypto and Web3 users extremely simple as the user doesn't need to worry about confusing recovery word lists/phrases or the need to back up all their private keys to a cold storage solution.
How Zippie DID Works
What is a Decentralized Identifier?
Decentralized Identifiers (DIDs) are a secure, verifiable, decentralized, identity format. A DID may describe a person, an organization, or a group of people (the DID subject).
Zippie DID is built around two main data structures: The DID Document and The DID Index. The DID Document is the underlying model that describes a person’s identity or an organizational unit structure. On the other hand, the DID Index is a lookup table, indexed by a public key, which points to the hash of the latest version of a users’ DID Document and is used to refer the user to the latest version of the associated DID document. But before the user can get to the document, they need to provide a public key to validate that they have the right to access it.
DID Index referencing a DID Document through IPFS
DID Documents are stored in storage nodes, and when the user tries to access their document, the nodes provide the information to a distributed P2P file storage system like IPFS. This document contains links to cryptographic assets, private keys, user-owned data, a person’s contact information and their connections to other people, and more. It also contains an area partitioned into isolated secure storage areas on an application-by-application basis. However, the level of security of these storage areas may vary depending on the authentication levels set by the application developer.
DID Index as TOSI Datachain
The TOSI chain is a computational blockchain designed and developed to be extremely flexible. The Tosi chain hosts the DID Index for keeping track of user and application DID Documents.
DID Data Hosting Nodes
To store DID documents, DID allows people to set up and host data through Data Hosting Nodes. These nodes will be incentivised by storing documents but they only get paid if they provide proof that this network concluded or probabilistically concluded that this data is available and possible to download.
To arrive at this conclusion, DID will be reusing the TOSI data availability checking method to check if these data hosting notes are providing the data. This function will randomly select a committee from a network of nodes and these nodes have to agree that the data is available to guarantee the legitimacy of the data availability proof. After they prove that this data is indeed available, this network of nodes will be rewarded.
Zippie Platform Service Nodes
User Creation and Sign-In Processes
When a user opens a DID-enabled application for the first time, they need to sign in or create a new DID-based account. During the Sign-Up process, when a new DID Document is being created, a set of secure encryption keys are created, one is used to encrypt the areas where application-specific data is stored, and another is created which is used to sign update operations on the users DID Document itself. A final and third key is generated specifically for each new application as default, this application key can be used by the application to create blockchain transactions, for example, using the DID API.
The Zippie DID API also provides a mechanism to display protected form elements and other web elements to the user. These elements will be used to enter the user’s new account information. When the form is completed, this data is used to create a DID Document and added to the Zippie DID Index within the TOSI datachain. The private information entered within the protected elements is handled directly by Zippie DID without any intervention required by the application and therefore reducing the possibility of data leaks and liability.
Decentralized and Trustless Services
The DID authentication is a modular system, it allows applications to decide which authentication methods or combinations of them they will require. An application can even add multiple levels of security by combining one authentication strategy such as username and password with a second level such as requiring Two-Factor Authentication (2FA).
User’s passwords are processed using an OPAQUE password authentication strategy, which essentially means that authentication services do not ever have access to a users’ password in hashed form or plain text.
Application developers may log into the Zippie DID Dashboard and select secondary authentication options, and when these extra authentications need to take place. For example, an application may require a user to confirm the generation of a cryptographic transaction signature with their fingerprint, or entry of a TOTP code from an authenticator app like Google Authenticator.
Below is a list of currently supported and planned authentication methods:
- OTP with email *SMS & WhatsApp *Coming soon
- TOTP / 2FA Applications and Pen Drives (like Google Authenticator, etc.) *Coming soon
- PIN *Coming soon
- KYC Facial Recognition *Coming soon
- FIDO Alliance *Coming soon
- Other Biometric options, fingerprints, etc. *Coming soon
Forgetting the password to a digital wallet can lock the user out of the fortunes stored within it. With this, account recovery is crucial to keep the user's account accessible all the time.
Zippie DID offers the ability to recover user accounts in case they forget their authentication credentials. As assets continuously grow in terms of value, the user or the application can increase their account security by moving to a more secure recovery model such as Facial Recovery and Multi-Contact Point. This progressive security ensures that no one would be able to access the user's wallet or steal the value stored within it.
Simple password reset
To regain access to an account, the user needs to verify their identity through an email or a username.
To reset an account’s password, the user needs to provide their username. Zippie DID will then send the OTP to the contact point associated with the provided username. Upon successful OTP verification, the user will be able to change or choose their account’s new password.
If the user fails to remember their username, they can provide the email associated with their DID account instead. DID will send their username to the associated contact point and they can proceed to log in after.
Secure account recovery
For an additional layer of security, Zippie DID allows a combination of multiple authentication strategies to ensure user authenticity.
Multi-Contact Point *coming soon
To increase the security of an account, the user can add multiple contacts such as an email, phone number, and authenticator app. Through this method, the user will need to pass through two out of three verifications to recover their password.
Facial Verification Recovery *coming soon
When KYC providers or users get connected to DID applications, applications can require the providers to authenticate the user against their own KYC information through facial verification for recovery. This method adds more security to the recovery process and can be required by applications to regain access when users change their passwords.
Zippie Developer Dashboard
Zippie Developer Dashboard is an interactive dashboard that allows developers to configure the behavior, look and feel of the DID within the context of their applications. This dashboard offers customization of user sessions and activation of multiple levels of security for authentication.
Persistence of User Sessions
Through the developer dashboard, developers can specify how long a user should stay signed in and whether or not they should re-authenticate upon entry to an application.
Activation of Multiple Authentication Strategies
To further secure user accounts, developers may add multiple levels of security by setting up the various authentication strategies they want to add in the developer dashboard.
Zippie Developer Dashboard will soon be available for use.
Zippie DID User Storage Space
Zippie DID allows client-side applications access to a partitioned and encrypted private user storage space. This storage space contains the users' personal information, application configuration & settings, as well as any other application-specific metadata. It is hosted on a peer-to-peer, trustless, and decentralized file storage network, which is only accessible if the user can satisfy the required authentication levels selected by the developer.
Encapsulated Secure User Storage
The user storage is partitioned on an application-by-application basis. There are no two applications that share the same storage space or set of cryptographic keys. In addition, an application or user may require that the area be further subdivided into security threshold layers which require more secure methods of user authorization in order to access them. This multi-layered security model is how facilities like 2FA requirements are determined and met.
When an application requires access to a cryptographic asset, it performs a secure request through the Zippie DID API, which depending on the operation, retrieves the application’s specific private key/s, performs an operation like signing a transaction, and then immediately forgets the private key and returns the resulting object back to the requesting application.
Zippie Web Runtime Secure Zone
The Zippie DID runs in such a way that the application will never have access to the user’s private cryptographic keys. Furthermore, the private cryptographic keys are retrieved and used in a secure way only within a secure browser component, immediately discarded after the desired operation is completed and cannot be accessed by any other entity. This maintains the non-custodial nature of the DID system, whilst enabling application developers the ability to implement blockchain functions in a simple, safe, and secure manner.
Distributed key generation
To transfer digital assets, one would need a unique private key to prove their ownership to a blockchain address. These keys can be kept in a single location but the user must ultimately trust the device or party to store their private key securely. However, these devices or parties can be easily compromised as hackers only need a single location to steal a private key. Once this key is in the wrong hands, hackers will have the ability to transfer assets stored in the user’s DID.
With more and more people losing assets due to opportunistic cybercriminals, Zippie DID utilizes Distributed Key Generation (DKG), a distributed network of nodes to prevent a single party or location from holding a user’s keys in its entirety. In other words, the network distributes a private secret network key into multiple nodes or parties, each keeping its share private from the other. These nodes will collectively generate a unique signature through the use of the Threshold Signature Scheme (TSS), a cryptographic technique that turns a generic authentication proof into the aforementioned signature. Once the signature has been generated, it can be used by the secure server component to unlock the user's secret storage which contains their private keys.
In order to take control of the DKG network, a malicious actor would need to hack the majority of the nodes. With this paradigm, the private key is not reachable without having proof of authentication (generated by the authentication service) and the unique signature generated by the DKG network. Taking control of one of these components would not be enough to allow a malicious actor to get control of the private key, drastically increasing the security of the user's assets while allowing the user to log in using well-known and frictionless authentication patterns.