White Paper

Version 1.2

Last Updated July 15, 2019

vereign, to ● verb ● /vɛre'ɪn/(short for verified & sovereign) to protect privacy, integrity, and authenticity by self-sovereign identity and data

This white paper was written 2018, and reflects our thinking when we started Vereign. Some parts have evolved or been modified, but most of its concepts are still topical and in fact the world has been slow in catching up to our bigger vision. Which is why we keep this as a historical reference for where we come from, and a yard stick that will let us know once we have reached the goal.

01

Introduction

This is not a traditional white paper, but an in-depth examination and expansion of the proposition made in our user story to introduce a new service category for the internet. Our goal is to provide a sufficiently deep overview to allow anyone to understand our proposal and our plan to achieve it.

Most people will not read each part of this white paper with the same intensity. The technical part is likely too technical for someone primarily interested in the business approach, and the business approach may not be of equal interest to someone from the technical community.

Also, our user story and white paper are far beyond just being a conceptual idea. Many of the components have already been developed into a proof of concept, and most of the technical questions have workable answers that will continue to be improved over time. The result is a combination of technical, social, and business aspects that will create a new layer of security for the internet. Based on blockchain technology, decentralized networks with democratic oversight, and Self-Sovereign Identity, this service allows seamless addition of integrity, authenticity, and privacy to any category of service. It also solves some of the most pressing issues of the digital world today with an innovative technical concept that combines digital identities and proven cryptography with a profound understanding of existing instruments and means of legal protection.

• federated networks with built-in legal protection and real control for users can replace monolithic, single vendor, or technology services
• an open, participatory ecosystem can guarantee that no person, organization, company, or technology will need to be trusted blindly
• transparency and accountability will start at the hardware level and continue over fully Open Source software all the way to the highest level of governance

Based on a solid foundation of traditional financing for the initial deployments for production, Vereign will launch a token as part of a capacity generation event to accelerate expansion on top of organic growth. The capacity-backed token will be directly linked to the usefulness of the services the federated networks provide to their users. It will be the mechanism of a self-amplifying virtuous cycle to drive sustainable growth in which organizations and users alike benefit from usage and the usefulness of the solution.

The result of our work will be a new kind of service with applications in many areas. This service will make blockchain an integral part of everyone's digital life. For the purpose of this white paper, we are focusing on the first essential step:

Authentic communication for email and documents.

02

Rationale

Our digital identity is an increasingly inseparable part of our lives. Digital is just as real as the real world. Yet when comparing the real world to the digital domain, most people and businesses today have far less digital control or protection than they would willingly accept in real life.

An overwhelming majority of people are currently living in an age of information feudalism. In exchange for not having to pay a fee, they have implicitly surrendered control over their data. Who has access to it? Does the communication remain private and authentic? Does their core identity remain safely in their own hands? Many have tried—and failed—to solve these problems for decades.

The challenges have remained unresolved for so long because they require user-centric solutions. The solutions must be technical, but also social, and they require a robust business angle in order to be sustainable. The technical evolution and understanding of the past 2-3 years combined with decades of experience in technology, regulation, law, and business has finally made it possible for us to build that better solution.

2.1 Keeping information safe

The state of the art gives us an excellent theoretical understanding of how to keep digital information safe and how to protect it against being surreptitiously modified, but we have consistently failed to make these benefits widely available. Virtually all successful uses of cryptography are by specialists working for enterprises.

Such systems are often centralized by design in order to drive the business interests of the solution provider. Cryptography is used, but only to serve the platform providers; the conflict between the WhatsApp founders and Facebook has demonstrated that this is also where it ends[1].

The remaining examples of using cryptography are often by people or organizations trying to change that situation for the common good. For the most part, those efforts have been struggling for decades to reach critical mass.

2.2 We have failed to secure email

The result of this failure is particularly evident in email, the most successful federated communication network ever built. Its traffic is largely unsigned and unencrypted and 48% of the 281 billion emails sent each day are spam[2]. This is also why email is such an effective vector for delivering malware. Recent statistics show that 92.4% of all malware is delivered via email and estimates the consequential economic damage to small and medium enterprises (SMEs) at $2.2 million per enterprise per year[3].

2.3 Qualified electronic signatures are possible - today

Making cryptography usable at scale would create enormous economic benefits for society. Governments have tried to promote and support this idea for decades and have managed to successfully provide the legal basis for qualified electronic signatures. The European Union fully enacted eIDAS in July 2016,[4] and Switzerland put ZertES[5] into effect back in December 2003. Nevertheless, due to the reasons outlined above and others, mass adoption is lagging without the proper technology required.

2.4 Users, not developers decide

Unfortunately, the ability to send and receive email in an authentic, secure, and verified way has never materialized for most users. Not because the technology does not exist, but because it is user-hostile and easy to misuse.[6] If the majority of people cannot use it, networking effects will see such technologies confined to small communities, lose touch with today's use of technology, and eventually slip into insignificance.

It is primarily user experience (UX) and user interface (UI) that have doomed existing approaches to failure. Sadly, this is not due to underestimating their importance. Ask any developer and they will agree usability is essential. Many will also be wise enough to realize they are not good at it.

Additionally, developers tend to seek the perfectly secure solution from a purely technical perspective, but technical design and human behavior are communicating vessels. User experience impact is real and immediate to the user. On the other hand, security is a much more abstract goal that translates into the absence of harm. In the long term, a concrete, actual pain will always win over an abstract, potential harm.

This is the fundamental issue behind the majority of security failures. Usability must be understood as one of the most critical mechanisms and designs in any secure system. Starting with passwords written on the infamous Post-it Notes all the way to virtually no one verifying that keys have not been falsified, no matter how simple it is being made for users to do so.

2.5 Total decentralization, self-hosting are dead ends

Many technologists find themselves inspired by the ideals of the Age of Enlightenment[7] and the Universal Declaration of Human Rights. Founded in this ideal is the idea of a sovereign human being who is capable of freely making informed decisions. Because our digital and physical selves are increasingly merging,[8] these ideals also naturally extend to our digital representation. Combined with a distrust of larger social structures and a personal affinity for technology, digital autarky by self-hosting and the paradigm of total decentralization looks like the perfect solution.

Unfortunately, both of these proposed solutions are based on flawed assumptions. The vast majority of all human beings lack the knowledge to self-host because their talents lie elsewhere, or perhaps they have chosen to pursue a different career. Even if they have the knowledge and technical background, they might still prefer to spend their time elsewhere. Whatever the reason, only a tiny fraction of that small minority has all of the inclination, time, and resources to self-host. The personal experience of our founders suggests it is predominantly males in the U.S. and Europe with a career in the IT industry, often ages 16-28 years, for whom self-hosting is a realistic and attractive scenario.

Total decentralization is a form of self-hosting that appears less technical at first, but is equally unrealistic. In order to make the experience more user friendly, most solutions and the major cryptocurrencies are based on a concept of cryptographically secured wallets.

As the Sovrin white paper explains, these can also be used for self-sovereign identity similar to what we are used to:[9] “In the physical world, we use the physical credentials in our wallet to prove our identity.” What happens if that wallet is lost? Digital wallets ultimately come down to a set of magic codes. If it's lost, so is the digital representation of the person. If they get into the wrong hands, so does their digital self.

Physical world wallets rarely contain all of an individual's personal information, assets, and wealth. In that case, the damage is limited, however, losing a digital wallet can easily compromise people on a much deeper level. Identity fraud is already a serious issue that affected 16.7 million people in the United States last year alone.[10] It also affects small and medium enterprises disproportionately. The physical world has means of recovering from this by allowing the victim to restore access and by preventing them from losing all assets associated with their wallet and identity. These means function independently of a person's ability to protect these magic codes throughout their entire life.

True believers in total decentralization will argue that the possibility of losing all control over one's assets is also a freedom and their right. This is a decision they can make for themselves. Most people have freely chosen, or would gladly choose, to live in a different world—one that includes safeguards, even if that meant there would not be perfect total decentralization.

2.6 A solution for the 99%

There is no shortage of far-reaching visions for the digital age. Those visions will remain unfulfilled until we solve the challenges outlined above in a secure, compliant, and user-friendly way. Until there is a widely adopted solution, e-government, the paperless office, and electronic legal transactions will remain in today's state of infancy.

Recent surveys show a majority of people want more control over their data.[11] Nevertheless, asking them to use technology designed for the—sometimes rightfully—paranoid and encouraging them to self-host everything is a lot like a modern-day version of Marie Antoinette's adage, “let them eat cake.” They can't, and they should not have to.

Vereign was based on the premise of creating a solution that offers digital sovereignty and privacy for everyone without a strict requirement for self-hosting or total decentralization. We combine usability, convenience, modern cryptography, and proven social structures. The result is a service that is ultimately user controlled, transparent, and available to all.

03

The User Solution

Different users have different priorities, but there are common denominators. For the purpose of this paper, we will make a distinction between users in a professional capacity and users acting as private persons. We will also differentiate between public authorities and private businesses.

For all of these users, our solution will add a layer of social interaction and authenticity that puts an end to phishing, fraud and spam, and allows people to know their messages have reached the intended recipient.

3.1 Social mail

Chat is interactive and typically uses mobile phone numbers for identity. Both make it easier for people to establish authenticity. Once someone has successfully interacted with a person a few times at a specific number, especially if they have spoken to them through voice calls, they've built confidence in the fact that this is their contact's phone number. The double ticks for sending, receiving, and reading give visual clues of interaction between the users and further builds confidence in speaking with the right person.

Vereign adds the same level of interactivity and social responsiveness to email. For users, this means adding the double check marks to an email for sending, receiving, and reading an email. It also allows adding proof of a verified mobile phone number to the sender records. With regards to authenticity, the status of the message over time can be verified by the participants in any exchange on any of their devices and over the web.

3.2 Registered Mail 2.0

Social authenticity is not always easily established or sufficiently useful, especially when the communication is infrequent, impersonal, or with higher stakes like a business deal for a large sum of money. These examples are typical patterns found in professional communication. People would prefer to add more authenticity, ideally via third-party confirmation in these types of cases. A commercial registry confirmation for the company, accompanied with sign off on general financial good standing by a rating agency, go a long way toward establishing trust in authenticity. When combined with a confirmation by a third party that this person is real and truly empowered to speak on behalf of the company, trust in any kind of communication increases dramatically.

For an even greater level of confidence, we've added the ability to verify that the message has not been modified by a third party while it was in transit to the recipient or after it arrived on their mail server, and the ability to ensure that the message is only read by the intended recipient with message privacy guaranteed.

These additions would make email a lot more interactive and social for everyone, virtually eliminate spam, and dramatically reduce fraud and malware. They would also make email much more useful for the professional business world. Qualified electronic signatures on demand would give email full recognition by governments and the legal system in a way that integrates seamlessly into the existing email workflow. This set of functionalities is what we call “Registered Mail 2.0.”

While physically registered mail only allows proving someone sent an envelope to an address on a certain date, Registered Mail 2.0 allows proving, in a legally recognized fashion, who sent what, when it was sent, when it was received by the recipient's mail server, when it was delivered to the recipient, and when the recipient read it.

The last two confirmations require that the recipient and their system participate in this authenticity framework. If their participation is not possible, even simply being able to prove the content of what was sent, when it was sent, by whom, and to whom it was sent are dramatic improvements—especially when combined with the speed and convenience of email at a substantially reduced cost compared to the traditional postal service. There is nothing currently comparable, although a few of these effects could be achieved or emulated by existing technologies and a well-run IT department.

3.3 For personal users, SMEs, and large corporates

Big and well-equipped IT departments are typically not what most people have at their disposal, and the required overhead for small and medium businesses can be prohibitive. For those who do enjoy this luxury, the world is getting ever more complex and diversified, and the reach of corporate IT departments typically ends at the border of their own systems.

Upgrading to the Vereign solution will benefit a range of users, from individual citizens through one-person companies to medium-sized businesses. Such a solution can also be extremely useful for large corporations where they depend on confidential communication with parties outside their own corporate domains. For example, imagine sending medical data in a way that it will reach its intended recipient, and its intended recipient only. It's the long-needed upgrade to email consumers and SMEs have been waiting for.

It also opens the door to a “postal forwarding service” where an email sent to an address someone held three years ago can still arrive. For the first time, people will truly own their email addresses in much the same way as how they can keep their mobile phone numbers when switching between cell providers.

3.4 Documents

Email and documents are tightly integrated. Often email is the coordination and communication layer for a document not unlike a cover letter. Documents could be the results of email conversations. Just as with registered mail, documents often contain most relevant information. Seamlessly integrating email and documents will make the whole approach more intuitive and useful, particularly when consistent levels of authenticity can be used between them.

For users of Vereign, this means documents could be created in a collaborative fashion where sign off can happen on different versions as part of a workflow, and the final result could be approved by all relevant participants. Contracts can be reviewed, edited, and signed with businesses directly and online. Bringing both together, across platforms and providers, also allows users to keep a personal archive of all their most important interactions.

3.5 The archive

Keeping a record of all essential documents and conversations can be cumbersome and hard to maintain. It is an ongoing effort made more difficult by changing providers or jobs, moving houses, or by a criminal break-in. In the physical world, some people use banks or notaries to store originals of value. The digital world has had no sensible equivalent to date. Add to that the various contracts, terms, and other documents everyone should be storing even though most do not.

The solution Vereign is proposing integrates the ability to keep an archive of conversations, documents, and digital assets independently and under user control. It provides a place where essential documents can be stored with embedded notary testimony to verify that the digital version is a true representation of the real document.

For companies, the archive fulfills all mandatory, tamper-proof archival requirements, and automatically enforces data retention rules through smart contracts. These rules vary depending on what is being stored, applicable jurisdiction, and national legislation. For example, in Germany that would include ten years of retention for invoices and six years for business correspondence. Even large companies struggle to fully comply with these types of legal requirements.

3.6 Data protection

More importantly for businesses, the European Union General Data Protection Regulation (GDPR) mandates deletion of customer data as soon as none of the justifications of Article 6 of the GDPR are demonstrable.[12] Specifically, a company must be able to erase personal data after mandatory retention periods are over. The fines for non-compliance are substantial.[13] Compliance with these rules is already a major undertaking for large corporations which are currently scrambling to somehow mitigate the associated risks. Compliance is also mandatory for small and medium enterprises, and they have even bigger problems following the requirements—partly due to a lack of resources and partly due to a lack of effective technical solutions.

This is where the solution offered by Vereign becomes crucial. Our strong background in the legal field has allowed us to take these requirements into account and incorporate them into our system seamlessly and naturally from the onset. For the user, this is as simple as using the tagging system to structure data in an extensible and familiar way. By doing so, professional users will implicitly set both retention and data protection rules.

3.7 Intuitive and natural

Passwords have become an anachronism—hard to remember, easy to lose, and often mishandled. Passphrases and seemingly-random natural words thrown together are better, but if users are expected to type them more than once a day on a mobile keyboard, we might as well realize they simply won't be used. We considered it a challenge to find a better way.

In our systems, users have authorized devices and applications being administrated from existing devices where all critical transactions must be confirmed with a second device, typically the mobile phone. Adding devices, removing them, and approving transactions all follow the same simple and elegant workflow based on QR codes.

Consider someone working on a document at an internet café. They activate the application temporarily and scan the QR code the application shows them with their authenticated mobile phone. They can then get to work. Once finished, they sign and archive the document using Vereign, authenticating the upload with another scan of a QR code. The mobile phone now brings up a request for confirmation showing them all the essential data of the transaction. They confirm this on mobile. They can then deactivate the application and log out. It's that simple.

This is made possible by the use of key-based authentication where every device and application have multiple keys, and those keys are uniquely associated with accounts. However, the complexity of key management doesn't fall to the user. Again, we have found an elegant solution.

3.8 Profiles

In the physical world, people have documents that verify certain information about them, such as driving licenses, ID cards, and passports. Because this is a familiar concept, we borrowed the term to describe our own concept of the Vereign profile.

A user can have any number of profiles for any number of applications. Each can contain a lot or a little information about them including name, address, mobile phone number, bank details, birth date, ID card number, etc. Profiles can be thought of as windows into the personal information defined by the user with obfuscation provided via privacy-protecting zero-knowledge proofs[14] where desired.

Users would, for instance, create one profile for their social media interaction, one for their preferred services, one for their business associates, and another one for their interaction with the government. Each profile represents an entirely separate set of keys that will be used in its nominated transactions, and selection of each profile is an implicit selection of the right set of keys to use.

Even non-technical people can utilize this kind of system intuitively. This allows users to finally take advantage of the security and privacy enhancing capabilities of key-based authentication, a virtually unlimited number of individual keys for signatures and encryption, and the privacy protecting capabilities of zero-knowledge proofs.

3.9 Social roster

The second function of the profiles in this approach is to allow users to connect with one another. Everyone has people they trust to some extent and who they interact with repeatedly. Because authenticity, signature, and encryption of email and documents are tied to profiles, the usage of the system automatically creates a kind of social roster.

This roster is under the user's control, and the person sharing the information is in charge of what kind of information to share with whom. Because of the dynamic nature of the profiles, with keys created on demand and rotated when required, the result for the users is like an address book with relevant contacts that is updated by the contacts themselves.

This solves the challenge of having to inform third parties of changes in mobile phone numbers, emails, or physical addresses. It is like a self-updating address book that can be imported into all the user's regular devices and applications.

3.10 Business contacts

This function will increase in value exponentially with every additional company supporting the system. The repetitive and boring task of having to enter personal data into a web form will eventually disappear. Instead, a user might say, “allow this airline to see my travel profile,” and the profile is set up to contain name, gender, birth date, birth place, passport ID, and visa status.

Companies gain access to a client-maintained and often third-party verified data base of required user information with built-in data protection and mandatory retention rules. Besides reducing inherent compliance risks, this approach also guarantees higher quality and data that's more up to date. It will also make interaction with the customer much more seamless. The resulting increase in people's satisfaction with this level of service will in turn translate into more users utilizing the service.

Data sharing is controlled by the user, and is approved when the user shares a specific profile. Should the user later decide to deny access, access for this profile can be revoked which immediately ends the data sharing. At the same time, there are situations where mandatory retention periods and legitimate business interests must be protected. In this situation, the solution stops providing automatic updates and it retains the latest state of shared data because the user has no right to delete data in the domain of the data recipient. Only once the retention period ends will the data be fully removed from the company records.

3.11 Wherever you already are

We strongly believe in usability and convenience. There should be no need for anyone to migrate. We want to provide a new service that every existing provider can embrace, and this is reflected in our technology and business models. We have consciously chosen not to become an email, document software, or file storage provider. Instead, our solution is developed to reach the user where they are today.

Our in-app strategy achieves this by embedding access to our solution into existing services. Starting with the most commonly used email providers, the second step will include integrating into LibreOffice (for the desktop and online) for document users. Users of these services and applications will be able to either install a simple plugin, or simply find the capability enabled by their provider when they log in.

Gmail currently has 1.4 billion users[15] and Roundcube is the most popular Open Source webmail solution with an estimated 100 million users. According to Michael Meeks, vice-chairman of The Document Foundation (TDF) and Vereign advisory board member, LibreOffice has 200+ million users. Integration with Gmail, Roundcube, and LibreOffice will make the function available for up to 1.7 billion users in total. Support for Office365 is targeted next which will add another 120 million business users,[16] bringing the total reach to an estimated 1.9 billion users within the first 12 months. Once the solution is fully deployed, it will be immediately available to almost 2 billion users worldwide.

Even if a provider were slow to adopt the solution, people would still be able to use it immediately. Recipients of messages and documents will be able to verify the authenticity and integrity via a web gateway. Users sending email from clients or platforms that do not support the system yet can use a workflow based on configuring their Simple Message Transfer Protocol (SMTP)[17] server to send via the Vereign network, or use blind carbon copy (BCC)—a method that is easy and intuitive to use for anyone.

04

The Technical Solution

Our system builds upon various Open Source communities, such as LibreOffice, Roundcube, Hyperledger, and of course all the basic technologies we have come to rely upon like the Linux kernel.

For all these communities it is our goal to become active contributors and good citizens. We have committed to release all our own technologies as open source under a license approved by the Open Source Initiative (OSI)[18] and the Free Software Foundation (FSF).[19]

Where we are entering uncharted waters, such as with our email authenticity layer based on distributed ledger technologies (DLT)/blockchain, we will work with all interested parties to turn these solutions into an independent standard, preferably in the form of a Request for Comments (RFCs) published by the Internet Engineering Task Force (IETF).

As explained in the Social Solution section below, Vereign has no intention of being the party running the solution. We consider ourselves to be the catalyzing force to bring the solution into reality. We also intend to play a constructive role in the further development, improvement, and support of the technology as it is being deployed worldwide.

Our commitment to “open, always” is based on our understanding that trust requires transparency. Following Kerckhoffs's principle,[20] we do not rely on conceptual secrecy for security. The most secure solutions and algorithms withstand peer review. Also, we are driven by the desire to turn this technology into an open, flourishing ecosystem with follow-up innovation for decades to come.

4.1 Technology stack

All of the above has informed our technical choices. Avoiding single points of failure must start at the platform level. Given the aggressive assertion of U.S. law onto companies with activity in the U.S.[21] and the various governments forcing cloud providers to provide them with access to data, each cloud provider—regardless of the individual corporate structure—must be considered a single instance. Keeping this in mind, we began our selection process at the hardware level.

The OpenPOWER Foundation[22] has become a vibrant ecosystem of hardware innovation with a special focus on high performance and strong cryptography. It allows offloading cryptographic operations to dedicated hardware in a more efficient way than the x86 architecture and provides the potential to support preferences for pluggable hardware modules that may be driven by national technical choices. More importantly, the OpenPOWER specifications allow for full verification of the CPU, firmware, and all components in a server. This makes it a great choice for both security and performance.

The operating system is one of the EAL4+ certified systems based on the Linux kernel—either Red Hat Enterprise Linux (RHEL) or SUSE Linux Enterprise (SLE). Development began on RHEL, but both platforms are similar enough that the choice can be updated if required. As we have chosen a microservice architecture with gRPC,[23] our deployment model was based on Docker and OpenSHIFT from the start. This should always allow the application and its components to run easily on any modern cloud platform.

Our default language on the server side is Golang, and we made this choice based on a variety of parameters. There is full support for advanced cryptography on OpenPOWER hardware. Golang has a rich environment of libraries and applications allowing us to join existing communities, and its parallel processing capabilities are excellent. Other important considerations were how fast and efficient, much more modern, and safer it is to use for security purposes than languages like C or C++. Where the ecosystem suggests usage of a C/C++ technology family, we will be using C++14 for its better security characteristics. Lastly, JavaScript is also used along with Golang for Hyperledger Fabric, which forms an essential part of our stack. So Golang, JavaScript, and C++14 are the most important languages used.

We would also be interested in exploring which of the public blockchains could be a good fit for adoption. Just as we have no opinion on a particular solution used as the message transfer agent (MTA),[24] we are ultimately blockchain agnostic. Hyperledger was chosen because it works, it is being developed in a well-structured Open Source community, and has involvement from institutional participants who understand issues of compliance and governance. However, with the rapid evolution in public blockchains, we believe there will be further platforms which we will likely ought to consider. On the client side we will still focus on developing with JavaScript and ReactJS for web and mobile. We're also building our client side's VIAM authentication library in JavaScript and C++14 which allows it to be reused across all clients.

We're following an Agile approach in development. We also built code reviews, quality assurance, unit testing, and continuous integration into our team and workflow from the start.

4.2 Feedback and contribution welcome

To specify all the components of our solution in detail would go far beyond the scope of this already fairly extensive white paper, but the following sections will highlight a few of the most relevant considerations and designs for its functionality. While all the solutions are feasible and have largely been tested within our proof of concept, we expect that the system design can and will be improved further.

For more detail, please feel free to visit our website at https://vereign.com, and sign up to our GitLab instance at https://code.vereign.com where our code and documentation is being built as we move toward production readiness.

As mentioned above, there are many details in the decisions made for this solution, some of which we are still testing and which may be modified. Should you have input for us as to what we could do differently, why, and how, it would be most welcome. We would love to hear your input in how to improve our concept further and are eager to engage in discussions with you at https://community.vereign.com.

Right now, this is a new, legacy-free field. You are officially invited to shape it together with us.

4.3 Authenticity and identity

Authenticity begins with identity. Signatures are worthless unless it is clear whose they are. The origin of a message forms an essential part of its content. Information to be shared requires a recipient. Identity is at the root of all these challenges.

Distributed ledger technologies (DLT), most famously the blockchain, have brought new life to these questions. Frameworks like Sovrin have laid the theoretical foundations for an exciting world of protecting privacy for one's identity. Simultaneously, the democratic process has finally caught up with the fundamental question of data ownership. The EU General Data Protection Regulation (GDPR) creates a whole new requirement to restructure the relationships between corporations and their customers.

4.4 Blockchain and GDPR

While some goals of both mega trends may be similar, there has been substantial controversy as to whether it is possible to marry blockchain technology and the requirements of GDPR. The function of DLT is to create a distributed, immutable, eternal ledger. GDPR establishes a right over personal data that includes—among other things—a right to be forgotten. This mandates a strong principle for system design: Because even encrypted personal data is still personally identifiable information (PII), personal data does not belong on a distributed ledger.

Permissioned and private blockchains are presented at times as the solution for some of the most mature projects in this field. In reality, substantial concerns remain over the storage of personal information on any kind of blockchain. Even within the scope of enterprise data processing agreements, system designers are well advised to avoid putting personal data of any kind on a blockchain.

Another rather promising approach to date is to store encrypted and obfuscated information, particularly related to so-called “zero-knowledge proofs” (ZKPs).[25]

Traditionally, a ZKP is a form of interactive proof system[26] where one party can prove knowledge of certain information to another party without revealing the information itself. Of all the cryptographic developments of the past years, ZKPs are probably among the most exciting and most closely resembling magic. Unfortunately, they are not trivial to understand or explain, so we're allowing ourselves to refer to the well-written blog posts by Matthew Green in his white paper.[27]

In the context of blockchain, people often speak about ZKPs in the context of non-interactive zero-knowledge proofs,[28] specifically so-called zk-SNARKs introduced by Zcash and also adopted by Ethereum.[29] These “Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge” (zk-SNARKs) use the specific properties of homomorphic encryption, an encryption technology where an operation on the encrypted data yields the same result as operation on the plain data.

In the context of the IBM Identity Mixer concept,[30] also adopted by the Sovrin framework, it is used in a third-party verification process where the answers to certain predetermined questions (e.g., “Is the person behind this anonymous person 18 years or older?”) are encoded into values and confirmed by a trusted third party. That confirmed value can then be verified by virtue of homomorphic encryption.

The driving motivation behind these concepts is better protection of user privacy. With this technology, even anonymous users can prove they are of a certain age without revealing their birth date. The possibilities are still restrained by the performance of homomorphic encryption, which is somewhat limited, but the implications are vast.

4.5 Usage of zero-knowledge proofs

Our team is closely following and staying up to date on the rapidly evolving zero-knowledge proofs along with our technical partners at IBM and elsewhere. Our goal is to ensure that users can apply their verified identities as source material for zero-knowledge proofs anywhere.

We are pushing these boundaries toward the integration of more complex interactive zero-knowledge proofs. This would allow users to prove they are within a certain geographical area without revealing their actual GPS coordinates. This dramatically increases the usefulness of the zero-knowledge concept and allows much more interesting applications to be built on top of the framework.

4.6 Storing identity data

Identity information will need to be stored somewhere, but that “somewhere” should not be on the blockchain. In some concepts, storage is provided by proprietary applications under the control of a single vendor. Even when that happens on a user-owned device, the data is controlled by the application vendor. For others, these are traditional, centralized identity management systems or user-held wallets. Neither is ideal, and both fall short of truly allowing people to own and control their own identity through the gaps discussed above. For Vereign, these gaps are critical and had to be addressed.

4.7 Vereign Identity and Access Management (VIAM)

Traditional identity and access management systems are hierarchical and tree based. The most common and well known of these is the Lightweight Directory Access Protocol (LDAP), which is also the underlying foundation for products such as the Microsoft Active Directory. As the old adage goes, sometimes it is no longer possible to see the forest for the trees.

Trees have proven poor representations of structures made up of human beings, but they were the best available solution when these systems were originally designed decades ago. In reality, we form a mesh of relationships around us. We are students, employees, business owners, family members—all at the same time. The mathematical and technical representation for such a mesh of relationships is that of a graph.

Also, building systems that need to be all-encompassing and monolithic in a single instance is a recipe for disaster. If there is no flexibility, no ability to adapt, no chance to compensate for failure, including at an organizational level, the whole system is doomed from the start. Federation, or the ability to have many networks within which users can migrate freely, is another essential requirement for any system we would be willing to trust.

Trust is a function of security. In an age of overstated security claims and false promises of technology, trust is hard to achieve.

The first obvious step is to not reinvent cryptography and to only use proven, known technologies that the best experts of today agree are likely secure. Bear in mind it's not usually the cryptography that is broken—it is the application. Only a complete dedication to open source and the guaranteed right for anyone to audit, modify, and reuse can be the basis for a secure system.

Based on these principles, the Vereigners initially referred to the “VIAM challenge” as “building the world's first Federated,[31] open source, graph-based identity and access management.” This system should use strong end-to-end cryptography (E2EE) for user data wherever possible and provide an immutable audit trail for its users across all the federated instances using blockchain. For authentication it should provide a simple, intuitive, key-based authentication scheme. Data should be made available via decentralized identifier (DID)[32] documents on the blockchain used also for identity systems that are designed to strongly protect user privacy, Sovrin included. These resolve to documents that define cryptographic material and definition of authentication suites, along with one or more service endpoints that allow trusted interaction with users' digital identities.

For instant notifications on user interactions and requests, we will use the Linked Data Notifications[33] specification of the W3C. We also want this system to support more traditional protocols like SCIM[34] and OAuth 2.0,[35] which will make this identity immediately usable by a large number of existing services and platforms even if some of them may end up switching to DLT-based approaches in the future.

4.8 Key management

Key management is one of the hardest challenges to resolve, and possibly the most crucial to the security of the Vereign solution. In order to enable key-based authentication, each device and each application will become part of the key management workflow. For end-to-end cryptography to be meaningful, we will need asymmetric, public key cryptography with keys generated locally on the device or within the application. Otherwise, keys can become compromised during generation or transmission to the client.

Each device or application will therefore generate its own authentication key as a private/public key pair. Activation of a device for a user translates into registration of this public authentication key with the server. When the server issues a challenge to the application encrypted for the authentication key, the application can decrypt the challenge and sign the response with its authentication key to relay it back to the server, encrypted with the server's public key. This way the application can later authenticate itself securely against the server.

We also need to keep large volumes of data on the server in encrypted fashion for multiple identities. Because asymmetric encryption is comparatively resource intensive, the traditional solution employed for email uses symmetric key encryption for the actual message and encrypts only the symmetric key itself, typically referred to as a session key, with public key encryption. Taking this approach also provides advantages for our storage system which needs to keep fewer copies of the objects. All session keys are unique. Even if an adversary gained access to an object's session key, they gain access only to this one object, and would not automatically compromise the entire storage.

In addition to the authentication key, each device generates its own encryption key. Because the session keys of the objects must be encrypted for each device encryption key, addition or subtraction of devices translates into the need for re-encryption of the session key for a new set of devices. Typically, the session key is re-encrypted for (old keys+1) or (old keys-1), but occasionally, e.g., on full regeneration to secure a potentially compromised user, or on adding or subtracting another user with a bundle of devices, the new set of keys may be substantially different. In any case, re-encryption will be a comparatively frequent event.

In most cases, re-encryption of the session key on the devices themselves would be ideal, but might be too resource expensive for some commonly used devices. In other cases, a device may be less trustworthy than the server. A typical example would be an internet cafe or similar location where the platform is even less trusted than usual. Or, it could be a situation where the user devices are suspected to have been compromised and they require a full re-encryption to lock out the compromised devices. The other case where this is not possible is if the user has lost all access to their devices because they have been rendered nonoperational. In such cases, we must support a scenario for restoring access without relying on the user's technical competency and allow third-party assistance.

Based on the scenarios above, we have decided to use a server-side hardware security module (HSM) as part of a re-encryption microservice that will handle the re-encryption of all session keys. This service is in the blocking path for many critical operations and must be well protected, and running on dedicated hardware using SVM power technology.[36] It will be the only part of the system communicating with the HSM and must be isolated from the rest of the network and the internet.

Besides the authentication key pair, which is never used outside the system, each device or client must also have a private/public key pair for each individual profile the user has defined or has access to, e.g., for an organization the user represents. These profile keys are used for signing emails or documents and are therefore public. Having a different key for each profile is required because we do not want to make it possible to correlate profile signatures against one another.

Each profile will have a server-side private/public key pair that is used to sign the profile keys on users' devices.

The profiles themselves establish DID documents on the blockchain, which include a certificate revocation list (CRL), and allow identification of signatures made by stolen, lost, or compromised devices.

The entire process of signing an email or document is therefore a process involving multiple keys. Initially, the device authenticates against the server with the authentication key. The email or document is then signed with the private profile key the user has selected on the device or application. Then it is uploaded to the server. Optionally, the server requests approval from one of the other registered devices of the user. Usage of the authentication key from that device provides sufficient authorization to super-sign the email or document with the server-side profile private key. For archival, the object is then encrypted with a newly generated session key and stored. At the same time, the session key is encrypted for all the public authentication keys of all the devices involved in this email conversation or document.

For the asymmetric encryption we have two established, common schemes to choose from. We chose X.509[37] because it is preferred by virtually all governments in the world. This is particularly important because Europe and Switzerland have agreed on CAdES, XAdES, and PAdES[38] as their technical standards for the eIDAS and ZertES laws. These establish legally binding qualified electronic signatures that are equivalent to paper-based signatures and accepted across the entire EU and Switzerland, as well as being recognized in Asia and Latin America. The United States has its own framework, but again chose X.509 for cryptography.

This is why all asymmetric keys in the system will be X.509 based. This decision also influenced our choices for cryptography libraries and primitives. We plan to go with modern, strong ciphers with Ed25519/Curve25519 as our preference for asymmetric encryption. Unfortunately, these are still in the process of being added to X.509[39] and are likely not yet fully supported in many clients.

Our preferred choice for a cryptographic library would be libsodium.[40] This library is actively maintained, used by many security conscious and relevant projects, and has received independent security review.[41] It fully supports Ed25519/Curve25519 and XSalsa20/Poly1305, which we would like to use for symmetric keys along with BLAKE2b for a modern, secure hashing algorithm. Since it does not yet support X.509 certificate handling, we plan to extend PKI.js[42] to use libsodium for its crypto algorithms.

In order to run the code quickly and with reasonable security for the proof of concept, we made the decision to start with PKI.js and the native browser support for WebCrypto[43] with ECDHE for asymmetric encryption which has been commonly used with X.509 for a long time. For symmetric encryption we will start out with AES-GCM, and use SHA-512/256 for hashing. Since IE11 currently does not support WebCrypto natively, we will fall back on the RSA-Sign JavaScript Library[44] for the moment.

We will revisit this once Ed25519/Curve25519 has been added to X.509.

In order to facilitate all of the above, we have decided to provide a library that will take care of key management and authentication in JavaScript and C++14, which has better security properties than C++ and can be added to a variety of solutions without unnecessarily inflating the build dependencies. This will make the library easy to integrate into any client application and ensure consistency across them all for developers of third-party apps.

4.9 Message signing, encryption, and status on the blockchain

Out-of-band status signaling and recording for email in combination with making, signing, and encryption [user-friendly and ready for mass adoption] is key to achieving the user benefits outlined above. Based on identity and key management, we can create a beneficial design for both.

Because it is essential that the solution for signing and encryption is maximally compatible with all standards and existing email clients, a choice for X.509 as encryption technology suggests usage of S/MIME[45] for email signatures and encryption. This standard is actively developed and maintained by the Internet Engineering Task Force (IETF) and updated regularly.[46] The publication of EFAIL[47] earlier this year mandates another update at protocol level that looks like it is going to break compatibility for legacy clients. We have established contact with the group that has discovered this vulnerability and agreed to stay in touch to implement the fixes in a timely fashion. Ideally this would fall into the same update window as introduction of Ed25519/Curve25519 for X.509.

4.9.1 Alternatives considered

We made the choice for S/MIME because it is based on the cryptographic standards adopted by governments for qualified electronic signatures. For this reason, it is likely also the approach with more mainstream adoption. OpenPGP has been the champion of the Open Source community for decades. But in all that time fewer than 5.5 million keys have ever been published,[48] which suggests an active user base for OpenPGP of 500,000 people at most. Even if one assumed that for each user that published their key there is one that kept it private, there is no critical mass and no realistic potential for support by legislation.

We also considered taking an even more radical approach which could include perfect forward secrecy (PFS)[49] as Matthew Green[50] or Moxie Marlinspike[51] have suggested. Given its function for providing one-time keys upon demand, PFS for email should be possible in a user-friendly, scalable way. At a business level, having secured applicable retention periods of business correspondence for an audit might be a real challenge, and even private people are often more concerned about how to find that one important email they sent four years ago. Reconciling these with PFS may require some more thinking.

Of all the proposals we have come across, the simple messaging and identity management protocol (SMIMP)[52] comes closest to our vision. It is a clean, RESTful protocol proposal which for the same reasons we outlined above replaces identity management and also chose key-based authentication. It takes some obvious inspiration from blockchain, but without the distribution—including proposing “Proof of Work” to receive email from a third party.

However, it is a proposal that, in order to succeed, must replace the world's largest, most successful federated messaging system because it is entirely incompatible with email.

While SMIMP managed to build on PFS, its answer for the business and professional use cases is essentially the creation of a corporate key management solution not unlike today's certification authorities. It is unclear what benefits to businesses, if any, should offset the dramatic cost of adoption of the system caused by the deep integration of email with workflows of all kinds.

The concept also raises questions about its compatibility with the General Data Protection Regulation (GDPR) as it provides personal data on public URLs. If the proof of work concept truly gets scaled to 281 billion messages per day, it might make the energy usage of Bitcoin seem insignificant by comparison. All of these may be reasons why the proposal has not been updated since 2016. The question of legal relevance and qualified electronic signatures remains for this and all other approaches.

This is why we chose to go with an approach that is fully compatible with email, uses modern concepts, and combines them with technologies mandated by the law for legally binding, qualified electronic signatures. The resulting system allows for a frictionless update of the existing infrastructure. At the same time, it is far superior to many of the current, often broken, attempts to achieve qualified electronic signatures and reliability for email.

Further improving this is a process we are looking forward to. Use of one-time keys would, for instance, allow adding capabilities for PFS encryption similar to the approach chosen by SMIMP for private users. This is an invitation to get involved and work with us on the next steps in the conceptual evolution. We are committed to making and implementing them.

4.9.2 Email signaling on the blockchain

In its simplest form, a single message hash stored on the blockchain by the sender, together with the message ID, could very likely replace signed email in a format much simpler than that of S/MIME. This approach would not lend itself to encryption easily, nor would it have some of the other benefits, and, unlike S/MIME, existing email applications would not support it.

By using profile certificates for signature in S/MIME, we can build part of the authenticity naturally into signed email through an existing standard supporting encryption. There are multiple steps in the relaying of an email where status messages can be written to the blockchain. Steps during which signaling can be added include when the message is sent by the user, when it is relayed by the user's message transfer agent (MTA), when it is received by the recipient's MTA, when it is delivered to the user's mailbox, and when it is read by the recipient.

All applications involved in the handling of the email message should be able to update the message status. From a privacy and security perspective, only these applications should be able to do so. The only thing that can be assumed for all of them is that they will have a copy of the email at some point. Possession of the email should therefore make it possible to locate the advanced notification properties on the blockchain. However, data written to the blockchain must always be encrypted in such a way that it is impossible to trawl the blockchain for data.

The required level of encryption is dictated by the actual data written to the blockchain. Information that is also present in the (possibly encrypted) email can safely be written using a symmetric key based on the email body itself. That way, in order to decrypt successfully, a party must already have access to the data it is trying to confirm. Everything that is part of an email header falls into this category. For the PoC—which is not yet targeting encryption—we will also use this same key for individual status information such as “has read,” in order to test the concept. In the future, this could utilize individual key management for encryption keys from VIAM.

The blockchain identifier of an email (BCID) will be a hash of a serialized JSON array composed of From, To, Subject, Message ID, and MIME boundary. Message-IDs and MIME boundaries are randomly generated by the email application of the sender, salting the hash to make it harder to break by brute force. The blockchain session key (BC-KEY) of an email will be a symmetric key generated from the hashed message body. For an encrypted email, with the body in its encrypted state will be used for key generation.

This method works regardless of the message format, and allows it to be deployed for any kind of email system. Even messages that are not S/MIME can take advantage of this approach

The signaling information (BC-DATA) will be a serialized JSON array of its properties, encrypted with BC-KEY, and written to the blockchain with a key value pair BCID:BC-DATA. The identity mixer of Hyperledger[53] can privacy protect individual transactions on the blockchain. The transaction is written to the blockchain with the identity mixed corresponding profile entities of the users. Applications such as message transfer agents (MTA) are assets associated with the organization. These applications can therefore transact on the blockchain with the identity mixer using the profiles of the organization.

The signaling information must always include the log from the email being sent and provide evidence of the email having been successfully transmitted to the next step in the transmission chain. This information must include information about the Date/Time, TLS/SSL certificate presented by the counter-party, corresponding DNSSEC/DANE status, and status responses from the receiving server. None of this information is Personally Identifiable Information (PII).

For the final step of reading the message, the recipients may also choose to provide a quick response in the form of a set of emoticons offered by the client. A quick response, or even just the confirmation that a certain recipient has read an email, must be classified as PII. That is why this status message must contain only a link to a service endpoint of a decentralized identifier (DID). The service endpoint will only provide further information, and quick feedback, in response to authentication by the user requesting access to this information. For our system, these service endpoints will be linked to the profiles. Whenever access to the profile is revoked by the user, so is access to the identity information for the “having read” confirmation. This cuts the tie to the PII.

Signaling information may include a smart contract field which can point to a smart contract on the blockchain that manages economic or other properties related to the transmission of the message, e.g., payment offered for receipt or reading. This field will be used in the future to model any kind of advanced smart contract execution and signaling into an email workflow.

Future versions of signaling information may also include a “next key” property by the corresponding party. This way parties can specify the next public key to be used for encryption for the follow-up message. This could become part of a key exchange mechanism between parties involved in a conversation. It could also be a future enhancement to enable PFS for encrypted email.

Signaling information may be written to the blockchain for none of the steps, some of the steps, or all of them. The system will always work as expected and provide the information it has.

Any regular participant in the message exchange (sender or recipients), can use the message itself to unlock this information.

This will also work on service web pages offered by networks running the solution, making the experience seamless, and providing a convenient way to access this information for clients where this functionality is not yet fully integrated.

Since an adversary knows the algorithms behind both BC-ID and BC-KEY, using selected headers for the one and the message body for the other makes it a requirement to have the entire email in possession to both find a message on the blockchain and confirm the meta information stored for it.

Usage of the message body hash for BC-KEY also serves as tamper-proofing for the message body. Any change to the message body would result in subsequent signaling messages written to the blockchain using a different key other than the original one. This is easily detected by any client, should be treated as an indicator of foul play, and alert the user accordingly. Likewise, possessing only parts of the message body would not allow generation of the correct key.

Parties that have illegitimately obtained a complete and intact copy of the message would also have access to this information. If the message was lost at the recipient end, it would already include the “Received:” headers, which contain all the PII that can be obtained from the blockchain.

These parties would be able to verify that those lines have not been tampered with and potentially gain additional insight into the information they already have. The only additional, not yet received, information that might be revealed in such a case would be links to any smart contract and/or the quick feedback emoticon from the recipient(s).

The smart contract information should therefore itself be identity protected by an identity mixer or similar technology. While this would allow a 1:1 link between an executed smart contract and a particular message, it should not enable tracking it back to other transactions or messages.

If the message content has been encrypted, this information would not empower an adversary to break that encryption. We consider this a sufficiently workable and robust approach to take, but we look forward to feedback on things we might have missed and how to further improve the approach.

4.10 Documents

Seamless integration into the document workflow requires integration into the actual document editors. Traditionally based on desktops, this is now moving to the web with collaborative editing capabilities. LibreOffice[54] is the most mature, most widely spread Open Source application that serves both use cases. Vereign has partnered with Collabora, the company that provides professional LibreOffice support and has put LibreOffice online in the cloud,[55] to bring native integration of signing and archiving into LibreOffice in all versions. Due to the principles shared by both companies, the entire integration will be contributed upstream as open source, making the capabilities available to all users of LibreOffice.

The integration will allow users to activate LibreOffice as a client via a QR code. Selecting the right profile will choose the correct key to sign the documents and upload them into the archive. Because LibreOffice uses WebDAV[56] on the desktop and WOPI[57] on the server side for file transfer, we have added services for both. This way a user can utilize the signing and archiving in any desktop or web instance of LibreOffice—including in-file sync and shared solutions such as Nextcloud[58] or ownCloud.[59]

4.10.1 Document publication

With the exception of public mailing lists, email is typically intended for its participants only. Documents on the other hand are quite regularly intended for publication. One problem that is often overlooked is the fact that even if authenticity and signature are confirmed on the blockchain, they are worthless without an actual copy of the document itself.

The InterPlanetary File System (IPFS)[60] is one of the most exciting technical innovations for the distributed web within recent years. It establishes a worldwide peer-to-peer storage protocol in which any node has access to the same global address space and exchanges data to allow retrieval of any object locally. Anything published to IPFS may be cached in one, several, or even all nodes. It is impossible to forcefully remove data from IPFS, and data migrates to where it is most often used. IPFS is many things, including a global, peer-to-peer content delivery network (CDN).

All these properties led us to choose IPFS for the publication of signed documents from within the storage system. This makes them globally available instantaneously with signatures on the blockchain for verification and secured identity. Because IPFS gives no guarantee that data won't be lost if it isn't requested frequently enough, our system will keep a local copy for as long as the user wishes to continue seeding the publication. Our storage system will continue serving documents up to the global IPFS network for distribution and verification as long as users want.

4.10.2 Document signatures and the blockchain

The deployment of LibreOffice on both desktop and third-party cloud applications presents a particular challenge for key management. Private keys should always remain with the user to protect end-to-end security. Downloading the whole document to the browser in order to sign it locally and then transmit it back to the server is woefully inefficient and requires substantial bandwidth.

Instead, our VIAM authentication and local key storage component locally generates a one-time key that is signed by the local device key for the profile ID selected by the user. The public part of this one-time key is transmitted to the federated network running the Vereign application, and the private key is provided to LibreOffice online (via WebSockets) or desktop (via local library) to sign the document. LibreOffice provides the signed document directly to the federated network, which verifies it has been signed correctly with the one-time key. If correctly signed, the document is then signed additionally by the profile ID master key, which is protected by the hardware security module on the federated network. If additional sign-offs are desired, e.g., from a notary or lawyer, the document is then provided to these parties for review and signing in the dashboard application. Once the document is fully signed, it is submitted to storage.

If the document is of limited distribution or private, it is then stored encrypted in the local object storage for the user, submitted to the private IPFS, and shared only within the federated networks in encrypted form. If the document is intended for publication, it is pushed onto the public IPFS without encryption. Either way, the document will receive a unique IPFS ID. This ID is in no way correlated to its content or its author and carries no privacy, security, or GDPR concern. The IPFS ID will therefore also be used for the blockchain ID (BC-ID).

The blockchain key is generated from the hash of the unencrypted document. Anyone in possession of an unencrypted copy of the original document can decrypt the audit information on the blockchain. Possession of the unencrypted document and knowing its IPFS ID will become the key to finding and decrypting the additional verification data.

The data written to the blockchain will include the one-time public key(s) used to sign the document, the public key(s) of the profile ID(s) used to super-sign the document, the log(s) from the HSM signing process, including information about the HSM used, and the history of the document with IPFS IDs of previous versions (if applicable). This adds an immutable audit trail to the document and also provides tamper-proof evidence of the time of signing and document history. This process results in documents signed with a qualified electronic signature, perhaps even notarized, as a public resource including a (notary) seal on the blockchain—which can then be used as immutable public resources for smart contracts in public blockchains and elsewhere.

4.10.3 Authenticity for printed copies

In order to protect the authenticity of a printed document, a QR code will be added to each individual page when printed. That QR code will provide the URL for the page documenting the digital signature for the document. Verification of the document will take place online where the original is also available, digitally signed and authenticated, for comparison against the printed copy. For published documents, that page will likewise be public and link to both the blockchain transaction and the document itself on IPFS.

For private documents, the system will require authentication and will enforce access control. The document and its status page will only be available to authorized users.

4.11 Smart Contract template generator

Profiles allow users to create purpose-built pseudonymous identification with various degrees of (verified) personal information about them. On the other side of the equation are organizations and companies that wish to conduct business in an authentic way online. Based on the company and the particular case, certain information may be legally required or demanded by the company in order to provide certain offers. These requirements are the negative image of the information in the profile—e.g., for this offer, a user must provide their verified real name and telephone number, and prove they live in Switzerland.

Those negatives form part of a smart contract that may be offered to all users, and can be specified in a way similar to how profiles are being administrated. Our team calls this the “smart contract template generator.” We will wait for real-life user experience with profile administration before enabling this component, but we would be very interested in collaborating with third parties who wish to work on this with us.

Particularly in combination with document publication, above, we believe this could provide a very useful solution for future token generation events (TGE) where requirements can be defined and automatically enforced by smart contracts for participating investors.

4.12 Federated network

Virtually all our components are built for a distributed, modern cloud environment with RESTful interfaces, and each individual component will be able to communicate through the network. All data written to either the IPFS or the blockchain is automatically distributed in tamper-proof fashion, and available to all federated network instances.

Data that must remain local, especially personal data, profiles, and local entity data, is provided by distributed identifiers (DID) that make it conceptually irrelevant where that particular data is located. The keys to decrypt such data provided over these endpoints are in the hands of the users themselves.

We believe this provides a robust approach to federation with an adequate security profile. The weakest link in this scenario is where the internet is used to establish connectivity between the federated networks since there may be attempts to disrupt, cause denial of service, or even create split brain situations. In order to mitigate this concern, we are building upon the SCION architecture[61] which was built at the Swiss Federal Institute of Technology (ETH) in Zurich with the purpose of preventing such cases of network disruption and other network-based attacks.

A future revision of our clients should also utilize the SCION protocol to connect to the federated networks from mobile, web, and desktop clients.

4.13 Securing keys in hardware

Thus far all descriptions of key management have been based on software only. We made this decision because we did not want to make hardware purchase a strict requirement for users to access the benefits of the system. For many users, hardware tokens have offered a poor experience over the years—and have subsequently become very unpopular.

That said, storing the user local keys in hardware, which may be less prone to being stolen, lost, or left behind—especially if the token is purpose built to protect its private keys—would be very desirable. We are therefore investigating various options and have some ideas for hardware tokens of our own that we believe will have much better chances of user adoption than current approaches.

If you have an interest in this area and would like to get involved, please get in touch with us.

05

The Social Solution

The previous section explained our technical approaches to solving the challenges of making communication authentic and protecting privacy and identity.

Building on proven and state-of-the-art technology and cryptography, it goes into some detail on the various innovative concepts contributed by Vereign. However, as outlined before, a solution to these challenges cannot be found in technology alone. In most cases, additional social processes will in fact be either commercially reasonable or mandated by law.

Returning to the concept of purely wallet-based approaches, if that wallet is lost, so is everything associated with it. Physical and digital life are increasingly becoming one. We cannot rely on the recovery code not being lost at the time the wallet access has disappeared. It's not just some email, but also contracts, business deals, future proof of ownership for real estate, proof of attorney, and bank accounts will all be secured in such a system. These recovery codes literally become the tether by which a user's existence hangs in the balance, and if stolen, so is the livelihood of the user.

For most of us, the physical world is not that fragile and dangerous, but our ability in the physical world to restore our identity and recover from a lost wallet relies on social constructs that have proven effective over time. People know and have developed a good understanding of the level of trust to place in them. And trust, at its core, is a social phenomenon that cannot be achieved by technology alone. It requires structures and governance.

5.1 Reusing proven social constructs

Identity typically starts with birth. Birth certificates place us at a certain point in time, at a certain location, and sometimes also under a certain jurisdiction. Geographic structures are what lay the foundation for us in the physical world. This is why it is natural for our political processes to have evolved around them in the form of countries with borders and our own governance processes. As outdated as this concept may seem on the internet, our physical existence is very much determined by it—as is our ability to live sovereign, self-determined, and secure lives.

As XKCD pointed out in typically succinct fashion, there can be no lasting differential between our physical security and that which we enjoy online.[62] This is also why many governments, for good reason, wish to ensure that essential data required for their sovereign functioning remains within their physical borders. This requirement can only be relaxed somewhat in locations where similar standards of physical security and rule of law are ensured to a sufficient degree by supranational bodies like the European Union.

Despite the global reach of the internet and the promise for exchange without borders, this is the reason why we have chosen to design the governance model and physical deployment of our networks after the physical world. To ensure regulatory independence, we will not run those networks ourselves, but will merely support those who do.

5.2 Empowering users and trustees

The concept of federated, multinational, and open source-based networks in independent ownership as the backbone for self-sovereign users is a strong proposition against failure of individual persons, organizations, or regions.

This focus on resilience and the avoidance of single points of failure also extends to local networks. Our approach sees the networks organized through user-driven organizations such as associations, cooperatives, and other forms of pursuing collective interest. Governance of these organizations will be supported by legal professionals from the fields of privacy, data, and consumer rights protection. Professional, lean executive management is sufficient for state-of-the-art management of data centers and system administration providers, legal compliance, and day-to-day management.

This combines user oversight with the professional capabilities of business, technical, and legal experts. The legal professions also play especially important roles as service providers to the network and its users by protecting clients' interests, rendering support for smart contracts, and dispute settlement. Within the legal profession is also the specialized role of notary public. In blockchain lingo, their role is to act as oracles for the real world. They perform essential functions as third-party witnesses who can officially attest to the existence of physical paperwork or assets. They can also document intent between people. Data protection commissioners and those tasked with defending customer rights are typically another specialized form of legal counsel.

All of these specialized professions have invested much into their education and certification and are duty bound to protect the interests of their clients—which is why they have much to lose when accepting any kind of illegal conduct or violation of user rights within these networks. This is why Vereign will not only support local and national user associations and cooperatives, but also bar associations, chambers of notaries, data protection agencies, and similar organizations in bringing federated networks into operation.

On an international level, a new global organization will ultimately be responsible for the contractual framework and principles of self-governance which local networks will need to adapt to their local regulation and then follow. This organization will be initiated by Vereign, consist of representatives elected from the individual member organizations running the networks, and follow democratic principles. It will independently decide upon acceptance of networks into the federation, and—where necessary—exclusion of networks with political or organizational failures.

As a result, Vereign will continue to play the role of catalyst, inception agent, and innovation hub for a self-healing, self-administrating, and self-controlling set of organizations and networks under the control of users and their trustees.

5.3 A new kind of service for lawyers and notaries

In addition to the framework of network governance, Vereign enables a completely new kind of service opportunity for lawyers and notaries and empowers them to act as trustees for users in the system. Users get to choose which lawyer or notary to trust, and empower them to restore access to their account in order to solve the “lost wallet” problem explained above. It is also possible to empower family and friends this way, but when real assets are involved, it's generally advisable to use the local notary or trusted legal counsel.

Notaries can confirm the existence of certain documents like birth certificates and family relationships which enables the verification of claims about the identity of any person in the system. These verifications can be used for privacy-protected Zero Knowledge Proof identification.

Lawyers will be able to assist users in the design and execution of smart contracts, and notaries can obtain new functions complementary to their existing ones where they can act as oracles for smart contracts in the blockchain.

As the system grows, so will the number of new services that lawyers and notaries can deliver in addition to all the services they are currently providing today.

Except where mandatory by applicable law, these services will not be exclusive to lawyers and notaries. In particular there are other well-established diligence processes and trustees, e.g., financial intermediaries for digital on-boarding to allow easy and convenient verification of identity claims. Additionally, there will be new services like electronic bodyguards and personal assistants. They will make the conveniences of a family office available to more people.

It is our vision that the system we are building will be the spark that launches a public service and infrastructure enabling an ecosystem of applications available to everyone.

06

The Business Solution

The third imperative for our solution was the design of a sustainable, scaling business model. Much has been written about how the token economy will bring about new business models and disrupt intermediaries.

In reality many of the “new” business models closely resemble the old ones: a token issuer or smart contract developer as a new kind of intermediary. Instead of having one of the “Big Five”[63] monetize your personal data, why not do it yourself? Or so the pitch goes. A truly revolutionary approach might be to replace surveillance as a business model.

In any case, the IT industry has long neglected transparency in its business models. If the business model is not transparent, this is likely because it puts the interests of the service provider at odds with those of the user. Sale of the business along with all the users, including their data—often to one of the “Big Five,” is a logical consequence. WhatsApp demonstrated that promises of no surveillance and no advertising are worthless once the willingness to lack a business model is less than the willingness to spend money on further growth. Likewise, collecting huge sums of money for network infrastructure based on the promise of one day releasing it as open source and turning it into a public network should probably be taken with a grain of salt until the subsequent business model is understood and sustainable.

6.1 Commercial Open Source on the Blockchain

Open source was a non-functional requirement for Vereign. Key reasons for this decision included transparency, security, and resilience against organizational or technical failure. Open source is also a strategic tool that allows subsequent, permissionless innovation, frictionless interoperability, rapid dissemination, and adoption by third parties at much greater speed than for any proprietary platform. Yet, the tech industry has many examples of superior technology never reaching its full potential due to lack of a sustainable business model. Open source is no different in this regard.

If one ignores all the “fake Open Source” models,[64] there are really only three fully established business models for open source that deliver sufficient revenue at scale. One is the software subscription with enterprise support model that has allowed Red Hat and SUSE to grow to their current profiles. The second is the—subtly different—“provide product as a demand generator for consultancy service” model that Canonical promotes. Then there is the software as a service (SaaS) model that can drive enough revenue to publish (parts of) the code base, favored by companies like FastMail and others.

Our team and advisory board started discussing the implications of a token-based economy for open source some time ago. Having superior technology and great potential alone is never enough. Interestingly, Bilgin Ibryam of Red Hat also recently highlighted some of the potentials of blockchain and the token economy for open source.[65] There will be more. Born of the Open Source community and spirit, blockchain and smart contracts seem a natural fit for new business models within open source.

While the public focus on blockchain and the token economy remains on its potential for bringing down the marginal cost of developers, there are also PayPal, Stripe, Flattr, and others who have made it sufficiently easy to transact even small amounts. Bug bounties, consultancy offers, payment for a feature—these are all old ideas. Still, they did not solve the problem. Advocating them on token basis is not going to solve the underlying root causes.

6.2 A better answer: the inclusive business model

Our team has been involved in business model evolution around open source since the mid-90s, and we see an opportunity for something new in blockchain and the token economy. We see a better answer that goes deeper. Smart contracts allow us to model relationships between any number of parties and transparently determine what happens when certain conditions are met. This is far more powerful than a transfer of a pre-arranged amount between two parties. It offers the potential for dynamic payments even for traditional software subscriptions—and turns them into a value share between user and provider.

Blockchain allows an alignment of financial interests between two or more parties that was almost impossible to achieve in the traditional world. The dramatically-reduced marginal cost makes such an approach practical and the built-in transparency protects the smaller players. This kind of inclusive business model creates a scenario where maximizing the revenue of one participant will automatically maximize it for all of them. All things considered, it is an almost perfect fit to the specific properties of free software/open source.

6.3 Revenue sharing ecosystem

The Vereign business model is entirely based on revenue sharing between the participants and is inspired by the concept of social franchising.

Vereign provides sales, marketing, customer service, billing, and software to the federated networks in exchange for a revenue share. The hardware is purchased by the networks under special business partner conditions at IBM and a leasing contract with centrally negotiated, beneficial payment terms that gives networks access to better terms than they would otherwise be able to negotiate. In addition, Vereign can take a role as back-up for their leasing payments. The hosting and operation are managed on a contractual level directly between the networks and their suppliers, such as data centers, or managed service companies. Specifically, as each new network launches, Vereign will offer to cover leasing and hosting costs as these are the biggest individual investments required for networks to launch.

For the members of local organizations associated with running the networks, such as the associations of lawyers or notaries, this provides a path to additional revenue without major upfront cost. All revenue comes on top of and will not cannibalize existing revenues. Without revenue, there is no cost, and without the networks, there would be no additional revenue.

The funds for network setup and infrastructure development are raised during the token generation event organized by Vereign.

Investors in the token finance the creation of networks based on the solution and scaling up of the productive ecosystem through marketing and support.

The revenue share model allows Vereign to integrate and join existing traffic of other service providers with applications such as collaboration, file sync, and sharing. Rather than tapping into existing revenue streams of those providers, Vereign offers its value-adding services and a share of the revenues generated on top. This provides a path to sustainability for many Open Source projects, which tend to have a large number of users but still often struggle with commercialization.

The revenue share doesn't only extend to ecosystem service providers. Every purchase of a user subscription actually triggers a token allocation to the wallet of the respective buyer which will then be used to incentivize email recipients to help keep the functionality activated. This way, the revenue share extends all the way to providing peer-to-peer user rewards.

Because Vereign uses part of the revenue share to replenish the infrastructure pool, the network can grow in a sustainable fashion as required by user demand. This includes hardware replacements as it breaks down or goes out of rotation.

Orchestrating such a revenue share between all participants, with billions of users, hundreds or thousands of networks and investors, and tens of thousands of providers would have been impossible under the traditional model. Due to the fact that any part of this network can be replaced if it malfunctions—Vereign included—the solution is both resilient and sustainable.

6.4 Enabling new and better business opportunities

Once the networks succeed at scale with the solutions outlined above, established businesses gain a unique opportunity to create new offerings and to dramatically improve the user experience for existing businesses.

6.4.1 Never have to re-enter your data again

Just one example is the frequent interaction with users during check-in. Nobody enjoys having to re-enter the same data over and over again. Once airlines have integrated into the system, they can request all the required data easily upon check-in with third-party assurance that the data is correct and up to date. Simultaneously, airlines do not need to store all this personal data beyond the individual flight. All parties win from this scenario. Users no longer have to go through the repetitive exercise of filling in name, birth date, passport number, and so on. This solution helps Airlines have a greatly reduced GDPR exposure and compliance risk, and customers benefit from check-ins becoming much more seamless and convenient. For added value, the airlines could then automatically deposit the boarding pass into the document store of the user along with important trip information.

6.4.2 The best possible answer to GDPR

This kind of system is the most convincing answer to many of the questions raised by the General Data Protection Regulation (GDPR). It puts users in charge and allows businesses to interact with that data within a defined, user-approved framework. This is the best possible solution for many reasons.

For instance, Article 20 of GDPR,[66] the “Right to data portability,” is anything but trivial. The migration of data from one system into another is always a major undertaking, and it often fails. Few companies are truly prepared beyond a general idea of planning to have employees copy customer data onto USB sticks for it to be handed over to the customers upon request.

In the system we are offering, data does not need to be exported. It resides in the domain of the user, who can effectively migrate from one business to another by canceling the contract and the access to one business—and enabling it for another. For all kinds of sensitive data, such as for banking, health and insurance, having it controlled by the people themselves is the best possible way to go. Users have complete control over their data and provide access to that data on the federated networks. The system ensures data is provided and specified as contractually agreed, observing mandatory retention periods and legitimate business requirements to fulfill existing contracts.

6.4.3 New opportunities for online business models

The system also allows for new business models in established fields starting with email and collaboration providers. Due to the ability to build smart contracts and financial transactions into the handling of messages, email providers could change their business models on these frameworks and expose this kind of capability to their users. For example, users could define one set rules for their friends and family, another for companies they have contracts with, and yet another for anyone else. The result could be pay-per-use models for enterprise collaboration platforms with no upfront cost and at much greater value than today's freemium approaches.

6.4.4 Our door is always open

There are many more possible future applications of the system. Our open, inclusive approach to technology and business make Vereign a welcoming partner for developing them together. Our revenue sharing model uniquely motivates us to work toward the success of our partners in technology, business, and service provision.

Join our community at community.vereign.com.

07

Corporate and Business Development

Vereign was established in the heart of the Crypto Valley of Zug, Switzerland, on October 25, 2017, with seed funding by its co-founders.

All co-founders share a profound belief in running code and real-life business and applications. We are driven by creating applications that have the potential to provide value for billions of people and we are convinced our solution has the potential to do so. That is why we decided not to spend our seed funding on a “white paper ICO” but instead, chose to build a team that could deliver on our vision. Instead of saying what we would do, we decided to do it.

Based on an existing prototype, we plan to run another traditional funding round to get the system ready for production and roll it out to the first users. The token generation event will then serve as a capacity generation event for an existing service already in production.

The token itself becomes the mechanism by which the system scales, and is ultimately fixed to the capacity and usage of the system—making it the world's first capacity-backed and service demand-driven, stable token. Further details of the token design and its function are explained in the following section. In the context of corporate and business development it should be mentioned that this approach will allow for a public sale to scale the network globally, which is fully compliant with financial market rules and regulations. The result will be a legal, reliable, and stable token. The token is designed to remain robust against speculation, with fluctuations reflecting utilization along a general increase in value. This base appreciation is the result of the increase in efficiency and performance of computer hardware over time in combination with a hardware peg. Please see section 8.2.2 for details.

7.1.1 Phase I: Assembling the team and building the structures - Done

Other projects have chosen to outsource much of their technical development to service companies in Southeastern Europe, Ukraine, Russia, or India. In contrast, it was our strategic decision to build upon our own entity and team.

In December 2017, we incorporated Vereign Labs, Ltd., as a wholly owned subsidiary in Plovdiv, Bulgaria. Over a period of seven months we interviewed hundreds of candidates. Our goal was to assemble a team of 10-15 experienced and passionate people who could bring the vision to life. Because all decisions in this phase may affect the product negatively for years, we deliberately decided not to hire any junior developers. Today, our team has grown beyond 20 people and spans Switzerland, Germany, Bulgaria, Russia, and Turkey. We expect to keep on hiring as part of Phase IV and beyond and will slowly add junior developers onto the team.

We have also focused on building up all the necessary structures simultaneously for us to succeed as a business. This includes items such as professional administration, reporting, contractual frameworks, and trademarks. Our team has decades of management experience responsibility for hundreds of people and many millions of turnover per year in multinational environments, so we are set up to grow in a structured, sustainable way.

Creating an ecosystem that thrives with open innovation is the third pillar for our vision for success. We began seeding our ecosystem quickly from the financial, business, service, industry and technology domains.

Just to name a few examples: our partnership with Collabora and authors of the Collabora Online Development Edition (CODE),[67] the web version of LibreOffice, and central contributors to the LibreOffice community have been essential to our ability to provide our integrated solution for all users of LibreOffice. Our close relationship with the Roundcube community with a special thanks to our valued adviser Thomas Brüderli, the original author and maintainer, has allowed us the freedom to discover the best integration path that benefits the community as much as possible.

Last, but not least, we are building on our special business partnership with IBM, one of the key drivers for the OpenPOWER, Hyperledger, and Linux Foundation ecosystems. As part of this partnership, IBM is making substantial investments into Vereign in the form of technical collaboration, workshops,[68] and communication.

7.1.2 Phase II: Conceptual and architectural work - Done

Setting up the initial infrastructure and defining our process was part of the second phase. For an exploratory development effort based on a vision that was still evolving, it was essential to stay flexible which is why an Agile methodology was chosen. Because user experience and security are both essential, we introduced code reviews and quality assurance right away and began continuous integration/continuous deployment as soon as development became fully operational.

This period was also characterized by extensive research into existing technologies and possible design decisions. During a variety of workshops and extensive conceptual discussions, we narrowed down the choices for our architecture, made our technology choices, and wrote the first technical papers. In addition, we took great care in starting to look at user interfaces and user experience since the usability of the system would be crucial to its success.

At the same time, we closely followed the development in the regulatory space around tokens and cryptocurrencies because we were determined to create a fully-compliant, stable token. This was not a trivial process since the conceptual and technical setups form communicating vessels. Changes in the token approach may require technical and conceptual modifications—and vice versa. As a result of numerous iterations, conversations with financial experts, and input from legal counsels, we ultimately arrived at the current token concept. This concept is being presented for approval by the Swiss Financial Market Authority (FINMA)[69] by Vischer,[70] our legal counsel. Most importantly, we had to decide where to first apply the technical and social promise of Vereign. With a vision of this magnitude, it was crucial to understand where to begin our journey. After many iterations, we ultimately settled on authentic communication as the first application of our technology addressing a real, pressing issue for billions of people.

7.1.3 Phase III: Development of a proof of concept - Done

The key deliverable of the third phase is a working demonstration of our solution to prove the concept. This is currently ongoing and we're preparing to present a first working prototype in September 2018. This is also when we will start opening up our GitLab and communication channels so third-party participation will become easier.

We are also currently holding our series A funding round in preparation for phases four and five in such a way that even without the phase five public token generation event we will be able to build out the global networks through organic growth or regular investment.

The finalization of this white paper is one of the major milestones for this phase in order to document and communicate the bigger picture and allow it to be shared with everyone.

7.1.4 Phase IV: Production readiness and initial deployment

The goal for the fourth phase is to build the first productive network association running the solution. In order to achieve this goal, our team will complete the prototype, bring it to production readiness, and integrate the revenue sharing and accounting functionalities. We have chosen Switzerland for the first network due to the location of our company headquarters and Switzerland's strong privacy legislation; Germany and France are the next targets for early expansion. This initial network will be built with capacity to scale up with user demand in order to adapt to potentially rapid growth until phase six can truly begin. It is also the network within which the lessons will be learned for the rollout in phase six.

During this phase we are planning to increase communication and participation in events to reach users, partners, and the technical community. Along with a growing developer community, our internal team is also expected to continue to grow. DevOps and platform specialists will be required and Vereign will need to build up a level 1 support department.

7.1.5 Phase V: Capacity generation period

The capacity generation period will lay the foundation to allow rapid global deployment of the federated network associations. The funds raised in this way will determine the speed with which the associations will be created and the number of existing tokens. Our aim is to quickly deploy at least two networks per continent, and in case of overwhelming success, we would create at least one network per country.

Success in this phase will also determine the further growth of capacity at Vereign, especially our sizing for the network association inception team and our level 1 support. Part of the funds will be used for increased in-app coverage to make sure all of our users have a convenient, easy, and well-integrated way of making use of the system's functionality.

Also, this is the phase when Vereign can begin the process of becoming a qualified digital signature provider to ensure that qualified electronic signatures will be available as an added service.

7.1.6 Phase VI: Launch of federated identity networks

This phase is characterized by the global creation of federated identity networks and their deployment of the solution. Similar to a social franchise concept, these networks will be utilizing a starter kit of contracts, statutes, and procedures to get them going quickly. The scale out of these networks will be demand driven and based on existing user numbers.

The solution will simultaneously switch to a release model where stability can be ensured for existing deployments while new features are also being developed and deployed. The microservice architecture in combination with a modern container platform and the chosen model for the client libraries will enable our ability to roll out new features as soon as they become available.

We expect the system to grow quickly in number of users during this phase. These numbers will create demand for legal and notary services which will be scaled up wherever there are associations for the federated network in operation.

7.1.7 Phase VII: Ongoing operation and development

The ongoing operation phase will likely begin before phase six is fully complete and covers operation in production for large volumes of users. At this stage the existing solution and global federation of user-owned network associations will grow in usage, coverage, and use cases. Further use cases, such as the ones outlined in section 6.4, will be built on top of the network, increasing its usefulness for everyone.

Vereign expects other participants in the ecosystem to grow its importance, to drive further use cases for the platform, and to be committed to remaining a source of open innovation and a service provider to the networks as a whole. However, the solution or federated network associations will not be dependent on Vereign since they are free to choose their own vehicle to fulfill the same function. The Foundation for Verified & Sovereign Technologies will take on a life of its own and drive a new wave of innovation.

7.2 Key Factors

Vereign is the catalyzing entity for this rapid growth of user-controlled networks. By driving development of the solution and the raising of funds in the capacity generation period, there is no systemic dependency on third parties for the achievement of our goals other than a general willingness to participate.

7.2.1 Economies of scale and hybrid franchise

Applying a social franchise[71] concept on the local network level allows the rapid deployment of user-controlled networks on demand and in any jurisdiction. The setup of hardware and procurement of suppliers, software, and services are all capital intensive, so we've supplemented the social franchise concept with a function of providing capital, expertise, and services that are required by all networks. The result is ultimately what can be described as a hybrid franchise.

Vereign offers franchise templates and starter kits. It will also provide both expertise and software required for the operation of the network under a contractual framework. These include access to global hardware purchase and leasing conditions negotiated by Vereign on behalf of all the networks. This allows each network to get access to much better conditions on hardware purchase and leasing. Also, Vereign can be a back-up guarantor in the hardware purchasing deals for the networks. For the initial period of network inception, Vereign will use funds from the capacity generation period to cover leasing and hosting.

All of the above will ensure Vereign has the capability to provide hardware replacement and upgrades, software maintenance and updates, level 1 support, ongoing development, marketing, and growth of the global network in perpetuity. By making the contractual framework dependent on periodic utilization, as well as the user performance within those networks, Vereign is actively contributing to the sustainability of the networks.

Users enjoy transparency, accountability, and full control of their data, but bear none of the economic risks otherwise associated with the running of such services. Small and medium enterprises benefit from a distributed, trustworthy, and compliant service network. Certain groups of professional users and larger companies can join the networks with locally installed instances of the same solution—adding further distribution while putting them in complete control.

7.2.2 Federated network organizations

The network associations are local legal bodies, such as registered associations under local law. Based on a global legal survey in preparation for phase six, the goal will be to find the right local type of legal body for each country which may hold their own assets without establishing financial risk to their members.

Membership is automatic for all active users of the local network, but each association is initially seeded with a group of members from the country who also take responsibility for its governance and financial matters. That initial group of people is sourced by the Vereign network association inception team who actively seeks out local privacy and security activists, data protection commissioners, lawyers, and notaries in order to create the association.

Associations will always be democratic with well-defined operational procedures. They will choose a sufficient number of data centers and managed service providers per country in order to guarantee data safety and redundancy for the needs of the expected numbers of users for each country. The funds to set up the local infrastructure of servers, storage, and data center equipment are guaranteed by Vereign as part of the hybrid franchise framework. Initial operational costs and other fees are also guaranteed by Vereign in order to help the networks launch rapidly and allow them to service users quickly.

When networks start creating revenue, repayment of the initial coverage of leasing cost for new networks will help replenish network inception funds at Vereign and can be used to bootstrap funds needed in other places. Also, Vereign will continue to build up reserves for hardware replacement and other necessary upgrades that may require faster growth than a network can achieve organically.

The local associations being open to participation will ensure they become fully user driven and, if the members so decide, user run over time. As their financial success increases, they can choose to switch to supplying and managing their own hardware, and increasing the revenue share that remains within the local association. These local funds can be used for purposes that are in line with the purpose of the association: developing local use cases, growing the local services, communication, and marketing.

Because the local associations are for purpose, funds beyond a constitutionally-defined reserve will go back to Vereign to help further the growth of the ecosystem and to the global Foundation for Verified & Sovereign Technologies (see Section 7.2.4) where funds will be used to further the same goals.

7.2.3 Certification authority and Financial Intermediary

Certification under eIDAS and ZertES is an expensive endeavor. It includes substantial procedural and organizational efforts in addition to external costs in the hundreds of thousands of Swiss francs. These costs are recurring because most countries have re-certification requirements. Such costs would be prohibitive for any individual network which is why Vereign will bundle these expenses in order to provide qualified electronic signatures to the networks as part of the hybrid franchise framework outlined above.

The pooling of resources in Vereign as a Swiss entity also brings the additional benefit of being able to work closely with approved financial intermediaries in Switzerland in order to keep all wallets and transactions under Swiss jurisdiction. This ensures legal certainty and stability for all networks regardless of the local regulatory situations, which are often still unpredictable and fast moving. As a result, our token will have immediate liquidity on a global scale without risk of regulatory upheaval.

7.2.4 Foundation for Verified & Sovereign Technologies

Once the initial investment has been recovered and Vereign is profitable, Vereign is committed to dedicating 1% of its annual gross profit to the funding of a Foundation for Verified & Sovereign Technologies. This foundation will have the purpose of promoting Open Source technologies that contribute to a world where users are sovereign and have control over their own data.

In addition, the funding will be supplemented by the surplus from the individual networks, as described in Section 7.2.2.

7.2.5 Keeping it simple

The goal of Vereign and our solution of giving billions of users more security, sovereignty, and control of their own data requires adoption to be as simple as possible. The vast majority of users will choose not to be involved in the local network associations, but they still deserve full control and ownership of their own data.

For this reason, the onboarding of users will not require users to explicitly make a choice regarding which network to join. Users also won't be required to get actively involved in the association itself. Instead, the system will make an informed best guess where to direct a user, and once the user is onboarded with governmentally issued identity, the system will direct them to the network in that country by default.

Initially, during phase four, all users will be onboarded in Switzerland. Later, choosing the location of data will be an expert level setting for active users.

08

Token Concept

Vereign will establish the world's first capacity-backed utility token that's linked to both capacity and the usage of the service.

The token is initially created as the investment vehicle for our investor community as part of our capacity generation event. In order to establish a compelling case for stability and return tied to success—specifically the utility of the system itself—we have realized hard currency characteristics for the token.

8.1 Service pricing and revenue share in fiat currency

While we are building the token with hard currency characteristics, adoption and usage of the system must not depend upon acceptance of crypto currencies. This new form of currency is still in its early stages, and is not yet mainstream. This is also behind the massive price volatility caused by speculation and the lack of liquidity. These issues make crypto currencies a fragile basis for reliable service pricing at scale.

In addition, crypto currencies suffer from the same psychological barrier that any currency faces when it's not the local government-issued currency.[72] That barrier is the feeling of familiarity that's built after thousands of transactions over many years of being able to understand a price and how to use the currency for everything including basic necessities. No crypto currency can offer that today.

For all these reasons, basic service and subscription pricing must be in local fiat currency for the user. This may change in the future as crypto adoption increases and fully-regulated exchanges provide the required stability, liquidity, and services in a way that is globally recognized and allows pricing to be intuitively understood by users.

Until then, Vereign will provide the token payment and exchange functionality in collaboration with a recognized Swiss financial intermediary, who in turn links up with selected global crypto exchanges. This effectively makes Switzerland the initial token hub for the networks. Given the well-established Swiss regulatory and financial environment, this approach provides an immediately workable solution for scaling the networks globally with intuitive pricing or all users. It also isolates the service and system from potential disruptions in the crypto currency ecosystem.

8.2 Token functions

Collaboration with a recognized Swiss financial intermediary brings the additional benefit that wallets can be legally hosted in Switzerland. All token wallets will therefore be protected by the supervisory framework of the Swiss Financial Market Authority and be fungible within one of the world's best jurisdictions for the security of assets. While local fiat currency is being used for service pricing and user subscriptions, the token acts as the accelerator and reserve currency that provides a few key functions.

8.2.1 Backed by infrastructure and service value

The initial value of the token is determined by network creation following the Token Generation Event (TGE; see Section 7.1.5) during which investment is collected for a global scale-out of the system. The token value is a function of total investment for network scale out. The capacity thereby created divided by the number of created tokens results in a peg that is kept constant over the lifetime of the system. New tokens are created only when further capacity is being deployed.

As a result, the token supply is pegged to the infrastructure deployed in the system. The need for infrastructure is driven by service and thus by real, rather than speculative, demand.

8.2.2 Tracking productivity and hardware improvements

This initial peg of token value to infrastructure cost means the Vereign token will effectively track infrastructure productivity. Because hardware is getting more efficient and the same investment will buy more computing power as hardware improves, we expect the token to appreciate with every new hardware generation. With infrastructure demand and frequency of upgrades being driven by use cases, the token will also appreciate based on market expansion.

8.2.3 Store of value with steady appreciation

In addition to the offerings of the participating Swiss financial market intermediary, Vereign will work to list the token on a variety of established crypto currency exchanges. This will allow the token to be traded in a distributed way, providing for good liquidity. In combination with the previous points, it will render the token a store of value that appreciates in sync with technical innovation cycles being deployed to the networks.

8.2.4 Built-in safeguards against excessive speculation

The key to success for any currency is its availability and adoption. Crypto currency exchanges serve the purpose of a public marketplace on which the token can be exchanged, but it is the purpose of the token for all users of the system that drives supply and demand and therefore determines the value at the exchanges. In order to render the token value impervious to the effects of excessive speculation, it is therefore imperative to tie the token to the utility of the service itself. This is why the ecosystem will accept the token itself for the purchase of services. This turns the token into the key mechanism for expansion and retention through loyalty reward and conversion promotions. It will also become the driver for adoption through peer-to-peer exchange incentives, making it the functional equivalent of a perpetual and fungible marketing fund.

8.2.5 Constant, service-driven token demand

For each purchase of services in fiat currency, a fixed fraction will be used to purchase tokens at crypto currency exchanges and credited as a loyalty reward to the wallet of the user making the purchase. The fiat payment itself will be credited in full, which means that for the user these tokens provide an ongoing, fungible loyalty reward program that can be used for any purpose. Where the demand for other tokens is driven purely by speculative demand, our loyalty program purchase is a constant token demand driven by usage of the service itself.

Depending on the inclination of token holders to release them at crypto exchanges, as well as the actual capacity utilization, the token value might temporarily appreciate beyond its capacity-linked value. However, it should be much more resilient against sudden depreciation below the capacity-linked value than purely speculative tokens.

8.2.6 Adoption reward

The token is also used to reward users for adoption, such as for downloading the Vereign plugin and keeping it active for email received from other users. The adoption incentive is not pushed top down by Vereign, but implemented as a peer-to-peer transfer from the wallet of the sender to the wallets of the recipients of an email. This serves as an incentive to keep the recipient notification outlined in 3.2 and 4.9 active, which is primarily in the interest of the sender. The adoption reward will provide an ongoing, automatic distribution mechanism for the token that counteracts centralization. Tokens gained in this manner can be used for sending email or converted to cover service subscription payments.

8.2.7 Marketing and promotions

With tokens piling up in user wallets, these tokens not only reflect claims to service consumption, but an opportunity for marketing and promotions. Donating tokens to friends or receiving a monthly subscription for free (if holding sufficient tokens) are ways of supporting the networking effects. Another promotion opportunity can be “happy hour” conversion modifiers when exchanging tokens for money at crypto currency exchanges—especially when these allow users to activate first-time subscriptions and start using the system more actively.

8.2.8 A stable, self-appreciating, fungible store of value

Because the ecosystem accepts tokens in return for service, it will likely be a large seller of tokens at the crypto currency exchanges. This allows the ecosystem to provide further liquidity that can be used strategically in part to overcome a surplus in demand, or simply to not exacerbate an excess of supply.

In summary, all of the above will render the token a stable and appreciating store of value that grows in acceptance and liquidity with the networking effects of the world's largest social and federated messaging network.

8.3 Capacity generation period

The capacity generation period (CGP) is our version of a token generation event or ICO. While our concept allows for organic growth, the CGP is organized to accelerate global growth of networks. For investors, this translates into an opportunity to receive early access to the token at conditions that won't be available at a later date. The book building process is designed to achieve a uniform distribution of investment and ideally create an immediate return on the allocation of tokens to the investors. The algorithm underneath the investment application will apply an individual scaling multiplier based on the current distribution of funds at the time the investment is made. The multiplier changes with each investment, and incentivizes a continuous overall distribution. Avoiding concentration of tokens in the hands of a few large investors by means of providing an incentive for continuous distribution of tokens helps to provide a sufficiently broad base of users and supply of tokens.

Simultaneously, we aim to make the CGP attractive to the entire spectrum of possible investors. The funding process will therefore be split into a seed and a distribution period. The target audience for the seed period is professional, accredited, and high net worth investors for a high median contribution.

Upon expiration of the seed period, we plan to move to the distribution period. This period will tie the multiplication factor of a contribution to the average distance reduction and median absolute deviation based on the median of the continuous distribution of investments. This will stabilize and drive down the average distance between payments to approximate a uniform overall distribution.

We expect participants to try and use the multiplier to their advantage. This is an anticipated result due to the way we designed the book building process. Investors might even want to split their contributions in order to achieve better multipliers over time. While this is an acceptable behavior, it also introduces the risk of larger, single investors and is therefore an unwanted skew. We intend to mitigate this by taking an investor's total investments into account before calculating the spot multiplier offered.

09

Leadership Team

9.1 Executive

9.2 Advisory Board

Appendix

1. https://www.wsj.com/articles/behind-the-messy-expensive-split-between-facebook-and-whatsapps-founders-1528208641
2. https://www.radicati.com/wp/wp-content/uploads/2018/01/Email_Market,_2018-2022_Executive_Summary.pdfhttps://www.statista.com/statistics/420391/spam-email-traffic-share/
3. https://blog.barkly.com/small-business-cybersecurity-statistics-2018
4. https://www.eid.as/
5. https://www.cryptomathic.com/news-events/blog/understanding-zertes-the-swiss-federal-law-on-electronic-signatures
6. https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf
7. https://en.wikipedia.org/wiki/Age_of_Enlightenment
8. https://www.digitaltrends.com/opinion/the-digital-self-our-online-lives-are-our-real-lives/
9. https://sovrin.org/wp-content/uploads/Sovrin-Protocol-and-Token-White-Paper.pdf
10. https://www.javelinstrategy.com/press-release/identity-fraud-hits-all-time-high-167-million-us-victims-2017-according-new-javelin
11. http://www.pewresearch.org/fact-tank/2018/03/27/americans-complicated-feelings-about-social-media-in-an-era-of-privacy-concerns/
12. https://gdpr-info.eu/art-6-gdpr/
13. https://www.gdpreu.org/compliance/fines-and-penalties/
14. https://hackernoon.com/eli5-zero-knowledge-proof-78a276db9eff
15. https://en.wikipedia.org/wiki/Gmail
16. https://www.zdnet.com/article/microsoft-office-365-now-has-120-million-business-users/
17. https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
18. https://opensource.org
19. https://www.fsf.org
20. https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
21. https://www.zdnet.com/article/yes-u-s-authorities-can-spy-on-eu-cloud-data-heres-how/https://www.aicgs.org/2018/03/congress-approves-data-access-outside-of-the-united-states-cloud-act-but-the-eu-may-not-like-it/
22. https://openpowerfoundation.org/
23. https://grpc.io/
24. https://en.wikipedia.org/wiki/Message_transfer_agent
25. https://en.wikipedia.org/wiki/Zero-knowledge_proof
26. https://en.wikipedia.org/wiki/Interactive_proof_system
27. https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/
28. https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof
29. https://z.cash/technology/zksnarks.html
30. https://github.com/IBM-Cloud/idemix-issuer-verifier
31. https://en.wikipedia.org/wiki/Federation_(information_technology)
32. https://w3c-ccg.github.io/did-spec/
33. https://www.w3.org/TR/ldn/
34. http://www.simplecloud.info/
35. https://oauth.net/2/
36. https://www.ibm.com/developerworks/library/l-support-protected-computing/
37. https://en.wikipedia.org/wiki/X.509
38. https://en.wikipedia.org/wiki/CAdES_(computing)https://en.wikipedia.org/wiki/XAdEShttps://en.wikipedia.org/wiki/PAdES
39. https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
40. https://download.libsodium.org/doc/
41. https://www.privateinternetaccess.com/blog/2017/08/libsodium-v1-0-12-and-v1-0-13-security-assessment/
42. https://github.com/PeculiarVentures/PKI.js
43. https://webkit.org/blog/7790/update-on-web-cryptography/
44. https://github.com/kjur/jsrsasign
45. https://en.wikipedia.org/wiki/S/MIME
46. https://datatracker.ietf.org/doc/search?name=S%2FMIME&sort=&rfcs=on&activedrafts=on&by=group&group=
47. https://efail.de/
48. https://sks-keyservers.net/status/key_development.php
49. https://en.wikipedia.org/wiki/Forward_secrecy
50. https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
51. https://moxie.org/blog/gpg-and-me/
52. https://github.com/smimp/smimp_spec/blob/master/smimp_specification.md
53. https://github.com/IBM-Cloud/idemix-issuer-verifier
54. https://www.libreoffice.org/
55. https://www.collabora.com/about-us/open-source/open-source-projects/libreoffice.html
56. https://en.wikipedia.org/wiki/WebDAV
57. https://wopi.readthedocs.io/en/latest/
58. https://nextcloud.com/
59. https://owncloud.com/
60. https://ipfs.io/
61. https://www.scion-architecture.net/
62. https://xkcd.com/538/
63. https://www.bloomberg.com/view/articles/2017-11-15/the-big-five-could-destroy-the-tech-ecosystemhttps://blogs.gartner.com/brian_prentice/2010/03/31/open-core-the-emperors-new-clothes/
64. https://opensource.org/node/102
65. https://opensource.com/article/18/8/open-source-tokenomics
66. https://gdpr-info.eu/art-20-gdpr/
67. https://www.collaboraoffice.com/code/
68. https://twitter.com/VereignAG/status/1004715825553641472
69. https://www.finma.ch/en/
70. https://www.vischer.com
71. https://en.wikipedia.org/wiki/Social_franchising
72. http://www.marketwired.com/press-release/lack-of-local-currency-pricing-suppresses-global-ecommerce-sales-1755801.htmhttps://home.bluesnap.com/snap-center/blog/why-local-currency-matters-when-you-are-selling-online/

Disclaimer

This document is for information purposes only and does not constitute an offering circular, information memorandum, or any other form of legally binding offering document. Consequently, it has not been registered with the United States Securities and Exchange Commission or any such authority.

The material contained in this presentation is intended to be general background information on Vereign AG and its affiliated company Vereign Labs Ltd., as well as their business concepts and intentions. This document has been issued on September 16, 2018. It reflects current views with respect to future events and is therefore subject to certain risks, uncertainties, and assumptions. The information is supplied in summary form and is therefore not necessarily complete. Also, it is not intended to be relied upon as advice to investors or potential investors, who should always consider seeking independent professional advice depending upon their specific investment objectives, financial situation, or particular needs.

Imprint

This document was authored and is Copyright © 2018 Vereign AG, Dammstrasse 16, 6300 Zug, Switzerland; https://vereign.com. In case of questions, contact@vereign.com.

This document is published under Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license; https://creativecommons.org/licenses/by-sa/4.0/