Ce que prouve le lien reçu par e-mail, et ce qu'il ne prouve pas

Arriver avec un lien de signature ouvre le document immédiatement — pas de mot de passe, pas de compte, pas de second code. Le lien est le justificatif d'accès. Il compte 192 bits d'aléa, frappé pour un seul destinataire et envoyé à une seule adresse, et ce qu'il établit est précisément ceci : celui qui a signé avait accès au message que nous avons envoyé à cette adresse. Il n'établit pas qui il était.

C'est une affirmation plus modeste que celle que font la plupart des produits de signature, et nous préférons l'énoncer clairement plutôt que de laisser une coche verte suggérer quelque chose de plus large.

Comment cela fonctionne

Chaque destinataire d'une enveloppe reçoit son propre jeton. Il est généré à partir d'une source cryptographiquement sûre, il est assez long pour que personne n'envisage de le deviner, et il n'apparaît qu'à un seul endroit : l'e-mail adressé à ce destinataire. L'ouvrir démarre une session liée à ce destinataire et à cette enveloppe. Rien d'autre sur le compte n'est atteignable depuis là.

La décision de conception sous-jacente est qu'un document qui vous est envoyé doit s'ouvrir quand vous cliquez dessus. Chaque étape supplémentaire entre l'e-mail et la signature est un endroit où un accord s'enlise, et les accords enlisés sont le véritable problème dans cette catégorie. La fraude est le problème le plus rare.

Ce qu'il établit

1. La remise à une adresse précise. Le jeton n'existait qu'à l'intérieur d'un message envoyé à une seule boîte de réception.
2. La possession au moment de la signature. Celui qui a complété l'enveloppe avait ce message, ou son contenu, en main.
3. Un enregistrement chronologique autour de cela. Quand l'enveloppe a été envoyée, quand elle a été ouverte pour la première fois, depuis quelle adresse IP, avec quel navigateur, et quand chaque champ a été rempli.

Pris ensemble, cela forme une chaîne qui va d'une adresse que vous avez choisie à une signature que vous pouvez désigner. Dans le cas ordinaire — le cocontractant avec qui vous échangez des e-mails depuis trois semaines ouvre le lien et signe — c'est entièrement suffisant.

Ce qu'il n'établit pas

Écrit noir sur blanc, car c'est la partie que les fournisseurs laissent hors de la page :

• L'identité. Personne n'a vérifié de passeport. Le lien prouve le contrôle d'une boîte de réception, et une boîte de réception n'est pas une personne.
• Que le lien est resté chez le destinataire. Un lien transféré emporte son accès avec lui. Si votre cocontractant transfère l'e-mail à un assistant, l'assistant peut signer, et le dossier ressemblera exactement à une signature du cocontractant.
• Que la boîte de réception est personnelle. Les boîtes partagées sont courantes — accounts@, legal@, une adresse familiale — et quiconque lit cette boîte détient le justificatif d'accès.
• Que le compte n'a pas été compromis. Si quelqu'un d'autre lit ses e-mails, quelqu'un d'autre peut signer.
• Le pouvoir d'engager une organisation. Savoir si une personne peut signer au nom d'une société est une question de fonction, et aucune plateforme de signature n'a d'avis là-dessus.

Chacune de ces limites s'applique tout aussi directement à une page de signature imprimée, signée et renvoyée en photo prise au téléphone, ce à quoi le lien fait concurrence. C'est une comparaison, pas une excuse.

Pourquoi nous enregistrons tout malgré cela

Parce que l'imputation se décide sur un faisceau de preuves plutôt que sur un fait unique. UETA § 9(a) prévoit qu'un enregistrement électronique ou une signature électronique est imputable à une personne “if it was the act of the person”, et que cet acte peut être démontré “in any manner”, y compris par la démonstration de l'efficacité de toute procédure de sécurité appliquée.

In any manner fait un vrai travail dans cette phrase. La loi ne réclame pas une preuve unique et décisive. Elle demande ce que l'ensemble du tableau soutient. Aussi la piste d'audit porte-t-elle l'envoi, la première consultation, l'adresse IP et le user agent de chaque événement, chaque champ rempli, le refus s'il y en a eu un, et le SHA-256 du document terminé. Aucun de ces éléments n'est une identité. Ensemble, ils forment un récit qu'il est difficile de raconter autrement.

Ce qui se passe lorsque quelqu'un nie effectivement avoir signé est une question à part entière, et fait l'objet de son propre article ailleurs sur ce site.

Quand vous devriez vouloir davantage

Le modèle du lien est le bon réglage par défaut et le mauvais choix dans quelques situations précises :

• Le cocontractant vous est inconnu et le montant est élevé.
• La relation est déjà conflictuelle et vous vous attendez à ce que la signature soit contestée.
• Un régulateur, un prêteur ou une politique interne impose une identité vérifiée.
• Vous signez dans l'UE sous une règle qui appelle une signature électronique qualifiée, où l'identité est vérifiée à l'avance par un prestataire de services de confiance qualifié.

Dans ces cas-là, la réponse honnête est que vous voulez une vérification d'identité que nous n'effectuons pas. La piste d'audit n'en est pas un substitut, et nous préférons vous orienter ailleurs plutôt que de vous vendre un dossier qu'il vous faudrait sur-argumenter plus tard.

L'étape que nous avons construite puis désactivée

Il y a un code e-mail à six chiffres dans notre base de code. Il fonctionne. Nous l'avons utilisé par défaut puis retiré, parce qu'il exigeait un second e-mail pour ouvrir le premier, et le coût — des destinataires qui n'ont jamais reçu le code, des codes atterrissant dans les indésirables, des enveloppes abandonnées sur le pas de la porte — était bien plus élevé que l'unique faille qu'il refermait. Cette faille, c'est le lien transféré, et un code envoyé à la même boîte de réception ne la referme de toute façon pas.

Il reste dans le produit comme renforcement ponctuel plutôt que comme réglage par défaut, ce qui est la place d'un contrôle de ce genre.