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 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.

Adendo de 2026-10-29: três descrições corrigidas

Três frases desta nota descreviam o recibo de um jeito que o emissor não segue. O formato não mudou; mudou a descrição, que agora bate com a especificação 1.4.

• O hash do consentimento não é o hash do texto. O texto_hash de cada consentimento é o hash de um identificador do consentimento (finalidade, escopo e versão), não do texto exibido à pessoa. O recibo diz qual versão do texto foi aceita; o texto daquela versão se pede à Hummand.
• A versão em fontes é a do software da Hummand. O recibo identifica o componente de terceiro que decidiu a presença, mas a versão registrada ao lado é a do software da Hummand que o chamou, não a do componente.
• O segredo da referência fica com a Hummand. A referência que o cliente dá à pessoa entra como HMAC com um segredo por cliente guardado pela Hummand; só a Hummand recompõe esse hash. O recibo não carrega identificador da pessoa em claro, mas carrega em claro o identificador do cliente e do ato, que são opacos.

Junto, uma correção no emissor, no mesmo dia: uma revisão humana decide o ato, não a presença. A garantia de presença viva passou a ser sempre o veredito do componente, e a revisão feita pelo cliente pela integração passou a aparecer no recibo.

Adendo de 2026-10-30: a revisão 2

Desde 2026-10-30, às 05:21:39 UTC, a Hummand emite o recibo na revisão 2 do humanproof/1. O formato é o mesmo. A revisão muda o que o recibo afirma e como se confere:

• Cada afirmação diz quem a sustenta: o componente técnico, uma revisão humana, a declaração do cliente ou uma base oficial. Uma revisão humana decide o ato, nunca a presença.
• O consentimento aponta para o texto que a pessoa viu. O texto_hash passa a ser o hash do próprio texto, e os textos estão publicados, com versão e hash, em hummand.com.br/consentimentos. Isso supera a primeira correção do adendo de 2026-10-29, que valia para a revisão 1.
• O cliente confere sozinho de quem é o recibo. A referência da pessoa entra como compromisso, calculado com uma chave do cliente e um valor aleatório por recibo. Com a chave e a referência, o cliente recalcula e confere, sem depender da Hummand. Sem a chave, o compromisso não liga dois recibos da mesma pessoa; quando houve comparação, o hash da imagem de referência é o mesmo nos recibos que usaram a mesma imagem.
• O recibo diz o nível que a política pedia e o que foi atingido, e traz o hash da política aplicada.
• Assinaturas por papel, para que uma troca de chave, ou uma assinatura nova no futuro, não invalide o que já foi emitido. O formato admite validade por chave; a chave atual não tem prazo declarado.
• Pontos de conferência e ancoragens encadeados: cada um aponta para o anterior, e a lista das ancoragens é pública. A ancoragem ainda não está ativa em produção; a lista existe e fica vazia até lá.

Os recibos concluídos até o corte seguem a revisão 1 e continuam verificáveis com as regras de antes. Depois do corte, um recibo sem a marca da revisão é recusado. A especificação descreve as duas revisões, e o verificador desta página lê as duas. Ele também confere um lote contra um ponto de conferência e a prova de ancoragem, o que o adendo de 2026-09-18 ainda não dizia.

Uma frase da seção de limites perdeu nesta data a primeira oração, que negava ao recibo uma categoria de produto que ele não ocupa; o resto da frase ficou como estava.