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.

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.

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.

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.

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.

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 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.

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.

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.

In order to abstract the intricacies of using TOSI chain for DID account management functions and day-to-day use cases, a set of services are implemented to offer a more friendly RESTful HTTP API for creating, updating, and removing DID entities from the system, as well as, using and managing crypto assets. Combined with these services, the Zippie Client API libraries for JavaScript and TypeScript, which application developers may use to more easily leverage the Zippie DID platform as associated services.

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.

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.

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.

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.

Zippie Developer Dashboard will soon be available for use.

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.

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.

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.

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.