O formato humanproof/1

Por que um recibo

A Hummand responde se há um ser humano real do outro lado de um ato digital: se está presente, se é a mesma pessoa da referência, se autorizou o quê. Essa resposta só tem valor se puder ser conferida por quem não é a Hummand: o auditor do cliente, um regulador, um perito. Por isso todo ato terminado gera um recibo assinado, exportável e verificável fora da Hummand. Positivo, negativo, expirado, cancelado e até a falha técnica recebem recibo; a ausência de recibo é o único estado invisível, e a cadeia a denuncia.

O que o recibo carrega, e o que nunca carrega

Um recibo humanproof/1 é um objeto JSON com o identificador do ato e do próprio recibo, o cliente (tenant), o tipo do ato, o nível atingido, o resultado e o motivo, as etapas cumpridas com seus instantes, as fontes usadas com o componente e a versão, as garantias afirmadas como booleanos ou nulos, os consentimentos por versão e a política aplicada. Tudo o que diz respeito à pessoa entra como hash: a referência que o cliente deu ao sujeito, a imagem de referência quando houve, o contexto do ato, o texto de cada consentimento.

Nunca entram biometria, imagem, template ou contexto em claro. O formato é fechado: um campo desconhecido é erro de verificação, então não há onde colocar esse conteúdo. A referência do sujeito é um HMAC com um segredo por cliente, porque o hash puro de um CPF se reverte por enumeração.

Canonicalização

Antes de assinar, o objeto é serializado na forma canônica da RFC 8785, com uma restrição: números só como inteiros seguros. O recibo não tem ponto flutuante, e assim a serialização é idêntica em qualquer linguagem. Chaves ordenadas pelas unidades de código UTF-16, strings escapadas como em JSON.stringify, sem espaços.

Assinatura e chave

O payload assinado é o canônico do recibo sem o campo assinatura; kid e alg ficam dentro dele, cobertos pela assinatura, e não há negociação de algoritmo. O algoritmo em produção é ECDSA P-256 com SHA-256 (ES256), com a chave privada em um módulo de chaves gerenciado, de onde ela nunca sai. A assinatura vai em base64url sem preenchimento sobre r || s, como em JWS. A chave pública é publicada como JWKS, selecionável por kid, em gateway.hummand.com.br/.well-known/humanproof/keys.json. O formato admite Ed25519 como opção para uma chave futura.

Hash e cadeia

O hash do recibo é o SHA-256 do canônico completo, assinatura inclusa. Cada recibo carrega em prev_hash o hash do recibo anterior do mesmo cliente; o primeiro aponta para um gênesis derivado do identificador do cliente, que está no próprio recibo. Um auditor com um lote reconstrói a ordem pelos hashes, em qualquer ordem de entrada, e detecta remoção, inserção e bifurcação, sem ver nada de outro cliente. A cadeia não promete ordem de tempo: um ato expirado conclui na data de expiração, que pode ser posterior à de atos emitidos depois dele. A destruição criptográfica dos dados de um ato, prevista na retenção, não quebra a cadeia, porque o recibo já não tinha dado pessoal além de hashes.

Verificação

Verificar é conferir a assinatura contra a chave do kid, o formato, a coerência interna e, num lote, a cadeia. A coerência é o que um auditor aplicaria à mão: um resultado positivo não pode ter etapa negativa; nível de presença exige etapa de presença e a garantia de humano vivo; nível com identidade civil exige a garantia correspondente; hashes na forma certa; nenhuma etapa depois da conclusão.

A implementação é única, em Rust, e roda em três lugares: no servidor que assina, no verificador de linha de comando humanproof-verify, que é distribuído aos clientes com checksum, e nesta página, compilada para WebAssembly. A verificação na página acontece inteira no navegador; nada é enviado a lugar algum. Os vetores de teste do formato são gerados pelo próprio código e conferidos a cada mudança: qualquer alteração em canonicalização, hash ou assinatura aparece como diferença.

Limites

O recibo afirma o que as fontes declaradas sustentam, e nada além disso. A presença viva vem de um componente de detecção de vivacidade certificado de terceiro; a identidade civil, quando presente, vem de uma fonte plugada, rotulada no recibo; o nível é o efetivamente atingido, não o pedido. O recibo não é laudo antifraude, não estima risco nem probabilidade, e não substitui o processo do cliente: ele registra, de forma verificável, o que ocorreu.

Esta é a versão 1 do formato. Mudança de formato é mudança de versão; a versão 1 não é editada.