- From: Ron Garret <ron@flownet.com>
- Date: Mon, 8 Oct 2012 10:08:22 -0700
- To: David Chadwick <d.w.chadwick@kent.ac.uk>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Anders Rundgren <anders.rundgren@telia.com>, Henry Story <henry.story@bblfish.net>, public-identity@w3.org
Excellent questions. First let me say up front that neither the design nor the implementation of DSSID is complete. It needs quite a bit of work still before it's really ready for prime time, but even in its current form it's better (I claim) than the username-password protocol that is currently ubiquitous on the web. This is the reason why I haven't pushed very hard on deployment. I sent the announcement out to this list primarily to get feedback like this. So let me address your questions: > Why would a web site bother in trusting the dswi.net server since it does not perform any authentication on the user? The DSSID site (secure.dswi.net) *does* authenticate the user. It does this by having the user sign a nonce with their private key. The premise behind this design is that your private key *is* your identity. That's the whole point. The problem you cite (if I understand the question correctly) is that a relying party has no way at the moment to *know* that secure.dswi.net is authenticating the user. But this is true of *any* third-party authentication scheme. If you use Facebook Connect or Google OAuth or LinkedIn or Twitter sign-ons you have know way to know that either of those entities has actually authenticated the user. You have to trust them. In the case of DSSID it is actually possible to provide an audit trail that could be used by the relying party to verify that authentication was done. It's not even that hard: the nonce, signature, and public key could just be added to the list information sent back to the RP. But ithat would undermine one of the goals of DSSID which is to keep things simple. Exploring the design space and tensions between simplicity and security is one of the reasons I am undertaking this project. I believe that one of the problems with extant security schemes, and one of the reasons that stronger security protocols have not been more widely adopted, is because they're just too darned complicated -- for users and for relying parties. > 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? Nothing. I consider this a feature. The goal of DSSID is *not* to make secure.dswi.net the central locus of authentication on the web. That is pretty much bound to fail. The point is to be an existence proof that it is possible to design an authentication protocol that is at once simpler and more secure than what is currently in use. The DSSID protocol is not a secret, and anyone can implement it. In this respect, DSSID is no different from OAuth (except simpler). The hope is that people will start to use it not because it's perfect, but because it's demonstrably better than what is currently in use (per-site passwords), and that this in turn will begin the process of user education necessary for the widespread use of PKE. The only reason that authentication is provided by secure.dswi.net instead of a reference implementation of the authentication code is (I am going to start sounding like a broken record here) to keep things simple. Two things in particular: with a public central server a relying party has to do very little work to use DSSID. Second, and more important, because localstorage is per-site, there is no way for Javascript to securely store the user's key in a way that can be accessed by more than one service provider. Let me add a few general observations as long as I'm standing on my soap box: 1. A criticism that is sometimes levied at DSSID is that it's a reinvention of client-side certificates. My response is, yes, that's (mostly) true. But client-side certificates *need* to be reinvented, not because they are insecure, but because the user experience for client-side certificates is abominably bad. It is so bad that even *I* can't figure out how to use them, and I'm about as technically savvy a user as you could hope to find. 2. It is not possible to build a secure identification scheme without some kind of browser support. And not just browser support, but browser UI support. The reason for this is that what matters is not just what is going on under the hood, but also what the user sees that gives him confidence that what is going on under the hood is what is *supposed* to be going on under the hood. So there must be *something* in the UI that can be rendered by the browser that cannot be mimicked by a web site. At the moment, the only UI element that has this property is the address bar (and the HTTPS URL scheme in particular) and the lock icon. But this is not the only possibility. Another possibility is, for example, a dialog box that has a visual appearance that only the browser can produce that solicits a pass phrase that unlocks a private key that is stored in some dedicate secure storage object, and that can only be used to sign nonces and hashes. Whether this is actually a good idea or not remains to be seen, but this is a possibility that heretofore has not even been discussed (as far as I know). The goal of DSSID at the moment is not so much to be the last word in identity protocols as it is to provide another data point to inform the debate on what form this browser support should take. rg On Oct 8, 2012, at 4:25 AM, David Chadwick wrote: > 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 17:08:46 UTC