WEBVTT 00:00.000 --> 00:09.520 So thank you very much, thank you all for being here, we're almost a closing time of 00:09.520 --> 00:18.360 fussing but I'm glad you're still paying attention and not yet to worn out, yes, my 00:18.360 --> 00:30.880 microphone's not working well enough, higher, maybe, one, two, three, better, okay, cool, all right, 00:30.880 --> 00:37.560 yes, so from reverse Google from email to decentralization, titles have to be a bit interesting, 00:37.560 --> 00:41.680 I tried to make this one interesting, but I could have of course taken others as well, 00:41.680 --> 00:50.840 however, I think Google perfectly exemplifies what I am thinking about it here, just like this. 00:50.840 --> 00:58.120 This was about when was it launched 2003, 2004, right, Gmail, so in fussing terms, 00:58.120 --> 01:06.760 fussing plus three, plus four kind of likeish, and basically from today's perspective, I would 01:06.760 --> 01:13.960 say that when you look at what happened back then, Gmail was a lost leader to capture the 01:13.960 --> 01:21.840 identity market. They basically gave Gmail away for free so everybody would get the address, 01:21.840 --> 01:31.240 right, it's enormous today, we all know that, and basically what they did then with the 01:31.240 --> 01:39.280 Federation of Identity, so login with Google, is that they got visibility on every single 01:39.280 --> 01:45.640 interaction that people are doing, right, whenever somebody uses the login with Google thing, 01:45.640 --> 01:54.240 then they know who is signing on where, for what, you know, I mean they have the full visibility 01:54.240 --> 01:58.960 on the interaction and then they monetize that, basically, right, because that allows them 01:59.040 --> 02:06.040 to create better data profiles. So Gmail has been the lost leader to create this kind of mechanism, 02:06.040 --> 02:15.080 but it goes deeper. I actually believe by now, it took me a while to come to this, and if you 02:15.080 --> 02:20.480 see my first Asia talk, last year actually, you'll see that I've actually, I have a little bit more 02:20.480 --> 02:25.720 story to this, but I'm not going to tell all of that today, I believe that the Federation 02:25.800 --> 02:35.560 protocols for identity are part of the problem, they're not part of the solution, because in the 02:35.560 --> 02:44.280 way that the web is set up, basically what happens here is that you have enormous economies of 02:44.280 --> 02:50.360 scale, you have the cost benefit of running a larger platform, more centralized system, and 02:50.440 --> 02:57.400 you have their ability to leverage identity into multiple markets that makes the life for every 02:57.400 --> 03:03.800 single free software project much harder, and it's harder for us to build applications, they have 03:03.800 --> 03:11.400 the identity platform to leverage into other domains. And that is actually part of the problem 03:11.400 --> 03:19.400 is to some extent view to the fact how the web, how TLS, how certificate authorities, how all 03:19.480 --> 03:25.080 these things work together to create a circle that actually works against us, it's like we are 03:25.080 --> 03:33.240 working against gravity, there's an underlying principle that really makes our life much much harder. 03:34.440 --> 03:41.400 That was at least my problem analysis, and this is basically why we started the rain, 03:41.400 --> 03:47.400 the rain is short for sovereign, so the idea was to create applications on top of self-sauvered 03:47.400 --> 03:56.520 identity that would help to change that dynamic in favor of free software in favor of open source. 03:56.520 --> 04:01.320 That was the idea behind this, right? Because I mean the only answer otherwise we had was again 04:01.320 --> 04:07.080 that's all self-hosted, but to me they're always sounded a lot like Marie Antoinette, 04:07.080 --> 04:12.680 the whole thing like let them eat cake, but come on guys, like seriously we need to have 04:12.680 --> 04:17.320 better answers than that, because most people do not want to self-host everything, 04:18.120 --> 04:23.800 I prefer not to self-host everything. I mean I have good connectivity, I can self-host, 04:23.800 --> 04:30.600 I really don't want to self-host everything, I really don't. So at the end of the day we need better 04:30.600 --> 04:37.880 answers, and I believe a very important part of that answer is actually this idea of self-sauvered identity. 04:38.600 --> 04:46.200 Now I do not want to do a full introduction of how this works, but I do want to talk about a few 04:46.200 --> 04:54.440 things conceptually, how all of this comes together, because what we see today is that the idea of 04:54.440 --> 05:03.880 self-sauvered identity is increasingly co-opted by the web-based federation technology community. 05:04.840 --> 05:10.360 They actually now implement a lot of things on top of open ID, connect, and things like this, 05:10.360 --> 05:15.880 and basically reintroduce similar patterns again when we actually want something else, 05:15.880 --> 05:21.880 we want actual decentralization. So let me show you what I think and what a decentralized key 05:21.880 --> 05:28.440 management system should look like, and this is one of them, right? So this is in fact the one 05:28.440 --> 05:35.160 that I say is the most advanced and most well thought out and best implemented approach, 05:35.160 --> 05:43.240 which is based on something called carry, the key event receipt infrastructure, and we start over 05:43.240 --> 05:49.720 on the left. We have an autonomous identifier, right? So similar to a content identifier, 05:49.720 --> 05:55.640 we have an autonomous identifier that identifies my key, right? It's derived from the inception key 05:55.640 --> 06:03.240 that I'd create for my identity. My key represents this identity. I can't have one. I can have many. 06:03.240 --> 06:10.600 I always generate them locally. They always remain on the device. Every device that ever interacts 06:10.600 --> 06:19.080 has its own identifier. The identifiers, of course, evolve, they do things, right? So they even have 06:19.080 --> 06:24.360 the possibility for key rotations, say, I want to keep my identity, but I think my key might have 06:24.360 --> 06:29.560 been compromised. I want to rotate the key. So I have a pre rotation key that allows me to do that. 06:29.560 --> 06:33.880 There's a couple of concepts here that are really, really powerful. I encourage everyone that's 06:33.880 --> 06:38.280 interested at all in this kind of technology to have a look at that because it's really 06:38.840 --> 06:46.440 quite interesting. What I can also do here is I can sign interactions. And I add all of this 06:46.520 --> 06:53.480 basic to a hash list, right? It's a bit like a micro ledger, just like hash linked transaction 06:53.480 --> 07:02.680 information. I share this information with a pool of so-called witnesses, which is nothing but a 07:02.680 --> 07:10.600 very simple agent running anywhere that receives those receipts, the receipts or updates and 07:10.680 --> 07:16.840 push-up spec receipts to your devices that have the AID and manage it to control us. 07:18.680 --> 07:27.320 That they made to the key and provide a unified view these things that I've created those certificates, 07:27.320 --> 07:32.680 that I have provided a new certificate for this topic, that I have signed a very file of credential, 07:32.680 --> 07:38.680 all these kind of things. And I have my curl, the key event receipt look that is the aggregation of 07:38.760 --> 07:45.720 all of this. And I can get that, of course, directly from my key management system, but I can also 07:46.600 --> 07:52.920 then get it from my witnesses, right? So I can ask a witness, here's an AID, an identifier that 07:52.920 --> 07:59.720 connected to me, do you know anything about them? What is their history? So I can link them back 07:59.720 --> 08:07.000 to actually the root of truth, which to those of you who have looked at ledger systems, 08:07.000 --> 08:14.040 blockchains and all these kind of things, it's basically taking some of those concepts from there 08:15.000 --> 08:21.160 and making them locally consistent with an eventually consistent approach in terms of synchronization 08:21.160 --> 08:27.880 across the interactions. And it's actually really, really powerful because it scales, 08:27.880 --> 08:33.240 right, unless blockchains, which you all know have a enormous scalability problem, this thing scales, 08:33.400 --> 08:41.880 because it's a decentralized set of micro ledgers, if you will. That is an actual full decentralized 08:41.880 --> 08:48.680 system that allows you to then verify the state of every single device. And because it's lightweight 08:48.680 --> 08:55.240 enough, you can actually deploy this, even in an IoT setting, you didn't deploy it anywhere. 08:55.800 --> 09:04.040 That is the kind of system that I believe we would want because if we had something like this 09:04.040 --> 09:10.440 that works, we could then, on top of this, use variable credentials, so machine readable 09:11.240 --> 09:19.160 documents that are signed and linked to these AIDs, in order to attest to certain interactions 09:19.160 --> 09:26.760 or certain statements about our identities that we can verify as much or as little all the way 09:26.760 --> 09:32.600 to full anonymity as the context requires, right, there's different contexts in world. 09:32.600 --> 09:36.120 If I need to buy a beer, it's different than if I want to open a bank account, 09:36.120 --> 09:40.840 or if I just want to exchange an anonymous message, those things are completely different use cases. 09:41.400 --> 09:47.160 This system allows us to say, I need this much or this little verification here. 09:49.560 --> 09:54.040 That is the kind of system that I think we want to move towards. Now, 09:56.360 --> 10:01.000 wanting to move towards a system and knowing that it is more secure than what we're doing 10:01.000 --> 10:06.760 more scalable is one thing. The other thing is how do we actually get this into the real world? 10:07.640 --> 10:15.080 And that is always kind of the hardest problem. I mean, all of us here are technologies, 10:15.720 --> 10:21.320 so all of us know how to build technology, but getting the technology into the hands of actual 10:21.320 --> 10:26.840 people is actually very often at scale. It's the harder problem. How do you get the actual adoption? 10:27.960 --> 10:36.040 We have been doing a lot of work with GIAX and other European projects in this field and 10:36.040 --> 10:42.920 through them managed to find health info net in Switzerland, health info net is a very specific 10:43.080 --> 10:51.640 part of ours with a very specific property because they are a company, but they are owned 10:51.640 --> 10:58.360 by the Swiss Doctors Association. So they do not have a profit motive, right? If they make a 10:58.360 --> 11:03.640 profit, they distribute back to the Doctors Association. There's no other player that wins. 11:04.360 --> 11:10.440 They have a service mission. They're driven by service. As long as they do not go bankrupt, 11:10.520 --> 11:16.360 they're okay, but they want to provide a proper service. They're very old, like 30 years 11:16.360 --> 11:23.960 old, and they started out in the 90s with email. Basically, back in the day, email was new, 11:23.960 --> 11:29.560 right? They realized we cannot just send patient data on encrypted back and forth. So what do we do? 11:29.560 --> 11:36.280 So at that time, had the answer S-mine, so basically now they're doing S-mine based domain encryption, 11:36.360 --> 11:48.040 which is not fantastic, but I guess it's better than pen text. They are operating in every single 11:48.040 --> 11:56.360 G-P's office and across all the hospitals and laboratories in Switzerland. And they realized 11:56.360 --> 12:05.000 a few years ago that if they continued to do what they do without actually adapting, 12:05.560 --> 12:10.120 they would go bankrupt. They would not exist. They would no longer be relevant at some point, 12:10.680 --> 12:16.600 because the world has moved on. So they decided to invest into their own reinvention 12:17.320 --> 12:22.200 on a platform basis, so moving to a modern cloud and open shift, and all these kind of things 12:22.200 --> 12:28.280 on a process level, so DevOps, agile, all the modern things that you would want to do, 12:28.280 --> 12:34.280 and also on a solution level, like, what is it that we should do 15 years from now? 12:35.160 --> 12:39.640 Was the question that they asked? And for them, they realized, 12:41.080 --> 12:46.520 basically in order to remain relevant, we need to look at how the health care sector is transforming. 12:46.520 --> 12:53.960 Coming, we have more seats there. They just don't worry, sit down. They realized that they 12:53.960 --> 12:58.280 do need in order to remain relevant, they do need to change the way they're doing this. And 12:58.360 --> 13:05.160 my version of this would be that they are increasingly becoming the data space terminal 13:05.160 --> 13:12.760 to the health care data space of Switzerland. On that journey, we got together through some 13:12.760 --> 13:17.720 POCs. They're looking at things like science, which is an ETA's age-based network technology 13:17.720 --> 13:24.200 for better secure networking and SSI, and something that they would want to be able to do. 13:24.680 --> 13:29.960 We've been helping them in that transition. In fact, we already have one product in 13:29.960 --> 13:35.720 production, which is sealed. I would be getting another talk, seal is a edge application based 13:35.720 --> 13:43.400 on IPFS, by the way. So, content, addressing, delivering all the messages of Swiss doctors to 13:43.400 --> 13:51.400 patients securely to the edge in the form of basically a cryptographic fragment swarm that comes 13:51.400 --> 13:56.200 together, only at the edge and only at the crypt of their. The system is in production today 13:56.200 --> 14:00.600 with around 800,000 messages every month. All of the Swiss doctors are using it. 14:02.520 --> 14:08.200 But I'm not here for that. I'm here for the S-Mime Gateway's, because this is the next stage 14:08.200 --> 14:13.880 of the transition, the S-Mime Gateway's very old technology. That is the next thing that really 14:13.960 --> 14:24.360 squeaks very hard in terms of what they are doing today. So, we with them have come up with something 14:24.360 --> 14:31.000 to replace S-Mime Gateway this year, all of them until the end of this year, which is really 14:31.000 --> 14:36.840 interesting time, by the way. It's quite challenging, but you know, we'll manage. We'll actually 14:36.840 --> 14:41.560 make it happen. But instead of just building a mayor gateway, because the hospital still needs 14:41.640 --> 14:46.120 to be able to send mail. You cannot tell that mail is no longer there. It doesn't exist anymore. 14:46.120 --> 14:51.640 That would never work. So, instead of just taking away the S-Mime Gateway, so what we did 14:52.200 --> 14:58.680 is we came up with the idea of let's wrap this concept of decentralized key management, 14:58.680 --> 15:05.880 organization, credential management, all of these things into a new kind of mesh node that basis 15:06.040 --> 15:14.120 key management on autonomous identifiers, fully, fully based on the principles 15:14.920 --> 15:23.560 from before, on that new generation, and then allow that to also generate x-fibre-nice certificates 15:23.560 --> 15:31.240 that we wrap into an S-MTP in S-Mime Flow. So, we are legacy compatible, right? We can still exchange 15:31.240 --> 15:38.520 messages with normal S-Mime Gateway, but new gateways, suddenly get the ability to verify 15:38.520 --> 15:44.840 those organizational identities based on the new technology on very fibre credential, 15:44.840 --> 15:50.440 organizational identity, multi-route trust systems, all of the things that you would actually want. 15:50.440 --> 15:57.320 We have a scalable, truly peer-to-peer mesh network that allows you to exchange data. 15:57.400 --> 16:02.440 We call this the sovereign data exchange that we're building around this, so it's a 16:03.400 --> 16:08.600 store-in-forward engine with smart routing, and smart in this case means programmable. So, 16:10.280 --> 16:16.440 rego-based policies stored in git, so you can actually version them, you can control them, 16:16.440 --> 16:20.600 you can alter them the way that you need to, and suddenly this thing becomes able to, 16:20.920 --> 16:28.440 a, of course, send mail, right? Wonderful, better, more secure. There's a wire guard tunnel 16:28.440 --> 16:33.560 between all these mesh nodes, so no, no more metadata leakage at least, so that is good, 16:33.560 --> 16:41.560 it's better than S-Mime was before, but what we've done by the end of this is we have rolled out 16:41.560 --> 16:51.400 a new, more capable infrastructure. Because we're not stopping an email, right? That email 16:51.400 --> 17:00.120 is necessary, but it's not the goal, it's not the end game of this. So what we have here now is a system 17:00.120 --> 17:07.800 that is able to handle structure data in an intelligent way, because based on autonomous identifiers 17:07.800 --> 17:15.960 and then using things like the overlay capture architecture, which is, it's basically content 17:15.960 --> 17:24.760 address schema system, if you will, that allows you to determine the schema of data in a way that 17:24.760 --> 17:30.840 is unique and clear, and both sites know they're using the same schema to interpret that kind of 17:30.840 --> 17:35.240 data, right? And you can link it all together, you can sign it all. So you know, have you, you 17:35.240 --> 17:42.200 exchange data that is signed, authentic, schema is clear, you know, even five years later, 17:42.200 --> 17:47.560 which schema has been used. You no longer have the unclarity on the schema level either, 17:47.560 --> 17:52.120 which is if you ever have looked at that sector, it's a big problem, because even to doctors 17:52.120 --> 17:57.160 will note things differently in their systems, right? Same case, two different doctors, 17:57.160 --> 18:03.160 they write it on different. And so you need to understand the semantics underneath, 18:03.240 --> 18:09.000 and the only way to do this is with some kind of layer for allowing you express the semantics 18:09.000 --> 18:15.240 of the specific data at the time it has been created. So this, I mean, we call it Stargate, 18:15.240 --> 18:20.280 actually this whole system. I mean, somebody came up with the idea that stuck as stupid names 18:20.280 --> 18:31.160 of the do, and basically now this whole thing is the ability of creating a mesh network of 18:31.240 --> 18:38.520 nodes that is able to handle male, but also structure data based on this new kind of autonomous 18:38.520 --> 18:47.320 approach of to identity and data. Just quickly, I don't want to go into the whole architecture 18:47.320 --> 18:52.120 of the whole thing, but just so you know, I mean, we're not reinventing everything, right? We're 18:52.280 --> 19:04.280 not idiots. We take whatever is proven in the free software world and combine it in a new way to 19:04.280 --> 19:09.160 generate this result. So if you look at the architecture here, you will see something like the open policy 19:09.160 --> 19:15.400 agent, right, which is for ego. You will see, you know, API gateway, because you need to somehow 19:15.400 --> 19:21.480 connect this to legacy systems. You have a key cloak in order to connect your SSI decentralized key 19:21.560 --> 19:27.560 management to open ID locally in a local environment, right? Because you need to somehow bring these 19:27.560 --> 19:31.960 things to work them together. I mean, you cannot replace everything around you as impossible. 19:31.960 --> 19:37.560 You have a post-pics, of course, for the male routing, because, well, you know, it is kind of 19:38.520 --> 19:45.240 application to do that. So it's not really like we're reinventing everything. We're just 19:45.320 --> 19:52.520 specifically building the components that are needed to make the new functionality possible. 19:54.360 --> 19:59.800 And that is exactly what we're building. And one of the beautiful things of our partnership 19:59.800 --> 20:09.400 with him is that they have committed to having us release everything, a hundred percent as 20:09.480 --> 20:14.600 free software, all of it without exception. Everything will be free software under the 20:14.600 --> 20:22.600 AGPL. So we have a complete stack that in a couple of years, I mean, this is now a work that is 20:22.600 --> 20:26.680 ongoing, right? It's not going to be over this year. It's not going to be over in a month. It's 20:26.680 --> 20:35.320 too much work. But that will be able to provide this capability to health systems anywhere 20:35.320 --> 20:41.960 fully as for software. We have an actual answer that is data-friendly, privacy-friendly allows 20:41.960 --> 20:47.320 us to give patients control over that data, because suddenly things like constant management 20:47.320 --> 20:51.800 and so on become much, much easier. You can actually handle them and you can prove them because 20:52.440 --> 20:57.000 your event logs are basically your audit trail for the interactions as well. 20:57.960 --> 21:05.880 So you can map this entire space in this in a secure, robust, scalable decentralized way. 21:08.760 --> 21:14.360 So yeah, and language is just in case you're you care, most of everything we do back and 21:14.360 --> 21:19.000 there's always going, some rust is in there for like the crypto primitives and stuff like this. 21:20.280 --> 21:26.040 And our front is usually reactivative. So technologies that pretty much most people know these days. 21:27.080 --> 21:36.440 Why do I think, yes, I'm almost done. Almost there. Why do I think this is relevant, 21:37.320 --> 21:44.600 specifically also here, and the decentralized communications room? You see, one of the 21:45.800 --> 21:52.120 beauties is that this note, because it is the stack, if you want to call it that, 21:53.080 --> 22:00.040 is actually capable of handling any type of data every time of interaction. And once you have 22:00.040 --> 22:11.720 the ability to handle organizational, institutional, server-side identity in this way, and sign 22:11.720 --> 22:19.560 verify the credentials to, to, to, um, e-mark data or local users or, or interaction requests, 22:20.280 --> 22:30.600 you can connect systems without a central source of truth. You can trust in the local source of 22:30.600 --> 22:35.480 truth, right? The local service provides you with all the signed evidence chain that you require. 22:35.800 --> 22:42.600 And on the other side, you can verify this. You can say, this is really this system or 22:42.600 --> 22:50.040 the stockter in this department in this hospital. And on the other side, you can verify that, 22:50.040 --> 22:57.560 without needing to agree to a single point of failure or control, that tells you in both directions, 22:57.640 --> 23:06.040 yes or no. You can now make this local decentralized, which I think actually offers us for the 23:06.040 --> 23:12.680 first time something that solves the usability problem of key management. That's why I started 23:12.680 --> 23:16.520 all of this, right? That's why I realized we needed something like this, because this is something 23:16.520 --> 23:21.640 after between since the 1990s. I mean, I, I, I was part of everything of key management thing that 23:21.640 --> 23:30.920 existed. Um, and that finally, we have an actual answer to this. So it solves this cross-domain trust 23:30.920 --> 23:37.880 issue, right? The cross-sure, trust issue in an elegant, robust and scalable way. And so I would be 23:37.880 --> 23:43.720 very happy if people were building on it. I mean, we are, um, with our partner together, 23:43.720 --> 23:50.120 having a health innovation center now. So anyone working on health care IT, right? Anything in this 23:50.440 --> 23:59.000 domain, interested in this, wanting to work together, please get in touch. We are not only 23:59.000 --> 24:04.200 open, but we would like you to, to reach out to us. We actually want to work on this together, right? 24:04.200 --> 24:10.200 We, this is, this is such a big thing. It doesn't just take, if you, if you, if you guys to do it, 24:10.200 --> 24:15.480 it takes the community at the end of the day. And of course, since everything is going to be 24:15.560 --> 24:21.800 free software, I would be very happy if others took this and applied it to other domains as well. 24:22.360 --> 24:28.680 Right? If this might be something that could solve a problem for you, right? Reach out as well. 24:29.400 --> 24:35.720 I mean, all of this is really like recent development. As in, the alpha test phase will begin 24:35.720 --> 24:44.040 in March in a month from now. It's that much that at the forefront, right? It's really at the edge. 24:44.120 --> 24:49.080 But by the end of this year, this thing is in production, across with someone. And I'm absolutely 24:49.080 --> 24:57.640 certain that that will happen. So, that is what I wanted to share. Thank you very much. This is my view 24:57.640 --> 25:07.000 card. So, without if you want, you have a point at detail. And if there's questions, maybe we still 25:07.080 --> 25:10.520 have space for more. Yeah, I've put up some further questions that. 25:13.080 --> 25:18.440 Yeah, thank you. Thank you. I'm very interested. The load of cells sober, 25:19.240 --> 25:25.240 identify systems always come down to how do you manage your private piece that you mentioned 25:25.240 --> 25:30.440 to be able to perform the device? The devices get lost all the way down. Yes. 25:30.600 --> 25:40.760 How can you reach all the devices? So, the way that carry allows us to handle that case is 25:40.760 --> 25:47.480 whenever you generate a new autonomous identifier, you have one key in private storage on the device, 25:47.480 --> 25:53.800 right, ideally in a hardware, of some kind, some HSM, however that may look like. And you have a 25:53.800 --> 26:00.200 second key that is your, your pre-commitment on the recovery key, right, but that key never gets used 26:00.200 --> 26:05.320 until you need it. You store that key in a different system. You can either do a social recovery, 26:05.320 --> 26:09.240 right, you can break it up and give it off to five people, you trust or whatever, right, 26:09.240 --> 26:15.480 or you could give it to an escrow. I mean, depends on your use case, this is a usability decision 26:15.480 --> 26:20.440 at the end of the day, right? So, you need to figure out what is my user base willing to accept, 26:20.600 --> 26:28.520 but I can handle that key anyway I want, and when that device gets lost, I can use that key 26:28.520 --> 26:34.280 to initialize a new device where again do the same thing, right, I have another private key in HSM, 26:34.280 --> 26:43.080 but I use this key to sign that interaction to say yes, this is the new authoritative key for that identifier. 26:50.440 --> 26:59.560 I would not tell her anything about keys, right? This is, no, I mean, this would be an application 26:59.560 --> 27:05.800 design thing, right? Like she would have her, whatever you want to call her, her app, right? And 27:05.800 --> 27:11.080 she would, you know, when the app initializes, right, it says, oh, you know, like either it's an 27:11.080 --> 27:17.480 initialization process that someone is participating in, as in you do it for her and you manage 27:17.560 --> 27:24.520 that or she gets it from a provider of some kind, like either her, her doctor or some other institution, 27:25.720 --> 27:33.720 like somebody that is in a trusted relationship to her. And yes, I mean, there's suboptimal scenarios 27:33.720 --> 27:42.120 obviously, right? But in the end of the day, I think a social recovery for these kind of scenarios, 27:42.120 --> 27:48.760 for most of us at least, would work rather well.