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 que a torna detectável, com o limite descrito adiante.

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 acusa buraco no meio da série, inserção, reordenação e bifurcação, sem ver nada de outro cliente. Um lote que não comece no gênesis é rotulado como de origem externa, e não passa como cadeia completa. 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 não carrega biometria, imagem nem identificador em claro.

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.

Dois limites merecem nome. O primeiro é do encadeamento: uma cadeia isolada acusa o buraco no meio, porque o elo seguinte aponta para um hash que não está no lote, e não acusa o corte do fim, porque o que sobra continua contínuo desde o gênesis. Numerar não resolve, já que uma sequência de 1 a N não revela que existia N+1. O que resolve é um ponto de conferência guardado fora, com o último hash conhecido e a contagem, comparado depois.

O segundo é da fonte. A presença viva é o veredito de um componente certificado de terceiro, que decide por critério probabilístico com limiar; o recibo registra o veredito e a versão do componente, não um escore. A comparação com a referência aplica um limiar definido pela Hummand. E o recibo não prova a legitimidade da referência que o cliente enviou: uma boa comparação contra a referência errada é confiança alta na pessoa errada, e quem responde pela referência é o cliente.

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

Adendo de 2026-09-18: o ponto de conferência existe

Quando esta nota foi escrita, o ponto de conferência descrito acima era o que resolveria o corte do fim, e não existia. Ele existe desde 2026-09-13: o gateway o emite sob pedido, como um objeto assinado humanproof-ponto/1, com a mesma chave dos recibos, afirmando quantos recibos aquele cliente tinha no instante do pedido e qual era o último hash.

A mecânica é a que a nota previu. O que o adendo acrescenta é o lado de quem audita, e é a parte que decide se o mecanismo vale: o ponto não serve guardado por nós. Um lote apresentado depois, que não contenha aquele hash ou que tenha menos recibos desde o gênesis, contradiz uma afirmação assinada da Hummand; é a comparação da cadeia com um ponto guardado fora que torna o corte detectável, e não a cadeia. Por isso não há, do nosso lado, tabela de pontos emitidos: a única cópia que serve para conferir é a de quem audita, e um ponto pedido no mesmo instante da conferência não confere nada.

O verificador de linha de comando compara um lote com um ponto guardado. A verificação nesta página continua sendo de recibo e de cadeia.

A seção de limites não foi editada, e nem o formato: a versão 1 do humanproof/1 não muda, e o ponto de conferência é um objeto irmão, com formato próprio, em vez de um campo novo no recibo.