On 19 Mar 2010, at 23:11, Brion Vibber wrote: > On 03/19/2010 12:39 PM, Story Henry wrote: >> >> Ok, you may say, so why is this interesting to status net, since you already >> have openid? Well the advantage is that you can in fact then also login to >> any server that supports foaf+ssl using 1 click, without having to type in >> your username or password. That is what the openid4.me demo was aiming to >> show. >> >> This becomes a lot more useful, when people start using many different >> status net microblogging platforms to talk to each other, or if you wanted >> to login to other services that support it. The limitation of OpenId is that >> the attribute exchange specification is very limited in what it can express, >> and limited in the size of what can be transferred. With foaf+ssl we have >> the whole of the semantic web information ready to be used. >> >> Ie, you could easily give access to certain agents to say a party invitation >> - just to take one example out of a million - because they were friends of a >> friends of yours, or perhaps just followers or followers of yours. >> > > That's actually quite clever! I hadn't encountered the FOAF+SSL combination > before, so had to dig about a bit to figure out just what it all means. :)
It has been gaining momentum recently, but is still relatively new. We discovered that about 2 years ago, and have only recently started having good simple demos. > > We all know that an encrypted SSL connection will provide your browser with a > certificate verifying the identity of the server. Most folks forget that this > works both ways -- your browser can also identify *you* to web sites if you > have a personal certificate. > > Public key encryption means that the certificate can't be faked by anybody > else who doesn't have the private key on your computer, but by itself just > having a certificate proves only that somebody issued you a certificate. How > can we use that to tell who you are without making an explicit agreement with > you? > > FOAF comes in here to provide a lookup mechanism. The cert includes a link to > your FOAF data on the supplying site, which itself will include a > verification of the certificate. Based on what it can tell about you from > your FOAF data, the site can then decide whether you're allowed access to > various resources, or customize itself for you. well summarised. > > > To my mind there are two main weaknesses of FOAF+SSL, though: > > First, it relies on end-users to manage personal certificates in their > browser. Current browsers just don't do a good job of making this easy -- > probably in part because it's pretty rarely used! The good news is that the > various browser developers are all thinking about ways to better integrate > identity management, so this might be "solved" in a year or two. So in fact creating a certificate is not that difficult. Using the old but only recently documented (in html5) <keygen> tag, browsers such as Firefox, Safari, Opera, and the latest builds of Chrome can force the browser to create a public/private key pair, and send in a POST a certificate request to the server which includes the public key. The server can then make a certificate, and send it back. The browser automatically then adds the cert to the keychain. We have an example of this working on http://webid.myxwiki.org/. Create an account and on your home page you will be able to create yourself a cert in one click. Or if you want to try it out immediately (but you won't get the benefit of having a matching foaf profile) try http://webid.myxwiki.org/xwiki/bin/view/WebId/CreateCert So making a key is easy. Deleting them from your browser is a bit more tricky, but hopefully by the time the masses start using this, browser vendors will have made client certificates much more easy to access. Oh yes, Internet Explorer has an ActiveX equivalent, and webid.myxwiki.org does a bit of javascript magic to get that to work too. > I would consider this an outright killer for most non-toy usage in the > meantime -- only geeks are going to touch it until it's not insane to manage > your certs. I'd love to see a plugin to make sure we could make it work > though! :-) > > > Second, from what I can tell it seems pretty limited in terms of > server-to-server communications. Sure you can fetch whatever's in the public > FOAF, but once you've established identity you'd already have access to that > - it's just a matter of knowing the URL. > > The real fun part is letting access-controlled data migrate around between > multiple services and clients, being machine-readable, usable offline, etc. > Unless a service has your private key, it can't make third-party requests on > your behalf... it looks like there's at least some talk about delegation but > I can't see a clear picture of what's actually specced, working, and > interoperable. Do you know of any documentation on the state of things here? We have not implemented that yet, because we are trying to make sure we get all the basics working first. But I have thought about this to make sure the idea has a future, and have written up how I think one can get something like an oauth mechanism to work using this. http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo foaf+ssl is really a p2p protocol. [ the web is p2p but most people don't think of it that way ] So the trick is for the server to also have it's webid, and then we can describe the server as being part of our list of privileged viewers - ie they could get access to certain files. I really want to do some demos on that soon. But we need to have a few people with WebId's first before implementing that makes sense. :-) Henry > > -- brion > _______________________________________________ > StatusNet-dev mailing list > StatusNet-dev@lists.status.net > http://lists.status.net/mailman/listinfo/statusnet-dev _______________________________________________ StatusNet-dev mailing list StatusNet-dev@lists.status.net http://lists.status.net/mailman/listinfo/statusnet-dev
