- From: David Chadwick <d.w.chadwick@kent.ac.uk>
- Date: Mon, 08 Oct 2012 12:25:55 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Ron Garret <ron@flownet.com>, Anders Rundgren <anders.rundgren@telia.com>, Henry Story <henry.story@bblfish.net>, public-identity@w3.org
Hi Ron I have tested your system and demo and it works fine, as you say. I guess my question to you is, Why would a web site bother in trusting the dswi.net server since it does not perform any authentication on the user? The value add is surely quite small (zero trust, adding a third party to the client server comms, but making the comms a bit easier). What is to stop the web site from running Java script in the browser in a similar way to that used by dswi, that causes the browser to create a key pair for the user (if it does not already exist), and then use this each time to validate the user by using TLS client side authn? In this way the web site does not need to trust dswi.net., there is no third party involved, and the client cert proves its the same user each time. regards David > > As long as Forge has entered the conversation I would also like to > point to my own identity project: > > http://dswi.net/ > > DSSID uses Forge for its crypto, but it uses a different protocol > specifically designed to be simple for clients to integrate with. > Note: this code is not ready for production use. Feedback and > comments are welcome. > > > Wow, looks really nice. > > If im not mistaken, it's quite similar to a web version of SSH? > > Does this sole harry's unlinkability problem too? > > > rg > >
Received on Monday, 8 October 2012 11:26:26 UTC