Quem assina um contrato de cada vez raramente perde a prova. O problema aparece no volume: a correspondente bancária com duzentos contratos de consignado na semana, a plataforma que renova o termo de todos os parceiros no mesmo mês, o RH que colhe o aceite de uma política nova de cada pessoa da empresa. Nesses casos o envio vira planilha, a planilha vira links, e cada passo manual entre o contrato e a assinatura é um lugar em que o documento pode trocar sem que ninguém perceba.
Este guia trata do lote do ponto de vista da prova. O que precisa estar fixo antes de o link sair, o que cada etapa avisa e o que conferir quando o lote fecha. A base jurídica das classes de assinatura está em assinatura eletrônica no onboarding, e o cuidado com a planilha em si, em lote por planilha sem FTP.
As características que a lei usa para a avançada
Entre particulares, a validade da assinatura eletrônica vem da Medida Provisória 2.200-2, de 2001, cujo artigo 10, § 2º, admite outro meio de comprovação da autoria e da integridade "desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento". A Lei 14.063, de 2020, rege a interação com o poder público e, pelo artigo 2º, parágrafo único, não se aplica à interação entre pessoas jurídicas de direito privado, mas é a régua escrita que existe, e a que o consignado do trabalhador adota para a assinatura avançada. No artigo 4º, inciso II, ela descreve a assinatura avançada, aceita pelas partes, por três características. Ela "está associada ao signatário de maneira unívoca", usa dados de criação que o signatário pode, "com elevado nível de confiança, operar sob o seu controle exclusivo", e "está relacionada aos dados a ela associados de tal modo que qualquer modificação posterior é detectável".
A terceira é a que o lote costuma quebrar. Se a assinatura não estiver amarrada ao conteúdo exato do contrato, trocar uma cláusula depois do aceite não deixa rastro. No envio individual, o contrato e a assinatura costumam nascer juntos. No lote, entre a geração do documento e o clique do signatário passam dias, sistemas e pessoas.
O hash no link, e não o contrato
A forma de amarrar a assinatura ao conteúdo sem mandar o contrato para quem verifica é o resumo criptográfico do arquivo. O SHA-256, do padrão FIPS 180-4 do NIST, produz um resumo de tamanho fixo de um arquivo. Pelo próprio padrão, é computacionalmente inviável achar uma mensagem que corresponda a um resumo dado ou duas mensagens diferentes com o mesmo resumo, e qualquer mudança na mensagem resulta, com probabilidade muito alta, num resumo diferente.
Daí a regra do lote: o resumo de cada contrato entra no link no momento em que o link é emitido, e fica fixo ali. Quem abre o link assina aquele resumo, e não outro. Se alguém trocar o arquivo depois, o resumo do arquivo novo não bate com o que foi assinado, e a troca aparece na primeira conferência. O contrato em si nunca precisa sair do seu sistema.
Três consequências práticas:
- Gere o resumo do arquivo final, o mesmo que vai para o arquivo morto. Resumo de um rascunho prova o rascunho.
- Um link por contrato e por signatário. O link é de uso único e leva um só resumo; reaproveitar o mesmo fluxo para dois documentos quebraria a ligação da assinatura com os dados.
- Guarde, ao lado do contrato, o resumo e a referência que você mandou na linha da planilha. É com eles que você confere depois.
O que a planilha de entrada precisa ter
Cada linha do lote precisa de duas coisas: a sua referência para o contrato, que é como você vai reconhecer o resultado, e o resumo SHA-256 do arquivo, em hexadecimal. O resto do lote sai disso: um link por linha, e um arquivo com os links que sai uma única vez. Quem manda o link para o signatário é você, pelo canal que já usa com ele, porque é o seu cliente e o seu contrato.
O cabeçalho é exatamente reference_id,document_sha256. A plataforma recusa o arquivo com resumo de tamanho errado, referência repetida ou planilha vazia, e recusa referência com cara de dado pessoal: a referência é o id do contrato ou do titular no seu sistema, nunca CPF, CNPJ, telefone ou e-mail.
Os dois avisos de cada contrato
No lote, a pergunta do dia a dia não é "assinou?", é "quem ainda não começou?". Por isso cada contrato dá dois avisos no webhook do flow.
O primeiro chega quando o signatário abre o link e começa a verificação. Ele traz o identificador do link, o da sessão e a sua referência, um aviso por link. É o que permite cobrar só quem não abriu, em vez de reenviar para todo mundo.
O segundo é o resultado da verificação. Com a assinatura aprovada, ele leva o dossiê: o resumo assinado, a assinatura, o algoritmo e a chave pública usada. A assinatura é Ed25519, o esquema descrito na RFC 8032, do Internet Research Task Force (IRTF), que opera em torno do nível de segurança de 128 bits.
Os dois avisos chegam pelo mesmo webhook assinado que já entrega as outras verificações, e o seu servidor confere a assinatura do webhook antes de tratar qualquer um deles, como mostra o guia de webhooks seguros.
Quando o lote fecha
O fechamento é uma conferência em três colunas, por referência:
- o resumo que você mandou na planilha;
- o resumo que voltou assinado no dossiê;
- o resumo do arquivo que está no seu arquivo morto hoje.
As três precisam bater. Se as duas primeiras divergem, a linha da planilha não é a que foi emitida. Se a terceira diverge, o arquivo guardado não é o que foi assinado. Os dois casos têm de ser achados por você antes de serem achados por quem contesta o contrato.
A conferência da assinatura não depende de quem a emitiu. A assinatura se confere sobre o manifesto recebido no dossiê, e a chave que vem nele só vale se for uma das chaves públicas listadas na documentação do módulo. Com isso, qualquer pessoa verifica o dossiê fora do nosso sistema, e é essa a conferência que vale numa disputa.
Fontes citadas
- Lei 14.063/2020, arts. 2º, parágrafo único, II, a, e 4º, II: Planalto
- NIST FIPS 180-4, Secure Hash Standard: NIST
- Medida Provisória 2.200-2/2001, art. 10, § 2º: Planalto
- IRTF RFC 8032, Edwards-Curve Digital Signature Algorithm (EdDSA): RFC Editor