Proving a user's identity after the user has forgotten his private key and password

Question

First some background. I am building an application where people send each other emails with messages inside that need their sign-off. Once the participants receive the email they're also given a callback link (the link is generated by cc-ing an email address tied to our app server, and then the app sever sends all the participants an email back with a link). Users click on that link, gets taken to a site, where the site's frontend generates a pair of keys locally inside the browser's localstroage, and the user can either say yes or no to the message, while signing his response + message with the key. We then store the signatures, should there be disputes later on they can search and find who agreed / disagreed to what when.

We've accounted for when the user flushes the browser or the browser flushes itself. The secret key is encrypted with the user's password and stored on the server (like protonmail), so if the user still remembers the password the secret key can be recovered locally in the browser.

But the problem is that I would expect most people won't be using this on a regular basis, so they will likely forget the password or that this site even exists in the first place. This means that their signatures are essentially worthless since there's nothing tying those signatures to these user's identity if they forget and resets their password and gets a new key pair.

One bit of information I do know is the user's email address. When they click on the link to agree / reject the message I right away know they are the owner of a particular email address. Let's assume for a minute that they're not likely to lose access to the email. With that assumption, is there some way I can tie a signature to a user's identity, even after that user has lost the private key (he 99% isn't even aware what a key is or that he has one) and lost his password to our site? To prove that, "Yes, that was you and only you who signed this message 1 year ago". Somehow tie the user's ability to access a particular email address to a signature?

The reason to use signatures is that it is not fakeable. If we only used regular logins then an argument can be made that the app server can just make up whatever it wants. But now we're saddled with a new problem which is how to reliably tie that signature to a user's identity.

Any help / ideas would be greatly appreciated!!

Answer 1

The easiest way to manage this sort of situation is to send people an email confirming that they signed a document. This is akin to the standard password reset pattern of "if this was not you, please notify us immediately."

If you try to make it stronger, you run into the issue that the server is the only party here that is verifying identity. It is the entity that is saying "this signature came from someone who can read XYZ's email address." If the server cannot be trusted, then there is no trustable entity verifying anything. And, given your situation, its unlikely the users themselves are adding any verification into the system.

One other tool you can use to build up trust is to use a blockchain like approach for the records. When people sign contracts, they also sign the chain of contracts. That would make it much harder to forge a single signature from years ago without invalidating every other signature in that time. You could also require the users to review recent signatures, building more belief into the blockchain.

But in general, if you're not going to take the time to build in a full identification system (which involves an in-person meeting), then the strength of your system is built on its auditing, not in its initial signing algorithm.