 So, thank you very much for everyone being here at this early hour for this Congress. I had a good chance passing my checkpoint for security this morning, so I had no problem in entering the C3 world today. And this is all about identity, identity to pass somewhere, to get somewhere inside in the right direction or to authenticate yourself towards someone else. This project HeartMood will tell us a bit about how we can solve this in the digital world, because wearing something around your wristband in the digital world might not work as well. And so, I want to hand over to HeartMood, who worked on self-sovereign identity here in the region of Hamburg. Welcome to SSI in Hamburg, and thanks for having me at the ModCast experience. My name is HeartMood from GENSTEP, and with my colleague Attila, we will today look at self-sovereign identity, first from a more user-focused perspective, and then diving deep into one core aspect of what actually needs to be done to build your own SSI system. So, before I talk about the consequences of putting SSI as a service into use, let me first start with some very high-level basics. What is SSI? It's not so much a working technology as of now, although there of course are some first implementations. It's more a set of standards. I'm saying this only for now, the end of 2020, as we see a lot of push from the EU and the German government to implement the European solution for an identity mechanism, and SSI checks all the boxes. So, SSI is actually two standards, and both could be used independently. Firstly, there is the decentralized identifier, but did. And secondly, the standard for verifiable credentials or VCs. Taken together, they provide a secure and privacy-focused decentralized identity and authorization mechanism. The did is an address, much like a URI. It is created using a did method, subject of the second talk. The address can be resolved, and a document retrieved that can serve as a storage for almost everything related to my identity. Storage can be in the document, which is really just a JSON file, or referenced in the document and stored externally. The document is technically managed by a did controller, and all of this is nicely documented in the spec. So allow me here to simplify and to say that it is not completely wrong to think of the did and its connected data stores as your wallet for ID and authorization. VCs now are an important part of what is in this wallet. A VC is a verifiable credential, a documented proof from a verifiable source signed with public key cryptography that contains validation of some sort. It could be from the state validating your personal data, or from your bank validating your account details. It could be your driver's license or the membership in your favorite music club. The important thing to remember about VCs is that they can be used like a membership card. You don't need the approval of the authorization source to show your VC as a proof to a third party. Also, you can do need things with showing only partial information or zero knowledge proofs. But what is SSI for the user? Let's distinguish between two different scenarios. One that you'll likely find when you search for SSI on the internet using SSI to identify a person. The did in this case is simply me or rather my wallet or running a hill twice within a certain time. The verifiable credentials can be described as follows. First, there are the badges I earned, proof that I did certain things, that I passed certain conditions, such as getting a degree, but also attending a conference or running up a hill twice within a certain time limit. Then there are the keys I collected, keys that unlock information I can access or share. For example, with digital services, keys to the data collected with my fitness band, keys to unlock my vehicle with my mobile. Finally, there are the powers I was officially granted, which is really just a different wording for the same thing. Permission to park in certain spots, ownership of a vehicle, permission to ride a bus or visit a concert. Another less known application of SSI is managing the ID of things. Here, the did can be linked to an ID token such as a windshield sticker, identifying my car or a portable access token that I can pass around freely. A VC here contains the data required for interactions. A car can provide its make and type of engine or state of battery and the permission from its user to pay for recharging. You can see where I'm going. Much as you don't need your bank to show proof of your financial data, the object does no longer need its owner to show proof of the powers it was granted. And finally, VCs can also be used to store the information about the history of interactions, much like badges only for objects. So what does this mean for a real application? Put simply, it's very powerful. We have explored some of the applications of SSI in a BMW research project nicknamed Stereo. There's a link in the comments and I will present some of the results here. If you, for example, take mobility and more specifically shared mobility, public transportation and ride services, so everything you use to get around but do not own, there are two different specific ways to use those as a tourist. Or if you happen to not see the next train vehicle on the street, you need to first understand what options you have. This is discover. Afterwards, it's straightforward. You book, you use. And very often the case is more simple. You already have a plan where you're going, you book a vehicle, you use it. Perhaps you don't know what you'll do later in the day, but that will follow the same mechanism. You book something, you use something. And in essence, this means that intermodal mobility seamlessly using different modes of transportation and different providers to get around in an urban environment sounds pretty complex, but is pretty much covered by Google Maps and SSI. SSI being used for getting permission and proving permission. Yes, Ubers and others are building mighty tools for collecting your data while providing mobility, but that's really not necessary. You are only required to share your information with the service providers you use and only the information that is required for the service with SSI. No need to share your location while you're walking from the Uber to the bar. So if you follow the discussion in Hamburg, mobility is also changing. And in Hamburg, the Beherde for Verkehr and Mobilities vendor, which roughly translates to agency for transportation and mobility turnaround is planning to change things. Cars will not go away tomorrow, but the idea is to improve utilization and fine control where they can go. And when? An important piece of the puzzle is the Landesbetrieb Verkehr, who are not only tasked with shutting out cars from Jungfansstiegen-Mänkebergstrasse, two of the main roads in the city center, but also with managing car traffic in general in Hamburg. Backstrasse, two of the main roads in the city center, but also with managing car traffic in general in Hamburg. If you want digital ID for cars, if you want digital IDs for cars, you need a digital registration. With the Christoph Kochgegruppe, we have defined digital registration for cars that will free you from having paper documentation such as the 2000s Bestätigung 1 and 2. Using your digital ID and the digital proof of where you live, the LBV then can give you a car, the digital permission to park in residential zones, digital permission to park in residential zones. If you invite a friend post corona, you can transfer your trip. If you invite a friend post corona, you can transfer your temporary permission to them so they can park in your residential zone to visit. If you need a plumber, they can provide digital proof of your order to be allowed to park in your street and so on. SSI can be used to store these proofs in a decentralized way with or in the car. This control does not need to access a central ID service and this in turn, thus access control does not require a central ID service and this in turn minimizes the need for sharing your personal data. The use case can be expanded to cover other services, control for deliveries to your infancy, access to private parking facilities or all the charging infrastructure that will be built in the city. Perhaps you can see how this has the potential to change the way we interact with services and the keyword here is decentralization. SSI can decouple timing of granting and checking rights. This in turn enables edge communication as a network of things can decide whether a car is parked properly or a ticket for the bus is valid without interaction with the central system. It returns the ownership of data back to the individual and it simplifies the integration of systems so data no longer needs to be sent from one system to another but it is rather the user who decides to share her data with those services she wants to use and trust. So why are we not there yet? As we see it, the problem is not that this is not feasible. The problem is that the most important gains are for the users and while there are no users of the system, no services will jump on the SSI bandwagon and without services the advantages for users remain hypothetical. We feel there is a good chance that SSI will move forward. As said in the beginning, there's a strong ask from the EU and German government for ID solutions. What we would like to discuss with you is if you have any ideas to give privacy a further push and how to faster make SSI a real solution, not just a very good idea. Thank you for listening so far. I hope you enjoyed the presentation and I'm really looking forward for your comments and questions. Welcome back from this video from Hartmut all about how to authenticate yourself, how to have your own digital identity at the moment. There are no questions asked yet, so we welcome you to come into HackInt and ask your questions. All you want to know about this project, there's our Signal Angel 95p waiting for your questions. You also have maybe the chance to use Twitter and all other feedback options. Anytime in between, Hartmut, you did this project here in Hamburg. What was the advantage of doing it in this wonderful city here? Well, I think the reason for doing it in Hamburg was that for one the project was about finding real-world applications and it's really hard to do that on a global or even EU-wide scale, so we went really local. The other aspect is that in Hamburg we have a lot of projects at the moment that are ongoing that are centered around mobility and we felt mobility is a really good starting point for identities, digital identities because yes, they are, I would say, not as necessarily secure as if you were going into banking, but they are very frequent use cases and if you want to get digital identity working, you need to use it and if you can use it in transportation, that definitely gives it a boost. So that was the thinking that we can do it in Hamburg. We could do it together with the city and this is also something that we found actually to be true. So we were working very closely with the LBV and with the HAFAV and with the HASPA to identify how we could basically reach people and offer very simple services to them. Okay, I have one question here incoming. I don't really see how this is different from what David Schoen did in the 90s. Actually, I don't know what David Schoen did in the 90s, so maybe whoever asked the question can amend that. What I would say new here is that the standards are developing into something that can be put into real use. So SSI for now is just standard by the World Wide Web Consortium, but there are several groups. We were only one of four projects that were using it as a technical standard. You have something that is not like OpenID, for example, a federated ID, but a really decentralized ID and a decentralized ID that is being pushed by the German government. And I think this is a new situation. It doesn't mean that all the technology is really new. Definitely a big part of SSI is public key cryptography and that is not really something new, but actually use it in this way is something that we found hasn't happened so far. Great. So there's another question going out for the security of the system. What is stopping the service provider to store my data provided by VC and abuse them? Is there also, this is also within the SSI outside of my personal control? Yes, once you, there is a fundamental difference if you start using SSI. First, you have control over your data and you have control with whom to share it with. This is, I think, an important difference. And then once you shared it, it depends on the terms of service. So the mobility provider, if we take that example, does not need your information. So there is no real use for them to actually store it. Sorry, there is no real must for them to store it. And if we, this is something that highly depends on regulation, if we were to introduce a regulation similar to GDPR that would make it actually costly to store that information, service provider would be motivated to not do this at the moment. The benefits of storing your data vastly outweigh the problems that people have with it and GDPR is starting to change that. So for simple use cases, I think SSI already does that. You don't need users credentials. You just need a third party for authentication. And this is where we see really big commercial services like Auth0 already working quite well. So people don't store their data themselves. They use a service to do that and could be the same for other types of data. All right. About making people feel secure with SSI, how do you do that? For example, do you know the term of Irma? I reveal my attributes or something like that. There is two problems that are here. I think one is feeling really safe and the other is conveniently still using your service. So what we saw also when we talked to citizens of Hamburg is that once you start thinking about it, there is really a strong willingness to protect your data. I think one good example for that is the German COVID app, which is comparatively safe, but a lot of discussion centers around how it shares data. And then the moment after they've discussed this, people just go on the Internet order a pizza and share their data with providers that take everything and give almost nothing. So I think in our concept, what we had to define is where is the sweet spot between really doing something very conveniently and doing something really safely. And this also if you go further into it starts with where do you store your data? Because if you're really, really, really concerned about it and SSI allows you to do that, you should basically run your own service provider, or you should have a hardware store to store your data. If you look at the citizens of Hamburg, you won't find that many who will do that. So there will be a need for some trusted providers. And this is why we work with Sparkas or Hamburg DE, who are not that interested in taking your data to actually monetize that. And you can, to a certain degree, trust them to actually take care of the data. I think this is the more severe topic then. And then the other bit is where do you show what data you share? And we haven't gotten to the stage where we can really define that from your eye perspective. But the thinking that we had in the project is that there is a relatively good model with how apps are being installed on mobile phones that many people know. So like other projects, we actually went down the same path and said, whenever you have a request for your data, it will show up much in the same way as someone asking permission to read certain bits of data. And if you want to expand on that, you definitely need the convenience factor for repeated questions. So if you do a transaction with your bank and they ask for certain details and you do that again and again, you might want to have something that is recognizable that says, okay, this is actually your bank asking and it's nothing out of the ordinary. And then if something comes that is very different from the usual request, that is something that we would show in more detail. Could you elaborate on how decentralization works on this? Yes, in many ways. So the most important, I think, is the very hyper credential. So most access control mechanisms in the digital world require to go to a trusted source and ask them for the information. So for example, if I wanted to look in, let's take your badge basically, if I wanted to know if your badge is real, I would go to the one who issued the badge and ask them. And with SSI, this is no longer necessary because the badge is signed and the signature can be verified. So I don't need the issuer of the badge to be present. I can just look at the badge and I can decide whether it is valid or not. And if it's valid, I can decide to trust it. I can add further mechanisms to see if it's still valid, like if it has an expiry date or if you take the driver's license, if someone did things that made the authorities take the driver's license away. But the existence of the driver's license doesn't need, you don't need the issuing authority to prove that the document is enough. And this means I can carry it. And that is a very important part of the decentralization. I can just have it with me. And this means, for example, if you go to the object IDs, a self-driving car can have all the required information to interact with services and there's no need for the internet. It can all be done on the edge. So the local communication is something that this enables. Great. We got another information on the David Schaum in the 90s. Schaum did road pricing, ticketing access based on zero knowledge proofs and decentralization for the Dutch government. It sounds pretty similar. I will definitely look into that. And we also didn't do everything ourselves in this project. So what we did is the SSI identification bit. There's already a project in the Hafa Faw, for example, at the moment, which is aiming to calculate the best price based on your actions. So when you take a bus and then an S-Bahn and then you go back and then in the end buy you a day ticket and not for individual tickets. But in order to do these services, the current solution very heavily relies on geo data. And that is something that is being stored and collected and actually not thrown away. And it would stay with the Hafa Faw for a long time. So what we did is we took the current plan and changed it in a way that would be more data friendly, I would say. It's for the last question now. Do you see the need for official regulations in order for this technology to become a good part for our society? Yes, I think that if there are no regulations, the chance that something like this will see it is relatively low. But it doesn't mean that everything has to be regulated. I think the important part is that people start using a system. And once it is in place and there is a certain user base, it will be commercially viable to incorporate that. And then the system can actually dictate how it's being used. But for the starter, I think this can be something like communal services. So if all cities in all of Germany would decide that their services are only being accessible using a secure identity system, that would definitely mean that everyone has a digital identity system that they can use. And that would be a really good start. What a wonderful word for the end. Thank you, Hartmut, very much.