Glossário

O que o cliente pede a uma pessoa, com tipo e nível.

Um tipo do catálogo, um nível mínimo de garantia e um contexto opaco. A política resolve as etapas; cada etapa consulta uma fonte; ao terminar, o ato deixa um recibo. Positivo, negativo, inconclusivo, expirado, cancelado ou falhou.

O tipo diz que pergunta o ato responde; o nível, quanta garantia.

Doze tipos no catálogo, de presença recorrente a assinatura. Quatro níveis: 0, sem humano novo; 1, posse forte; 2, presença viva e mesma pessoa; 3, presença e identidade civil. O recibo carrega o nível atingido, não o pedido.

Um passo da jornada, com id fixo, resultado e instante.

Transparência do contexto, consentimento geral, consentimento biométrico, presença viva com match e resultado são as cinco em produção. Cada etapa consulta uma fonte e entra no recibo.

Traduz tipo e nível em etapas; a versão vai no recibo.

Hoje uma política global, versionada. A política por cliente, com overrides sobre chaves declaradas do contexto e reutilização de ato recente, entra quando o segundo cliente pedir uma diferente.

O que uma etapa consulta, pela mesma interface, com rótulo no recibo.

Presença viva e match são nativas. Identidade civil, conta federada, posse, assinatura, documento e estado vital são plugadas: adapter com contrato real e mock; a real entra com o credenciamento ou o cliente.

Há um humano vivo agora, e é a mesma pessoa da referência?

Desafio ativo por um componente certificado de terceiro, e comparação transiente com a imagem de referência do cliente. Imagem e template são descartados; ficam o resultado e o hash da referência.

Geral antes de tudo; biométrico antes de qualquer captura.

Textos versionados; cada aceite grava instante, hash do texto e versão, e o recibo os carrega. O geral nunca desbloqueia biometria.

O que o ato deixa: assinado, encadeado, só hashes.

Um objeto JSON com o que aconteceu (tipo, nível, resultado, etapas, fontes, garantias, consentimentos, política) e tudo o que diz respeito à pessoa em hash. Assinado com ES256 sobre o canônico RFC 8785; verificável sem a Hummand.

Cada recibo aponta para o anterior do mesmo cliente por hash.

O primeiro aponta para um gênesis derivado do id do cliente. Um lote reconstrói a ordem pelos hashes, em qualquer ordem de entrada, e denuncia remoção, inserção e bifurcação.

A chave que verifica o recibo, publicada; o kid diz qual.

A chave privada fica num módulo de chaves gerenciado, de onde nunca sai. A pública é publicada como JWKS em gateway.hummand.com.br/.well-known/humanproof/keys.json; o kid dentro do recibo seleciona a chave, e a rotação é por kid.

Confere assinatura, formato, coerência e cadeia, sem a Hummand.

A mesma implementação em Rust roda no servidor, na linha de comando (humanproof-verify) e no navegador, em WebAssembly, sem enviar nada.

Uma presença nova no meio de um processo, por causa de uma ação sensível.

De transação, cadastral ou de operador. A política pode aceitar um ato positivo recente e encurtar para o nível 1 com passkey; a presença recorrente nunca reutiliza.

Dois humanos distintos aprovaram, cada um com presença.

Dois step-ups de operador encadeados num grupo, com a exigência de humanos distintos; recibo composto, um por operador, ligados pelo grupo.

Um humano com presença provada autoriza uma pessoa ou um agente, com escopo e prazo.

O mandato deixa recibo com o escopo (ações, limites, validade, revogável). Um ato delegado é uma ação sob mandato: verifica que ele existe, vale, não foi revogado e cobre a ação; sem presença nova, nível 0.

Um ato aberto por um gatilho externo, com política de escalada.

A origem é o cliente ou uma fonte de estado vital, a pedido; a referência do gatilho entra em hash, nunca o motivo. O default escala ao nível 3. A fonte só dispara; a prova continua sendo a presença.

Cada registro tem a sua chave; apagar é destruir a chave.

A chave de dados de cada registro é embrulhada pela chave-mestra no módulo de chaves. Destruí-la torna o texto cifrado irrecuperável: é o apagamento a pedido e por prazo de retenção.

Disponível, em credenciamento, arquitetura-alvo.

Toda capacidade leva um dos três, em toda superfície: código, docs, site. Disponível está em produção; em credenciamento existe no código e depende de um terceiro; arquitetura-alvo existe no catálogo, no motor ou no plano, sem tela, sem provider ou sem fase iniciada.

Tenant é o cliente; sandbox é o modo de teste que não gera recibo na cadeia.

Cada cliente é um tenant, isolado por linha no banco, com chaves de API por escopo e um segredo próprio para os hashes de referência. Em sandbox o resultado é simulado e nada consome presença nem entra na cadeia de recibos.