| > Could you give a short explanation of the differences to BrowserId? DSSID pre-dates BrowserID. The underlying protocols are essentially the same, except that in BrowserID you have multiple keys and they are bound to email addresses. In the current implementation of DSSID you only have one key (though that could easily be changed) and it isn't bound to anything. You establish the identity of your key simply by using it to sign things. > Are the keys tied to origins? No, but again, that could be changed. > If so, how is that enforced? That depends on what you mean by "enforced", but the answer is probably that they keys would be stored in a dictionary whose keys are origins. > If not, how do you address the privacy issue of origins tracking you through your key? The current implementation is just a proof-of-concept prototype that I put out there several years ago to see if there was any interest in it. There wasn't. But since BrowserID hasn't really caught on I bring it up every now and again. It's a plausible theory that BrowserID hasn't caught on because it's too complicated to deploy, and that DSSID might turn out to be closer to the Right Thing. Its pretty clear that passwords must die sooner or later, preferably sooner. |