White paper feedback

[circlespainter]

Personal highlights

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.

1.Introduction

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

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.

3.8 Profiles

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

P.18

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.

A similar observation regarding safety can be made about JavaScript versus TypeScript in my opinion.

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!

[circlespainter]

Another couple of notes:

• several companies are listed in the ecosystem section of the website, it would be interesting to better understand what type of interactions and connections exist with them, especially with those not (yet?) mentioned in the paper; this does not necessarily belong to the white paper, but still (personally I’m especially curious about the relationship with Aeternity)
• a plan for a 3rd-party professional security review of the cryptography, protocols and the overall system architecture would add to the transparency and peer review opportunity already granted by the OSS model; a public threat model would also be nice (e.g. the Aeternity people seem to have done an impressive job there)

[georg.greve]

Thank you so much for your thoughtful comments, Fabio!

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.

It’s fantastic to see this comes across to you. Indeed the first version of our white paper represents our vision, information and plans as of around summer 2018. As also discussed on our Telegram channel, it is probably time for an update, as we have learned a lot more since then and have made great progress in bringing our vision about.

Allow me to try and share some insights and feedback on the questions you’ve raised:

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.

Fully agreed.

The term blockchain has become problematic in a lot of ways to distract from the actual value of what we are building. Which is unfortunate, because DLT technologies are perhaps 5% of the technical stack at the end. It’s one of many technologies we employ towards a greater goal for our product.

2. Rationale

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.

That’s a very good observation. I think your formulation is better, so I would be happy to include it in the next version of the white paper.

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.

Agreed. This is definitely something to extend upon.

By the way: I believe mobile phone numbers or email addresses are somewhat less of a concern than social security numbers (SSN) or similar concepts because they can be changed and/or regenerated. SSN and personal identification numbers on the other hand are eternal and cannot easily be re-created. So much like biometrics once they are stolen, they remain stolen.

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.

A sensible point. We’ve meanwhile built most of this and are preparing to go live.

There are a lot of players in this particular field but based on what we have learned we are the first solution that can offer subscription based, unlimited e-signing (advanced & qualified) for corporations in a way that it white labels gracefully and is easily integrated into any environment or application - based on one time certificates which are robust even against CA compromise and backed by DLT for tamper proofing.

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.

Agreed.

This is a topic we did not yet have any time for - building a simple, usable solution was our first and highest priority. So there is still full flexibility in building this out and we’d love insights, contributions and ideas to this topic.

3.8 Profiles

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.

This is a point I think warrants more conversation.

A profile does not publicly expose an email address. If it contains one (or several) email addresses, these are shared only with the intended recipients of that information. Of course such a recipient would be able to correlate the email addresses from the profiles to the person. But then the purpose of sharing information via profiles with another person is to say “this is all my information/this information belongs to me.”

So it isn’t so much correlating information but rather multiple attributes of an identity having been shared with a third party.

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.

That makes sense.

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.

Agreed. At the time we wrote this, much of it was still at “this is the concept we’d like to try” and we were still assembling a team that could actually deliver on this vision. By now we’ve tried (and mostly validated) our assumptions of that time and we have a team that is working hard to deliver at a steady pace over the coming months.

So indeed a road map should be part of the next revision.

4.1 Technology stack

P.18

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.

The choice of programming language is always complex, in my experience. Our initial set of languages to consider included Golang and Rust, but also Erlang and some others. Aspects we considered:

• Security profile?
• Ecosystem size / libraries available?
• What language was used for the components we were likely to use?
• What is the availability of developers?
• Can developers from different backgrounds quickly become productive on the language?
• Native support for hardware cryptography offloading on OpenPOWER?
• Good choice for micro-service & federated architectures?

After weighing it all, and deliberating it for a bit, and considering the planned architecture along with the components we were thinking to use for it, we chose Go. It wasn’t the only possible choice, of course, but it seemed like the pragmatic approach.

I find this article fairly helpful in that regard, as well.

A similar observation regarding safety can be made about JavaScript versus TypeScript in my opinion.

That’s a valid point. We went with JavaScript mostly because of pre-existing knowledge and experience. Which then also influenced our choice for REACT JS for the front end. TypeScript + REACT certainly sounds like a pretty interesting combination.

There seems to be a migration path between them - and I certainly would not mind you trying to play with this to see how we can perhaps improve the overall solution that way.

What do you think, @gbodurov?

As for VIAM, shortly contextualizing the choice of C++14 over Golang can also be useful.

VIAM is written once in JavaScript right now, as that is useful for integration into browsers, as well as Gmail, Outlook and (in future) also Thunderbird. But then there are legacy applications with code bases that try to keep things as simple and clean as they can. An example of that is LibreOffice.

They would like a language that compiles well on all their platforms, and code with minimal external dependencies. C++14 seemed to fit that bill well enough.

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

Fully agree on your opinion on Sovrin. They’ve done awesome work based on the research of IBM’s lab in Rüschlikon near Zürich. This was one of the reasons why Hyperledger Fabric was our first choice for our prototype. The others being the closeness to the Linux Foundation and the fact that it was existing code we could actually look at and play with.

Ultimately Hyperledger Fabric turned out to be fairly painful, though. There is very little support for running it locally, and the IBM Blockchain as a Service platform offering Hyperledger Fabric was a rocky experience for us.

Going with a fully public blockchain was something we had considered for a while, and while we were open to talking with them all, aeternity was the one that we managed to build a relationship with. Not to mention they have some very interesting technical properties - starting from building it on Erlang - and promise good scalability also for a lot of small transactions. Which is why our current app.vereign.com is writing its audit trail to the aeternity test net.

Since DLT are such a young area it is probably too early to declare a winner. So we were careful to protect our technology agnostic approach for this part of the solution. We can ultimately use anything that gives us the functionality of a tamper proof, time stamped, distributed ledger.

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.

In my experience, process and team are always tightly linked. Like all teams it took us a couple of iterations and experiments to find an approach that works. We are currently doing two week sprints with
@kalincanov as our local product owner and coordinator. He’s working hand in hand with @gbodurov who is our Head of Development and responsible for technology choices and hiring.

We started out with releases after each sprint, but as we are now pushing for production we have decided to do fewer releases as each release takes a final round of QA.

We had exceptional UI/UX from the beginning, same as QA. Right now we have two automation QA experts on staff. On the tooling side we’re using GitLab with CI/CD always building for x86 and Power in parallel. For testing we’ve also set up Jenkins.

Extra cool is our unicorn bot, by the way, which we can trigger from Riot chat. You can just tell it to deploy you a certain branch or version, and it’ll grab all the repositories, build them, configure & deploy and ultimately provide to you at your personal URL.

It’s worth noting that these matters can also simply be the subject of engineering blog posts though.

I fully agree. In fact I wish @gbodurov, @sasha.ilieva, @damyan_mitev or @kalincanov would write a bit more. But they’re right now extremely focused on finally going production & general availability. Every day is an adventure right now, and it is hard to find the time to write - for everyone, myself included.

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.

Yes, these are exactly the kinds of conversations that the forum should be used for.

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.

Good point, and I am certain @felix.greve would very much agree with you.

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.

True. I think this part can definitely be improved. Was already a little concerned about the amount of technology at the time, and tried to not add more. Also, from the time of writing this to when this will be deployed I was quite sure we were going to see a lot more development in this area, as well.

So I’d love to revisit this based on the initial go-live and an assessment of the best options available then.

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.

This might be a longer article or set of articles, even.

Attempting a TL;DR style answer:

Most SSI architectures are focusing on the exchange of credentials and identity information only. But information must exist digitally in order to be exchanged. So in most architectures, that is a large number of proprietary silos which often will be competing against each other for user data. And yes: Every application that runs on a user device is a proprietary silo as long as the application itself is proprietary. It also is irrelevant for the user whether the data is encrypted on their device at this point: If they cannot control the software that controls their data, they do not control their data. This is one of the reasons for the uncompromising “everything must be Open Source” tenants of Vereign.

Also, these identity silos are often provided by companies whose business model is transaction based, and in competition with others offering similar things. A prime example of this are the companies that offer the creation of digital identities via digital onboarding and id card scanning.

A situation where proprietary companies compete against one another for the transaction fees of their users, only held together by an open standard layer for exchange of identity claims and information is not a stable platform. Once one of them reaches critical mass they will introduce “improvements” to the exchange layer that provide features and convenience. In reality, they create lock-in and a slippery slope toward a solution that is dominated by one vendor alone. Look at the history of SMBFS for reference.

The user is always at a loss here, having to administrate tons of digital identities on top of all of the accounts he already has. Of course those solutions would have the providers offer their own identity instead and allow log-in with them. But that’s again a limited market. In reality, it will probably behave more like the well known XKCD comic:

And all of this depends on the speed of adoption of SSI in the first place, whereas OAuth2.0 is widely used and deployed - and endorsed by the big five. It is easily set up, easily used, easily integrated, and has billions of users already. That’s a lot of networking effect.

Which is why Vereign

• Aggregates the verification of identity for any attribute of your identity as part of your actual core identity, which is then put into your hands by means of Open Source software and federated networks. That way you can take your different sources of identity and unite them under your control;
• Supports OAuth2.0 with selective data disclosure from this identity from the federated instances, allowing your identity and its profiles to easily be used anywhere OAuth2.0 is already supported.

This may not be perfect, but it is 10x better than what people are using today. And it will help with the adoption of the SSI based exchange layer on top of root identities that really belong to their users.

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.

Yes, you are right.

I’ve actually started to try and write an article on some of the benefits that arise from the above concept in terms of disintermediating Certificate Authorities to some extent. And how it will help us build a more robust trust ecosystem for digital interaction.

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?

This was the result of analysis by our Head of Legal & Compliance, @felix.greve. If it is important to you perhaps he can share some of the most important findings of his conclusion?

So service endpoints act as (managed) SSI “agents” if I’m correct; then maybe it’s worthwhile to reference literature that explain these concepts.

These are also some good points.

The email signatures have also seen some evolution based on our experience with document signing and overall usability and user experience - as well as our growing understanding of the benefits offered by the system in terms of less dependency on traditional CA models.

You’ll find some of this at Your V-Card will be your signature.

The entire section definitely needs some update work by now.

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.

Agreed. I am a big fan of diagrams. Whiteboards are one of the most important tools.

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

That is a good question - but perhaps rather for @felix.greve?

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.

We know that a good solution will exist there, but we did not yet have time to scope this out fully while using a SSI exchange layer like Sovrin.

Let’s build the simpler solution first, and then add the bells and whistles.

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?

Agreed, and this also is something not yet scheduled or fully developed in terms of UI/UX.

The idea is pretty simple: If someone wanted to offer certain services to users, they could specify what is the information they absolutely must have, and at which granularity level. For someone to buy a beer, knowing they are above 18 is good enough. For someone to open a bank account there is generally a lot more information required.

The solution can assist this for better usability by offering up only the profiles that contain the information required by the other side - or suggest to create a profile that fits the requirements when trying to use your Vereign identity in a certain place.

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

Yes, that is exactly what I was thinking of.

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.

I’d love to share more insight, and this is going to have to undergo its own stages of evolution.

Any new idea always starts from the first network, the first user, and then grows from there. When we wrote this, ICOs were still “a thing” so we were even wondering whether a coin offering might have been a way to finance the bootstrapping of a larger infrastructure with more organisations from the start.

But we felt we first had to build a good part of the solution before even being able to consider this, and by the time that was sufficiently far advanced, the climate had changed from positive to negative.

So we’re now focusing on delivering value first, and then growing it out step by step.

Which means this section also needs a bit of a rework.

Could you also spend a few more words about “electronic bodyguards”? It sounds like an interesting idea (interestingly expressed, too)!

I should say it’s not my invention. Peter Houppermans was the first I met who wanted to provide this kind of service. It’s essentially the realisation that many people - especially affluent individuals - tend to not be technically savvy and require the assistance of a trusted, competent person or organisation to protect their digital selves.

To me, this reflects a solid understanding of what we can expect from people in general, and how the world actually works for people. The option to rely on trusted service providers must be party of any system design, I believe - or else the solution won’t be usable for a majority of people.

6. The Business Solution

My business competence is quite limited but the social franchising concept sounds great; […]

The business solution also needs substantial rework, especially given that the dynamics of bootstrapping it are now somewhat different. But the social franchising concept will remain along with the revenue sharing approach for service providers in the ecosystem.

A solid revenue model and business is absolutely crucial for any such idea to gain enough traction to succeed.

Bonus Questions

• several companies are listed in the ecosystem section of the website, it would be interesting to better understand what type of interactions and connections exist with them, especially with those not (yet?) mentioned in the paper; this does not necessarily belong to the white paper, but still (personally I’m especially curious about the relationship with Aeternity)

Aeternity is the blockchain on which we are writing the audit trail - see above.

They are also investors into Vereign as part of our seed extension round.

Writing all of the above has taken a little longer than anticipated, so if there is a question about any specific partner on the site, feel free to ask.

• a plan for a 3rd-party professional security review of the cryptography, protocols and the overall system architecture would add to the transparency and peer review opportunity already granted by the OSS model; a public threat model would also be nice (e.g. the Aeternity people seem to have done an impressive job there)

Yes. Peer review is essential. We’ve had a strong advisory environment from the start, as well as a lot of experience ourselves. Next we plan to work with external parties to have both concepts and implementation reviewed.

Participation on any of the above, as well as the revision of the white paper is very much welcome!

[circlespainter]

@georg.greve Thanks for the really informative, interesting and comprehensive answer!

By the way: I believe mobile phone numbers or email addresses are somewhat less of a concern than social security numbers (SSN) or similar concepts because they can be changed and/or regenerated. SSN and personal identification numbers on the other hand are eternal and cannot easily be re-created. So much like biometrics once they are stolen, they remain stolen.

Absolutely.

A sensible point. We’ve meanwhile built most of this and are preparing to go live.

Great, looking forward to seeing the archive functionality in action soon then!

This is a point I think warrants more conversation.

A profile does not publicly expose an email address. If it contains one (or several) email addresses, these are shared only with the intended recipients of that information. Of course such a recipient would be able to correlate the email addresses from the profiles to the person. But then the purpose of sharing information via profiles with another person is to say “this is all my information/this information belongs to me.”

So it isn’t so much correlating information but rather multiple attributes of an identity having been shared with a third party.

True, in addition not only emails are correlatable but other information as well, so perhaps it would be sensible to issue some kind of warning when the same information is shared across multiple profiles as that may be unintended; on the other hand my understanding is that at least one email address is always shared with the recipient in one way or another to allow for a reply (BTW the “no-reply” case could be interesting to explore) and mandatory information presents more opportunity for (unintented) correlation.

The choice of programming language is always complex, in my experience.

Definitely true and I also agree with the article’s main theme that Go VS Rust is somewhat like Java VS Kotlin (or perhaps Scala or Clojure), i.e. less powerful but easier to learn and to find devs proficient in it; admittedly I’m somewhat biased in my preference for richer/more elegant languages and type systems due to my language-oriented academic and professional past as well as experience in languages with a steeper learning curve such as OCaml, Scala and Clojure; my time and effort investment was significant then but it really turned me into a programmer that can pick up comfortably and quickly new languages and paradigms (e.g. starting with Rust was not that difficult for me personally, a couple of small but significant OSS contributions took me 3 days starting just from a basic Udemy course).

Actually in past technical lead roles I have chosen myself simpler languages in order to end up with a code base maintainable by a team of people with different profiles and experiences, so I understand the compromise. And then of course there are also all the other aspects you mentioned.

Perhaps I’d suggest to add to the paper just the points you mentioned above as a more detailed explanation (or something more extensive in a future engineering blog post).

That’s a valid point. We went with JavaScript mostly because of pre-existing knowledge and experience. Which then also influenced our choice for REACT JS for the front end. TypeScript + REACT certainly sounds like a pretty interesting combination.

There seems to be a migration path between them - and I certainly would not mind you trying to play with this to see how we can perhaps improve the overall solution that way.

WIth pleasure, as soon as the sources are available you’ll see me there hacking Actually I did the same porting recently for a project of ours.

VIAM is written once in JavaScript right now, as that is useful for integration into browsers, as well as Gmail, Outlook and (in future) also Thunderbird. But then there are legacy applications with code bases that try to keep things as simple and clean as they can. An example of that is LibreOffice.

They would like a language that compiles well on all their platforms, and code with minimal external dependencies. C++14 seemed to fit that bill well enough.

Understood, perhaps that’s a good point to add to the paper as well.

Going with a fully public blockchain was something we had considered for a while, and while we were open to talking with them all, aeternity was the one that we managed to build a relationship with. Not to mention they have some very interesting technical properties - starting from building it on Erlang - and promise good scalability also for a lot of small transactions. Which is why our current app.vereign.com is writing its audit trail to the aeternity test net.

Oh so I see now how you relate to Aeternity; yes their tech stack is very interesting indeed and I’ve been meaning to learn myself some Erlang/Elixir for a long time. Actually I was part of the Parallel Universe team and we built concurrency abstractions on top of lightweight threads, such as channels and actors and an OTP-like framework, that were largerly based on Erlang’s model; in some cases we even tried out things in Erlang/Elixir when the docs were not enough to figure out the behavior of an abstraction that we were “porting” to the JVM.

I don’t know their platform too well yet but I know they heavily rely on state channels and were among the first ones to do so 2-3 years ago; nowadays that approach is not considered “bleeding edge” anymore due to the lots of sharding and ZK (and generally off-chain trusted computation) research that has happened but they do seem to have built a very concrete platform for real-world usage that is gaining traction so personally I’d really like to study and contribute to their platform.

Since DLT are such a young area it is probably too early to declare a winner. So we were careful to protect our technology agnostic approach for this part of the solution. We can ultimately use anything that gives us the functionality of a tamper proof, time stamped, distributed ledger.

I think this consideration too could make its way into the paper more extensively.

So true, if there’ll be such a thing as a “winner” at all For this precise reason ledger abstraction is a sensible approach that is (rightfully) being adopted across the industry. I honestly expect rather standardization and federation than single dominance, e.g. things more like Polkadot, Cosmos/Interchain, Interledger/Quilt and Ethereum 2 itself; today’s dominant technologies will also evolve to incorporate the latest research in major re-writes with an eye on backward compatibility or migration paths (just like Eth2).

In my experience, process and team are always tightly linked.

Absolutely, that’s why I think that the most successful processes are not verbatim from literature but rather evolutions tailored to the team after the internalization of the principles, rather than the form; still I strongly believe in the power of process awareness so it must be a serious and explicit effort to bear its fruits: I’ve heard too often “we’re kind of agile” with nothing to say beyond that (which basically results in chaos).

I fully agree. In fact I wish @gbodurov, @sasha.ilieva, @damyan_mitev or @kalincanov would write a bit more. But they’re right now extremely focused on finally going production & general availability. Every day is an adventure right now, and it is hard to find the time to write - for everyone, myself included.

Very understandable, looking forward to reading more when you’ll be able to spend time on that!

Most SSI architectures are focusing on the exchange of credentials and identity information only. But information must exist digitally in order to be exchanged. So in most architectures, that is a large number of proprietary silos which often will be competing against each other for user data. And yes: Every application that runs on a user device is a proprietary silo as long as the application itself is proprietary. It also is irrelevant for the user whether the data is encrypted on their device at this point: If they cannot control the software that controls their data, they do not control their data. This is one of the reasons for the uncompromising “everything must be Open Source” tenants of Vereign.

Couldn’t agree more, trusted/verifiable execution is indeed a weak and painful matter in the whole “trustless and secure” story and it extends down to the underlying hardware.

The clarification you provide further down is very enlightening and I think it should also find its way into the paper.

I’ve actually started to try and write an article on some of the benefits that arise from the above concept in terms of disintermediating Certificate Authorities to some extent. And how it will help us build a more robust trust ecosystem for digital interaction.

Looking forward to reading it!

Let’s build the simpler solution first, and then add the bells and whistles.

Sure, definitely OK, especially considering that you already state so in the paper itself.

Participation on any of the above, as well as the revision of the white paper is very much welcome!

I definitely would like to stay in the loop and help out, looking forward to it and thanks for your openness!