Stay informed – Subscribe to our Newsletter

Our newsletter offers the latest news as well as useful information about Berlin's economy. Receive regular information about new posts on reason-why.berlin.

IDunion is working on a blockchain-based solution to make identity verification on the web easier
07.11.2022

Tell Me Who You Are – ID Sovereignty

Making logins, online purchases, and verifications safer – with a blockchain?

How many times a day do you have to log in to some service or other, or register with some provider, or give your details away when you order something on the internet? 

And how often have you been lazy and used convenience services such as ‘sign in with Google’ or ‘sign in with Facebook’?

Every time you sign up on some website or other, you’re creating a digital identity in some CRM (customer relations management system), i.e. in some database or other. The company using the database sees your details, as does, at least potentially, the company providing the database platform, which is likely to be an online service, and likely not using servers in your country. 

The basis of your entry is usually your email address. It is quite possible that the foundation of who you are, your unique identifier, is different from one CRM to another, depending on which email you used. In any case, there are details concerning you floating around the global internet in all sorts of scattered databases. 

And of course there’s the bother of managing all those passwords. We’re always told to use a different password for every service, and our passwords must not be too simple either. Ideally with 32 characters, including numbers and symbols and capitals. How are you supposed to remember all that? 

Modern sign in solutions send temporary codes with which you log on, but it all still relies on the good old email address as identifier. 

The German project IDunion is tackling these complex identity issues with the aim that everyone (including natural as well as legal persons and things) can manage their identity information themselves and decide when they want to share which data with whom. In this way, says IDunion, “technology companies are no longer acting as a central identity manager, but the user himself! The user can decide where the information can be seen, which program is used to manage information and with whom this information is shared. We call this concept the self-sovereign identity.”

IDunion proposes a complex solution based on decentralized distributed ledger technology, in other words, a blockchain.

One of the partners of IDunion is the Technical University Berlin. We spoke with Professor Doctor Axel Küpper about the project, its use cases, and the blockchain technology behind it. Prof. Dr. Küpper is an expert on distributed ledger technologies, token economy, self-sovereign identity, emerging blockchain-based applications, blockchain analytics, and decentralized online social networks.

Expert in decentralized ledger technologies and advocate of self-sovereign identity Prof. Dr. Axel Küpper
Sovereign over his identity: Professor Doctor Axel Küpper of the Technical University Berlin – © TU Berlin SNET

Professor, you are “an advocate of decentralized systems and applications”. In simple terms, what does that mean, and what are the benefits?
In its purest form, the term decentralized application means that we can implement digital services without the need of central servers. I know that there are many hybrid forms between central and decentralized applications, but in the perfect form it means that we implement applications on a pure peer to peer basis, and in this sense, decentralized applications represent an alternative to the large hyperscalers like Amazon, Facebook and Google, and therefore they are more appropriate for saving the privacy of users.

The IDunion solution is based on distributed ledger technology (DLT). Can you explain in three sentences what that is?
Well, a distributed ledger is a peer to peer system that goes back to the invention of the Bitcoin system, a cryptocurrency that was invented as a result of the last financial crisis in 2008. Bitcoin enables the execution of value transactions like the transfer of cryptoassets without the need of a central bank. The idea is that each participant in such a network maintains the ledger, the Kassenbuch. So it's basically a script for storing transactions. And the distributed ledger maintains so-called consensus mechanisms where the participants in the system agree on what transactions are appended to the ledger and which do not get on the ledger. Meanwhile, distributed ledgers are not only used for conducting value transactions but also for storing public, non-critical data like we do in the IDunion project.

One of IDunions many use case projects is the digital student ID, which you are implementing at the TU Berlin. Would you describe the idea behind the project and how far it is already being put into practice?  
So the idea behind the IDunion is to implement a new paradigm for identity management. We have seen two or three other paradigms before. One of them being central identity management, where a central identity provider stores all the identity attributes of a user. The idea of the IDunion project is to get rid of that and implement something that is called a self-sovereign identity

In the context of the student ID, this means that the Technical University, for example, is a so-called issuer that issues the student ID. So on the student ID, you have several attributes like the matriculation number, the name of the student, birthday, and so on. And this is digitally signed, which results in a so-called verifiable credential. And the issuer then hands over this credential to the user. And the user is 100% self-sovereign where to store, for example, this credential, this student ID. 

In our use case, we have so-called wallets, small apps that are implemented on the users’ smartphones. You can view this wallet as a kind of container for storing all the credentials the user received and maintains, among them the student ID. And in a particular use case, for example, if the student has to prove that he is really a student, he can present this credential to a so-called verifier. For example, the cinema where he wants to get a student discount for watching a movie.

So the digital wallet to “receive, store, manage and present digital credentials” is on your mobile phone. What happens if you lose your phone or it breaks or it’s stolen?
So then you can think about different solutions for that. One of them is, of course, a kind of hybrid approach again, where the credentials are also stored in a backup that is located somewhere in a cloud. But it is important here that the user has the free choice of which cloud to use. 

In another scenario, you can imagine revoking the credentials of the user so that there is a mechanism that the issuer of the credential in question can simply say, okay, these credentials that were part of the wallet that is lost are now revoked. Not valid anymore.

The wallet with all your data is on your phone. Surely a phone can be hacked as easily as a CRM database?
Yes, that’s true. But we have for many phones dedicated hardware that is safe from being hacked. This is a trusted execution environment and it is possible to store very sensitive information in this trusted execution environment.

The verifiers: in your example, the cinema. But it could be something else as well. Some bigger organization or company. The benefit for companies is that they receive a verified ID. So their CRMs are then filled with validated data. What information do companies get along with the ID? Doesn’t that mean less anonymity for the user, who might otherwise sign on with just an email …?
It’s subject to the user which information to disclose. Of course you have a particular application. So in the case of the cinema the name of the user and maybe his birthday are not relevant and do not have to be disclosed. It is only important that he is subscribed as a student at a particular university. 

The user can of course choose which information to disclose to the verifier, that is the information that is absolutely necessary for the respective use case.

The decentralized way that blockchains store data means that every node in the network has all the data locally. These nodes are operated. How is the operation of such a node rewarded in IDunion? 
I would like to mention another important thing here. First off, IDunion is a technology stack that works on two different layers. On top is the self-sovereign identity idea, where you have a role play between issuer, identity holder, and verifier, as explained before. And below that you have a distributed ledger that works as a new public key infrastructure. 

It is important here that the distributed ledger does not store any personal data. So the credentials are only stored in the wallet of the user, not on the distributed ledger. 

Rather, the distributed ledger is required for storing information regarding the issuer's public identity, which can then be used or verified against by verifiers. In the ssi paradigm an abstract long token called decentralized identifier, or DID, is used to reference issuers and other entities, for a tight coupling between that identifier and the public key necessary for verification processes. So whenever an identity holder like a user of a verifiable credential sends it to the verifier, the verifier gets the issuer's public key from the ledger to validate the credential. But the distributed ledger does not contain any personal data. This is the first part to mention. 

And the other thing is that of course it requires incentives for the operators of the distributed ledger to participate in IDunion. We follow an approach that IDunion asks for a small fee for writing operations on this distributed ledger. Whenever the new identifier is created, then this requires a write operation on the ledger where you submit the so-called DID document that binds the DID of an entity to its public key that is needed for verifying a digital signature, and thus for verifying the credential that has been issued by the issuer. So for writing a DID document onto the ledger, we could imagine asking for a small fee from the person submitting. In general, IDunion follows the idea of a non-profit organization. But of course, the institutions who run a node need to get some part of the fees to compensate their costs for running their node. 

Does the IDunion ledger use a proof of work or proof of stake consensus algorithm, or some other concept?
You can basically use any decentralized system that is able to be tamper proof. So a distributed ledger is. From the cryptocurrency world, we have basically two different mechanisms. They are proof of stake and proof of work. Proof of work, as you know, has, of course, severe problems, energy consumption, etc.. And of course, a promising alternative is proof of stake, which I would say is not as secure as proof of work. Proof of work is applied mainly in public networks so that basically each participant can be part of the distributed ledger. 

In our scenario, we have created a European cooperative consisting of many players that will operate the distributed ledger. And this is a permissioned, closed ledger where not everyone can participate. 

It is based on a consensus algorithm called Indy Plenum. Plenum makes use of Redundant Byzantine Fault Tolerance or RBFT, which is, to some degree, robust against malicious parties while not suffering from a high energy consumption or value staking. Every node and operator of the network has the same chance to write a transaction on the ledger.

So that’s the project partners, then?
Yes.

Bosch and all the rest of them.
Yes. We have in the IDunion project many partners, some large companies but also small startups, who want to participate in this network. And they are the ones operating the ledger. At the moment we are still in the test phase. We have, as far as I know, 15 to 20 nodes at the moment, and a lot of more partners have announced plans to join the network.

You mentioned it yourself that especially the proof of work algorithm has energy issues. Some blockchains use up as much energy as a small country. How much energy does each IDunion transaction, each ID verification, use up? Is there a way of measuring that already?
Not as far as I know, no. We are still in the test phase. And it is, of course, our goal to implement a solution that does not show the problems as we saw them in the Bitcoin network. So this is a subject for further investigations, but be sure that we do not have this kind of energy problem by far, because with Plenum and RBFT we use a different approach, as I pointed out before.

And the problem with proof of stake is that basically those who are willing to pay most will get to append the next block, right?
Yes, this is, of course, a trend again towards more centralization, which in particular is a problem in the field of crypto currencies, but not in IDunion. The higher the stake of a participant or node, the larger is the power of the node. The chances to write the next block are higher then. 

The larger nodes there have more power. But, as all of these partners are more or less trusted, I don’t see a big problem in that. I mean, it is just for the consensus algorithm. So the node who has submitted the most funding or the greater part of it, the most stake, can decide about the next block. 

The blocks themselves do not contain the data. You stated that quite explicitly. So they basically just record that there was a transaction, that there was an identity transaction, right?
The ledger is mainly used for storing DID documents and some additional data that is needed for enabling the revocation of credentials and schema definitions of credentials.

The way the data items are linked together means that they are unchangeable. They’re immutable. If a transaction has taken place, you can’t change that within this blockchain. So what happens if somehow some faulty or fake identity verification has taken place? It's impossible to delete or change or correct? 
There are two answers here. The first thing is that, of course, in case your private key got compromised, it is possible for the issuer to submit an updated version of the DID document. So it does not mean that the original DID document is deleted, but the new version is submitted. This is the first point. It must be possible, of course. 

And the second part of the distributed ledger is to maintain revocation lists. So in case a certain credential is not valid any longer, for which you can imagine different reasons, then it's possible for the issuer who issued the credential to revoke it. And this revocation is also on the revocation list which is also maintained by the distributed ledger. 

The longer this ledger gets, the longer it takes to search through it, right? Also, decentralized almost by definition means slow because you’re checking all the nodes against each other. And if millions and millions of Europeans are using this system on a day to day basis, how can the system possibly perform adequately? 
I wouldn’t say that the ID union network will be the only network that is used for self-sovereign identity. I expect to see many dozens of distributed ledgers that are part of different ecosystems. And the challenge, of course, is to make them interoperable.  Compatibility is an important challenge here. And this means that we won't see scalability problems that are so hard to manage. 

The other thing is that not read operations cause scalability problems. As each node holds a full copy of the ledger you can contact each of them to get the required document. The scalability problem is caused by write operations as each change on the ledger has to be communicated to all nodes. And in our particular use cases, I see that we have many more read operations than write operations. 

Furthermore, we have meanwhile powerful ledger technologies at hand here, so that I don't expect to see these problems. If scalability problems will occur, I could imagine having multiple distributed ledger systems interconnected, I don't know, in a hierarchical fashion so that you can easily handle the scalability problems.

Doesn’t decentralized also mean unregulated? The Bitcoin or the other crypto blockchains are unregulated. Aren’t most blockchains unregulated? Is this one?
You mean, whether there exists a legal framework the distributed ledger is based on?

A legal framework or any kind of regulation, yes.
So we follow GDPR, the General Data Protection Regulation, and eiDAS, the electronic identification, authentication and trust services. But apart from that, there are of course other legal problems that still need to be solved. I would like to see a legal framework for issuing one’s ID in general, the Personalausweis [the German identity card], basically. 

And once we manage this, then this ecosystem will become very vital, because you have a root of trust with this ID. And as long as we don't have this root of trust, then we will of course see legal problems, especially for regulated use cases where a national ID is required.

So the question is always, do we follow up a top down approach here in that the government takes action and by establishing a root of trust with the ID card and implemented with ssi and underlying ledger technologies, or whether we will see a bottom up approach in which many different domains like education, health, industry 4.0, and others, implement such solutions, so that the government then says, okay, this is a very powerful approach and we will now implement the legal framework for it. So as things are going in Germany, I guess we will see the bottom up approach, because the government authorities and administration is always behind digitalization. As you probably know.

Thomas Jarzombek, who is representative of the digital economy and startups at the Federal Ministry for Economic Affairs and Energy, BMWi, said in a press release, “I think it is important that there is a state secured identification option for smartphones which functions without a hidden commercial agenda with regard to user data.” But Commerzbank, one of the biggest banks in Germany, is deeply involved in this project. And the Hyperledger blockchain technology, which underlies it all, received contributions from IBM, from Intel, from SAP, and early members of Hyperledger include Deutsche Boerse Group and US giants like J.P. Morgan and Wells Fargo. In the Hyperledger steering committee, you'll find people from Accenture. So basically, in a deeper level, there are a lot of commercial interests involved, and not only European ones.

We as IDunion consortium are not following a commercial agenda that is hidden. However, I'm convinced that it won't work without any commercial incentives at all. I guess what he wanted to say is that the underlying business model should not be big data. So we want to get rid of business models where large companies collect tons of data from their users and use them for commercial purposes. This is exactly what we wanted to get rid of here in Germany and also in Europe. 

But if you want to establish a peer to peer identity management system that has an impact on society, of course there need to be commercial incentives. And the major players here are part of the distributed ledger where, as I said, no personal information is stored, but it must be possible that each of these players implement on top of that their very tailored ssi solutions. And of course it should also be possible to implement business models on top of that, as long as the self-sovereign identity ideas are fulfilled and given. Namely that the user has 100% control about where his data is stored, how it is processed and so on. 

The IDunion website says, “the data transfer history allows the user to easily see who has received his or her personal data, as well as when, for what reason and with what rights.” To this end there is a ‘Block-Explorer’ with which you can search for entries such as schemas or credential definitions. How does this work? Is it by taking all the entries and putting the info into a conventional database which is much more searchable?
The block explorer again does not contain any personal information. I mean, it is just a tool for browsing the transactions stored on the IDunion ledger, and these mainly include the DID documents, the revocation list, and of course, the schema. The schema is some kind of semantic definition of what credentials should look like. And it does not contain any personal information. It is publicly available. Everyone who wants to issue credentials must, of course, know the semantic structure so that the verifier can of course understand the credential. And, actually, if you want to download parts of this block explorer, for example, schema definitions, then that is no problem.

What are the next milestones for your project at the TU and for the IDunion as a whole?
For IDunion as a whole it is of course the foundation of the European cooperative which implements the distributed ledger. So we are basically on a good path and we can very soon start with the implementation and bring this to the operational phase. At the moment it's only a test phase. 

And for the TU Berlin, it's of course bringing ssi to the whole student life cycle. So starting from issuing a student ID to final degrees. Now if the student gets a master's degree here, then it is still paper based. And yeah, this is somehow old fashioned. Of course, ssi has the potential to implement it in form of a digital version. And the challenge here is, of course, to make it compatible so that future employers or potential employers, wherever the student applies, can receive and interpret the credential with the student's degree. And yeah, starting from the matriculation of the student until the ex-matriculation, there are a lot of administrative hurdles on the side of TU Berlin, which of course makes it difficult. But yeah, we have to integrate the ssi into our existing student lifecycle management systems. All of these are major problems that still need to be solved.

So there’s a lot of work ahead. Can you say something about how Berlin fits into this project and what you’re doing?
I mean, Berlin is a wonderful playground for testing and implementing ssi solutions, because Berlin is very diverse. Berlin is very innovative. We have a rich ecosystem here of many different application domains. I don't know, 35 universities, many research institutes and tons of startups, each of them coming up with their own applications and services. So there’s a lot of potential here for implementing ssi.

Absolutely. Thank you very much for your insights and the explanations.
 


Interview: Olaf Bryan Wielk, ideenmanufaktur
Header image: © Adobe Stock

Get news and information about Berlin’s business, startup, and science scenes.

Sign up for the latest articles on reason-why.berlin.

Subscribe now

More articles

Previous Next