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

Open and federated identities with ID4me

00:00

Formal Metadata

Title
Open and federated identities with ID4me
Subtitle
An alternative to "sign in with Facebook"
Title of Series
Number of Parts
490
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
Online identities are the cornerstone on which data-based capitalism is built - so, Google, Facebook and other OTTs are trying to dominate them and close them into silos. The ID4me platform extends OpenID Connect to create an open and federated architecture that allows any number of providers to interoperate, and gives back control to users, and a role to community service providers. This talk was promoted from a lightning talk because unfortunately the talk "P2P how and Kademlia" by Kishan Sagathiya has to be cancelled due to administrative issues. It is moved from 09:10 to 11:00 and becomes a 30 min lecture. In the last years, the Internet has been increasingly centralized into the hands of GAFAM and other over-the-top companies that built walled gardens in fields like messaging and social networks. More and more of these companies have user data monetization and targeted advertising as a core revenue stream; thus, tracking people across their Internet activities is necessary to their existence. This is why they have also built closed identity systems that supply single-sign-on and very easy sign up for new websites and services, at the expense of privacy and user control. As managing hundreds of separate accounts is inconvenient and insecure, and as alternatives such as password managers are not easy enough for the average Internet user, clicking on “sign in with Google” or “sign in with Facebook” has become a very common choice. We think that this is bad for the Internet in general, and thus we are creating a platform that allows anyone to provide identities, creating an open, public and federated single-sign-on and data management system. We are extending OpenID Connect just a bit, the bit that is necessary to break the silos and allow interoperability; and we are basing the system on the DNS, the widely available and already federated naming directory of the Internet. The talk will explain how the system works and encourage participation and contributions.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
FacebookSign (mathematics)Open setIdentity managementBit error rateOpen setIdentical particlesProjective planePresentation of a groupComputer animation
Identity managementExecution unitIdentical particlesComputing platformInternetworkingDifferent (Kate Ryan album)Single-precision floating-point formatPasswordPhysical systemLoginSource codeService (economics)TrailPrice indexInternet service providerSource code
AuthenticationInternet service providerSingle sign-onService (economics)
Sign (mathematics)FacebookWebsiteLink (knot theory)InternetworkingEmailExterior algebraForm (programming)Machine visionInformation privacyCommunications protocolTerm (mathematics)ImplementationResultantService (economics)
Single sign-on1 (number)ConcentricTrailInformation privacyFacebookTerm (mathematics)Service (economics)Web 2.0Axiom of choiceComputing platformWeb pagePhysical systemCommunications protocolGoogolImplementationSource code
Information securityGroup actionPhysical system
Axiom of choiceSign (mathematics)Identical particlesOpen setInternet service providerMassAuthenticationWebsiteComputing platformFacebookService (economics)Single sign-onPhysical systemAddress spaceEmailInformationSet (mathematics)InternetworkingSystem softwareMultiplication signMechanism designOcean currentDivisorDesign by contract
Service (economics)Server (computing)Mechanism designSingle-precision floating-point formatProper map
Internet service providerLoginSingle sign-onConnected spaceSingle-precision floating-point formatIdentical particlesDirectory serviceServer (computing)Centralizer and normalizerCommunications protocolWebsiteGroup actionStandard deviationLie groupWeb 2.0Direction (geometry)System callService (economics)
Standard deviationBlock (periodic table)ChainProjective planePublic key certificateIdentifiabilityWeb 2.0MassEncryptionDirect numerical simulationIdentical particlesDomain nameStandard deviationServer (computing)System callService (economics)Connected spaceCASE <Informatik>Observational studyBlock (periodic table)
Direct numerical simulationNumbering schemeServer (computing)InternetworkingLimit (category theory)Direct numerical simulationScaling (geometry)Different (Kate Ryan album)Ocean currentEmailAddress spaceDomain nameMotion captureRow (database)Internet service providerStandard deviationIdentifiabilityImplementationRegulator geneAlgorithmString (computer science)Moment (mathematics)FreewareDot productCommunications protocolInformationQuicksortExecution unitSpacetimeService (economics)Data managementUniform boundedness principleCore dumpGame theoryCentralizer and normalizerNamespaceArithmetic meanForcing (mathematics)Group action
Domain nameIdentical particlesProjective planeInternet service providerValidity (statistics)Open setIntegrated development environmentServer (computing)Standard deviation
Group actionNeuroinformatikProjective planePoint (geometry)Identical particlesProcess (computing)Standard deviationEmailSet (mathematics)Internet service provider
LoginWebsiteMoving averageProcess (computing)Medical imagingAuthorizationLine (geometry)InformationFlow separationDirect numerical simulationService (economics)Exception handlingLie groupTexture mappingLevel (video gaming)Standard deviationPhysical systemInternet service providerMultiplication signDynamical systemHypermediaOpen setIdentical particlesPlanningDataflowLogic gateNeighbourhood (graph theory)Price indexRow (database)NumberQuicksortUtility softwareWindows RegistryNormal (geometry)Connected spaceQuery languageSession Initiation ProtocolLoginField (computer science)Game controllerTheoryAuthenticationDomain nameMoment (mathematics)Set (mathematics)Computer architectureIntegrated development environment
InformationDomain namePlug-in (computing)Server (computing)Formal verificationIdentical particlesFlow separationImplementationValidity (statistics)Degree (graph theory)CASE <Informatik>Standard deviationAuthenticationFreewareService (economics)Operator (mathematics)Process (computing)EmailExtension (kinesiology)TestbedMereologyProjective planeData managementLevel (video gaming)Formal languageGoogolSoftware maintenanceBoss CorporationSource codeCollisionUtility softwareLiquidPoint cloudOpen setPrice indexState of matterWebsiteTime zoneWorkstation <Musikinstrument>Coefficient of determinationINTEGRAL
Projective planeSpacetimeWebsiteMereologyLink (knot theory)Web crawlerExtension (kinesiology)Line (geometry)Identical particlesVapor barrierProcess (computing)Lattice (order)View (database)Standard deviationCASE <Informatik>ImplementationService (economics)Formal verificationOpen setLevel (video gaming)Public key certificateGoogolInternet forumKey (cryptography)Term (mathematics)AdditionWeb 2.0Client (computing)Communications protocolMessage passingArithmetic meanAuthenticationOperator (mathematics)Workstation <Musikinstrument>Software developerOnline helpGroup actionDirect numerical simulationImage registrationInternet service providerSimilarity (geometry)Connected spaceScaling (geometry)TheoryLoginServer (computing)Lecture/Conference
Web browserServer (computing)Web 2.0Degree (graph theory)System callFocus (optics)Standard deviationConnectivity (graph theory)Interactive televisionBitLattice (order)Connected spaceImplementationMultiplication signRoundness (object)Direct numerical simulationQuicksortCASE <Informatik>Data storage deviceInternet service providerElectronic mailing listProcess (computing)YouTubeSign (mathematics)Point (geometry)DampingService (economics)FamilyAlgebraProjective planeComputer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
Hello, everyone. Is this on? So, thank you for coming. I'm Vittorio Bertola. I'm here to present the ID4Me project for open and federated identities. So, as soon as we get back to the presentation.
Okay. So, I mean, I think everyone already knows about the online identities and how bad they are today but to recap, basically, we actually have, each of us has an online identity which is internet-wide. It's the one that is created by the big advertising and tracking platforms
because they know everything about us and they cross all different sources of data about us. So, we do have a single online identity but we don't own it. We actually don't even know a lot about it. On the other hand, when we have to identify, so we want to use multiple services online, we are still stuck with having a thousand different accounts
with different passwords and different systems for login and this is really inconvenient. It's insecure because people use passwords or then they cannot use them so they write it down and so it's really a system that doesn't work. So, of course, the solution is well-known. The solution is single sign-on which means that you have some kind
of authentication provider which is the one that verifies your credentials and so tells everybody else all the services you want to log into that you are you and they should let you in. And, of course, this requires some kind of trusted authentication provider. And, of course, the big internet platforms, the over-the-top's already thought about this.
So, in the last two or three years, there's been this proliferation of forms like this one. They are now everywhere, almost on every website. As you see, I mean, most websites usually give you these alternatives so you can either log in with Facebook or with Google. Some only have Facebook or Google. Some have a few more. And then there's a tiny link which is going
to disappear more and more. If you really want, you can log in with your own personal account with your email but, again, that's going to disappear. And what's the problem with this? The problem is that this is proprietary, not in terms of protocols but in terms of the implementation and of the actual service. So, this is very convenient. It's now ubiquitous. I mean, you just click and you're in.
You don't have to enter your data. Everybody likes it, especially the average user that doesn't realize the privacy implication of this. But it's really terrible if you think it is. First of all, there is no interoperability. It's fragmented. So, I mean, if they support Facebook, you have to use Facebook. If they support Google, you have to support Google. So, this leads to concentration because, of course,
no one will want to support 1,000 systems on their webpage login. And so, only the big ones will survive. If you want to support more systems, I mean, your website, web admin, you have to implement each and every of them separately, again and again. And the users, in the end, don't have a choice because you can only choose the ones that are supported by most websites.
And in the end, this makes tracking straightforward. So, the platforms that already know everything about us, then they have an even easier way to track us across the multiple services we use. And on the other hand, you get to situations like this one, which was actually funny. This was the recommended hotel for the IETF OAuth working group, the security workshop they had. And the recommended hotel had,
you choose between eight different systems to log into your wifi. So, this was really crazy. So, it showed everyone at the IETF also that there's a problem that needs to be solved. So, we need some kind of better way of doing this. So, we need openness because we cannot allow these companies to own our identities. And we need federations so that everybody can run their identity.
Or at least we can have thousands of providers and we can have a choice. So, of course, single sign-on has lots of advantages. So, these are advantages that you already get with the current system. So, of course, you only need one set of credentials because you log into a single place. This place can be made more and more secure because you just need to implement, for example, two-factor authentication in the single place
where you log in. And you have a way to control your information as long as the provider lets you control the information, which Google and Facebook unfortunately basically don't. And you don't need to register. I mean, in the end, this idea of registering for a website is going to go away. You just have to show your identity the same way when you want to rent a car,
you show your identity documents. That's what's going to happen in front of websites. But if we succeeded in making this public and federated, that would be more and more advantages. So, why cannot single sign-on work like email? Email is being an all-time service before all this mass commercialization and big internet platforms came.
Email is still federated, which means that you can get your email address from whoever you want, including running it yourself. And then everyone can speak with everyone else. And that's how it works. And there's no reason why identities should not work like that. So you could get your identity from whoever you want or even run it yourself and then use it everywhere. And do you just need one account for everything?
And you could choose your provider or you could even run it yourself. And you could possibly choose one that is not selling you out. And you could also keep your identifier, which is a known problem. So I mean, you have to own your own username in a way. Otherwise, it will always depend on the company that supplied you your username.
So the technical problem is that to have a federation, you need what is called the discovery mechanism. So what's necessary is that someone shows you an identifier, their own, let's say, username. And the website, the service that needs to verify that you are you, needs to know where to go, which server to contact to do that.
And actually, the main protocol that is used today, including by the proprietary single sign-ons, for online single sign-on is OpenID Connect. I guess people here are most, I would say, could be familiar with that. So I mean, it has some federation capabilities, but it's never deployed in a really federated manner. So the federation in the common deployments of OpenID Connect is that the same company
has 10 different services, and they all use a centralized login server for login, identity provider. But it's always everything run by the single company or at most by a group of companies. And so we need a real federation. And so we need to keep this directory of identities somewhere so that websites can look them up. So where do we do that?
And this is what we try to do. I mean, the standard OpenID Connect method relies on web fingers. So it's an HTTPS call to a web server running on your identity provider, which is a problem that you need to have a website running for that on each and every domain name or identifier that you want to use. So it's not very handy, and it's actually, I mean, basically very hard to implement,
for example, for domain name industry and for the hosting industry for the ISPs, because you need to implement. And so, and also it requires you to have a web big AI certificate with Let's Encrypt. You can get one for free, but still it's. And of course, why not the blockchain? There are, I mean, I'd say thousands of identity projects
based on blockchains, and it's fine. We have nothing against the blockchain, but we want something that can actually compete today with the big OTTs. So it must be something that is already available today everywhere. It's tested, it can scale to mass service and so on. And everyone can just pick it up and run it. And so in the end, we're going for the DNS.
And I mean, the DNS usually, I mean, there are people that love it, there are people that hate it, but it has several advantages. Because in the end, it is an open public standard. There's free implementations everywhere. You can just download one around your DNS server. It's widely available, it's tested, it runs for 30 years on a global scale. It keeps the internet up. And so it has some kind of regulation.
So even if there is some centralization, there's also some regulation to prevent capture. And so maybe that's not perfect, but it's already there and it works. And so we chose to use the DNS for the namespace, because also, I mean, to have a global internet scale online identities, you need a global unique identifier.
And of course, our own names are not unique identifiers. There's many people with the same name over the world. And so you need a global namespace, which is also distributed and federated, and then this is the problem that was already solved with the DNS 35 years ago. So you can just use DNS names and people are actually familiar with them.
And they are human readable in the end. They are usually strings with dots in the middle. You could even use email addresses and just convert them into a domain name with a fixed hashing algorithm. And in the end, this would also allow people to just buy a domain name for a few euros and become owners of their own identifier, which is another advantage. So then you could just move your identifier
across different providers if you don't like your current provider anymore. And so it's also very easy to realize that the discoveries came, to make a discoveries came over the DNS. Since again, email basically does that. Email has the same problem. You have an email address, you need to know which server is managing it. And so there's the MX record in the DNS
that tells you which server is managing it. And we did the same. We're not going for a new resource record type, because that's hard to get implemented. We're just using a TXT record, like many other new protocols. And there are actually the internet drafts already there. We are not at the moment going forward with standardization,
because first we want to get implementations and prove that it works and so on. But the drafts are already there, they are public. So basically, this is what we did. We just chose that, I mean, you can use whatever valid host name, even if it doesn't correspond to an existing server in a domain that you control so that you can create records in it. And you can just create a standard special use TXT record,
and which points to a stringer, which basically tells you where this is being run. Who is the issuer and the claims provider for your identity in Open IDE ConnectSpeak. Well, the project in itself is basically this. It's just an attempt not to become
yet another identity provider or group of companies or entities that compete to provide identities against everyone else. But it's meant to provide the basic building technology to allow everyone to run providers and interoperate with each other. So the point is that we want to create basically a set of open, patent-free standards that are there for everyone to implement.
The traditional way, like email is, I mean, we are an email company, so this is why we believe in this model. And so in the end, we do have also a foundation. We're here in Brussels, it's a non-profit. We decided to have one because you need a place basically to ask companies and supporters to put money and then spend it for the project to pay, for example, promotion and people
to develop something maybe and other expenses. So it's not a controlling entity anyway. The standard is open and everyone can implement it. It's more like a place where we can run additional activities over that, including some, I mean, well, I will come to that. Basically, the architecture of the roles in IDE for me
is more or less the same as the traditional OpenID Connect system, except that we decided to break the traditional identity provider role in two, partly because, I mean, among the original supporters, there are several companies and people from the domain name industry, which, I mean, that's not a surprise since we are using the DNS. And so we have a sort of separation that mimics
the domain name registrar and registry separation. So we have an identity authority, which is basically the registry for identities. And the only thing that it does, it verifies your credentials, so it harms your authentication. And it doesn't get to actually know your data. So, I mean, the data and the relationship with you are kept by your agent, which is the other entity
which basically gives you the service. So that you could even change agent without changing the authority, or you can change both, or you can run both on the same service. You could even have a service running both roles at the same time. It's entirely free. But at least, I mean, for the attempt to, I mean, to get to the real average users, which needs to be built upon an existing industry
to have channels to actually reach out to people, then this is, we thought this is the best way of organizing it. And so in the end, you provide your information and manage it with the agent. And then the authority is the trust anchor, as I say, in the authentication system that guarantees that, I mean, the authentication is being done correctly.
And so the login flow is actually pretty standard. If anyone is familiar with OpenID Connect. So, I mean, it's basically, it is a standard OpenID Connect login process, except that before starting the entire process, you have to do this DNS query. So the relying party will have to discover who is running your identity, who is managing it.
And so they will make this DNS query and get it returned to the record and discover which server they have to contact to start up the normal OpenID Connect login process, which then uses a feature of OpenID Connect, which is called distributed claims, so that the initial identity provider, which is the authority, then redirects the relying party to the agent
with a signed token, so that they can actually get your personal information. But the nice thing in this process is that the authority, for example, can ask you actually which data you want to share. So, I mean, you have a set of information, for the moment it's a basic one, but in theory you could standardize names and claims
for any kind of information that you would like to share with websites from your frequent flyer number to whatever. And then when you log in, with the first time you log into a website, the authority asks you, I mean, this is the information they would like to have about you, and do you agree? So do you give consent? And you can choose for each information field whether you agree with sharing it or not.
And then this is signed and gets sent to the agent, so that the agent knows which data they actually can share with the relying party. And so in this way, we are trying to put back control over data sharing in the hands of the user, so that in the end it's the user that chooses
which information gets passed on to the website and so on. So, as I said, the process is about a couple of years old. It was initially promoted by a few German companies. Now it's becoming international. There are more entities signing in,
profit for profit and non-profit. So there's a website, there's specification, and there's an API. There are several prototypes, test beds. There's actually an ID for me based service, which is DINIC ID. DINIC is the manager for the top level domain in Germany. So they are the first company that really tries to release a public service based on this,
and this technology, and they're basically about to launch it. And we are working on the possibility of adding a verification layer on top of this, so you can still, I mean, the data in that is what you put in it, so it's not verified. You can use it also anonymously. Sedonymously, you decide you can have many identities, whatever you want, but for certain use cases, you might want to have a third party validate
that you are you, and in that case, we are building the extensions to the standard that would allow, basically, the third party to sign an attestation and so on, and so provide verified identities. And we have now about 30 members in the international non-profit here in Brussels. So what's coming next? If anyone here will attend the Cloudfest in Germany,
there's going to be an hackathon project to develop a completely free server implementation. We already have a part of it, so we want to finish it and release it so that it's available to everyone. We already have several authentication plugins for several languages. They are also free and so on. And so, as I said,
we are working on the verified identities part so that you can have a stronger identity, and we are discussing the reputation issue, and I want to stress this because this is a problem that cannot happen in any federated approach. And it should not be underestimated because it is a difficult project because in the end, if you are Google, you can say, okay, I'm Google, I decide which degree of validity I want to give
to the information I pass to websites, and people have to trust me. In a federated system, like exactly it happens for email and spam and so on, there could be people that run services in a bad way. And so you need to have some way to exchange your reputation information and be sure that if someone is telling that this person is authenticated and these are the data,
they are not just making everything up, at least for certain use cases. So this is the discussion we are having around how to manage the reputation of the operators. So this is the website. You can go there, and there's everything about the project. There's also the technical part with documentation, links to our GitHub space and whatever. And that's it.
So basically, thank you, and I'm happy to take questions. Yeah, hi. I have a question. So when I'm a website, and I integrate the login with Google button for the SSO for my users, basically, the reason I do that is because I trust Google
that it's doing the authentication correctly for the user. But if I, for example, use ID for me, I don't know who I'm asking. And in OpenID Connect, I usually need a client with the identity provider, right? So how does that work? Because they need to establish some kind of trust with the identity provider.
Yeah, as I was saying, this is the key problem we are discussing exactly because we decided to make, for example, the client registration open and dynamic, so you don't need to ask the identity provider for a key to start being a relying party because that would make the federation unworkable. But yeah, in the end, it depends on the relying party
because if you're just a basic website, a forum for obvious or whatever, you don't need any real certainty about the data. I mean, people, actually, that's a case in which people should be encouraged to log in anonymously if they want. On the other hand, for some services, you might really want to be sure about the entire process. And in that case, possibly you as a relying party
want to put some barrier on the identity provider that is being used. So I mean, since you cannot know, I mean, you could in theory say, I will only accept identities from these one, two, three identity providers, but again, this is done on scale. So what we are thinking is that we could have some kind of certification so that you can get some cryptographic
like a station that tells, I mean, this provider has been verified up to this level of verification, so you can more or less trust that they are who they are and this other is completely unknown, so accept it as your own risk. But on the other hand, we don't want to make this too hard because otherwise you will rule out the self-hosting of identities, which I think is a pretty important case.
I have a question. The OpenID Connect process, they have a certification process. Did you take your services through that process or did you talk to the people about certifying your services? Yeah, I mean, you mean the certification of the implementation? Yeah, I mean, as I said, Diniq who is the first company that is launching services
is an OpenID Foundation member and they have applied, so their server implementation is being certified by the OpenID Foundation. And also, we have been submitting some of this development for standardization basically in some of the extension. I mean, there are a couple of extensions that just came out to OpenID Connect in terms of federation and they were actually influenced by some of us participating in the working groups
and bringing ideas. And of course, we want to be aligned. So in the end, of course, this is still catching up. So there are no websites almost today except maybe for Diniq and a few of you that accepted these identities. So this is the challenge. If this gains adoption, I mean, we were gonna apply for standardization of all the parts of the protocol, both at the OpenID Foundation and at the IETF.
My question is, have you thought about integrating with the decentralized identity standards that is going to be developed? Okay, I mean, we have thought about getting a DID schema, for example, for ID4ME. So I mean, that's what you're referring to.
Yeah, so there's already a DID method for web. So you can write some kind of in DNS. It looks kind of similar. It's just how to resolve. So. Yeah, as I said, I mean, we haven't done it yet, but we have now. I mean, we could do it. We actually have thought on it. So I mean, that's what we have done.
Is there any place here at Fostum where I can find people from OpenExchange to chat with them or you? Yeah, well, me, there's several here that are watching that. So yeah, just grab us later. Either on this or any other thing that OpenExchange is doing, so.
Have you thought about a use case where you're not trying to identify a web application, but any other thing that doesn't have a browser available?
Sorry, I speak loudly because there's an auto. Have you tried about identifying, providing the ability to identify outside of the browser? I mean, yeah, we were trying to, for example, see whether this could be used for IMAP logging, for example, all these kind of things. There's not been the focus yet
because of course there's a problem with interactivity because OpenID Connect is an interactive process. But I think you could get a token and store it or you could find ways. But we have not worked on this yet. It's on the list of two things. But if you want to help, you're welcome. Have you looked at engaging with web standards bodies
or web browsers to standardize this so you could just have a new HTML component to have a federated login, for example? Yeah, I mean, we do not have browsers at this point in time. Also, this is a very European project, originally German, now European, and there are no basically European browser makers.
So we, yeah. Okay, so if you're interested, please join. And yeah, I think that some degree of support in the browsers would help a lot. I had a quick chat with Mozilla over a year ago. The problem is that they tried Persona, if you remember it, and then it didn't really work. So they are sort of, I mean, wary of these kind of things.
But this is how I understood it. I was wondering if you can talk a bit more about the status of the project, because if I understand correctly, most of the components basically are just thin layers in front of ID connector providers and other data storage.
So it's just a matter of writing these small layers. Yeah, exactly, this was a design feature. So when we decided not to design everything from scratch, but to try to design something which had an implementation path which is as short as possible. So yeah, for the relying part, it's actually just this DNS call in front of a standard OpenID Connect implementation.
Then if you want to support some of these more advanced features, maybe you want to customize at the time. But basically, yeah, and also, the unique is running the implementation from the server side by using an OpenID Connect server and just developing a few things on top of it. So yeah. Okay? Thank you very much. Thank you, and I'm here around, if you still have questions, of course.
Just give him a warm round of applause. Thank you.