re:claimID - Self-sovereign, Decentralised Identity Management and Personal Data Sharing [YBTI/wefixthenet session]
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Felde, Hendrik Meyer zum
Schanzenbach, Martin
In this talk we present re:claimID, a decentralized, self-sovereign identity management system. re:claimID allows users to reclaim authority over their identities and personal data. The system is built on top if a state-of-the-art, decentralized directory service: The GNU Name System. Built-in cryptographic mechanisms allow users to selectively disclose personal data and the directory service ensures that this data is accessible to authorized parties even if the user is offline. Through OpenID Connect, integration and use of re:claimID is straight-forward and authorization flows are familiar. In this talk, we present the current state of re:claimID as well as a future roadmap. Today, users are often required to share personal data, like email addresses, to use services on the web. As part of normal service operation, such as notifications or billing, services require access to - ideally fresh and correct - user data. Sharing attributes in the Web today is often done via centralized service providers to reduce data redundancy and to give services access to current, up-to-date information even if the user is currently offline. Abuse of this power is theoretically limited by local laws and regulations. But, the past has shown that even well-meaning identity providers struggle to keep user data safe as they become major targets for hackers and nation state actors while striving for monetizing anonymized statistics from these data. We advocate for a new, decentralized way for users to manage their identities for the following reasons: * The current state of omniscient identity providers is a significant threat to the users' privacy. * Users must completely trust the service provider with respect to protecting the integrity and confidentiality of their identity in their interest. * The service provider itself is facing substantial liability risks given the responsibility of securely managing potentially sensitive personal data of millions of users. We present re:claimID, a decentralized identity service with the following properties: * Self-sovereign: You manage your identities and attributes locally on your computer. No need to trust a third party service with your data. * Decentralized: You can share your identity attributes securely over a decentralized name system. This allows your friends to access your shared data without the need of a trusted third party. * Standard-compliant: You can use OpenID Connect to integrate reclaim in your web sites.
 Now I'm very happy to introduce Hendrik Mayer-Zumfelde, who will speak about a reclaim ID that is helping to build a self-serverine decentralized identity system. So thanks a lot. Hello, everybody. Hello. Hello, everybody. First of all, thank you for making this speech possible. My name is Hendrik Mayer-Zumfelde, and today I want to present to you a tool which was developed at the institute where my colleagues and me work. We work at the Fraunhofer Eisek. It's an IT security institute located in Munich, working in close relation with the technical University of Munich. And my colleague Martin Schanzenbach is the leading programmer of Reclaim ID. And let's get started. But before I present the tool itself, I want to tell you something about the motivation behind the tool. So we all know identity providers. Most of us may already have used some of these. And basically, if you think of things like Facebook or Google, it allows you to perform a login at other websites or services. And the first advantage of identity providers is, of course, comfort. You don't have to remember hundreds of passwords or user credential sets in order to log into a website, but you can simply use an identity provider instead. And you have the possibility to manage your identities at a single entity. And of course, people have gotten familiar with identity providers. Another main advantage of identity providers is the liability, because some websites or some parties may suffer from legal issues, and it's easier to outsource the protection of identity data to an identity provider. And what you can see here is basically a scheme which shows some measurements taken in the year of 2014 and 15. And it shows on the left-hand side what percentage of identities are stored at which identity provider services. And the main point that you can easily see is, of course, Facebook has about maybe more than 60% of all the identities that are used on the web. And it's followed by Google with about 20%, followed by Twitter with about 6% of the identities that are used to log into other websites, followed by Yahoo and LinkedIn and other small identity providers. And the main point, what you can see here immediately is basically the market share of identities is highly focused on very few companies. So basically, Facebook and Google control more than 80% of the identities. Why is this an issue? Well, first of all, if few companies control whenever a user wants to log into a website and performs the login steps for the user, it's possible to use this information and perform targeted advertisement or perform steps to create opinion shaping. And on the other hand, in the context of this conference, it's of course clear this data can be used for mass surveillance and data collection. And this is an issue. On the other hand, another liability risk is at hand because if one single identity provider like Facebook controls all the identities of the people, then basically there's a single point of failure. And if this company is hacked, it may suffer from an existential legal issue due to the general data protection regulation. And of course, another issue which is at hand is basically that an oligopoly may occur, which is basically a monopoly which is shared by multiple parties. So you may have the issue that too few parties have too much control over the market of identities. And so far, no federation is widely practically used yet. Okay. Here's a quote, everyone needs complete control over who they share personal information with at all times. Do you have any idea who said this? Okay. It was Mark Zuckerberg. Yes. And of course, it seems a bit ironic in the context of this conference. But what he meant was he wants users to have full control of their data within the realm of Facebook. But we want to break out of this realm of a third party that we want to trust. We do not want to trust a third party at this point. And some of you, I mean, most of you probably already heard about stories like these. Just an incident, Yahoo a couple of years ago lost a billion credentials of users and some other incidents like the Facebook, Cambridge, and a Lutica scandal. These things just reveal that these things occur often. I mean that it's a real problem that we are dealing with here right now. Okay. So for the tool that we created, the primary objective is this. We want users to exercise their right for digital self-determination. We do not want to have a third party involved for the management of the identity or the data sharing. We want it to be open, free, and we want to use a decentralized service, which is not under the control of a single organization or a business or something like that. And we want the software itself to remain free. And here comes the name. We want users to empower themselves to reclaim control over their digital identities. That's why the tool is called Reclaim ID. Okay. Before we get further to the tool, it's important to understand what the purpose of an identity provider is. And basically there are two different main areas. The first main area covers the following things. They are partly already mentioned. First of all, you want to provision your identity to other services. You want to maintain control. You want to allow the management of the identities. And you want to be able to share your personal data with third parties. And you want to be able to update your information. And you want to enforce your authorization in the service that you're using. The second main part is about identity information verification and the attestation about it. For instance, you may have an email address and often some identity providers offer an additional service just to attest the email that is used at hand. Or maybe some other service may say this person is actually living in Germany and this is a true fact, for instance. So these two main areas are covered by identity providers. And Reclaim ID focuses on the first area. So we want to solve all the tasks that are explained in the first set. And the second part is not yet our department, but we are working on it. And I will get to that point later on. Okay. Time to introduce Reclaim ID. First of all, Reclaim is a self-sovereign personal data sharing system. And if you know about this realm of software, then you may think of other tools that implement similar behavior. Some other ones are, for instance, sovereign, U-Port or name ID. And sovereign is based on a hyperledger. And it's basically using a permissioned blockchain. And whenever we use a blockchain, then we cannot make it free anymore because at some point there's a fee to pay. So this was not a good option for the project that we wanted to create. U-Port is using Ethereum, which is also a blockchain. And another downside is that the data could not be accessed anymore if the user was offline by third parties that actually should share the data. And name ID had some good ideas which were actually taken for additional steps that we took. But the main downside at this point was that all the access had to be performed through one central server. And this is a limitation. And we wanted to create Reclaim in such a way that we do not require a blockchain. It should be fully decentralized. And it should be possible to access the data of the users in an asynchronous way. So basically in a nutshell, Reclaim ID is, first of all, a decentralized directory service and it's combined with cryptographic access control. Those are the main elements. OK, most of you probably already know directory services. If you think of the x.500 standard, you may know LDAP or Active Directory, which is a commonly used directory service in Windows systems. And you already know name systems, for instance, like DNS, which is the domain name system. Whenever you look up a website like Google.com or whatever, it translates the name to a given IP. And the interesting thing is using these namespaces, you don't, it's not only possible to save IP addresses and strings or whatever, but you can actually save a lot more different kinds of data in these systems. And the decentralized directory service that we are using is heavily based on the GNU name system, which in the following part of the talk is abbreviated as GNS. And the GNU name system basically allows you to perform an S lookup, for instance, check up email.bob.org. Who is this? And the answer will be, this is the email that is located there. And the great thing about the GNU name system is that it natively supports the encryption and the digital signature of certain resource records. And we can use these features to protect the identity data from unwanted disclosure. And we can actually enforce control using these features. Okay, so how does it actually work? What you can see here is basically a scheme which consists of three main parties. On the bottom left, you see the user which has a browser plugin installed in the web browser that is being used and is able to locally set up a reclaim identity. So the plugin is installed, it started, and the user is able to create a new identity with maybe a name like the typical name John Doe or whatever, his email address, and date of birth. The second party which is involved is basically the decentralized directory, which you can see at the top in the middle. And this is where we store the information of our identities in an encrypted way so not anybody can get access to the information which is saved over there. And on the bottom right, you actually see the website which is demanding to receive an identity via the reclaim ID system. Okay, so there are some slides now which contain a bit of math. And some people might get overwhelmed by these figures. Some other people are interested in the cryptography. How does it work actually in detail? If this is not so interesting for you, that's okay. You can just take the following slide for granted. But I want to give a quick deep dive on the crypto that is being used. Okay, so in the new name system, a namespace is defined by a public and a private elliptic curve key pair. So we need the following things. We have a generator of the curve which is G. We have a group order prime number which is N. We have a private key which we denote as X. And we have a public key which is basically XG modulo N. And using this private key and this public key, we can derive additional keys from this original keying material. And we use these derived keys to encrypt and sign our resource records. Afterwards, the encrypted records are published in a distributed hash table under a key called Q. You can see it in practice later. And it is important to note that any peer is able to verify, first of all, the signature as the corresponding derived public key is also published. So it's always possible to check the signatures. And the records can only be resolved and decrypted if the true identity and the label is known. So the main point at this point is basically just a namespace cannot be enumerated. You cannot guess them. You need to get specific information to retrieve information out of these namespaces. And it's impossible to, I mean, you cannot observe the queries or responses unless you know the label and the identity. So okay. So first, a user creates a namespace using a private key and a public key. And this is basically the namespace where the user can store his personal identity information inside. And this is the data structure which is created in the end. You see here a table. You have three columns. The first column is the label. The second column is the record type. And the third column is the value. And the labels, which you can see on the first column, this is a random secret value with a very high entropy. You cannot guess this information, but you need this information to actually get the value which is saved. For instance, if I want to receive the value, my email is Alice at example.com. Then you can only access it if you know the label for email. Okay. So this resource record is stored in an encrypted way in the decentralized service. And this is another encryptor slide. If we have a namespace given using the private key X and the public key P, then we perform the following actions. First of all, we define H to be a hash of the label that is used and the public key P. Afterwards, we create our distributed hash table key, which is Q defined to be the hash of the previously hash again with the public key. Next we derive our encryption key K, which is another hash of a label and P. And using this key material, we can actually encrypt our records. And another variable is used for the signature. D is defined to be HX modulo N. So basically in a nutshell, all you need to access the information is the label and the public key. If you have these two things, then you can get all the access that you need. Okay. In practice, what is going on now? Basically the website demands a login using the identity provider. And the reclaim ID wants to access, wants to grant access to a certain identity. And the website downloads the information which is required from the decentralized directory. And in practice, this is what happens. So we have our information stored in the decentralized service. And whenever a user grants access to a certain set of attributes, an additional entry must be given. What you can see here is basically next to the main attributes which were added, we see another line which is basically labeled with the label ticket. And we can see the record types are attribute references. And each for each authorized party, such a reference record is added. And the label L ticket can now be shared with any third party in order to authorize the access to the email and the date of birth. And this layer of indirection, well, basically the third party does not receive the label email and the label name and the label of date of birth directly, but indirectly. This allows us to revoke tickets if we do not use them anymore. So in practice, the website downloads the stored information. Since it knows L ticket, it is able to retrieve the information, how it can find the date of birth and the name. And afterwards, the information can be used. And here at the decryption process, it's basically the same. Again we perform a hash of the label and the public key. And again, we create our queue, which is a hash of the previously created hash again with the public key. And also on this side of the server, the key to decrypt all the information, K is also again generated. And in the end, this way, if the server knows the label and the public key, the resource records can be decrypted and used and validated. So for all attributes that the server wants to download or the service, this step of decryption and checking the values is repeated. Okay. Now the interesting thing is, okay, we just have given a third party access to our identity information. But what happens if we want to revoke it? What happens if I don't not longer want to share certain attributes with some services? And this is where this layer of interaction comes in very handy. So here basically, we see again, we have our main attributes which were stored and saved by the client in the beginning, and we have two services registered in our decentralized service, which is basically a service called Alice and a service called Bob. Okay. Now we want to revoke the access for the service called Alice. And basically, we simply just delete the label that was used to access the information for Alice. The problem of course is, since Alice beforehand knew what the label of email and label of date of birth was, Alice would still be able to access the label, it would still be able to access email and date of birth. So we have to update the original labels for the attributes. And at this point in time, the service Alice can no longer access the email or the name or the date of birth, because it is important that any service that wants to access the identity information must know the label. And of course, if we want to maintain in the position where we want to let other third parties keep getting access to our email name and date of birth, for instance, their labels which are accessible need to be updated. This is why in this slide, you can see that the label for Bob, the information that Bob can access using the label for Bob, must be updated too. And the interesting part is that for this step, no interaction is required with a third party. Okay, so this is basically how it works. And the reason why the only thing that you need is the label, this is just given by the GNU name system. That's the main feature that is provided. Okay, so Reclaim ID implements the OpenID Connect protocol, which is a very widely used standard. And it's already used by websites which integrate any other identity provider, like Google, or Facebook, and so on. And the interesting part is for the end users, the registration process, and the behavior is completely transparent. That means it's the same. All the cryptographic background things that happen are hidden for the user. Okay, time for a quick demo. What you can see here is basically a website, and on the right-hand top, you see basically we visited the website, and the user which is shown is anonymous. That basically means we are not locked in at this point of time. And we see it's a message board. So basically someone like John Doe posted a message, and the website allows us to click a button called Reclaim ID, and by clicking this button, a prompt is created, and this is handled by the plugin that must be installed in the browser. And basically the plugin asks us, oh, wait a moment. The website Reclaim ID demo message board wants you to use Reclaim ID to authenticate yourself. And now I have the option to decline the request or select an identity which I stored to allow this service to use the identities that I previously put up. And the service wants to know my email and my full name. So afterwards, I click I want to choose my identity, and basically I previously set up two identities which I can choose from. One is Johnny, but Johnny has not the sufficient amount of attributes. And John Doe, of course, has the information which is required. And I can click this Share from this Identity button, and basically the user behavior is just like logging in with Facebook or Google. And in the end afterwards, after I chose to use my John Doe identity, as you can see in the top right corner, I am logged in as user John Doe. And this all happens without a third party being involved or someone else having control over my login process. Okay, wait a moment. And what's the time? Okay. Okay, so far, the interesting thing is that sometimes you do not just need certain attributes like name or email. Sometimes it's important to use sets of information which were validated by a third party like a state governmental thing or some other piece of information. Sometimes we still need third parties to validate trust on certain claims that we make. And some identity providers like Facebook or Google, they implicitly provide this assurance for some attributes. And the big problem is that those parties are actually not the full authority over the information that is being shared. For instance, whether your real name is actually the name that you post on Facebook or whether your phone number is the one that you actually use or whatsoever, that cannot be asserted there. And what we basically need in the everyday life of identity providers is often we need a collection of different credentials. And these credentials are issued by a variety of different entities. For instance, if you want to log in at a state website, you need a validated piece of information about your date of birth, about your residence or things like that. And the concept which is the difficult part is basically at this point we want to preserve the privacy of these credentials while still offering them to some services. And one approach of performing these things is zero knowledge proofs. And the thing that we are currently working on as the next features is basically one of the new features of OpenID Connect. It's called aggregated claims. It basically means that you can combine different attributes and identity information pieces into one big claim. So this is it. And that's what we are working on right now. Okay. How can we actually use ReclaimID? First of all, you can install the web extension. It's built for Mozilla Firefox. If you check out the add-on market, you can just search for ReclaimID. And you have to install GNU Net. And you need at least the version 0.12. And in case you want to install it bare hands, then you might get a bit frightened because you have to perform a lot of steps. But that's okay. There also exists some containers which allow to use the GNU Net system. And we are working on making it easier, of course. Okay. So in summary, you can get all the information about the ReclaimIdentity project at Reclaim-Identity.io. A demo website exists where you can just check it out, create your identity and test it. There are two demos. One is demo.reclaim-identity.io. And another demo is available at eusack.clouditor.io. And the roadmap basically contains the following steps for the next things. We want to make it more user-friendly in the packaging of the GNU Net. It may be possible to ship GNU Net inside a browser plugin. And the version 1.0 of this tool is coming soon, about to finish. Okay. Since my colleague is the leading programmer of this project, and if you have complex questions, please just send an email to him. And he can give the best answers, of course. Here is his public key and stuff like that. So if you have any questions, please feel free to ask them. Thank you. And if you have any questions that you want to pose now, just raise your hand and I will give you the microphone. So first of all, I want to say it sounds like a really great project. I wanted to know how it compares to Tim Berners-Lee project solid. Is it in any way comparable? To me, the problem is I personally have not checked out sovereign yet. Solid. Yeah. And the thing is just if you send us an email, we can provide you the information. And on the project side, there's some scientific papers where you can look it up in detail. What has been compared? I wanted to know, couldn't just Alice or the other party save the data? And then even if I revoke my label, they still keep my data. Well, but then we would not keep control. We want to be able to change our data and we want to be able to revoke access to our point of maintainability. We want to maintain all of our information at one point and we want to be able to say our data cannot be accessed anymore. So of course, the website can keep a copy of the information which was stored. That can always be the case. You cannot control that anyways. If you release information, it can be recorded or in any way. But the advantage is that some websites, if they do not have to keep the information, which is privacy related at the same website, then they do not have to suffer from general data protection regulation issues or things like that. So it's a feature to a website to be able to access the information of the user at any time even if the user is offline. Do you plan on implementing web of trust, like other users vouching for other users' attributes? Like a decentralized kind of authorization thing? We're planning on implementing something we call FOG of trust, which is a private version of web of trust where the web is not visible to the world. That's a great answer. That's interesting. So I see more questions here in the back. Raise your hands in the meantime. When I understood you correctly, so, hi here. That's all stored in the underlying distributed hash table of GNUNET. So how do you ensure actually that the GNUNET nodes just don't keep copies of the database in an older state so that also the older labels could still be resolved even if you do this in direction thing? I have to be honest. I have to think about that. But if you write us an email, we can answer your question, of course. I mean, you touched on a little bit with the private fof, but I guess I have two questions one, isn't the most important thing with these logins, the most valuable thing, the social graph of connecting between people? And like, who are the other people who use this same application? And then the other is like, it doesn't seem useful to know what you claim your email address is or what you claim your phone number is. I want some person who is not you to verify that you have control of those bits of contact information. So the thing that you mentioned, that you want to be sure that the information that you propose is validated, this is dealt with. Any moment I have to go back on the slide. If you want to share validated pieces of information, then you can do this using this technology too. So if you have a set of information like this is my email address, it has been validated by a third party or maybe by multiple parties, these can also be saved and shared in the decentralized directory. Can you repeat, please? I guess the question is, do those exist? Well, it depends. If you trust a third party. Is there code for running an email validator on Reclaim ID? Oh, that's what we're working on right now. It's part of the aggregated claims feature. Next question over here. So obviously there's a possibility to have multiple identities, right? In your proof, in the little demo you've shown you basically two different identities and one identity like the attributes, the website required, right? So obviously there is a mapping between your actual labels, not the technical labels but basically what you had L, email, A, day of birth, et cetera, et cetera, and the sort of meaningful name for the attribute that the application requires. So how does this mapping actually work? So I mean the website basically cares about the day of birth but they don't know what kind of internal label you've given. You can codify the day of birth, whatever. So how does this mapping work? So each user that you create also creates a new namespace. So the two users that you could see had two different namespaces. And a namespace is defined by one private key and one public key. And if you send the public key to the server and the label containing the ticket information for the third party that you want to give trust or that you want to give access to, if these two things are at hand, then the web server can actually retrieve the information from the decentralized service. So let me go back to the slide. Here. This namespace belongs to one identity but the second identity that I could choose has a completely different namespace and another public key. The only two sets of information which are required to access information about an identity is a label and a public key. And you? The question was, where does the semantics of the prefixes email name DOB come from? The question was, what about the semantics of name email DOB where that comes from? And I think it comes from simply from the OpenID standard here. Oh, yes, indeed. Thanks for the help. Next question here. So question would be more, isn't your tool making the identity thefts more easy? Because for example Facebook accounts, you can create a fake one and use to post things and various malicious things. It depends on your use case, if you do not want a third party to know whenever you are giving access to a certain website or whenever you are visiting a certain website and you want to take a decentralized approach, this is a good option. But of course you can make up fake accounts. Of course you can put up any information that you want but if you want to add information that was attested by another third party, you can do this as well. So the main focus is about getting the identity monopoly, the identity oligopoly away from the big identity providers and from something independent. Sounds pretty nice but I fear you are running into a scale up problem regarding performance. So presume one billion people are using your service, what time do you intend, does it take to update the whole decentralized network? Well I think that's a big question for the GNU name system. Can you dive in? Well DHTs exist at scale logarithmically to the number of nodes, so the performance, scan scale, you have seen cadmium or cat used for bit torrent, so the scan scale to very large networks. I am not claiming that the current implementation in GNU net scale to that level but I think by the time we get to a billion users we will address that problem as well. At least in theory the complexity, the big O is manageable. Thank you so much. So next one over here. Yeah, just shortly picking up on the question from the person over there, so he asks doesn't it make identity theft easier? And you said yeah, of course you can create like other identities, no worries. I think the other part of the question is how do you handle, well of course you don't handle but I mean you have an important aspect of end user device security in there. So I would assume that stealing identities from end user devices might be easier actually than stealing them from Facebook, I'm not sure. But do we address that issue somehow or? People try to understand the question I think. The idea is basically, oh okay. If I've stolen your end user device don't you think I usually get your Facebook account with it? Not in your case, you don't use Facebook I know. Yeah well of course since the management of the identities is handled locally on the web, on the laptop, well you have to manage it somewhere but if you post the information in the web, I mean if you post the information in the decentralized service you can only access it if you have the label and the public key. So the weak point that you are saying is since I can now handle my identities on my laptop, the weak point is that my laptop is at hand and I can steal information from my laptop. Well actually I was more like asking if you already did consider integrating some security tokens or something like that. So you can outsource it from the laptop or something like that. Yeah you can do that too. Currently I don't think that's implemented. But that's another suggestion. Thank you. I would be eager to use Reclaim ID today as an end user but I'm afraid I cannot or it's only the demo websites but I cannot use it for example to log into a GitLab installation also. Yes that's a good point but this login ID button, I mean Reclaim ID uses the OpenID Connect protocol and it should be fairly easy for websites to implement it to offer their feature to use Reclaim ID. So I need to ask the provider of the instance to implement it and then I can come with my Reclaim ID. And they don't have to implement it, they can use the things that are provided. Okay but they have to integrate it like they have to add another OpenID provider. Yes indeed. Okay thanks. We seem to have tackled all the questions. Do you still want to say something? I don't know. I'm very sorry. Are you okay? I hope. So I will recover at least. So thanks so much again for this presentation. We have the contact information here again if anybody has more detailed questions of course. And also you said the version 1.0 will be published soon so we can all dive into it more and talk to our services that we want to use to implement this part of OpenID. Yes indeed. And I want to mention one more time the main programmer is Martin Schanzenbach. Okay. Thank you so much. Thank you so much.
 Now I'm very happy to introduce Hendrik Mayer-Zumfelde, who will speak about a reclaim ID that  is helping to build a self-serverine decentralized identity system.  So thanks a lot.  Hello, everybody.  Hello.  Hello, everybody.  First of all, thank you for making this speech possible.  My name is Hendrik Mayer-Zumfelde, and today I want to present to you a tool which was  developed at the institute where my colleagues and me work.  We work at the Fraunhofer Eisek.  It's an IT security institute located in Munich, working in close relation with the technical  University of Munich.  And my colleague Martin Schanzenbach is the leading programmer of Reclaim ID.  And let's get started.  But before I present the tool itself, I want to tell you something about the motivation  behind the tool.  So we all know identity providers.  Most of us may already have used some of these.  And basically, if you think of things like Facebook or Google, it allows you to perform  a login at other websites or services.  And the first advantage of identity providers is, of course, comfort.  You don't have to remember hundreds of passwords or user credential sets in order to log into  a website, but you can simply use an identity provider instead.  And you have the possibility to manage your identities at a single entity.  And of course, people have gotten familiar with identity providers.  Another main advantage of identity providers is the liability, because some websites or  some parties may suffer from legal issues, and it's easier to outsource the protection  of identity data to an identity provider.  And what you can see here is basically a scheme which shows some measurements taken in the  year of 2014 and 15.  And it shows on the left-hand side what percentage of identities are stored at which identity  provider services.  And the main point that you can easily see is, of course, Facebook has about maybe more  than 60% of all the identities that are used on the web.  And it's followed by Google with about 20%, followed by Twitter with about 6% of the identities  that are used to log into other websites, followed by Yahoo and LinkedIn and other small  identity providers.  And the main point, what you can see here immediately is basically the market share  of identities is highly focused on very few companies.  So basically, Facebook and Google control more than 80% of the identities.  Why is this an issue?  Well, first of all, if few companies control whenever a user wants to log into a website  and performs the login steps for the user, it's possible to use this information and  perform targeted advertisement or perform steps to create opinion shaping.  And on the other hand, in the context of this conference, it's of course clear this data  can be used for mass surveillance and data collection.  And this is an issue.  On the other hand, another liability risk is at hand because if one single identity  provider like Facebook controls all the identities of the people, then basically there's a single  point of failure.  And if this company is hacked, it may suffer from an existential legal issue due to the  general data protection regulation.  And of course, another issue which is at hand is basically that an oligopoly may occur,  which is basically a monopoly which is shared by multiple parties.  So you may have the issue that too few parties have too much control over the market of identities.  And so far, no federation is widely practically used yet.  Okay.  Here's a quote, everyone needs complete control over who they share personal information with  at all times.  Do you have any idea who said this?  Okay.  It was Mark Zuckerberg.  Yes.  And of course, it seems a bit ironic in the context of this conference.  But what he meant was he wants users to have full control of their data within the realm  of Facebook.  But we want to break out of this realm of a third party that we want to trust.  We do not want to trust a third party at this point.  And some of you, I mean, most of you probably already heard about stories like these.  Just an incident, Yahoo a couple of years ago lost a billion credentials of users and  some other incidents like the Facebook, Cambridge, and a Lutica scandal.  These things just reveal that these things occur often.  I mean that it's a real problem that we are dealing with here right now.  Okay.  So for the tool that we created, the primary objective is this.  We want users to exercise their right for digital self-determination.  We do not want to have a third party involved for the management of the identity or the  data sharing.  We want it to be open, free, and we want to use a decentralized service, which is not  under the control of a single organization or a business or something like that.  And we want the software itself to remain free.  And here comes the name.  We want users to empower themselves to reclaim control over their digital identities.  That's why the tool is called Reclaim ID.  Okay.  Before we get further to the tool, it's important to understand what the purpose of an identity  provider is.  And basically there are two different main areas.  The first main area covers the following things.  They are partly already mentioned.  First of all, you want to provision your identity to other services.  You want to maintain control.  You want to allow the management of the identities.  And you want to be able to share your personal data with third parties.  And you want to be able to update your information.  And you want to enforce your authorization in the service that you're using.  The second main part is about identity information verification and the attestation about it.  For instance, you may have an email address and often some identity providers offer an  additional service just to attest the email that is used at hand.  Or maybe some other service may say this person is actually living in Germany and this is  a true fact, for instance.  So these two main areas are covered by identity providers.  And Reclaim ID focuses on the first area.  So we want to solve all the tasks that are explained in the first set.  And the second part is not yet our department, but we are working on it.  And I will get to that point later on.  Okay.  Time to introduce Reclaim ID.  First of all, Reclaim is a self-sovereign personal data sharing system.  And if you know about this realm of software, then you may think of other tools that implement  similar behavior.  Some other ones are, for instance, sovereign, U-Port or name ID.  And sovereign is based on a hyperledger.  And it's basically using a permissioned blockchain.  And whenever we use a blockchain, then we cannot make it free anymore because at some  point there's a fee to pay.  So this was not a good option for the project that we wanted to create.  U-Port is using Ethereum, which is also a blockchain.  And another downside is that the data could not be accessed anymore if the user was offline  by third parties that actually should share the data.  And name ID had some good ideas which were actually taken for additional steps that we  took.  But the main downside at this point was that all the access had to be performed through  one central server.  And this is a limitation.  And we wanted to create Reclaim in such a way that we do not require a blockchain.  It should be fully decentralized.  And it should be possible to access the data of the users in an asynchronous way.  So basically in a nutshell, Reclaim ID is, first of all, a decentralized directory service  and it's combined with cryptographic access control.  Those are the main elements.  OK, most of you probably already know directory services.  If you think of the x.500 standard, you may know LDAP or Active Directory, which is a  commonly used directory service in Windows systems.  And you already know name systems, for instance, like DNS, which is the domain name system.  Whenever you look up a website like Google.com or whatever, it translates the name to a given  IP.  And the interesting thing is using these namespaces, you don't, it's not only possible to save  IP addresses and strings or whatever, but you can actually save a lot more different  kinds of data in these systems.  And the decentralized directory service that we are using is heavily based on the GNU name  system, which in the following part of the talk is abbreviated as GNS.  And the GNU name system basically allows you to perform an S lookup, for instance, check  up email.bob.org.  Who is this?  And the answer will be, this is the email that is located there.  And the great thing about the GNU name system is that it natively supports the encryption  and the digital signature of certain resource records.  And we can use these features to protect the identity data from unwanted disclosure.  And we can actually enforce control using these features.  Okay, so how does it actually work?  What you can see here is basically a scheme which consists of three main parties.  On the bottom left, you see the user which has a browser plugin installed in the web  browser that is being used and is able to locally set up a reclaim identity.  So the plugin is installed, it started, and the user is able to create a new identity  with maybe a name like the typical name John Doe or whatever, his email address, and date  of birth.  The second party which is involved is basically the decentralized directory, which you can  see at the top in the middle.  And this is where we store the information of our identities in an encrypted way so not  anybody can get access to the information which is saved over there.  And on the bottom right, you actually see the website which is demanding to receive an  identity via the reclaim ID system.  Okay, so there are some slides now which contain a bit of math.  And some people might get overwhelmed by these figures.  Some other people are interested in the cryptography.  How does it work actually in detail?  If this is not so interesting for you, that's okay.  You can just take the following slide for granted.  But I want to give a quick deep dive on the crypto that is being used.  Okay, so in the new name system, a namespace is defined by a public and a private elliptic  curve key pair.  So we need the following things.  We have a generator of the curve which is G. We have a group order prime number which  is N. We have a private key which we denote as X. And we have a public key which is basically  XG modulo N. And using this private key and this public key, we can derive additional  keys from this original keying material.  And we use these derived keys to encrypt and sign our resource records.  Afterwards, the encrypted records are published in a distributed hash table under a key called  Q. You can see it in practice later.  And it is important to note that any peer is able to verify, first of all, the signature  as the corresponding derived public key is also published.  So it's always possible to check the signatures.  And the records can only be resolved and decrypted if the true identity and the label  is known.  So the main point at this point is basically just a namespace cannot be enumerated.  You cannot guess them.  You need to get specific information to retrieve information out of these namespaces.  And it's impossible to, I mean, you cannot observe the queries or responses unless you  know the label and the identity.  So okay.  So first, a user creates a namespace using a private key and a public key.  And this is basically the namespace where the user can store his personal identity information  inside.  And this is the data structure which is created in the end.  You see here a table.  You have three columns.  The first column is the label.  The second column is the record type.  And the third column is the value.  And the labels, which you can see on the first column, this is a random secret value with  a very high entropy.  You cannot guess this information, but you need this information to actually get the  value which is saved.  For instance, if I want to receive the value, my email is Alice at example.com.  Then you can only access it if you know the label for email.  Okay.  So this resource record is stored in an encrypted way in the decentralized service.  And this is another encryptor slide.  If we have a namespace given using the private key X and the public key P, then we perform  the following actions.  First of all, we define H to be a hash of the label that is used and the public key  P. Afterwards, we create our distributed hash table key, which is Q defined to be the hash  of the previously hash again with the public key.  Next we derive our encryption key K, which is another hash of a label and P. And using  this key material, we can actually encrypt our records.  And another variable is used for the signature.  D is defined to be HX modulo N. So basically in a nutshell, all you need to access the  information is the label and the public key.  If you have these two things, then you can get all the access that you need.  Okay.  In practice, what is going on now?  Basically the website demands a login using the identity provider.  And the reclaim ID wants to access, wants to grant access to a certain identity.  And the website downloads the information which is required from the decentralized directory.  And in practice, this is what happens.  So we have our information stored in the decentralized service.  And whenever a user grants access to a certain set of attributes, an additional entry must  be given.  What you can see here is basically next to the main attributes which were added, we see  another line which is basically labeled with the label ticket.  And we can see the record types are attribute references.  And each for each authorized party, such a reference record is added.  And the label L ticket can now be shared with any third party in order to authorize the  access to the email and the date of birth.  And this layer of indirection, well, basically the third party does not receive the label  email and the label name and the label of date of birth directly, but indirectly.  This allows us to revoke tickets if we do not use them anymore.  So in practice, the website downloads the stored information.  Since it knows L ticket, it is able to retrieve the information, how it can find the date  of birth and the name.  And afterwards, the information can be used.  And here at the decryption process, it's basically the same.  Again we perform a hash of the label and the public key.  And again, we create our queue, which is a hash of the previously created hash again with  the public key.  And also on this side of the server, the key to decrypt all the information, K is also  again generated.  And in the end, this way, if the server knows the label and the public key, the resource  records can be decrypted and used and validated.  So for all attributes that the server wants to download or the service, this step of decryption  and checking the values is repeated.  Okay.  Now the interesting thing is, okay, we just have given a third party access to our identity  information.  But what happens if we want to revoke it?  What happens if I don't not longer want to share certain attributes with some services?  And this is where this layer of interaction comes in very handy.  So here basically, we see again, we have our main attributes which were stored and saved  by the client in the beginning, and we have two services registered in our decentralized  service, which is basically a service called Alice and a service called Bob.  Okay.  Now we want to revoke the access for the service called Alice.  And basically, we simply just delete the label that was used to access the information  for Alice.  The problem of course is, since Alice beforehand knew what the label of email and label of date  of birth was, Alice would still be able to access the label, it would still be able to  access email and date of birth.  So we have to update the original labels for the attributes.  And at this point in time, the service Alice can no longer access the email or the name  or the date of birth, because it is important that any service that wants to access the  identity information must know the label.  And of course, if we want to maintain in the position where we want to let other third  parties keep getting access to our email name and date of birth, for instance, their labels  which are accessible need to be updated.  This is why in this slide, you can see that the label for Bob, the information that Bob  can access using the label for Bob, must be updated too.  And the interesting part is that for this step, no interaction is required with a third  party.  Okay, so this is basically how it works.  And the reason why the only thing that you need is the label, this is just given by the  GNU name system.  That's the main feature that is provided.  Okay, so Reclaim ID implements the OpenID Connect protocol, which is a very widely used standard.  And it's already used by websites which integrate any other identity provider, like Google,  or Facebook, and so on.  And the interesting part is for the end users, the registration process, and the behavior  is completely transparent.  That means it's the same.  All the cryptographic background things that happen are hidden for the user.  Okay, time for a quick demo.  What you can see here is basically a website, and on the right-hand top, you see basically  we visited the website, and the user which is shown is anonymous.  That basically means we are not locked in at this point of time.  And we see it's a message board.  So basically someone like John Doe posted a message, and the website allows us to click  a button called Reclaim ID, and by clicking this button, a prompt is created, and this  is handled by the plugin that must be installed in the browser.  And basically the plugin asks us, oh, wait a moment.  The website Reclaim ID demo message board wants you to use Reclaim ID to authenticate  yourself.  And now I have the option to decline the request or select an identity which I stored  to allow this service to use the identities that I previously put up.  And the service wants to know my email and my full name.  So afterwards, I click I want to choose my identity, and basically I previously set up  two identities which I can choose from.  One is Johnny, but Johnny has not the sufficient amount of attributes.  And John Doe, of course, has the information which is required.  And I can click this Share from this Identity button, and basically the user behavior is  just like logging in with Facebook or Google.  And in the end afterwards, after I chose to use my John Doe identity, as you can see  in the top right corner, I am logged in as user John Doe.  And this all happens without a third party being involved or someone else having control  over my login process.  Okay, wait a moment.  And what's the time?  Okay.  Okay, so far, the interesting thing is that sometimes you do not just need certain attributes  like name or email.  Sometimes it's important to use sets of information which were validated by a third party like  a state governmental thing or some other piece of information.  Sometimes we still need third parties to validate trust on certain claims that we make.  And some identity providers like Facebook or Google, they implicitly provide this assurance  for some attributes.  And the big problem is that those parties are actually not the full authority over the  information that is being shared.  For instance, whether your real name is actually the name that you post on Facebook or whether  your phone number is the one that you actually use or whatsoever, that cannot be asserted  there.  And what we basically need in the everyday life of identity providers is often we need  a collection of different credentials.  And these credentials are issued by a variety of different entities.  For instance, if you want to log in at a state website, you need a validated piece of information  about your date of birth, about your residence or things like that.  And the concept which is the difficult part is basically at this point we want to preserve  the privacy of these credentials while still offering them to some services.  And one approach of performing these things is zero knowledge proofs.  And the thing that we are currently working on as the next features is basically one of  the new features of OpenID Connect.  It's called aggregated claims.  It basically means that you can combine different attributes and identity information pieces  into one big claim.  So this is it.  And that's what we are working on right now.  Okay.  How can we actually use ReclaimID?  First of all, you can install the web extension.  It's built for Mozilla Firefox.  If you check out the add-on market, you can just search for ReclaimID.  And you have to install GNU Net.  And you need at least the version 0.12.  And in case you want to install it bare hands, then you might get a bit frightened because  you have to perform a lot of steps.  But that's okay.  There also exists some containers which allow to use the GNU Net system.  And we are working on making it easier, of course.  Okay.  So in summary, you can get all the information about the ReclaimIdentity project at Reclaim-Identity.io.  A demo website exists where you can just check it out, create your identity and test it.  There are two demos.  One is demo.reclaim-identity.io.  And another demo is available at eusack.clouditor.io.  And the roadmap basically contains the following steps for the next things.  We want to make it more user-friendly in the packaging of the GNU Net.  It may be possible to ship GNU Net inside a browser plugin.  And the version 1.0 of this tool is coming soon, about to finish.  Okay.  Since my colleague is the leading programmer of this project, and if you have complex questions,  please just send an email to him.  And he can give the best answers, of course.  Here is his public key and stuff like that.  So if you have any questions, please feel free to ask them.  Thank you.  And if you have any questions that you want to pose now, just raise your hand and I will  give you the microphone.  So first of all, I want to say it sounds like a really great project.  I wanted to know how it compares to Tim Berners-Lee project solid.  Is it in any way comparable?  To me, the problem is I personally have not checked out sovereign yet.  Solid.  Yeah.  And the thing is just if you send us an email, we can provide you the information.  And on the project side, there's some scientific papers where you can look it up in detail.  What has been compared?  I wanted to know, couldn't just Alice or the other party save the data?  And then even if I revoke my label, they still keep my data.  Well, but then we would not keep control.  We want to be able to change our data and we want to be able to revoke access to our  point of maintainability.  We want to maintain all of our information at one point and we want to be able to say  our data cannot be accessed anymore.  So of course, the website can keep a copy of the information which was stored.  That can always be the case.  You cannot control that anyways.  If you release information, it can be recorded or in any way.  But the advantage is that some websites, if they do not have to keep the information,  which is privacy related at the same website, then they do not have to suffer from general  data protection regulation issues or things like that.  So it's a feature to a website to be able to access the information of the user at any  time even if the user is offline.  Do you plan on implementing web of trust, like other users vouching for other users'  attributes?  Like a decentralized kind of authorization thing?  We're planning on implementing something we call FOG of trust, which is a private version  of web of trust where the web is not visible to the world.  That's a great answer.  That's interesting.  So I see more questions here in the back.  Raise your hands in the meantime.  When I understood you correctly, so, hi here.  That's all stored in the underlying distributed hash table of GNUNET.  So how do you ensure actually that the GNUNET nodes just don't keep copies of the database  in an older state so that also the older labels could still be resolved even if you do this  in direction thing?  I have to be honest.  I have to think about that.  But if you write us an email, we can answer your question, of course.  I mean, you touched on a little bit with the private fof, but I guess I have two questions  one, isn't the most important thing with these logins, the most valuable thing, the social  graph of connecting between people?  And like, who are the other people who use this same application?  And then the other is like, it doesn't seem useful to know what you claim your email address  is or what you claim your phone number is.  I want some person who is not you to verify that you have control of those bits of contact  information.  So the thing that you mentioned, that you want to be sure that the information that  you propose is validated, this is dealt with.  Any moment I have to go back on the slide.  If you want to share validated pieces of information, then you can do this using this  technology too.  So if you have a set of information like this is my email address, it has been validated  by a third party or maybe by multiple parties, these can also be saved and shared in the  decentralized directory.  Can you repeat, please?  I guess the question is, do those exist?  Well, it depends.  If you trust a third party.  Is there code for running an email validator on Reclaim ID?  Oh, that's what we're working on right now.  It's part of the aggregated claims feature.  Next question over here.  So obviously there's a possibility to have multiple identities, right?  In your proof, in the little demo you've shown you basically two different identities and  one identity like the attributes, the website required, right?  So obviously there is a mapping between your actual labels, not the technical labels but  basically what you had L, email, A, day of birth, et cetera, et cetera, and the sort of  meaningful name for the attribute that the application requires.  So how does this mapping actually work?  So I mean the website basically cares about the day of birth but they don't know what  kind of internal label you've given.  You can codify the day of birth, whatever.  So how does this mapping work?  So each user that you create also creates a new namespace.  So the two users that you could see had two different namespaces.  And a namespace is defined by one private key and one public key.  And if you send the public key to the server and the label containing the ticket information  for the third party that you want to give trust or that you want to give access to,  if these two things are at hand, then the web server can actually retrieve the information  from the decentralized service.  So let me go back to the slide.  Here.  This namespace belongs to one identity but the second identity that I could choose has  a completely different namespace and another public key.  The only two sets of information which are required to access information about an identity  is a label and a public key.  And you?  The question was, where does the semantics of the prefixes email name DOB come from?  The question was, what about the semantics of name email DOB where that comes from?  And I think it comes from simply from the OpenID standard here.  Oh, yes, indeed.  Thanks for the help.  Next question here.  So question would be more, isn't your tool making the identity thefts more easy?  Because for example Facebook accounts, you can create a fake one and use to post things  and various malicious things.  It depends on your use case, if you do not want a third party to know whenever you are  giving access to a certain website or whenever you are visiting a certain website and you  want to take a decentralized approach, this is a good option.  But of course you can make up fake accounts.  Of course you can put up any information that you want but if you want to add information  that was attested by another third party, you can do this as well.  So the main focus is about getting the identity monopoly, the identity oligopoly away from  the big identity providers and from something independent.  Sounds pretty nice but I fear you are running into a scale up problem regarding performance.  So presume one billion people are using your service, what time do you intend, does it take  to update the whole decentralized network?  Well I think that's a big question for the GNU name system.  Can you dive in?  Well DHTs exist at scale logarithmically to the number of nodes, so the performance,  scan scale, you have seen cadmium or cat used for bit torrent, so the scan scale to very  large networks.  I am not claiming that the current implementation in GNU net scale to that level but I think  by the time we get to a billion users we will address that problem as well.  At least in theory the complexity, the big O is manageable.  Thank you so much.  So next one over here.  Yeah, just shortly picking up on the question from the person over there, so he asks doesn't  it make identity theft easier?  And you said yeah, of course you can create like other identities, no worries.  I think the other part of the question is how do you handle, well of course you don't  handle but I mean you have an important aspect of end user device security in there.  So I would assume that stealing identities from end user devices might be easier actually  than stealing them from Facebook, I'm not sure.  But do we address that issue somehow or?  People try to understand the question I think.  The idea is basically, oh okay.  If I've stolen your end user device don't you think I usually get your Facebook account  with it?  Not in your case, you don't use Facebook I know.  Yeah well of course since the management of the identities is handled locally on the  web, on the laptop, well you have to manage it somewhere but if you post the information  in the web, I mean if you post the information in the decentralized service you can only  access it if you have the label and the public key.  So the weak point that you are saying is since I can now handle my identities on my laptop,  the weak point is that my laptop is at hand and I can steal information from my laptop.  Well actually I was more like asking if you already did consider integrating some security  tokens or something like that.  So you can outsource it from the laptop or something like that.  Yeah you can do that too.  Currently I don't think that's implemented.  But that's another suggestion.  Thank you.  I would be eager to use Reclaim ID today as an end user but I'm afraid I cannot or it's  only the demo websites but I cannot use it for example to log into a GitLab installation  also.  Yes that's a good point but this login ID button, I mean Reclaim ID uses the OpenID  Connect protocol and it should be fairly easy for websites to implement it to offer their  feature to use Reclaim ID.  So I need to ask the provider of the instance to implement it and then I can come with my  Reclaim ID.  And they don't have to implement it, they can use the things that are provided.  Okay but they have to integrate it like they have to add another OpenID provider.  Yes indeed.  Okay thanks.  We seem to have tackled all the questions.  Do you still want to say something?  I don't know.  I'm very sorry.  Are you okay?  I hope.  So I will recover at least.  So thanks so much again for this presentation.  We have the contact information here again if anybody has more detailed questions of course.  And also you said the version 1.0 will be published soon so we can all dive into it more and talk  to our services that we want to use to implement this part of OpenID.  Yes indeed.  And I want to mention one more time the main programmer is Martin Schanzenbach.  Okay.  Thank you so much.  Thank you so much.
36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_0_539.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_540_611.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_612_659.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_660_791.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_792_1619.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_1620_3047.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_3048_3131.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_3132_3527.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_3528_6311.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_6312_7055.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_7056_7247.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_7248_7883.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_7884_10307.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_10308_11987.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_11988_12095.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_12096_12239.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_12240_12587.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_12588_14447.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_14448_14591.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_14592_15539.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_15540_17111.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_17112_17363.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_17364_17711.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_17712_18275.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_18276_20363.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_20364_21095.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_21096_24383.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_24384_27143.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_27144_28439.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_28440_33599.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_33600_34943.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_34944_35699.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_35700_36995.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_36996_37967.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_37968_39719.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_39720_40535.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_40536_40667.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_40668_41663.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_41664_43187.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_43188_43283.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_43284_43535.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_43536_44159.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_44160_44315.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_44316_45623.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_45624_45683.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_45684_46151.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_46152_49271.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_49272_51287.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_51288_52967.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_52968_53651.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_53652_54275.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_54276_57347.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_57348_65615.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_65616_66971.png 36c3-oio-161-eng-reclaimID_-_Self-sovereign_Decentralised_Identity_Management_and_Personal_Data_Shar_66972_67037.png