Nice, I checked that out. It looks like you store the encrypted private key in session storage (i.e. a glorified cookie). My main concern would be how to back up that private key. As a technically savvy user, I shouldn't have a problem with that, but I'm not sure how a novice could manage while still keeping everything "Dead Simple". (I suppose a "backup to cloud" option could be arranged somehow.)
Another problem in my particular case is that I have my browser set to clear all cookies upon exit. I'd obviously have to change that, because otherwise I'd lose my private key every time I closed the browser. But that isn't the concern of DSWI I know.
I also checked out BrowserID briefly, but as I understand it that requires all logins to go through a central server. Consequently they need to have a "privacy policy" which "promises" not to track your online behavior. That is not true with a system like DSWI, which avoids any central repository or authentication server.
Actually, the encrypted key is stored in localStorage, not sessionStorage. If you choose "keep me logged in" then the UNencrypted key is stored in sessionStorage (which automatically goes away when you close the window). There are no cookies involved (unless the site using DSSID for login gives you a session cookie).
Packaging PKI so that a non-technical user can use it is the central challenge here. There's actually quite a lot of functionality that is hidden in order to keep things simple. To see it visit:
Yes, thanks for clarifying. I see that now. I've been through your demo a few times in Chromium, and I've been poking around and looking at the "Cookies and Other Data" values. So yes, I see now that my actual private key is in "Local Storage".
By the way, these concepts of localStorage and sessionStorage are new to me. Evidently they're something like glorified large cookies in HTML5. Chromium handles it just fine, but I don't think my Firefox browser even understands it yet. I see where I can examine all my live cookies there, but I don't see any mention of "storage" there. (I'm using Firefox 3.6.24 on Ubuntu.)
Consequently I haven't been able to get it to work yet on FF. But maybe that's because long ago I did a bold yet insane experiment wherein I deleted all trusted root CAs in that browser. So it might be my problem, not yours.
DSSID has been tested in FF, Chrome, Safari and Opera. It doesn't depend on certificates, so deleting your root CA's shouldn't make a difference. Google "HTML5 local storage" for more info on localStorage and sessionStorage.
When I click "Login with DSSID", the page says nothing except "Welcome to DSSID". No login box, button, or anything. Of course, it's not your fault, because when I do a View Source, I see all those things. They just don't appear to me visually.
This is happening on two different Firefox browsers on two different Linux machines. It must be a problem with settings or a plugin. I'll try it on a brand new Linux machine with a fresh install of FF and let you know.
Of course it's my fault :-) Failing silently is never acceptable under any circumstances.
That said, a silent failure is pretty weird. It can happen if you have Javascript disabled (are you running noscript?), but there's a check for that on the demo page. I just added an explicit check on the DSSID page, so please try it again.
I'm pretty sure the problem is actually related to my deletion of all root CAs. Why? Because there's a red exclamation mark over the lock icon at bottom right of window, and when I hover it says "Warning: Contains unauthenticated content."
I already force-accepted the dswi.net certificate as a specific exception when I first played with DSWI yesterday. I would think that acceptance should apply to the JS content as well. But apparently not. So I'm poking around in my FF settings to see how I can trust your certificate even more than I already have -- yet without installing Comodo's root CA certificate.
It's all my fault, because of my bold yet insane experiment in distrusting all root CAs.
