We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

ID4me: using the DNS as a directory for identities

00:00

Formal Metadata

Title
ID4me: using the DNS as a directory for identities
Subtitle
Who needs a blockchain when you have the DNS?
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
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.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The DNS was born as a directory for hosts, but shouldn't it also be a directory for people? As Internet-scale single sign-on and identity management platforms multiply, each enclosed in its own private namespace, there is a need to federate them and make them interoperable in an open and standard manner. We will discuss why the DNS is the best tool for that, compare it with trendy but less suitable alternatives (e.g. blockchains), and summarize the workings and the status of existing projects (ID4me). The talk starts by discussing why a standard identity layer for the Internet is necessary and how it could work. It then discusses the possible options to build a distributed and federated database of existing identities, which is necessary for any such layer to work; and shows why the DNS is the best option currently available, when compared to Web-based protocols (e.g. Webfinger) and to blockchains. The talk then presents the architecture of the ID4me project, an attempt to build an open and public standard for Internet single sign-on based on the DNS; since the project was already partially presented in last edition's DNS devroom but has accomplished several new steps, it then gives an update on its status. An earlier version of this talk was already presented at the 2018 DNS Symposium organized by ICANN in Montreal last July (the slides from that talk are attached as a sample). This version will include an updated second part with some more details on the architecture and recent developments of the ID4me project.
10
58
80
111
137
Thumbnail
15:21
159
Thumbnail
18:51
168
Thumbnail
26:18
213
221
Thumbnail
15:22
234
Thumbnail
49:51
248
Thumbnail
23:06
256
268
283
Thumbnail
28:38
313
Thumbnail
1:00:10
318
Thumbnail
21:35
343
345
Thumbnail
36:13
353
Thumbnail
18:44
369
370
373
Thumbnail
44:37
396
Thumbnail
28:21
413
Thumbnail
16:24
439
455
Thumbnail
25:10
529
Thumbnail
15:36
535
Thumbnail
28:04
552
Direct numerical simulationIdentity managementDirectory serviceControl flowTrailSingle-precision floating-point formatSingle sign-onExistenceSign (mathematics)Mechanism designTime domainMathematicsInfinite conjugacy class propertyComputing platformPhysical systemOpen setSingle sign-onInternet service providerMechanism designSingle-precision floating-point formatDomain nameWebsiteLoginDifferent (Kate Ryan album)NumberTouchscreenTrailInformation securityFacebookWeb 2.0Service (economics)Point (geometry)AuthenticationSet (mathematics)PasswordAddress spaceCASE <Informatik>Communications protocolIdentifiabilityString (computer science)TwitterSign (mathematics)Directory serviceIdentical particlesToken ringServer (computing)Scaling (geometry)Information privacyQuicksortDomain nameCNNGame controllerDirect numerical simulationClient (computing)Flow separationEmailDevice driverConcentricPhysical systemElectronic mailing listOpen setConnected spaceIterationPublic key certificateUniform resource locatorArithmetic meanOrder (biology)Axiom of choiceGoodness of fitWater vaporComputer animation
System identificationArchaeological field surveySoftwareSource codeElectronic mailing listNumbering schemeNamespaceDirect numerical simulationMathematicsVideo gameNormed vector spaceSupersonic speedSoftware engineeringIdentifiabilityHash functionPointer (computer programming)File formatIdentical particlesDirect numerical simulationProjective planeNamespacePoint (geometry)NumberStandard deviationDisk read-and-write headTwitterCapability Maturity ModelDimensional analysisElectronic mailing listArchaeological field surveySoftwareLine (geometry)Block (periodic table)AuthorizationAddress spaceEmailGoodness of fitString (computer science)Row (database)Presentation of a groupDomain nameCartesian coordinate systemSpacetimeWebsiteMotion captureNumbering schemeServer (computing)Arithmetic meanType theoryDatabaseImplementationExtension (kinesiology)Information securityNatural numberRegulator geneRootChemical equationState of matterSoftware developerFrequencyDomain nameReal numberService (economics)
Internet service providerBetti numberPoint cloudWebsiteProgrammable read-only memoryFeedbackTerm (mathematics)Cartesian coordinate systemCentralizer and normalizerGoodness of fitInformationBitContent (media)Query languageService (economics)Server (computing)Point (geometry)Connected spaceIdentical particlesDirect numerical simulationSquare numberInternetworkingNumberMechanism designFile formatProjective planeRevision controlLatent heatOperator (mathematics)Independence (probability theory)Row (database)Different (Kate Ryan album)FacebookInformation privacyInformation securityWebsiteMereologyStandard deviationJava appletAuthenticationAssociative propertyIP addressOperating systemMessage passingData managementPresentation of a groupProduct (business)Sinc functionBeta functionNormal (geometry)PrototypeDataflowCASE <Informatik>Address spaceSoftware developerOpen setInternet service providerIdentifiabilityMultiplication signWeb 2.0
Computer animation
Transcript: English(auto-generated)
So, as I was saying again for the people remotely connected that the problem that we are trying to address is the problem of online identities and so how to do something better than just having 200 different accounts and 200 different passwords. And the point is that interestingly, we already have online identities because
each one of us has an online identity. The problem is that we're not controlling them. So we have an online identities because we are being tracked everywhere and we are being profiled. So maybe it's not directly connected to our main, but sometimes it is. But I mean, a lot of companies really know who we are across multiple services.
And this is basically because of advertising. But we do not have a way to basically do the same and have a single identity and control it. So we are stuck with having a thousand different accounts which is insecure and inconvenient. And so of course, the solution is some kind of single sign on.
And so you have a single set of credentials, you have someone who is basically running the authentication and verifying that you are you and telling all the other services that you are you. So of course, we already have this now. So of course, I'm sorry for Warren and the Google people, but again, we now have
basically two big entities running this, Facebook and Google. And it's really good. I mean, you see now everywhere on websites, you get this, I mean, big signing with Facebook, signing with Google, but if you really want, you can sign up with your own account with email. And so this is really a trend.
And it's very convenient. So it's actually very easy to do. And users like it. So it's been growing really fast in the last two, three years. But again, we have a problem where there is no interoperability. So I mean, even if all the systems are more or less based on the same protocols, they don't talk to each other. So and so you have a fragmentation in the end, you get you have a concentration because the
problem is that clients websites would have to implement each and every different provider separately. And so they don't do it for 200. They do it for two basically Google and Facebook. And users cannot choose. I mean, you can choose between Google and Facebook basically. And then again, this again creates an issue with privacy and tracking because if
whoever is running your single sign on will be able to tell all the places where you log into. And so I mean, if people try to do it, I mean, in a more open way, this is actually a real screen from a hotel, which was the recommended hotel for the ITA for security workshops. Actually, the old people were meeting there. And in this hotel really tried to give you some choice.
And so you had eight different login buttons to choose from. So this quickly becomes totally unmanageable and inconvenient. So we need some kind of federation, which is the solution. Of course, you can have a very, very easy to use a single sign on which is also federated so that you can choose your provider. You can have any number of providers.
They can interoperate. You can actually get your identifier. You can even get a domain name and so use a string in your domain name as your identifier. I mean, this is, I will not go into detail. The point I wanted to get to is that if you want to do this kind of federated whatever, then you need some kind of discovery mechanism.
So you need a way for the website that wants to authenticate you to know who is running your identity. And so this is what is missing. Actually, I mean, the protocol that everyone is using, which is open ID connect based on 2.0. There's also others, but open ID connect is most commonly used for this kind of use
case. They are not really, I mean, they do support some kind of federation, but they are not deployed in this way. They are just deployed. I mean, it's federation in the sense that you have many websites and a single identity provider, and that's it. And so we really need a place to keep the directory of online identities and a way to look into this list.
And so where do we keep the public directory for identities? And of course, the web people do it on the web. I mean, since now they are also doing DNS over the web. So there is actually a discovery mechanism which is already standardized in open ID connect, but it's based on WebFinger, which is based on HTTPS, again, and a well-known
address, URL, and so on. And so it has some limitations. By the way, it uses URIs as identifiers, which are really inconvenient. But the real point is that if you want to let people have their own domain name, their own identifier, and so you want to apply this on a million domain names for one million customers, then you need to have a web server for each and every domain in one million.
So you have a million websites, a million certificates, and so this is really inconvenient for deployment on a big scale in which you want to have any number of names and of providers. And so, well, the web is so uncool. So I'm sure you heard about this. So, of course, everyone is talking about the blockchain. Now, you know, everyone wants to use the blockchain.
You need to be self-sovereign, whatever this means, but it's the buzzword. And by the way, of course, there are tokens and ICOs and money going on. This is really a big trend. Maybe it's been slowing down in the last few months, but it's really big. I mean, this is one of the big drive, identity is one of the big drivers around blockchain. And so, of course, you see all sorts of different blockchain identity projects.
I mean, I took the screens like, I mean, last summer, so some of them might be older, might have already have folded up or whatever. But you still see a lot of different projects ranging from IBM, which is, of course, very willing to make yourself sovereign, to, I mean, foundations or startups. There's all sorts of players here.
And so the people do it on the blockchain. These people say we're going to put your identity in a blockchain so that it's there, it's public, then you have to protect it in some way because otherwise it's too public. But then you don't put identities, in fact, because, I mean, writing data into the blockchain is expensive.
And so you put pointers or maybe hashes of the pointers or something like that. And it's not very clear. But the selling point is that this is decentralized. So the nice thing is that we don't need a trusted central authority. We have decentralized everything. We don't need government. We don't need, I can, so, and there's even some standardization going on, even
if it's not by the W2C, but at the W2C as an independent effort. But there is some standardization. So this is, I mean, I went to a conference last year. This was in May 2018. And there was actually a guy that had tried to use a blockchain identity project for his own company. And so he did this survey. Went through a community website, went through the list of blockchain identity projects.
He found 91 blockchain identity projects. And 63 of them were already having or planning or announcing an ICO or raising money. But only 17 had a website which was more than, I mean, three lines and, yeah, coming soon. Only three had some software and zero had working software. So, I mean, this is not necessarily bad. The point is that this is really an immature technology.
So maybe it could come. I mean, I'm not saying this is all crap. It doesn't matter. But it's really not there yet, at least. So if you want to build something that can work now, you cannot really use the blockchain. So, I mean, of course they're talking about this public distributed ledger. But the blockchain is not a solution.
So, wait a minute. So we already have a public distributed ledger because it's an open standard. It has many free implementations. It's widely available everywhere. It's been working very reliably for 30 years. It's secure, at least if you deploy the security extensions. It can scale. We know how to scale it and serve millions of people. It's actually regulated to prevent capture.
So, I mean, some people don't like this point. They say, I mean, we want to be self sovereign, meaning we have no governments and we have no trusted authorities. Well, yeah, we really had already a period in which we had no trusted authorities, no institutions, no states, and it was called the Middle Ages. So I think we went beyond that. So I think that some trusted authorities are actually a good thing.
But still, if you're worried about someone capturing the DNS, there's been 20 years developing regulation and checks and balances and ways to prevent someone from capturing the root and making it disappear and whatever. It is actually decentralized and federated. So it's a DNS. And so this is the real point we wanted to make.
So the point is that we have to be aware that DNS is actually a very good public distributed ledger. And we could be using, we should be using for more than just naming the hosts and a few other things. And so this is really the, I think it's also good for everyone in the DNS community because the more applications we build onto the DNS, the more it stays relevant.
So actually, the DNS is very good to provide a namespace, which is a big problem for identities. Because with identities, I mean, people use natural names. Natural names are really bad as identifiers because they are not unique. They are not uniform. They don't have uniform formats around the planet. They are not even easily passable. So I mean, in the end, it's impossible to use real world names as identifiers for online
identities. And so you need some kind of namespace. And this namespace must be distributed, must be federated so that you can still ensure that every identifier is unique, but you don't have any centralized place where one has to go and register each and every identifiers and make a big database of all the existing
identifiers. And again, this is a problem that was already solved 35 years ago with the DNS. It's the same problem. So of course, it's nice for people to try to develop new technologies to do the same stuff. But still, we already discussed this. We already found a way. And so if you use the DNS, you can actually assign your identifiers to identity in a way
in a namespace, which is already naturally federated. And it's already familiar to users. So everyone is already familiar with DNS-like strings. You can use email addresses if you wish. Or also you can, I think in general, this should be a good trend for everyone.
We should really encourage people to get a domain name. It's cheap. It makes you independent in a number of dimensions. So of course, it's also good for those of us that make money by selling domain names, domain name related services. But in general, I think it's really good for people to own the little piece of the DNS namespace. So and also the DNS gives you a discovery scheme, which is also, as I said, working
very well. So what we need is just a pointer so that you enter your identifier or you provide your identifier to a website and they can discover who is running your identity, which server is responsible for it. And again, this is a problem that was already solved for email. It's the same problem. So now we're doing it.
I will show you briefly a little about our project, but we're doing it with a TXT record. We didn't get a new or try to get a new resource record type. And that way I already did this presentation at the ICanDNS symposium last year and people were like, no, you need to get a new resource record. Why are you polluting the space with TXT, which is fine. But then if you're an application developer and you need something to do, I mean, you
start doing it with a TXT record. And then, yeah, in the future we will change and then you never do it because then you start deploying it. So I am aware of the problem and I'm happy to hear comments. But still, I mean, there's already a couple of independent internet drafts. There's not IETF work going on on this yet, but at least there are public documents and specifications that you can see.
So it's very simple. We just created for, I mean, a very simple TXT format in which you have the user underscore name and you describe, well, a version number and who is the issuer of your identity and who is the claims provider, which is in the OpenID Connect talk. It's the entity that is actually providing the values for your name, for your identity.
So this could be the same or a different entity. So in the end, this is actually blockchain. So I didn't want to bash the blockchain people too much. So I mean, if you wanted, you could just then replace this with some blockchain mechanism. But at the same time, you have to do something which is available now.
So the project is called ID for me. I will not go really too much into detail on this. I will go very quickly through the last presentation. There are some logos mostly for transparency, but it's basically now a public consortium. So there's a non-profit association consortium running it. And the point I wanted to make is that if, let's skip this.
If anyone is interested, there's a website, of course. There are public specifications. There's a Java API development. We have this international non-profit consortium. So we're trying to make this as open as possible. We have a prototype up and running. There's going to be possibly a beta product launch in Germany since many of the original
promoters are German, including Diniq, the top-level manager. And so there will be possibly a beta public launch at the end of March. And we'll start using it and see whether people like it and whether it works. So again, of course, if anyone is interested, this was the advertisement part of the presentation. But I think apart from this, well, of course, this is the website if you want more information.
But apart from this, the message I really wanted to give here is that I think it's good for the DNS community to find new ways and new content to put into the DNS and new things to point, because it's really a wonderful service. And I think it's good if we keep it relevant and bring it forward with the new technologies. So thank you.
This is a bit tongue-in-cheek, I have to say.
So have you thought about maybe doing that with Ethereum DNS? There's actually some. I think there's already some. Yeah, I mean, yeah. I mean, maybe they will succeed. Yeah, I mean, it's nice to see people try and do stuff. I think in the end, and then people will see whether it's useful or not.
So it's not like everything is bad about the blockchain. But I think that the centralized identity problem is also a big issue in terms of privacy and security and a number of things. So I think that finding a solution that can work immediately would be good. Even if I must say it will be, we are aware that it will be very hard to succeed since most users just already use Google and Facebook and that's it.
But at least we want to try and make something different and try to keep it open. Could you explain the differences between your approach
with the DNS records and WebFinger? Yeah, the question was about the difference between the approach we have here and WebFinger. Basically, the operation you're trying to do is the same one, because you need to, you basically start from an identifier, you need to do something to get information on who is the issuer. The difference is that here is just, I mean,
the relying party that has to start the authentication flow just does a DNS query, gets the information through the DNS query, and then all the rest is standard OpenID Connect. So then it's the normal OpenID Connect authentication flow. If you do it with WebFinger, then the relying party has to do this HTTPS connection. But by the way, it has to do a DNS query anyway,
because it has to retrieve the IP address for the WebFinger server it has to connect to. So at that point in time, you just do the DNS query and you already get the information. There is one issue, and by the way, in this thing, the DOH might actually be useful to this project, because in the end, one of the problems is that JavaScript applications have problems today in doing txt queries.
So DOH, by the way, one of the good uses of DOH would be enabling JavaScript applications to do more than a other square is to reverse, which could be solved also by just by changing the way the APIs are done in the operating system. But still, in this case, that might be helpful. But in the end, I think it's technically, I think it's simpler as long as you can make this txt query,
because you just do the DNS query, rather than doing the DNS query and then the HTTPS connection.