-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would assume by delegation you would mean something like having a private key to a cert that has been signed the the user whose data we are talking abouts private key. If this is not what you are talking about I would suggest thinking about it. Just like your browser throws exceptions if the cert it receives from a website is not trusted itself or signed by a trusted cert who also has your trust to sign other certs, you could allow delegation of authority through signing a cert for that 3rd party. That would also allow for separate key usage extensions or similar that would be specific to this type of application, those usage extensions could specify what kinds of data the third party is allowed to access on your behalf. The final benefit I see right now is the potential to revoke a 3rd parties permission without a re keying or to set a time limit on their access, for instance I want to test compatible service ABC, but I am not sure I want to use then for any real length of time, I sign a cert for them that has an expiration date in one week so that I can try it out and give them access, but if I decide I do not like it their permission will expire and if they are not trustworthy it does not matter, they can not in any way keep any useful credentials to continue.
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. :) > > 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. > > > 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. > > 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? > > -- brion > _______________________________________________ > StatusNet-dev mailing list > [email protected] > http://lists.status.net/mailman/listinfo/statusnet-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkuj+X4ACgkQzSSLW0oTVN4oeACeNKyK8SmNyjSUHOmzKdrdr8+e iD4AnR4jH6drYn9+R8UNRHl+m35YmHDk =ZPMl -----END PGP SIGNATURE----- _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
