How to verify a signer's identity

Nearly every argument about signer identity is really an argument about email. The link goes to an inbox, the code goes to the same inbox, and somebody eventually asks the obvious question: what exactly did we verify?

It is worth answering honestly, because the three options available do genuinely different things and only one of them adds a factor that is not the signer’s email account. This is general information rather than legal advice, and what counts as adequate verification varies by country and by document, so check your own position before relying on it.

What identity means for a signature

Two legal tests are worth having in mind, because they set the bar and it is lower than people assume.

Australia’s Electronic Transactions Act asks for a method used to identify the person and to indicate their intention, and then asks whether that method was as reliable as appropriate for the purpose, in light of all the circumstances. It is a proportionality test, not a checklist. A small service agreement and a company sale are not held to the same standard by the same words.

The eIDAS Regulation is more specific about the top of the range. Article 26 requires an advanced electronic signature to be uniquely linked to the signatory, capable of identifying the signatory, created using data the signatory can use under their sole control with a high level of confidence, and linked to the data so that later changes are detectable. None of the three checks below reaches that on its own, and nobody should tell you otherwise.

Email link

The default. The recipient gets an invitation, clicks through, and is authenticated automatically without ever seeing a challenge screen.

What it proves is that somebody opened that link. Not that the addressee opened it: email gets forwarded, shared inboxes exist, and a link in a message is a bearer token. What it has going for it is that it is the lowest friction option in existence and that the audit trail still records the open, the view, the consent and the IP address.

Use it where the address is one you already deal with and the document is not worth impersonating.

Access code

You set a code of at least four characters when you prepare the request. It is stored as a salted scrypt hash and compared in constant time, and the API will not hand it back to anyone, including you.

That last part is the design. The code is only worth something if it travelled by a different route than the link, and the tool refuses to make the lazy version easy. Say it on the phone, or hand it over at the property, and you have a real second factor: possession of the inbox plus knowledge of something you gave them. Paste it into the covering note and you have added a step that proves nothing.

Five wrong attempts lock that recipient out for fifteen minutes, written so that parallel guesses cannot skip the counter. The access code page covers the setup.

One-time code by email

The recipient opens the link, asks for a code, and a six digit number arrives at the same address. It expires in ten minutes, can be redeemed once, and at most five can be issued in any ten minute window. Wrong entries count towards the same five-attempt lockout as an access code.

It is a good default for a document going to a personal address you have never dealt with, because it turns a forwarded link into something that needs live access to the inbox rather than the message.

Be clear about its ceiling, though. NIST’s SP 800-63B, the standard behind most authentication assurance work, states that methods which do not prove possession of a specific device, and it names email explicitly, are not to be used for out-of-band authentication. So an emailed code is not a second factor. It is a fresher test of the same one.

The comparison

Every number and every certificate string for the three checks is in the table below. Two rows in it decide most choices: what each one proves, and whether it is a second factor at all.

What the signer sees before verifying

This is the part that surprises senders. Before any check is passed, the request returns the title, your message, the recipient’s own name, email and role, which check is required, and the consent version. It returns nothing about the document.

So the title is public to whoever holds the link. Naming it “Redundancy agreement, R. Whitlock” tells the story before anyone has proved anything. Title it plainly and put the detail inside the file.

Once the check passes, the signer holds a session bound to their recipient record for thirty minutes. It is held in memory only, so a page refresh sends them back through verification. That is a deliberate trade of convenience for a shorter window of exposure, and it is worth warning slow signers about.

Choosing by document risk

A rule of thumb that survives contact with real work:

Emailed link for anything internal, anything low value, and anything going to an address that is already in your system. Adding friction here costs completion and buys nothing.

Emailed one-time code for offers, contracts and consents going to a personal address, especially where the signer’s inbox is the only thing you know about them. It is the setting most people should use more often than they do.

Access code where you are already going to speak to the person, which is nearly always true in property, vehicle sales and anything with a deposit attached. The phone call is happening anyway; carry four characters on it.

In-person signing where you are in the room, which waives the emailed check for that session and records who hosted it. See in-person signing.

If the underlying question is really what makes a signature stand up at all, the evidence side of it is in are electronic signatures legally binding, and the two-way comparison of codes is in access code versus one-time code.

The example

The worked example below is a one-way non-disclosure agreement, which is the document that most often deserves a code and most often gets sent with a bare link. The asymmetry is the reason: one side is handing over something it cannot take back, so the cost of the wrong person opening the link is not symmetrical either.