 Okay, hi. Welcome to my presentation on IndyCert. I had a bit of a cold in the last couple of days, so maybe I'll sniff a bit once in a while. I'm sorry for that. So, a little bit about me. I worked professionally on SAML Identity Federation, so I do know something about federated identity protocols and how to authenticate in decentralized ways. I wrote an OAuth 2 server and client and I started working on IndyCert after finding out about IndyAuth. Does anyone here know anything about SAML or OAuth or is it all new to all of you? Anyone ever heard of OAuth 2.0? Okay, three people, four. Okay, interesting. I'll try to explain more details and if you cannot follow, just ask a question or interrupt me and then I can maybe explain this particular ID better or differently. So, IndyCert is based on the idea of IndyAuth and IndyAuth is a decentralized authentication mechanism where you do not need a central service like Facebook. Many sites use Facebook Connect to authenticate users, but in this case it will be much better or at least I think it's much better to use a decentralized mechanism where the user is in control of their authentication. And what is new about IndyCert compared to IndyAuth is the use of client certificates, which has been available for many, many years basically since the introduction of the browser, but almost no one uses it. And that's a shame because it's really interesting technology and also quite secure once if you implement it correctly that is. So, a little bit about IndyWeb and why I'm building this actually. The idea of the IndyWeb is that every user has their own homepage with an SSL certificate preferably, so you run your own domain and you have your own hosting arranged. So you're in control, you're not depending on other people or big corporations to give you a webpage or a blog. So that's basically the principles of the IndyWeb. There's a wiki dedicated to this kind of technology and it's an IndyWebCamp website, the link is there. And then the one particular interesting thing about this IndyWeb is that there's a decentralized way to authenticate. Basically, you use your domain name as an identifier to log into various services around the internet. So that gives you the option to use the same identifier everywhere in all the services. And it also gives you the option to have one method of logging in. So as a website that wants to support IndyWeb, you would implement a protocol and then it will be up to the user to decide who they will trust for their authentication. So for logging into this particular website. So in addition to Facebook you can have GitHub or Twitter while the site that wants to authenticate the user doesn't have to implement all those protocols directly themselves. So how does it look like for the user? It's basically this, you just type in your domain name at relying party or client that wants to authenticate you. And then the IndyAuth client and service will take care of the rest. So you can use your domain name basically as an identity across the web. I'll go into a little bit more detail now as to how this works. On your homepage you will just put a number of different authentication sources that you trust to authenticate your domain basically. So initially IndyAuth supported a number of different mechanisms for example GitHub or Twitter. If you put this tag on your own homepage, IndyAuth will know that it can ask GitHub to authenticate and then verify that that account belongs to you. And in that way you will claim your own domain name then basically. So the relying party will know that you authenticated with this account so it must be your domain. So you can use it as an identity in the service. So that's what you do. You just mentioned the identities on your own homepage. Okay, so once you indicate the sources of your providers that can authenticate you, you can also indicate which service you trust to validate this identity information. So as a domain owner you can choose this. So here's two examples. One is using the IndyAuth service and the other one is the IndyAuth service where I will talk about in a second. One of the problems with IndyAuth is that you still depend on GitHub or Twitter or Facebook to log in although the mechanisms are interchangeable. So if Facebook decides to close your account you can still use Twitter or GitHub to claim the same domain name basically. And so the idea was to remove this liability of the dependency on third parties by using client certificates. And using client certificates would also get rid of using passwords at all for logging in which is also a nice benefit. But yeah, if you use a client certificate and this is a Firefox example you get really confusing screen and like what am I supposed to do and what is all this information here. So that's a bit of a usability problem right now. Luckily in Chrome or Chromium it's a little bit better but still it might be confusing to the user. Like should I press OK or not. So that's a usability issue with client certificates that has to be solved at some point. So if we would just ignore this and see look at the benefits of using this. The credentials are actually stored in the browser or in your operating system depending on your browser or operating system. You don't need to use passwords anywhere. The certificate is just available to your browser and can be used to authenticate everywhere. There's also no need in this kind of setup. There's no need to have a signed certificate or at least it can be self-signed. So you don't need to pay someone to verify your identity. It can just be any self-signed certificate. The only thing that's important is that you can prove that you own the key that belongs to the certificate or the private key that belongs to the certificate. Which is taken care of by TLS for free so you don't have to. What happened? That's weird. Anyone knows what's going on? It's back. OK so TLS takes care of the proof of private key. But if you install it in Firefox or in Chrome then you don't have it on your mobile device. So you would have to copy the certificate to your other devices or create new credentials. But because in the authors supports multiple authentication sources you can just put all fingerprints from the certificates from all the devices on your homepage for example. So every browser or every device gets its own certificate and thus it's own public key and you can all list those on your own homepage. So then InDesert can verify that you own this private key based on you putting it on your homepage. So you know they know it's you because you proved ownership of the private key. There will be a demo in a while so then it becomes a bit more clear hopefully. So on your homepage instead of mentioning GitHub you would mention something like this and the value here is the base 64 encoded fingerprint of the certificates. Now a little bit about the protocol. How does it work? See if the mouse works. Very unreliable. OK that's not really useful. Well the protocol starts at the relying party or the client that wants to authenticate the user. It will first fetch the homepage that the user provides in the box in a few slides back where you provide your domain. It will fetch the homepage and see what kind of authentication server you configure there. Then it will start the authentication by redirecting you to the service. Then that will check the certificate or ask for a certificate from your browser then verify that you have the private key. Then fetch your homepage again and see if the fingerprint is actually mentioned there. If that's done then authorization code is sent back to the relying party that then can be used to verify this code and confirm that you're actually locked in. So it would be really good to have the tools available to make this very simple so to create certificates and use them for this kind of purpose. But it's a bit too soon mostly due to the bad user interface and user experience. But at least it works. So for a couple of nerds it will be fine. Maybe if it's actually being used then it creates some incentives to improve the browser UI. Oops it goes away again. Okay maybe it's my laptop. So the benefits are that you don't need a password anymore. You do need your own website with an SSL certificate configured correctly which is surprisingly hard. And well if you have your own website then you're already any web member by default so there's no application process. Okay now it's time for a demo. Maybe some of you would like to follow along so you can go to this website on your mobile device or laptop or anything. I'll try to do the same here to show how it works. Can you read it or doesn't really work great. So you would type in your domain name here and then it will redirect you to a page that says that you do not have a certificate installed. You don't have a client certificate available. And it shows you a link for the enroll process where you can generate a certificate and have it installed in your browser. You only need to press generate. And then Chromium in this case will say okay install the certificate. You can click here to try to authenticate using this certificate which will then show the pop-up screen that you can accept. Almost there. Now I need to put this certificate fingerprint on my own homepage so that because I typed in tux.net. These are fetched this homepage but I didn't find a certificate on there so it doesn't know yet if I actually own this domain. So if I put this on the homepage I don't show it now. Okay this is the HTML of my homepage. I can just add it like this. Save it. And now in the background I will push this to the web server. If the Wi-Fi wants to cooperate. Okay. I did that now. Okay. So I put this fragment on my homepage and if I press reload it should find it. Okay. So now it's asking if I want to give permission to the indyser.net webpage to verify my identity. Which is here. So I approve that. And then I'm logged in and this identity is now verified. Again log out. Then I'm back here. Because the process I'm now already enrolled. If I do this now it will immediately ask for the identity and then I can press approve and it is done. So that's only a one-time step. So for all services that support this now you will be immediately logged in basically after you approve it. Did anyone manage to follow along or does it work? Cool. Nice. Okay so there are a number of alternatives. Although maybe I can first ask if anyone has questions about the demo or wants to know a bit more about what they saw. And a usual problem there is that a browser somehow gets confused and you just get an HTTPS error message. And then you have to go into your Firefox setting and delete some security device to fix it. So it seems that this client certificate mechanism has some principal problems that a normal user won't be able to fix. Well that's one of the problems with the client certificate. The user interface and experience is pretty bad. Also if you don't approve the log in with the client certificate but you want to do it later you cannot. You have to restart your browser first. Which is not really great. I'll talk a little bit more about the problems with client certificates later. Any other questions on this particular part? Okay. Then I'll talk a little bit about alternatives that already existed before this. One of the most promising ones was IS WebID plus TLS. It's using a similar system. I'll talk a bit more about it in a second. Mozilla persona browser ID which works based on your email address instead of your domain name. And OpenID Connect which is very similar to indie auth. But it's a bit more of an enterprise-y standard nowadays. So it includes everything and the kitchen sink. But the kitchen sink. So WebID and TLS. So these are very similar and it would be a better final solution to this client authentication problem. But it's more work for people trying to implement it right now. So it would be the ideal end situation but right now it seems like any sort is in the middle way. So it's like halfway between username password and halfway towards WebID TLS. So it seems like it would be a good start to make a small step first and then maybe later go to WebID and TLS. Which seems most interesting long term. WebID TLS is not really compatible with anything currently deployed. So every relying party would have to implement everything. And most of them already implement some kind of OAuth interface to Facebook or Twitter. Which is almost identical to the one required for indie auth and indie cert. So in that sense it will be a lot easier to start using indie cert than WebID. Persona browser ID uses an email address or actually it's in verified email protocol. So the only thing the server knows is that you own this email address. It turns out that although a number of sites use it, it's quite difficult to make it decentralized. The protocol is quite difficult. Many of the implementations only support the Mozilla as the identity provider. So if you would actually implement it all yourself then it wouldn't really work anyway on a lot of relying parties. They would just go to Mozilla and ask Mozilla to verify your identity. Which is not really decentralized in any way. It also requires you to host some software on your domain. So it cannot be delegated to another party. Well it can be delegated to another party but then it involves lots of things that were never implemented or tested. It's probably not supported anyway. OpenID Connect is another solution that's quite similar. It started out as a good idea but it really quickly turned into a really complicated spec with many documents. It got a bit of a semel feel that's like many documents. All documenting how to do this and that but not really making anything must. So it still will open to interpretation by different vendors. So it will not really be interoperable anyway. And it will make it very complicated to implement it yourself. Oops, screen. Yeah, so OpenID seems super complex. OpenID Connect is super complex compared to indie auth and indie cert. So for just authentication it might be smart to not go this way. So in the auth and indie cert it's like very similar to OpenID Connect. But it just stripped out a lot of different optional parts basically. It's quite easy to run your own. It's also quite easy to delegate your authentication to a public server for example. You can switch your identity provider at any time. If you just change the link on your homepage you will use a different one. And yeah, the only disadvantage is that you will really need a TLS certificate on your own domain on homepage. Otherwise it's not going to be secure. So because it's based on OO2 which is a little bit broken. Although it's quite easy for server implementers to fix some of the flaws as shown by this blog post for example. Although even though it's already like five years old. Yeah, five, no not five, three. It's still not addressed or even acknowledged that there are some problems with the spec by the working group. So that's a bit of a problem. As for the user experience with client certificates there are a number of proposals. One decent one I found is browser auth. It's a website created by Google engineer. It states very clearly that it's not official Google initiative so no guarantees there. Yeah, so the number of items that were listed there is the better user experience which is quite obvious if you ever used client certificates privacy. If you use the same certificate on all relying parties then it will be quite easy to link the users together. Although that's not that different from using the same email address when you register at every site so in that sense it's not much worse. One of the problems was portability. So if you have a certificate on one device. You cannot really easily copy it to another device or maybe it's not even possible to extract it, the certificate. So you would need to have multiple ones. And another enterprise problem is that if you have a big data center you have some kind of TLS terminators. So then that would have some influence on the trust you would need to have on this TLS terminators. So a couple of initiatives by browser auth is to use origin bound certificates. So for every domain you want to log into you have your own, has a known certificate. So there's no need for user interface anymore to ask which certificate to use because there is only one per domain. And if it doesn't exist it would just be created on the fly. Another enhancement would be to bind it to session cookies. So you would use the, it doesn't work with any other certificates so if someone steals your cookie then they cannot use it because they don't have your certificate. There's another problem in, they try to solve this if you have a federation protocol so that you have some kind of identity provider with various relying parties. That you have to somehow convey the information that you actually own this key to a relying party. But because you're using all kinds of different keys for all different services it becomes a bit complicated. So they came up with a JavaScript API to solve this problem which seems a bit weird to me but okay. All right, that was it. Anyone have any more questions or remarks or ideas? Why this is a bad idea at all or maybe it's quite good or I should just stop it immediately or it can be very critical so. Don't be scared. So how does it work with smart cards if I want to keep my certificate on something at the Nitro key that was presented also here earlier. So does it work smooth or not? Well I haven't tested it yet but in theory it should if it can store client certificates. It will probably use some kind of PKC as 11 driver to interface with the USB card or stick then it might work. So there's no reason why it shouldn't actually but we interesting to try out at least. More questions? It maybe depends a bit on what you want. Do you just want just some sort of identity? This is the same guy as last time or do you really want proof that his name is first name, last name and so on. It maybe depends a bit on what you want whether it works or not. Yeah. Right. Yeah, yeah. In theory it would be possible to only use a certificate and not use a domain name. So you would have a surname only that could also work. Any more questions? Then there is going to be for people who are interested in this kind of stuff. There's any webcam in Dusseldorf on May 9th this year where people will be talking about in the Oath and hopefully in the cert if I'm there. So if you're interested in working on that or finding out more you can come there and register online. So that was it. Thank you.