Nota técnica para perícia: o recibo e o dossiê da Hummand

1. O que é um ato e o que fica dele

Um ato é um pedido de prova que uma organização cliente da Hummand faz a uma pessoa: estar presente e ser a mesma pessoa de uma foto de referência, autorizar uma ação, conceder um mandato. A pessoa cumpre as etapas no próprio celular, por um link individual. Quando o ato termina, com qualquer resultado (positivo, negativo, expirado, cancelado, falha técnica ou revogação), a Hummand emite um recibo humanproof/1, assinado.

O recibo tem duas revisões. Desde 2026-10-30T05:21:39Z (a data de corte), a Hummand emite a revisão 2, marcada no recibo pelo membro "revisao": 2. Os recibos concluídos até o corte são da revisão 1, não têm esse membro e continuam verificáveis com as regras de antes. Um recibo sem a marca e concluído depois do corte é recusado. O perito identifica a revisão pelo membro; onde as duas diferem, esta nota diz qual é qual.

Do ato, o perito pode receber três coisas:

• O recibo, um arquivo JSON assinado. É a peça que se confere sem a Hummand.
• O dossiê do ato, impresso, em PDF, num pacote .zip ou aberto por um link compartilhado. Junta o recibo, a linha do tempo, os consentimentos e os acessos. Na linha do tempo, cada evento traz a fonte: Assinado (está no recibo e se confere), Carimbo do tempo (atestado por uma Autoridade de Carimbo do Tempo) ou Registro do sistema (anotação operacional da Hummand, que vale pela palavra de quem guarda o registro).
• O pacote do auditor de uma campanha ou ciclo: a lista dos atos em CSV, os recibos de um trecho contínuo da cadeia, a chave pública e, quando houver, o ponto de conferência.

Nenhum desses arquivos contém imagem, vídeo, template ou outro dado biométrico. A pessoa aparece só por hashes e pela referência que o cliente usa internamente, quando o cliente a inclui na lista.

2. Como a evidência é produzida

Num ato de presença (nível 2, o mais comum), as etapas são estas, cada uma com o instante registrado no recibo:

1. Contexto e consentimento. A pessoa vê para que serve a prova e aceita os termos: o consentimento geral e, separado, o biométrico. O recibo registra cada aceite com a versão do texto e o instante. Na revisão 2, registra também a camada (geral, biometrico ou escopo), o idioma e o hash do próprio texto que a pessoa viu; os textos estão publicados, com versão e hash, em hummand.com.br/consentimentos.
2. Presença viva. Um componente da AWS certificado pela iBeta segundo a ISO/IEC 30107-3 decide se há uma pessoa viva diante da câmera. A decisão é probabilística, com limiar do componente; o recibo registra o veredito, não um escore. Na revisão 1, o recibo identifica o componente em fontes, e a versão registrada ali é a do software da Hummand que o chamou, não a do componente. Na revisão 2, fontes separa o fornecedor, o componente, a versão do componente (que pode vir como nao_informada), a versão do software da Hummand (versao_adaptador), o ambiente (producao ou homologacao) e, quando há, a certificação do componente, com esquema, laboratório, relatório e data.
3. Comparação com a referência. O rosto capturado é comparado com a foto de referência que o cliente enviou. O limiar é definido pela Hummand e não é publicado. O recibo registra o veredito e o hash da foto de referência. Na revisão 2, a política de comparação aparece pelo identificador e pelo hash (evidencia_tecnica.politica_de_limiar), sem os valores.
4. Revisão humana. Um caso inconclusivo não vira resultado sozinho: vai para revisão, feita pela Hummand, em que quem revisa prova a própria presença antes de decidir, ou pelo cliente, pela integração. Na revisão 1, o recibo traz revisado_por: o id do ato em que o revisor da Hummand provou a presença, ou apikey: seguido do id da chave do cliente. Na revisão 2, traz revisao_humana, com a via (emissor ou cliente), o revisor, o protocolo e o instante; o revisor da Hummand passa a ser identificado pelo hash do recibo em que provou a presença. A revisão decide o ato, não a presença: a garantia de presença viva é sempre o veredito do componente, e uma revisão não aprova um ato em que o componente negou a presença. Na revisão 2, cada garantia diz quem a sustenta (componente, revisão humana, declaração do cliente, base oficial ou mandato), e nenhuma garantia biométrica é sustentada por revisão.
5. Resultado e recibo. O nível registrado é o efetivamente atingido, não o pedido. Na revisão 2, o recibo traz os dois, o nível exigido pela política e o atingido, e a versão e o hash da política aplicada. O recibo é montado, assinado e entra na cadeia do cliente.

Outros níveis mudam as etapas: o nível 1 usa passkey, o nível 3 acrescenta identidade civil por uma fonte oficial (em credenciamento), e o nível 0 é a ação de um agente sob mandato, sem pessoa nova. O recibo diz qual foi o nível e quais etapas houve. Na revisão 2, cada etapa diz também se o instante foi medido ou herdado do fim do ato (medido).

3. O que garante que o recibo não foi alterado

• Forma canônica. Antes de assinar, o recibo é escrito na forma canônica da RFC 8785 (chaves em ordem, sem espaços, só números inteiros). Qualquer pessoa reproduz os mesmos bytes a partir do arquivo.
• Assinatura. ECDSA sobre a curva P-256 com SHA-256 (ES256). A chave privada fica num módulo de chaves gerenciado, de onde não sai; a pública é publicada em gateway.hummand.com.br/.well-known/humanproof/keys.json. Alterar um único caractere do recibo faz a assinatura falhar.
  • Na revisão 1, há uma assinatura, sobre a forma canônica do recibo sem o campo assinatura; os campos kid (qual chave) e alg (qual algoritmo) ficam dentro do que é assinado.
  • Na revisão 2, há uma lista assinaturas, uma por papel, e a do papel emissor é obrigatória. Cada uma assina a forma canônica de { "recibo": <o recibo sem assinaturas>, "assinatura": { "papel", "kid", "alg" } }, de modo que papel, chave e algoritmo ficam cobertos pela própria assinatura. O formato admite validade por chave no JWKS, e a chave precisa estar válida no instante ts_emitido; a chave atual não tem prazo declarado.
• Cadeia. Cada recibo traz em prev_hash o hash do recibo anterior do mesmo cliente, e o primeiro aponta para um gênesis derivado do identificador do cliente. Um lote de recibos reconstrói a ordem e acusa buraco no meio, inserção, troca de ordem e bifurcação. Uma cadeia pode ter recibos das duas revisões. A cadeia sozinha não acusa o corte do fim (seção 8).
• Ponto de conferência. Uma afirmação assinada, com a mesma chave, de quantos recibos o cliente tinha num instante e qual era o último. Só serve se foi guardado por quem audita antes da conferência. Na revisão 2, cada ponto traz o hash do ponto anterior do mesmo cliente, e um ponto suprimido do meio fica visível para quem guardou os vizinhos.
• Carimbo do tempo. A cadeia pode ser ancorada num carimbo do tempo RFC 3161 de uma Autoridade de Carimbo do Tempo da ICP-Brasil, terceiro que atesta que o recibo ou o ponto já existia numa data. O formato e o verificador estão prontos; em produção, a ancoragem ainda não está ativa. A lista pública das ancoragens existe e fica vazia até lá. Quando o dossiê traz o arquivo ancoragem.json, ela existe para aquele recibo; quando não traz, a data do recibo é a afirmada pela Hummand.
• Acessos. Cada abertura da evidência de um ato, inclusive a de quem recebe um dossiê por link compartilhado, gera um recibo de acesso humanproof-acesso/1, assinado e numa cadeia própria. O motivo declarado vai só como hash.

4. Como conferir

Há três caminhos, do mais simples ao mais independente. Todos dão o mesmo resultado para o mesmo recibo.

A. No navegador. Abra labs.hummand.com.br/verificar e arraste o .zip do dossiê ou do pacote do auditor, ou cole o recibo. A conferência roda inteira no navegador; nada é enviado. A página busca a chave publicada pela Hummand e confere assinatura, formato, coerência e cadeia, nas duas revisões. O “Relatório completo” mostra cada recibo campo a campo (na revisão 2, também as fontes com ambiente e certificação, o compromisso da referência com o sal, os participantes e as assinaturas por papel), a impressão digital de cada chave e o SHA-256 do lote conferido, e se imprime para juntar ao laudo.

B. Pela linha de comando. O verificador humanproof-verify é um binário que não abre rede: lê o recibo e a chave de arquivos e confere o mesmo que a página. É fornecido aos clientes com checksum; o perito pode pedi-lo ao cliente ou à Hummand. Ele também confere um lote contra um ponto guardado e gera um relatório em HTML para imprimir.

C. Sem nenhum código da Hummand. Para conferir a assinatura com ferramentas próprias, num recibo da revisão 1:

1. Obtenha a chave pública no endereço acima e escolha a que tem o kid do recibo.
2. Retire do recibo o campo assinatura.
3. Escreva o restante na forma canônica da RFC 8785.
4. Decodifique a assinatura de base64url: são 64 bytes, r seguido de s.
5. Confira a assinatura ECDSA P-256 com SHA-256 sobre os bytes UTF-8 da forma canônica, com as coordenadas x e y da chave.
6. O hash do recibo é o SHA-256 da forma canônica do recibo inteiro, com a assinatura. É esse valor que o recibo seguinte da cadeia traz em prev_hash e que o dossiê declara.

Num recibo da revisão 2, os passos 2 a 5 se repetem para cada item de assinaturas: retire do recibo o campo assinaturas, monte { "recibo": <o restante>, "assinatura": { "papel", "kid", "alg" } } com os valores daquele item, escreva na forma canônica e confira o valor do item com a chave do kid dele. Confira também que há uma assinatura do papel emissor. O passo 6 é o mesmo.

O arquivo conferir.mjs faz esses passos, nas duas revisões, em menos de quarenta linhas de JavaScript, para Node 18 ou mais novo, sem dependências:

node conferir.mjs recibo.json keys.json
assinatura (emissor): confere
hash do recibo: sha256:…
recibo anterior (prev_hash): sha256:…

Num recibo da revisão 1, a primeira linha sai como assinatura: confere.

Ele serve para recibos legítimos e não substitui o verificador: não valida o formato, não recusa um arquivo com campo repetido nem números fora da forma permitida, e não confere a cadeia. Também não confere a validade nem o estado da chave no instante da emissão, não exige a assinatura do papel emissor e só lê chaves ES256, que é o algoritmo da Hummand: uma chave EdDSA, que o formato admite, ele não lê. Para testar qualquer implementação própria, a especificação traz vetores de teste com o resultado esperado de cada um.

5. O que cada hash permite conferir

Nas duas revisões:

Campo	Como é calculado	Quem consegue reproduzir
Hash do recibo	SHA-256 da forma canônica do recibo inteiro	Qualquer pessoa
prev_hash	O hash do recibo anterior do mesmo cliente	Qualquer pessoa com o recibo anterior
sujeito.referencia.hash	SHA-256 dos bytes da foto de referência que o cliente enviou	O cliente, com o arquivo original da foto
contexto.hash	SHA-256 da forma canônica (RFC 8785) do contexto que o cliente enviou	O cliente, com o contexto original

Só na revisão 1:

Campo	Como é calculado	Quem consegue reproduzir
sujeito.ref_cliente_hash	HMAC-SHA256 da referência interna do cliente, com um segredo do cliente guardado pela Hummand	A Hummand, mediante pedido; ninguém mais
consentimentos[].texto_hash	SHA-256 de um identificador do consentimento (finalidade, escopo e versão), não do texto	A Hummand, mediante pedido; o texto de cada versão é pedido à Hummand ou ao cliente
motivo_hash (acessos)	SHA-256 do motivo declarado, na forma canônica de texto JSON: entre aspas, como em "conferir"	Quem tem o texto do motivo, em geral o cliente

Só na revisão 2:

Campo	Como é calculado	Quem consegue reproduzir
sujeito.ref_compromisso, com ref_sal	HMAC-SHA256, com a chave de referência do cliente, sobre o sal do recibo seguido da referência interna	O cliente, com a chave de referência e a referência
participantes[].ref_compromisso, mandato.concessao.mandatario.ref_compromisso	Como o anterior, com o sal que vem ao lado de cada um	O cliente, com a chave de referência e a referência
consentimentos[].texto_hash	SHA-256 da forma canônica do texto que a pessoa viu	Qualquer pessoa, com o texto publicado
politica.hash	Hash da política aplicada ao tipo de ato, na versão registrada ao lado	A Hummand, mediante pedido
evidencia_tecnica.politica_de_limiar.hash	Hash da política de comparação, que não é publicada	A Hummand
ingredientes[].hash do documento anexo	SHA-256 do documento, declarado pelo cliente	O cliente, com o documento
participantes[].presenca_recibo_hash, mandato.uso.mandato_recibo_hash	O hash de outro recibo: a presença de um participante, a concessão do mandato	Qualquer pessoa com o outro recibo
motivo_hash (acessos)	SHA-256 da forma canônica de { "motivo": <texto>, "sal": <motivo_sal> }, com o sal no próprio recibo	Quem tem o texto do motivo
ato_recibo_hash, componentes[].conteudo_hash (acessos)	O hash do recibo do ato aberto e o do que foi entregue	Quem tem o recibo do ato ou o conteúdo entregue

Na revisão 1, o ref_cliente_hash usa segredo porque o hash simples de um CPF se reverte por tentativa, e ligar um recibo a uma pessoa determinada pede a foto de referência original, cujo hash qualquer um confere, ou a confirmação da Hummand sobre a referência interna. Na revisão 2, isso não depende da Hummand: o cliente, com a chave de referência, recalcula o compromisso a partir da referência e confere. Sem a chave, o compromisso não liga dois recibos da mesma pessoa, porque o sal muda; o hash da foto de referência, quando presente, é igual em recibos que usaram a mesma foto.

6. Perguntas frequentes da perícia

O recibo foi alterado depois de emitido? A assinatura responde. Se confere com a chave publicada, nenhum caractere do recibo mudou desde a assinatura.

Quando o ato aconteceu? Os instantes de criação, de cada etapa e de conclusão estão no recibo e são cobertos pela assinatura, mas são afirmados pela Hummand. Na revisão 2, o recibo traz também ts_emitido, o instante da assinatura, e diz de cada etapa se o instante foi medido. Uma data atestada por terceiro existe quando há prova de ancoragem para o recibo.

A Hummand poderia ter fabricado ou refeito o recibo? Quem tem a chave privada pode assinar. O que limita uma reescrita é externo à Hummand: um ponto de conferência guardado antes por quem audita, o pacote que o cliente recebeu na época e, quando ativa, a ancoragem em carimbo do tempo. Sem nenhum desses, a existência do recibo naquela data depende da palavra da Hummand, e o laudo deve dizê-lo.

Havia uma pessoa viva? O recibo traz humano_vivo e identifica o componente que decidiu; na revisão 2, também o fornecedor, o ambiente e a certificação do componente. É o veredito de um componente de terceiro, com limiar; não é certeza.

Era a pessoa certa? O recibo afirma mesma_pessoa_da_referencia: a pessoa era a mesma da foto que o cliente enviou. Não prova que a foto era da pessoa certa; isso é do cliente. Quem é a pessoa no registro civil só está afirmado se identidade_civil for verdadeiro.

A pessoa consentiu? O recibo traz cada consentimento aceito, com a versão do texto e o instante. Na revisão 1, o texto daquela versão se pede ao cliente ou à Hummand. Na revisão 2, o texto está publicado, e o hash no recibo confere com ele.

Alguém mexeu na evidência? Os recibos de acesso registram cada abertura pelo caminho oficial, com quem abriu (por papel e identificador opaco), o desfecho e o instante.

Faltam recibos? Num lote, a cadeia acusa buraco no meio. Para o fim, compare com um ponto de conferência guardado antes.

7. O que pedir, e a quem

• Ao cliente: o pacote do dossiê ou do auditor como foi gerado na época; a foto de referência original, para conferir o hash; o contexto original do ato, se houver; pontos de conferência que ele tenha guardado; o texto dos consentimentos nas versões que aparecem num recibo da revisão 1; num recibo da revisão 2, a conferência do ref_compromisso com a chave de referência dele.
• À Hummand, pelo contato em hummand.com.br/contato: o verificador de linha de comando, o texto dos consentimentos por versão, a confirmação de um ref_cliente_hash da revisão 1 e esclarecimentos sobre esta nota.

8. Limites

• O recibo afirma o que as fontes declaradas sustentam, e nada além. Não estima risco nem probabilidade e não substitui o processo do cliente.
• A comparação com a referência não prova que a referência é legítima.
• A cadeia isolada não acusa o corte do fim. Só um ponto guardado antes, ou a ancoragem quando estiver ativa, acusa.
• Um ato que nunca virou recibo não aparece em cadeia nenhuma.
• O recibo de acesso cobre a abertura pelo caminho oficial; acesso por fora dele não gera recibo.
• Coerência é ausência de contradição interna, não confirmação externa.
• Eventos marcados como “Registro do sistema” no dossiê não estão assinados.
• Esta nota descreve o mecanismo técnico. O enquadramento jurídico da prova não é objeto dela.

9. Referências

• Especificação dos formatos, versão 2.1: labs.hummand.com.br/especificacao, com os schemas e os vetores de teste das duas revisões.
• Nota “O formato humanproof/1”: labs.hummand.com.br/notas/o-formato-humanproof-1.
• RFC 8785 (JSON Canonicalization Scheme), FIPS 186-5 (ECDSA), RFC 7518 (ES256), RFC 7517 (JWK), RFC 2104 (HMAC), RFC 3161 (carimbo do tempo), RFC 5652 (CMS), RFC 6962 (árvore de Merkle), RFC 7638 (impressão digital da chave).

10. Versões

• 1.2, de 2026-10-30: a revisão 2 do recibo, emitida desde 2026-10-30T05:21:39Z. A seção 1 diz como identificar a revisão; a 2 descreve o que a revisão 2 registra do consentimento, das fontes (com o componente da AWS certificado pela iBeta), da política de comparação, da revisão humana e do nível; a 3, as assinaturas por papel, a validade por chave, o ponto encadeado e a lista das ancoragens, ainda vazia; a 4, a conferência da revisão 2 e três limites do conferir.mjs que esta nota não declarava; a 5 separa os hashes por revisão; a 6 corrige a frase que dizia que o recibo traz a versão do componente; a 7 e a 9 apontam a especificação 2.1.
• 1.1, de 2026-10-29: a seção 2 dizia que a versão do componente estava no recibo; a versão registrada é a do software da Hummand. O passo da revisão passa a descrever as duas vias, a da Hummand e a do cliente, e a regra de que a revisão não muda a garantia de presença viva, corrigida no emissor no mesmo dia.
• 1.0, de 2026-10-29: primeira versão.