 Good afternoon. This is our last session. This is Marco Sons and he will talk about taking identity back from Facebook and Google, right? Yeah, that is it. Thank you very much. Okay, so it sounds like a pretty dry topic and it's been a long week and today is Sunday and this is the last talk. So I will try not to strain your brains too much. I'm going to make it easy for you to understand. Okay, so this is Sungoten. Sungoten is the second son of Sungoku. It's a very powerful warrior. And then you have a Trunks as well. He's a very powerful warrior as well. He can travel in time. So each of them have abilities and very great skills of fighting. But then they are able to fusion together and go to a new level of power and this is God Trunks. Okay, it's a whole new level of Super Saiyajin powers. So this is what you really have to keep in mind. Now let me move on. This is the current state of single sign-on in the web, the social media login. Okay, so each of those great, great. Now, well, I made this picture this morning and it's already been circulating over there and I don't really have to talk very much about what the problems are. The problem is not the DNS stuff and the problem is here. Okay, the problem is people making these accounts and sharing the information like this. So the project we are working at the moment in Denik together with other two companies I mentioned in a moment is taking this to a new level, to the next level of identity in the web. And we call this INET ID. It's just a working name. Okay, don't stick to it. It's just a working name and it's using your domain name as the cornerstone of your digital identity. And it's not like logging with Google, logging with Amazon, it's logging with your domain. And as I said, this is something we have just initiated. We're working some three companies that believe in open internet, free internet. I like to use the comparison of the mail. A mail is like this. If you talk SMTP, you just can put, set your own mailer and you can start sending emails and you start receiving emails. And as long as you abide to the standards, everything will work great. And this is the goal we are pushing at the moment. So it's the possibility of setting an identity provider yourself, running yourself if you want to in your own domain, then your private domain name or the domain name of your company. Or maybe if you are a bit lazy, you can just leave it to your ISP. And if you wanted to use an open provider, but it's up to you, the user, what you want to do. So thank you. I see feedback from the audience. And well, these are the features of the thing we're working on. It's based on open existing standards. I mean, we're using Open AD Connect as the basis of our work and we're going to expand it a bit. And everyone is able to participate in this open federated model. You can use your own domain name, you can brand it yourself for your online identity. And hey, if you don't like the provider who is serving you with your domain name, you can change it because you have been able to do this in the past and take your data with you and not leave them in a silo as the social media providers are at the moment. You can choose who you trust with your privacy and you can choose who you share your personal data with. Okay, so now about the thing that what has to do with DNS. At the moment, the mechanism for finding your identity provider, it's a bit DNA-based. Like the person itself has to choose what the identity provider is. So I know my identity provider is Facebook, so I click on login with Facebook. I know it's login with Google, so I click on login with Google. So it's a bit like a human base and we want to do this with a domain name. So we have to to automatize this somehow. I have to admit that there is a mechanism for in Open AD itself to discover what the identity provider of a given identify is. It's based on webfinger and RFC 73 and it's basically like you have to have a webfinger service up and running and then you get a get with some parameters and then find out what the value of the parameter is and you return it back. So there is a mechanism out there that could be used. However, we are using a DNS base discovery mechanism because we think it's the natural fit for the thing we are doing. So if you have a domain name, you are setting the DNS anyway. So DNS is set up and running and we think that setting up a webfinger service or an HTTPS server just for the purpose of the discovery is a bit of overhead. On top of that, if you set up HTTPS for the discovery, you're making a new look aside dependency. So you are introducing a trust dependency. So who is signing that certificate and do I trust that certificate for the answer? I'm getting back. Admittedly, you can redirect that to the DNS back with Dain, a self-signed certificate with a point in Dain. But it makes everything just much more complicated if you have DNS back. And well, DNS, we just think that it will be lightweight and faster that this webfinger service up and running. And as I said, webfinger is not being used the way you thought. A couple of considerations though. It makes DNS second must. This is not bad. This is actually good. So it's the perfect use case for DNS second. There's a privacy aspect there. And I like to dovetail with what Stefan said in the previous talk. And you're putting now personal identifiers in there. So I'm marcos.diniq.de and my identity provider is. Now marcos.diniq.de is now in the DNS, is on the clear in the DNS. Well, I can do a couple of things there. You can pseudonymize. I mean, you don't really have to put your real name there. You can use an pseudonym and put it in the DNS and use a mapping there. That's one option. You can do the pseudonymization at a lower level. For instance, you could, instead of putting the names themselves in there, you can just hash them. This is what RFC 81-62 does. S-MIME, Dain for S-MIME. OK, Dain for S-MIME had exactly the same problems. You have to put email addresses in the DNS and people didn't want that. And Dain for S-MIME hashes the local parts of the email addresses before putting them in the DNS. So it's something can be dealt with. And another aspect is, well, when you have HTTPS, assuming you're doing the padding right, each lookup has some confidentiality. So nobody knows what you are asking. And if you do this in the DNS on the clear, so no encryption, then you won't have this. Still, when you decide to put this in the DNS, you are in front of a couple of options. What do you do? And you can do just SRV record, like 2788. You can do an after record. You can combine both of those in this process called straight forward and after. Everything is, all of those are RFC standards. You can even invent a new error for that. Dain has a couple of problems as well, if you do that. And then we have DNS service discovery, a combination of SRV and a TXT record. This is what Weftab does. And you can just use a plain TXT record. And you know what? This is what we are doing. Why? Because it's easy, because everybody understands this, because you can read it. And it's easy to read as this. So this is our mechanism for finding out where the identity provider for a given domain name is. And we are using an underscore up there, the owner of the domain name. We have scoped it in underscore open ID. And then you have the rest of the domain name. And then, well, it's version. This is something like Dikim and DMARC 2, like putting a version at the beginning of the RTA of the TXT record to be able to cope with new versions. And then, as you see, issuer equals, and then you have this name there. The issuer is the jargon in open ID for the identity provider. And we don't care about the claims provider now. It's not very relevant to the talk. So, well, we have got a bit of feedback about this. Somebody told me, oh, my dear, TXT records. And then, OK, I'm just not going to discuss about it. And somebody said, well, it was, if you edit a website, it's easier for somebody to do it and introduce things in the web. But putting things in the DNS requires talking to the DNS department and the company or something. And that's not so easy. It's a bit of an organization or coordination problem. And then we also have the problem of the lazy web developers. OK, the lazy web developers, the one that do web shops, they just want to put some JavaScript snippet there, like to log in with the INET ID, put the JavaScript snippet. Well, the problem is I just cannot provide them a client-side JavaScript snippet because this is not going to work because the JavaScript is in a sandbox. And, though, I've seen pretty cool things with JavaScript. Somebody taught me a demo where you can find out your local IP address via JavaScript. I didn't know that was possible with HTML5 and WebRTC. Apparently, you can really find out your local IP address. But you cannot do DNS lookups. So, remedy for that. Well, there is DNS over HTTP. That's a possibility. We have this draft there that Shane knows pretty well. It's a bit clunky for the JavaScript developer because he still has to do with the DNS wire format to cope with it. This is not what the JavaScript developer wants. So maybe we'll get something easier for them. You just can set up an HTTP proxy service. Okay, I just can run an HTTP proxy and you can do the queries there and I can do the resolution for you. But we still have those third-party dependencies. I don't want you to trust somebody to find out the identity provider. I want you to find it for yourself. So, this is more or less the whole of the talk because I wanted to leave some room for discussion and questions. We have a project page out there, inetited.community. We have there a better explanation of the whole project. We have links to our overview paper, technical papers, the two drafts we have submitted to the IDF, and one of those is the one about OpenID DNS discovery. So, that's it. And please, feedback. It's not good private stuff in DNS. I mean, there's too many people do that and it ranges from tort of using DNS to discussions on putting HTTPs in DNS. Basically, nobody has come up with a good solution on protecting private stuff in something like DNS that tries to publish it as far as possible. So, maybe you don't like to have a web server for that, but I would say, well, go for the web server. Okay. Thanks for the feedback. Is it down to the user level on the delegation to be approachable on provider or can I do that on the main level? Because that would lessen the issue. As in, I'm from that domain, okay, I think I understand the question. The question is if you have to put each one of the records beyond the second level. And at the moment, the discovery mechanism just requires you to put each one of those. I mean, you could think of some kind of bottom-up discovery mechanism that if it doesn't find the third level, then goes to the second level to find out and so on and so forth. I haven't had really good experiences with that. At the moment, the specification says you really have to put the identifier itself in the DNS to find out who the identity provider is. How do you actually make services or service providers actually use NetID login or whatever name will be? Well, it will be as easy as putting yet another login with because the mechanism is exactly the same. We just have to convince them, okay, this is a bit of the hard part of the work. And I'm pretty convinced of what the good aspects of this is and I'm sure that many people in this room agree with this. The problem is getting to the people that really don't mind about this and I think that approaching big service providers, big shops and telling them, it's not that hard for you to include this additional login with but you have the potential of reaching a whole new world of users that don't have a Facebook account, don't have a Google account, don't want to have it and still, they are potential customers. If we try to present it like this, then maybe they say, okay, it might be worth it. Okay, then thank you very much and if you want something, just approach me, Vittorio Bertola from Open Exchange, Peta Hobel from Open Exchange are also over there and thanks for your feedback. Have a nice day.