Presença viva e match são nativas. O resto é plugado pela mesma interface, com rótulo honesto e registro no recibo.
hummand.presenca, hummand.match e passkey disponíveis; Serpro em credenciamento; as demais com adapter e mock, em arquitetura-alvo.
Fontes · o que cada etapa consulta
Nativa ou plugada, rotulada.
Cada etapa da política consulta uma fonte pela mesma interface: entra um pedido, sai um resumo sem dado pessoal; o sensível fica cifrado e o transiente é descartado. Toda fonte tem adapter com contrato real e mock com as personas dos cenários de aceitação; a real entra quando o credenciamento ou o cliente chegar. O recibo registra a fonte, o componente e a versão.Fonte é de onde vem cada confirmação: a verificação de presença da própria Hummand ou um serviço externo, como a base civil. Mock é a versão de teste de uma fonte, que responde como a real sem consultá-la.
Categoria
ProdutoFontes
Duas nativas, nove plugadas.
N
Nativas
hummand.presencadisponível
Há um humano vivo agora? Desafio ativo por um componente da AWS certificado pela iBeta (PAD, ISO/IEC 30107-3); o recibo registra o componente e o veredito
Etapa: presença viva
Adapter real e mock
hummand.matchdisponível
É a mesma pessoa da referência que o cliente deu? Comparação transiente com a imagem de referência
Retenção: imagem capturada e template descartados; a referência do cliente fica cifrada só enquanto o ato está aberto; depois, fica o hash
Etapa: presença viva, junto com a presença
I
Identidade civil
serpro.datavalidem credenciamento
CPF, dados cadastrais e biometria facial contra a base governamental (CNH, CIN)
Etapa: identidade civil, o nível 3
Adapter real e mock; a resposta é minimizada e o bruto nunca sai. Protocolo de credenciamento em andamento no Serpro, no prazo deles
Consultas: identidade e gatilho de prova de exceção
Mesmo contrato do Datavalid
F
Federação e posse
govbr.oidcarquitetura-alvo
Cidadão autenticado no gov.br, com o nível da conta: bronze, prata ou ouro
Etapa: conta federada
Entra puxada por cliente público
passkeydisponível
Posse do aparelho, com verificação do usuário nele (WebAuthn); nada biométrico chega à Hummand
Cadastrada só depois de uma presença aprovada; o recibo sai no nível 1
Etapa: passkey
dispositivo.atestacaoarquitetura-alvo
App e dispositivo íntegros (Play Integrity, App Attest); exige app nativo do cliente
Etapa: passkey, como posse
A
Assinatura e documento
icp.brasilarquitetura-alvo
Assinatura qualificada (A1, A3, e-CPF): a Hummand valida a cadeia e anexa ao recibo
Etapa: assinatura jurídica; a assinatura gov.br entra pela mesma etapa
ocr.documentoarquitetura-alvo
Dados e foto do documento (CNH, RG, CIN, passaporte); a foto vira referência transiente para o match
Etapa: documento anexo; o hash vai no recibo
V
Estado vital
crcarquitetura-alvo
Certidões de óbito, casamento e nascimento (CRC Nacional, convênio Arpen)
Consultas: certidão e gatilho de prova de exceção
Restrita: só com convênio
sisobiarquitetura-alvo
Óbitos informados por cartórios (INSS)
Consulta: gatilho de prova de exceção
Restrita: só órgão público
Fontes
Fora por escolha
Bureaus, score de fraude, fingerprint de dispositivo, listas PEP e sanções, geolocalização ou comportamento como prova, estimativa de idade por rosto: não são fontes. SMS é só o canal de entrega do link.
Nenhuma fonte real entra antes de um cliente que a puxe. Até lá o adapter existe, tem contrato e responde pelas personas dos cenários de aceitação; em produção, uma fonte que só existe em mock responde como indisponível.
Por onde começar
hummand.presenca · hummand.match
Presença viva e match
Disponívelnativas, em produção
Traços
P
Pergunta
há um humano vivo agora, e é a mesma pessoa da referência?
C
Componente
detecção de vivacidade por componente da AWS certificado pela iBeta, declarado no recibo
R
Retenção
nenhuma depois do ato: a referência fica cifrada enquanto o ato está aberto; depois, só o hash