It is a fantastic integrated proposition combining elements of a manifesto, a programmatic document, a technical white paper, a roadmap, a business plan and crypto economics through a multi-disciplinary analysis of the contemporary “digital citizenship” situation and a clear, specific, pragmatic vision about the way forward that you intend to pursue.
I also really liked the to-the-point and witty non-technical cultural references and analogies with the physical reality that go a long way in exemplifying and clarifying the concepts, the attitude and the vision.
Specifically, I strongly agree with the following points you make:
- we live in an era of “information feudalism” (great characterization) with little to no control over our data
- applied cryptography has the potential to power digital sovereignty solutions but it has been severely hindered by failed efforts to make it widely available, mostly because of a widespread failure in understanding that the user and social interactions, relationships and structures (including regulations and the legal systems) are an integral part of the security challenge and need to be taken into account when designing a solution; hence, such a solution must necessarily be comprehensive in relation to all of these aspects
- digital transformation is ultimately dependent on successful, widely available, easy-to-use (correctly) and comprehensive digital sovereignty solutions
- most users doesn’t have the skills (or the will, or the time) to totally understand and control all the complexities inherent to their digital interactions and the information technology at their disposal and they shouldn’t be forced to; they must be able to safely entrust tools and parties if they so wish, i.e. radical disintermediation is a dangerous illusion (the reference to Marie Antoinette’s adage is great)
- trust is thus inevitably needed; it is first of all a human and social phenomenon that is intertwined with geopolitics and local legal frameworks so it must be tackled as such by digital sovereignty solutions
- a regulatory- and legal-aware design is at least just as important as a technically sound one due to (rightfully) strengthening data rights protection regulation (e.g. GDPR) and its non-trivial applicability challenges in the context of a decentralized infrastructure (especially if immutable such as DLT and even more so if public)
- email is the most widely used digital service, the most basic and widespread federated communication mechanism for both private and business matters and yet it’s ridden with fraud, insecurities and a frequent vehicle for malevolent actions and downright attacks; for this precise reason it is also a most logical and promising starting point for a digital sovereignty solution
- it makes the most sense from a user-centric perspective to sovereignty-enable existing services, reaching users where they already are, rather than build new, incompatible and thus inconvenient ones
- open-source commitment is key to shared, unobstructed progress benefiting everyone and, just as importantly, to strong security and resiliency
- siloed cloud provides must be effectively considered a central point of failure
- lack of transparency in IT business models results from service provider interests being at odds with user interests and smart contracts now have the potential to align those interests
- OpenPOWER is an interesting and forward-looking technological choice for servers due to its better architectural characteristics as well as its verifiability
- key generation locality and total key management participation of devices and applications is a very sensible design choice
- only re-using existing and widespread standards and infrastructure can ensure widespread adoption
Some suggestions/proposals and questions about specific parts follow below.
P.6: please consider using the more general term “Distributed Ledger Technology (DLT)” rather than Blockchain (I know, “blockchain” is more widely known and has become a kind of nickname for all DLT technologies), at least in general occurrences. In this specific sentence it may also help to further restrict the “decentralized networks with democratic oversight” (which is a great short general definition IMO) to the more specific class of distributed immutable ledgers.
2.5 Total decentralization, self-hosting are dead ends
P.9: I think “total decentralization” here can be generalized to “radical disintermediation” as in “Radical disintermediation is a dead end”; I’m proposing this because decentralization also has a technical connotation but the reasoning is more generally about a cultural and social phenomenon. This can also smoothen the claim that “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” (P.10) because “true believers in radical disintermediation” identifies more precisely the people that wouldn’t even trust recovery mechanisms built in wallets (or not even wallet technology tout-court) and would rather risk losing their assets. I also wouldn’t state that digital wallets ultimately come down as a set of recovery codes because there is a great variety of them (including custodial) and a lot of work is being done to advance recovery mechanisms that might also incorporate and build on social structures.
3. The user solution
Even though the mobile chat example is very useful to make the point about email, I suggest to also highlight the dangers for privacy brought about by universal identifiers such as a phone number or a single email address used for all communications, even worse if named after a person or a social security number (due to the high correlation risk that undermines the minimal disclosure principle) and to introduce pairwise identifiers as well as verifiable credentials; I think it’s also worthwhile to elaborate on how Vereign intends to tackle these topics (e.g. suggest using at the very least a different email address per profile and check for sensitive information in the address?) and integrate the relevant technological components (this also regards section 4).
Information minimization also allows control over personal versus functional communication, e.g. I don’t actually need to know the (real) name of a person helping me on a specific support case (modulo psychological aspects), only that she’s authorised support personnel and that the same person is handling the whole communication. This is especially important in business scenarios and it also relates to section 3.10 (Business Contacts).
This section also presents the opportunity to clearly and early state that all the information produced through these interactions (content but also relationships, e.g. the social roster) will remain under a user’s sovereign control.
Documents (3.4) and The archive (3.5)
Functionally, document management is an almost unbounded territory with so many solutions that range from unstructured collaboration support to collaborative editing backed by cloud storage to CMSs to DAMs (none of the existing ones especially concerned about sovereignty, true).
For example, a player in the “secure” (or even sovereign managed, not sure) collaborative document workflow is Orca AG; how does Vereign intend to differentiate?
I think it’s worthwhile to clarify how the archive could integrate with the communication flow also because email has the bad reputation of disrupting document collaboration workflows due to (unrelated and unversioned) copy attachments support. I think it would be unclear for many readers how document management can be meaningfully integrated with Vereign’s “sovereign email”.
The archive is a very compelling functionality because it both closely mimics and at the same time improves upon the paperwork pile everyone has at home, let alone even more stringent requirements for businesses. I think a more concrete functional characterization, if possible, would go a long way to increase the appeal and one or two short examples of how it would work would suffice for the white paper’s purposes.
3.6 Data Protection
More details about the tagging system (if possible) would also help; it can also be a good opportunity to mention the possibility of e.g. NLP-assisted tagging and in general ML-assisted communication and communication management enabled by a solution that fully and clearly models and manages all the relevant identity aspects.
Maybe this is the right place to mention the correlation risk when using the same identifiers, such as mobile number and email address, with more than one profile.
Explicitly stating that the (flawed) assumption “one email belong to one person” is dropped and made obsolete by profiles can also help but I think this is not enough to dissolve the correlation concern because it is indeed a very common case.
Also at P.14 I’d rather use “information minimization” in this context rather than “obfuscation” because it has a more logical and less technical connotation that I feel is more relevant here.
4. The technical solution
P.17 I think that providing a roadmap (even just qualitative, e.g. after the beta and before the token launch) for the release of the code as open-source can increase overall confidence and appreciation.
4.1 Technology stack
I suggest to detail further the reasons for choosing Golang as a server-side platform, for example Rust has lately become very popular in the decentralization space, including e.g. Hyperledger Aries and Indy, and is arguably a richer, more sophisticated systems language that also provides interesting memory protection features; for this reason I expect the paper’s technical public to wonder about that.
As for public blockchains it would be useful to elaborate about which Hyperledger projects are currently planned to be used and (briefly) how, e.g. Indy was designed to be especially suited to DID (as a DPKI infrastructure) and Aries specifies and implements P2P communication patterns for SSI and verifiable credentials use cases (and they enable Sovrin). The Digital Identity Foundation also specified SideTree as a viable DPKI infrastructure on top of public blockchains like Bitcoin and Ethereum (and others, through adapters). Elaborating more on the relationships with these projects and the organizations backing them would also engage the technical audience (I personally consider Hyperledger’s and Sovrin’s multi-faceted work truly exceptional).
As for VIAM, shortly contextualizing the choice of C++14 over Golang can also be useful.
Finally, providing more insight about the product development process (incl. e.g. which Agile methodology has been currently chosen or tailor-suited and why) can also increase confidence and appreciation.
It’s worth noting that these matters can also simply be the subject of engineering blog posts though.
At P.19 the architectural diagram is very interesting (thanks for it!) but perhaps a bit too detailed and might stimulate the technical public to ask about technical choices that could turn out to be transitory at this stage; e.g. why and how are Riak, dGraph, Badger used, what is the layout of the blockchain network and how is access control performed, if and how stateful is the Vereign system w.r.t. especially documents and crypto material ecc. I think this level of detail and discussion is well suited to be hosted on the forum and summarized by periodic engineering blog posts.
4.3 Blockchain and GDPR
P.20: hashed PII might also still be considered PII under the GDPR (and potentially salted and peppered hashes too), perhaps it is worthwhile to shortly cite the GDPR general guiding reasoning that any information that is potentially relatable to a natural person or correlatable to other PII and might allow identification now or in the future (e.g. through technological advancements) must be regarded as PII in order to comply with the strictest GDPR interpretations.
Also, “in the context of blockchain, …, in the context of” could be rephrased “In the context of blockchain, technologists specifically consider non-interactive zero-knowledge proofs”. I’d also remove the specific reference to zk-SNARKs because the field is going through an explosion of research and new techniques (e.g. Bulletproof, SONICs, Halo, STARKs, …) or at least I’d make it more inclusive e.g. with “for example zk-SNARKs” rather than “specifically zk-SNARKs”.
P.21: I’m still studying ZKPs and I’m by no means an expert but according to my understanding homomorphic encryption properties are only a part of the toolbox, for example CL signatures are also used in Jan Camenisch & co.'s Idemix, so I’d mention it as one out of a set of tools rather than the most prominent one.
4.7 Vereign Identity and Access Management (VIAM)
It is a very interesting section that I think deserves more space and more elaboration; for example: how do authentication and authorization relate (or do they) to verifiable credentials? Supporting frameworks such as OAuth 2.0 also raises questions about how (if) the auth provider will be harmonized with a SSI architecture.
4.8 Key Management
This is a very pivotal technical section and I suggest to highlight the most important concepts, justifying them and perhaps even adding some diagrams, for example: device authentication is (Vereign federated network) server-based, profile communication authentication is DID-based, profile content storage authentication is server-based. A diagram about the whole email or document signing could also be very useful.
Alternatively this could be a very interesting cryptography and security blog post.
4.9.2 Email signing on the blockchain
I think it would be useful to expand security considerations about email infrastructure such as: how to enable MTAs to signal on the blockchain (I’ve seen that MTA plugins are planned but I think it’s better to highlight it) and how to incentivize infrastructure owners to adopt them? Alternatively, pointing to the business and token sections will do.
Also, since part of the header is written to the blockchain as BCID, can it be assumed not to contain PII (it shouldn’t, as encrypted PII is still considered PII under GDPR) or should the system make an attempt to make sure of that?
A possible typo: the “Hashing and encryption of data on the blockchain” subsection lacks a final closing dot at P.27.
In “Signaling information definition” on P.28 these two sentences are not clear to me: “The identity mixer of Hyperledger 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.” How would this work?
Also, why should an emoticon or the reception confirmation be classified as PII if they are the only possible feedback? And are they and why?
So service endpoints act as (managed) SSI “agents” if I’m correct; then maybe it’s worthwhile to reference literature that explain these concepts.
4.10.2 Document signatures and the blockchain
I think the document signature mechanism through a one-time key could be better understood if illustrated by a diagram, in particular the private part transmission.
Also, since the IPFS ID includes a hash of the content, actually it seems to be correlated with the content and some GDPR concerns might apply if the document contains PII (just as in the encryption case), at least in strict GDPR interpretations w.r.t. blockchain technology; could you clarify this part? It is a widely used approach but I read e.g. in this report that it is currently unclear whether hash-linking of off-chain data can present PII risks (due to hashed PII still potentially considered PII).
4.11 Smart Contract template generator
I think this section introduces a vision for Vereign-authenticated documents to be associated with profile credentials and be able to unlock smart contract logic that allow to participate in some (e.g. economic-sensitive) functionality. It would be interesting to understand if you have already thought about how this document-to-credential process would work and if you plan to use SSI verifiable credentials.
Also, I think it makes sense to elaborate on the “smart contract template generator” terminology, does it refer to generate smart-contract backed questionnaires based on documents for specific or common cases?
5. The Social Solution
This section is also very interesting and inspiring as it deals with the digital governance structure for trust that parallels the national and international geopolitical ones and, as such, deals with a much broader vision than the initial email solution; I see it as an export of Swiss federal democracy culture to the (whole) digital world, further reinforced by the social franchising model (6).
It would be interesting if you could share more insight about direct democratic governance elements of the global organization, for example through a staked liquid democracy model (if planned) and also how the wider Vereign solution could integrate the legal, finance and regulatory professions; some concrete, briefly described user stories supported by hints about the underlying technological mechanisms would certainly be enough. The notarization use cases are especially interesting in connection with verifiable credentials.
Could you also spend a few more words about “electronic bodyguards”? It sounds like an interesting idea (interestingly expressed, too)!
6. The Business Solution
My business competence is quite limited but the social franchising concept sounds great; I read that it relies on traction and economy of scale that are further illustrated in section 7 and 8 but a quick summary would be useful in this section too, I think. Also, if possible, understanding better your relationship and planned (or even existing) agreements with IBM would also help grasping the growth potential.
In “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” could you clarify the dynamics? Is it related to the usage of the token as a loyalty and usage incentive vehicle (8.2.4 and further)? If so, I suggest to state it briefly here too.
It is a paper that commands respect, I really liked it and enjoyed it, congratulations!