- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 27 Oct 2011 11:24:43 +0200
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: "public-identity@w3.org" <public-identity@w3.org>
On 27 Oct 2011, at 10:10, Anders Rundgren wrote: > Hi, > I may have read the specification in too much haste but I can't see how > you can store keys for arbitrary RPs using an unmodified browser and JS. > > Could someone enlighten me? They can't of course. Which is why the JavaScript API to be developed here is needed for such a protocol to work. Currently they are doing demos to see how javascript fans take onto the idea of decrypting keys, and if the resulting e-mail address is something they are interested in. But it is at present a centralised system of identity and can only be decentralised if all the major browser vendors implement this API correctly. The way a Relying Party is meant to verify the e-mail address of the user sent to it in the certificate is by according to BrowserId to verify the signature of the e-mail domain holder. How they intend to get that public key of the domain holder was not specified clearly when I last looked. But it could be through a lookup in DNSsec I suppose. So then it is clear that the JSON certificate received by the Relying Party could contain a WebID for the user too , pointing to his WedId Profile. That profile could also contain the public key of the user, as a way of verifying that his certificate was still valid. When discussing this with Ben Adida he for some reason thought this was an absolutely incompatible with his protocol, where it obviously is not. So there is something else going on. It is odd since it is clear that a simple e-mail address is not that interesting to the RP. It is certainly not going to make for a very user friendly personalised web site, let alone a socialised one. In WebID we can point to an access controlled profile that could show more or less information depending on who accessed it. So if a friend access of a friend accesses it could show information about your friends. I think perhaps the browser folks are thinking of the browser as a centre of user information. So that it could send different certificates with more or less information depending on what the user could reveal? Not sure... I wrote up the difference between browserId and WebID in detail here http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid Henry > Anders > Social Web Architect http://bblfish.net/
Received on Thursday, 27 October 2011 09:25:26 UTC