On 9 Jun 2010, at 00:57, John Kemp wrote: > (after this email, I suggest we move off the OpenID list to discuss this)
This is going to be my last email as it is 1 am here in Switzerland. Thanks for listening in and punching btw. It's good to feel some life at the other end of the wire :-) > More below: > > On Jun 8, 2010, at 6:05 PM, Story Henry wrote: > > [...] > >> Perhaps you mean that you could create a WebID and assert you are me, by >> using my public key? But that would never work, because you don't have the >> corresponding private key. > > I shall assert that I am you, and make myself a private/public keypair, > create a corresponding FOAF file and upload it to the server I control. > > Who's to say that I am not you, cryptographically-speaking anyway? You need to take the social network into account. Imagine I organise a party, put up a wiki, or some party site which all my friends and their friends can access. I tend to know who my friends are, because I will be following them closely. What they tell me over the phone, should fit what I see on their profile. When they are at work late, their tweets should state something about that, not about how they are in the office. Truth is coherent, and inconsistencies build up on each other. The emails they send me, when they add a WebID at the bottom of the email, should match the Web ID I know them by. That is how I know who are my friends. The above is recursively true of each of my friends. So when I invite the friends of my friends to a party the above social network is quite strong. Each individual, as in a democracy, plays their part to render the whole consistent. Sometimes bobos come up, and there follows investigations, and some people may stop being thought of as friends: too unreliable, perhaps they are placed in the category of acquaintances, whom one keeps at a distance. There are less parties they can go to. >> >> I just added that as a FAQ >> http://esw.w3.org/Foaf%2Bssl/FAQ#Could_I_not_simply_copy_your_foaf_profile_onto_my_server_and_pretend_I_am_you.3F >> >> >>> Which is to say, why bother with all the crypto if a user can self-assert >>> his or her WebID and FOAF file anyway? >> >> Without the crypto you would not have authentication. > > True, in some sense, just not a relevant one. You are certainly, with SSL > client certs, authenticating that the owner of the associated private key is > the same entity presenting the cert signed with that key. And that this same > entity created the cert with the WebID attribute in it. > > That's like me saying "my name is Henry" and a server saying "that guy says > his name is Henry, he signed that his name is Henry, and I verified that he > signed the name Henry". Exactly. That is exactly what it is. We don't do more. The rest is built at a different layer: in the Social Web. > >> You would just have a web page describing a person. The crypto allows the >> server to tie a description of a person to >> agent at the other end of the https connection. >> >>> OpenID relies on an OpenID provider "vouching" that a particular URI is >>> "owned" by some user for whom the OpenID provider has an account. >> >> We do the same, but we bypass the need for the Identity Provider. >> >> (Perhaps this is the sticking point, as people have developed businesses >> around that? I think there are many more businesses that can be built in >> this area.) > > Well, perhaps, and I would also note that I actually like self-assertion. I > don't have a problem with it for lots of use-cases. I don't think it's a > problem that people can lie either. > > But the reason people want identity providers, I think, and the potential > (note: potential) value they bring is the ability to make an assertion backed > up by something close to facts - ie. a verification or "real" authentication > process. The problem with identity providers, is that if they are liable for something, anything, they won't want to provide the verification, without it being very costly. Does an identity provider want to verify who your girlfriend is? How much would that cost. Does he want to verify that you like the color green? How would he go about that? > One interesting assertion is "this requester I'm sending over to you was > authenticated by me to have a user account at my site, and supplied a > password at 10am this morning". If I trust the sender of that assertion > enough, I might use that assertion as the basis to authenticate that > requester at my site too. > Same goes for wielders of URLs - "I assert that the requester I'm sending to > you indeed has a user account linked to the URL that requester supplied". yes. The Web ID part happens to fit in with web architecture very nicely, and works in the browsers already. > Another assertion is "I signed this guy's certificate because he gave me a > boatload of paperwork about his company (...and some money!)" The money part, is why there are so few client certificates. But come to think of money, there is no reason your foaf file could not point to a bank account URL, which described endpoints (URLs one can POST to) for people to send you money, and ways for you to agree to send other accounts money.) That bank account URL could also be a Web ID. So that when you go to a web site using your usual minimal WebId, and when you want to pay the firm something, they can discover your account, find out that that is an account by a well capitalized bank which they trust, and continue with the transaction. You may sign a statement on your bank by being redirected there, where you login with your bank WebId. This is just an initial sketch of how one could do payments RESTfully in a linked data fashion... something worth doing some more research in. >> >>> You could also run your own OpenID provider and self-assert that way. And >>> the question is whether that is a particularly interesting thing to do in a >>> Web context (as we self-assert all the time without any special protocols >>> needed and it works fine for many things without new techniques, systems or >>> other technology). >> >> yes, it is not that different from usual e-mail authentication login, which >> is what powers most of the web currently. Except that here >> >> 1. You don't have to create an account on every server >> 2. You don't have to give your email out >> 3. you can do it in one click, >> 4. you get linked data with it >> 5. you can bring your social network along with you >> 6. No need for limited Attribute Exchange >> >> And I think that's just the beginning. But I should be careful, or Dick >> Hardt will say I am overselling myself. The above is proven to work. > > I'm not saying it doesn't. But what is the difference between your solution > and a semi-automated form-filling application without any crypto magic? The social network at Web scale: the Social Web. Your identifier is a URL that can be linked to and information fetched from using HTTP GET. The network effect sets in from that point. > >> And the social aspect is exactly how Facebook and LinkedIn increase the >> quality of the data: it is crowd sourcing of attribute validation. Your >> friends are the people who vouch for you. > > Yes, this is the interesting part of your work, but it still seems entirely > unrelated to SSL SSL does authentication, tying a user to a URL (Web ID). The Web ID ties into the linked data network, which is the social web. They fit together. So that is probably why few people came across this idea, because few people are that knowledgeable in REST, Web Architectures, Security and the Semantic Web. (I am not very knowledgeable in any, but enough to recognise this idea) Good night all, Henry > Cheers, > > - johnk > >> No need for big co, or big governments. (Though they too have a role to play) >> >>> >>> Regards, >>> >>> - johnk >>> >>>> it may be worth going over to the foaf-protocols mailing list >>>> >>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >>>> >>>> Henry >>>> >>>> >>>>> >>>>> Regards >>>>> Signer: Eddy Nigg, COO/CTO >>>>> StartCom Ltd. <http://www.startcom.org> >>>>> XMPP: [email protected] <xmpp:[email protected]> >>>>> Blog: Join the Revolution! <http://blog.startcom.org> >>>>> Twitter: Follow Me <http://twitter.com/eddy_nigg> >>>>> >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> >>>> _______________________________________________ >>>> specs mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >> > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
