 This is a buff, which means that I have no responsibility whatsoever what is happening the next 45 minutes. It is a collective effort meaning that it's everybody else. I hope others take more responsibility than me and one thing you can do is you can join the gobby and write what we are finding out here. So how many of you know what WebID is or maybe the opposite? How many of you have no clue what a WebID is? Fair enough. No, it's perfectly fine. So maybe I should just try and give a short summary. I was exercising that just 15 minutes ago also. So WebID is one piece of a larger puzzle that is called the semantic web. WebID is the ability to authenticate on what has exercised, there's two levels of this, what has been practiced the most at the moment and then there's the possibilities, technicalities, details later. So I will tell the simple story of what has been practiced the most. You have a client-side certificate on your web browser and you access a web server and the web server is verifying you not by the certifier of your certificate but instead by a hint that you also include on the client-side certificate that points to another web page that you own which has more information about you. So that's the very short version of WebID. Is there anybody who still has no clue what I have just said? Do any of you know about the underlying thing called fof, friend of a friend network? Someone is nodding. One was nodding. Anybody heard about the thing called Facebook? Okay, someone is laughing. Someone is trying to combine the knowledge of who are your friends by who are your friends friends. So when you log into Facebook the first time, if you only tell one of your friends, then instantly it can pop up and say, oh, if you know that person, maybe you know this person also. That is part of this logic of graphing your relationships and relationships can not only be about friends, it can also be about knowledge in other ways. So the thing that I have a passport and this passport is issued by this government and someone trusts this government to issue passports. This is also a graph of relationship about facts. So one of the things that have been tested the most in relation to WebID and fof is this playing with friendships and how you can build trust based on friendships. Now, most of us in this room probably know that that is pure evil because that is what Facebook is doing. But it might not be the only way that you are reasoning and verifying on facts. It could be other chains of fact chasing that you are doing than the fact chasing of who are your friends, if I know your friends, I know who you are in bed with. It could also be things like what we are actually doing, practicing with PGP by showing a passport and then reasoning that well, if this passport looks pretty nice, then it probably is issued from the government that is printed on the paper. This buff is spawned by the interest to have Debian use WebID as a way to identify the users, the developers and the maintainers in Debian against the Debian services which could then also be used for outside services. It is a little tricky if we are starting completely from scratch with what is WebID because then maybe we cannot reach the point of discussing how we actually are going to use it. Is anybody in the room, you knew about WebID. Is anybody else, is someone knowledgeable about semantic web in here or am I the only one? You know something about semantic web, you also? Could you maybe help me in explaining this? I tried one angle of this and I have a feeling that I was a little confusing in the way I was explaining it. Could I, with a microphone, just turn your head around, there's a microphone behind you. Does anyone hear me? Yeah. Okay. Basically you separated the semantic information that you want to publish, make it machine readable so that other instances like semantic web browsers can read this information and graph them to the user as he wants it displayed. So basically as I understood it, you make machine readable information as replacement for what we do these days with HTML documents and do the presentation at the user, at the client side. Yeah. That's what I wanted to say. Sure. I'm not quite sure how to move on from here. If we can try to talk about WebID without people really certain about what we're talking about here. How many of you know OpenID as a mechanism to separate the authentication from the services? Okay. That was a little better. So one of the ideas of OpenID is that you separate, the service itself shouldn't contain your, you shouldn't remember your passwords. You should be able to separate that and have the passwords in a trusted place. So you have a third party saying go or no go for is this person saying who he is, who he claims he's saying. WebID is similar in that fashion, but with the differences that the way that you are expressing this verification process is done using this technology of semantic web. So what is the power of that, as far as I understand it, is that you are in control of this third party. You can set up your own service that provides this verification process where OpenID is you, the two services, the services, the web mail service and the OpenID service, the authentication service and the actual service you want to reach, they need to exchange some information with each other in order to have this verification process work. And as far as I understand it, the WebID design avoids revealing some of the information to the, for instance, the email service, the web mail service. You can separate this more strong. Another stronger separation is also in the approach from Mozilla called BrowserID. Now it's been renamed to Persona. One of the weaknesses of Persona and BrowserID is that it's tied to the browser. That means that it's when you are interactively on your web browser, you can let your browser, you can pass on the verification process to your browser and it has, it contains the identifier. Something similar to the certificates but a new design that stays within the browser. The flaw of that or the weakness of that is that you can only do it as a user sitting next to your browser. You cannot pass on the task to an agent working on your behalf. If you, for instance, have a, if you want to tell one of your robots to figure out what is the cheapest price for flying to, to Hong Kong, then you cannot have this robot acting on your behalf, on your behalf. For instance, if you had extra cheap tickets, if you identify who you are, you cannot pass it on to a different machine, a different identity. And WebID has this, it's machine readable, it's machine operable. It's not tied to, it must be a human operated service. Yes? With the microphone, please. So if I would like to test one of these technologies today, are there any bigger sites using them? There is only test sites, there is only demo sites using, using WebID today. But some of the demo sites is also functioning as open ID sites. You can, you can set up a WebID authentication which is then providing a service that is open ID. Open ID with its weakness of revealing too much information is a weaker form of authentication and then WebID. But you can weaken your WebID service and have it also act as an open ID service, if you like. So if you want to interact with the larger world today and play with whatever, what can you do with, if I have a WebID, then you can set up or you can use, if you trust an open ID service that authenticates using WebID. I mean, some, some, some WebID, some, some open IDs, the most open IDs I know of, when you log into those, you have to type in a password, so you have to memorize a password. If you imagine that the user side of that, instead of replacing the having to show a password with having to present a client side certificate, which it then verifies using your full ID on running on your server. So you can, you can chain load an open ID with WebID. Okay, okay. I was just asking because it would be nice to see the usability with normal users. So if I would send a few lines of instructions to a few people with different platforms to see if they managed to log in. So that's why I was asking for actual real life usage of WebID or browser ID, because I, I don't know if there are those. I have used open ID myself. Yeah. The browser ID, I haven't, I haven't played with it myself. I believe that it works in recent versions of Mozilla, obviously that's the ones that driving this. I'm not even sure if it, if it exists in, in, in Chromium and others yet. So, so with this in mind, I just wonder if it's too early for Debian to start using this technology, if it's not widely used or do you think that by having Debian use it, it could become more accepted? What I think is that the way I see it is WebID is working now and has been working for quite some time because the, the structure of WebID is that it's standardizing different use cases of existing certificate with TLS. So there's no new invention in the technical parts of this. It's already used in the browsers. There are some weaknesses in the user experience of handling certificates. And there are some works on some of, some of the things that makes it more user-friendly if you, if you do some extra work today is that you sidestep a little bit and run a JavaScript-based certificate generation. That is security-wise bad because you don't, you didn't have a chunk of code that you don't really verify because you loaded it from a web server. Yeah. I think these are exactly the issues because I've never seen mobile users use client-side certificates with the browsers. They won't even recognize the term. I only seen people in companies using these on company laptops and they haven't installed them but the staff of the company has installed them. So I wonder what sort of usability issues we're going to run into? Well, the reason that happens is companies typically have some kind of CA. And so the, the, the PKI is taken care of, whereas if it's not a hierarchical organization, that's, that tends to be a problem. Okay. And a question on, on IRC, whether WebID is related to OAuth? Ah, no, it is not. OAuth is, as I understand it, is OAuth is tied to the open ID way of doing things. WebID is independent from this. Okay. So some of the, well, this, this question of whether it's, it's, it's usable right now. It's, it's, there's this, there's this chicken and egg problem of web browsers don't really see the, the relevancy of improving the client-side certificates because, well, it's dead in the water, that's not really used anymore. But the point is that, well, it could be used if it is used in a different way than the hierarchical certification that it, that it was intended for. Well, it was promoted for, for, for a long time. But is it true that mobile browsers don't support client authentic, client certificates? Not that, as far as I know, that would be news for me. Okay. I don't, I don't, I don't think that it, that it's the case that, that they don't support client-side certificates. I think that it's the case that they don't have the kind of, of a user interface for managing, importing, from outside. Maybe they don't have the external storage. If you don't have a file system, then you cannot say, open up and import this pks12 file because you don't have a file system to install it from. So that, that might be the, the situation that it has cut some wings. So you need to operate only within the browser. Okay. So as I understand it, what is, what is usable now and is claimed to actually even be user-friendly now is to do it by loading JavaScripts that then makes a shim over the things that the web browsers do not, the web browsers do not do elegantly yet. And the weakness of that obviously is that if you're doing security that you're loading off the internet, then what you cure is that, is that. So another stronger argument of, of a, a skepticism about, about WebID is that the test cases done now, until now is test cases, both about tied to this ontology called the, the fof, friend of a friend, which is, which is exposing your information about your friendships publicly. You didn't, you don't need, in principle you don't need to publish your information you could just share in secret circles, but that has not been practiced, that has not been tested because that is more complex to do. You need to run some interactive servers instead of static web pages. You need to publish. So it's more complex to set up a test environment for, for doing that. And also when doing the actual verification triangle with WebID, what has been tested the most is using what I've been talking about all the time until now, these, these certificates of TLS transport. But really the WebID design don't need to use certificates. It could use other means of ensuring that the transport is, is established safely. So in the most recent draft of the, oops, of the WebID specifications, yeah, here, no. There's the WebID specification and then there's the recent draft of it. In the recent draft they have split it up in two different specifications, one called WebID and one called WebID TLS to emphasize that well, WebID itself need not use TLS for its establishing the, the secure exchange between these endpoints. It's just the one that has been practiced the most. It's the one that has been tested the most. There are other ways to do it. One of them might be using Tor, TorOnion URLs. The only thing that, that WebID, the, the, the core design requires is that it is using URIs. So you can use different URIs than HTTP or HTTPS URIs. It could also use a PDP URI if you want to. Then you need to define that PDP URI and you need to exercise how to interact with these PDP URIs. But in principle, there's no, nothing in the long, longer term to, to against having a different kind of security structure than the one which is tied to the domain name system that some theme as being completely useless and flawed and tied to this WebID, WebID sidesteps from the hierarchy of certificate issuing. But it does not sidestep from, it's tied to domain names in the WebID plus TLS implementation. But that can also be avoided by other implementations, other sub-implementations and the TLS one. So one of, one of the things that, that I see could be relevant in Debian now is not to have Debian provide services that our mothers and our sisters and, and, and friends can use similar to OpenID. What I imagine that we could do is the, some of the services that we now provide that we need a lot of access to inject a PDP key to issue a temporary or a different single, a simple key phrase for a service. Instead of having a key phrase, we can have it spit out a certificate that we could use. So that we could have our interactions with our services being possible to do with web services. We could pass on to our agents individually without it having to being hard coding a simple number that is then used, stored in clear text on our machines. So we could start using these structures that are standardized and then on the back end we can use semantic web tools to, to juggle with the data that we are, are fetching that way. So, but if most of the crowd here is more interested in hearing what this could be instead of discussing it, then I don't, this was not, this is not what I had prepared for. Okay. I can see that there's a lot of things filled in on the copy. So one of, one of the, one of the benefits that I could see in, in, in moving from this current LDAP based activation of a, of having an account on a service to using WebID is that we could decide that from the beginning we could, we would bootstrap it with all of the Debian maintainers or the Debian developers that already have an account on our systems, but it would be quite easy to then extend a network. For instance, some of the Debian.net machines might want to say, well, we want to, we want to trust and give access to all of the people that have an account on Debian and all of the people in this other circle that is some, in some other way is bootstrapping and setting up their WebID authentication. So you could have other, you can have, you can join multiple networks in that way. And that means that we could easily expand services to include more people. It could be that one of our big derivatives is setting up WebID the similar way. What Ubuntu is doing at the moment, as I understand it, is that they're running things on a centralized server at Ubuntu where they authenticate against their identifier-based services. But that is tight, that is centralized and we cannot really collaborate with those except if we use maybe OAuth, which means that then they are tracking every time we are doing things. There's another question from IRC or rather a suggestion to check HTTP colon slash slash WebID dot Debian dot net slash as a start. Yes, I have been there and that side just redirects to the, to the wiki page. Ah, okay. Which is introducing that Debian, Debian now has Fooved profiles, auto-generated for all Debian developers, all package maintainers, both for people in Debian and for people that don't have an account in Debian. I have this odd situation myself that the way it's generated is from your email address, and I don't use my Debian email address. So I have no fof profile for my account in Debian. I only have a fof profile for us being. I'm treating it as an external person. So an example of what you can do now, this is not WebID fully. There's no authentication service anywhere. This is only the part of having some profile that can then be the third thing that you reference against, as you make the look up against. If you come with your certificate and say, well, I am this person, you can just go here and verify that it's true. Then it's the third point. The funny thing about that is, well, the third point is supposed to be in your control. And this third point is in Debian's control. This is a Debian service generating fof profiles. So you want to build something that works on a global scale, or do you want to build something for Debian and assorted, trusted, other organizations? Because then one thing you could do is Debian has the Debian key ring, which is strongly connected. Debian has some. So you could use the key fingerprint as your WebID URL, and then look that up. And if the GBG key is sufficiently authenticated, it's the right person, something like that. WebID, Debian already has ways to authenticate Debian members, Debian account members. You want to get rid of the central server. And using the key ring would do that, because you could put the key ring on each machine. So you wouldn't require trust relationships between the machines, and you wouldn't even require active network connections between the machines. How would I verify that it's the right person? Anybody could claim that they have my email address, and you could look up that it's the key. So then I would be using signed emails to verification. Oh, what do you mean? OK, let me try to answer your question instead of bouncing it back. As I see it, it makes sense to have Debian provide a service for the same people that it already provides other services for. The benefit of using WebID instead of using the current services, the current mechanisms of authenticating its users is that this new service is a standardized format for service for decentralized authentication, which means that a Debian plus Fedora service, some third party or a Debian service that is meant to be for Debian people and for Fedora people, can then say, oh, great, we have this standardized way of doing things. We don't want a copy of all your passwords to your logins. And we also don't want to have a pipeline to your GPG keys in Fedora land. We just want you to run this standardized service just as we are running a standardized service. And then we can, every time people log in, it will resolve that it will verify at our end or it will refer at your end, because it's verified at each user's own end. The thing is, what Obergeeks has provided until now is a demo of it is possible to generate a profile for each user at the Debian server. And a service has his running. But really, to make this really work, I should not have my certificate point to his service, because his service is no proof that I am me. If I'm pointing to a server that I own, then I prove that I am me. So if I point to a server and the server certificate on my server is also tied to me, then I have identified that. Then I have proven that the identifier that is running around on some web browser is tied to some server, the owner of the server. So sure, if my server is hacked, but then it's the same thing as if I lose my keyring, my key to lock myself in. The core idea of WebID is to separate, to have the authentication process being multiple points, instead of being everything contained within one point. So you're not running around with a key that contains every valuable details for you to lock into a keyhole, because you maybe don't trust the keyhole. And it might be a complex thing to verify if the keyhole is trusted, and if the key is trusted, and if we trust to reach each other and verify each other. So that's the way it's a chain loading of things. The server that does the complex things, you're running itself, but you're running it somewhere else, so you don't need to run around with all the complex stuff. Elsa, a hand up. Oh. On the topic of exploiting the GNU PG web of trust, and I'm sorry if you covered this before. Not at all. Possibly. Peace. One of the criticisms that I read when the WebID idea was discussed is that this reliance on an existing CA infrastructure. And I'm aware that there was some work from the GNU PG maintainers when GNU PG2 started out of generating X509 certificates from the same key pairs that you use for the GPG stuff. So I wanted to know if anybody knows of the status of this, and if this is still a thing that we could use for migrating people, or not migrating, but exploiting the web of trust and creating X509 certificates for WebID. Anybody know about this? Possibly. But OK. Do I puzzle things, or is that somewhat the direction that monkey sphere is going? Doesn't it? It works also based on GNU PG keys. Someone might kill me because I don't really, really understand monkey sphere. But as I understand monkey sphere, it is about bridging between different technologies, different protocols. So when certificates are hierarchical certificate certification is fundamentally broken, we don't trust the kind of trust that they want us to trust. Then monkey sphere is bypassing that by linking up to the PDP Web of Trust. So it's using the PDP Web of Trust to verify certificates. The one in control of the certificate might have gotten it from somewhere. It doesn't matter because this same person signs the certificate with the PDP key. And then all of the users then look up in PDP. Is it a person in the PDP Web of Trust that I trust, myself, that has signed this certificate? So it sidesteps this using PDP. From Gunnar Wolf. Monkey sphere is rather about presenting a human-friendly and human-meaningful face to GBG key signatures and so on. Thank you. Could you send the microphone back? I really like the idea of WebID to know, but whereas your problem is the role of the user, how do you expect this to happen? Sure, we all are techs. We all probably run our own servers at home to set the WebID part for ourselves up. But as it goes to non-tech people, most of them don't have any servers hanging around. Would it be acceptable for the concept of WebID to have little clusters of friends that everyone has a techie in his area of friends so that one does like one stores the WebIDs of a group of people? Would that be acceptable? Well, that is the same as asking me, is it acceptable for teenagers that their parents have a key to their diaries? Well, that depends on each circle. The policies are different. What I just wanted to emphasize was that, yes, these security issues that I have heard being raised is possible to avoid, but that makes things more complicated. If you're not using DNS, then you are not using DNS, and that makes things not very user-friendly for a long time forward, because then you need to have built Tor into your web browser, and that is a different task. But that's not an argument to say that, well, WebID is not user-friendly. No, WebID, if you insist that it must re-implement the whole web as we know it, then it is not user-friendly yet. So similarly, what has been tested and played with until now is WebID using TLS. And TLS has some quirks in its user-friendliness that is currently worked around by running some JavaScript. All of this makes it less and less secure, meaning we should all drop WebID and use Facebook as authentication mechanism, because that is fucking user-friendly. Everybody has a Facebook ID anyway, so we just, all of us, log in there. I mean, I'm not joking here. I'm saying that is what people are doing now and have done for many years, not many, a couple of years at least. I mean, independent services not tied to Facebook are using Facebook as identifier, as authentication mechanism, which is completely insane. So compared to that, it is much better that I personally set up some mechanism that people can offload some JavaScript they don't know shit about so that they can magically have some access, because that's what they care about. That's user-friendliness is not caring about the security, not caring about what's going on. I just want my fucking access to my thing, whatever it is. And looking from that perspective, it's better that I set up a service, or Uber Geeks, who already set up a service for Debian people. That's much, much better than Debian using Facebook. Now, so we're talking about different kinds of situations here. If you're talking about the user-friendliness, you're not talking about Debian developers. If you're talking about security, you're not talking about the need for independent service. So Debian developers trust Debian to some extent already. We are running all of the code via Debian. So we should trust Debian. So we don't have the same kind of trust issue with the service running at Debian. But if you are judging Web ID as a technology, then it's very interesting to look at, is it possible to make it more user-friendly? Is it possible to make it more secure? If both things are possible, then both things combined might also be possible over time if we develop the things to do it. Both things are not medically done over time. And we need to work towards that. But as I said, you can kill Web ID by saying it's not user-friendly. You can kill it by saying it's not secure enough. But both of them is like, then you're not looking at Web ID. You are looking at Web ID as it's implemented in a buggy way using the current world buggyness. So it's the current world that is buggy. It's not Web ID in principle. Does that make sense? There's another question. Oh, the people want to. What would be the follow-up for this both discussion? Obergeeks has already implemented some steps. He's asking, or? Obergeeks is asking. Obergeeks is asking. Oh, shit. Well, I can. Hello. Obergeeks, that's for you to decide. There's some people jotting down what we're talking about here. I hope that could be helpful for Obergeeks and me, at least, and for anyone else who might not be scared by this, but by be excited by this so far, to try work further on putting the pieces together so that we can have some maybe more understandable proof of concept or demo for use by Debian. Obergeeks is asking, who's in charge of sso.debian.org? FTP master. DSA, DSA. My judgment, my guess is that from the current stand of the dialogue, the discussion we've had in Debian Devel, DSA is not currently interested in activating any WebID on Debian systems, because there has been raised some skepticism about the security and also the sanity of even playing with WebID at all, because it has been argued that it is looping around TLS problems. So even if you start out with the problems and then you try to solve it, then you're ending up with the server-side TLS still being needing the hierarchical trust. I was bouncing that criticism to the developers at w3c.org and was encouraging them to respond in Debian because it doesn't need any authentication to any subscription to post to Debian Devel. But unfortunately, none of them did do that. They wrote very long arguments back and forth about why this is not the case, and Debian has misunderstood completely. But the people in developing this WebID is also some of them philosophers, and they are complex to digest, at least for me. So what I was hoping for was that they would condensing their argument why WebID is just perfect, and then they could throw that at Debian and we could have a continued discussion in Debian Devel. So at the moment, the status right now for Debian as a larger scale and DSA is, as I feel, is that, well, it's unsolved if WebID is trustworthy and sane to do. It's also linked from the Wiki page. When you go to WebID, Debian Net, WebID, Debian Net has a link to the Wiki page. The Wiki page has a link to, was supposed to have a link to the email, not to the email that, no, it doesn't. I remember wrongly this session has a link to the threat on Debian Devel. The threat on Debian Devel was someone with, I think maybe it was me mentioning WebID. What about WebID? And UberGeek says, well, we already have a sort of WebID. We have fof. And then someone else says, what is all this? And then nobody could really answer this. That's, Russ Aubrey is coming with a lengthy one with that. Never heard about it before, and now I looked at it, and it seems not good. And then there's a threat about me trying to defend it, not really understanding how to defend myself against Russ Aubrey. And calling for help by DKG. And DKG is saying, yeah, he agrees with Aubrey. Damn. So someone has written here on the gubby, why don't we use distributed authentication like the Web of Trust, meaning the DPD, the PGP, Web of Trust that we already have? Well, that is what we are doing now, so to speak, in that we have the LDAP service that is, well, we're doing it some ways now. And yes, we could do it in other ways. One way it could do would be to link this to Monkeysphere, maybe, if I understand Monkeysphere correctly. But one of the powers of WebID is that it is designed around webby objects, meaning all of the things that can be linked on the open data world, which is the open world wide web, public data, and all the things that can be linked in similar fashion but in closed networks. I'm emphasizing this other part so that it's not only about, if you publish all your data to the open world, to the whole world, then it is exciting. It is also exciting if you lock all your things up, but then you link the things against each other the same way as the worldwide web is doing things. What I see as powerful in that is that there's a lot of tools to handle web resources. There's less tools to handle custom resources in whatever data format that you invent yourself, and then you tie it to GPT directly. So yes, to me, it could be very interesting to have WebID extend WebID with an WebID dash, a PGP authentication mechanism instead of a WebID TLS mechanism, but saying that, oh, we don't even need WebID. We could just use PGP directly. That would be inventing something we hack together, which is not really scalable to other things. So we couldn't reuse such a design across the board to Fedora or any other free software or other projects. There's another question from IRC. How can one experiment and use the metadata published at WebID-Debian.net? Oh, OK. Could you repeat the question? How can one experiment and use the metadata published at WebID-Debian.net? There's a website, WebID.info, that generally introduces to WebID. And through that, and yes, it's confusing, you can also dock.go or Google or whatever you prefer for WebID and some of the information there. But WebID.info, and then follow that to some of the example pages, some of the more recent example pages that is still working. Then the places where it says, oh, and now you should use your fof file. Then you can actually point to this page. What is called WebID-Debian.net really, essentially now, is what others call a fof profile. WebID is the whole triangle, the whole process protocol to exchange data where fof profiles is one key element. And what is produced now is fof profiles for all Debian developers, gathering the data that is already public and expressing it machine readable, grouped by each identifier, each person. So every time that in WebID context that it says, oh, now you should use your fof profile, you don't need to write one yourself from scratch. You can take this profile and then start out from that one. Are we out of time? Okay. Oh, okay. Thanks a lot for joining, and for your patience here, I was, I'm sorry I didn't prepare a presentation about this, there was a little fussy here. But that's the goppy now. I believe that me or Obergeeks will try to look through the goppy and then post an email to, I guess, DebianDebel or wherever the other thread was also going on. And then we'll see what comes out of this. Thanks a lot.