- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 18 Jul 2011 05:27:49 +0200
- To: Ben Adida <ben@adida.net>, dev-identity@lists.mozilla.org
- Cc: Danny Ayers <danny.ayers@gmail.com>, WebID XG <public-xg-webid@w3.org>
On 18 Jul 2011, at 01:44, Ben Adida wrote: >> >> Also I think it's far cleaner to allow the user to directly assert the >> association of a URL with their identity rather than leave it to any >> other party. > > So this is a self-assertion? With BrowserID, assertions are done by the > email domain. Why would they sign whatever URL the user wants them to > sign? What authority do they have to make that assertion? The use case of course would be the one where that server is providing both an e-mail address and a profile page. Google is one such provider. But any e-mail server can put up a page associating a simple key-pair with a WebID. Vice versa, if the social networking service does not own the e-mail domain of all of its users, then it won't be easy for them to certify the e-mail information with your BrowserID as it is specified currently, but they will find it easy to certify a profile page. And it seems to me that social network tie in is a very big and interesting feature to Relying Parties. Now if the social networking service wishes to provide proof of identity - social identity in a network - then an HTTP WebID, being RESTful and linkable, also provides a great advantage. That is why I am for both options being available. WebID is quite open about allowing both. Henry Social Web Architect http://bblfish.net/
Received on Monday, 18 July 2011 03:28:19 UTC