Changelog

O cliente da API e a verificação offline acompanham o recibo de hoje, sem deixar de ler o de antes.

Com o núcleo 0.9.2, a verificação offline lê as duas revisões do recibo: assinaturas por papel, validade da chave quando o JWKS a declara e compromisso da referência. Recibos da revisão 1 seguem as regras de antes.

O estado do mandato pelo hash do recibo da concessão, e o executor de referência revoga pelo hash que o mandato.revogado passa a trazer. No PyPI, sob Apache-2.0.

A mesma ferramenta, offline, agora com as regras da revisão 2.

Com o núcleo 0.9.2, lê a revisão 2 do recibo do ato, do recibo de acesso, do ponto e da ancoragem: assinaturas por papel, validade da chave no JWKS e compromisso da referência. Recibo da revisão 1 concluído depois do corte é recusado; os de antes seguem as regras de sempre.

A linha de cada recibo diz a revisão quando ele a traz. Binários para Linux, macOS e Windows, com checksums.

Na revisão 2, o uso e a revogação apontam o mandato pelo hash; a API e o webhook passam a falar a mesma língua.

GET /v1/mandatos/por-recibo/{recibo_hash} devolve o estado do mandato pelo hash do recibo da concessão, com o mesmo corpo da consulta pelo id. O evento mandato.revogado passa a levar mandato_recibo_hash, nulo enquanto o recibo da concessão não foi emitido.

O recibo que fecha a dupla aprovação passa a dizer quem foram os dois operadores.

Núcleo 0.9.2. O recibo que fecha a dupla aprovação lista os dois operadores, com compromissos que mostram pessoas distintas, e aponta pelo hash a presença do primeiro. Recibo da revisão 1 concluído depois do corte não é emitido. O tipo operador.dupla segue arquitetura-alvo. Sem migração e sem variável nova.

A revisão 1 segue verificada como antes, com todos os vetores intactos.

O núcleo verifica e emite a revisão 2 do recibo do ato, do recibo de acesso, do ponto de conferência e da prova de ancoragem: assinaturas por papel, validade da chave no JWKS, compromisso da referência com sal, consentimento pelo hash do texto e garantias com quem as sustenta. Vetores da revisão 2 no índice público.

A 0.9.1 fixa a data de corte, 2026-10-30T05:21:39Z: recibo do ato sem revisao concluído depois dela é recusado. A 0.9.2 corrige a regra da dupla aprovação. No PyPI, e a especificação pública dos formatos passa à versão 2.0.

Desde 2026-10-30T05:21:39Z, cada garantia do recibo diz quem a sustenta.

O recibo sai com revisao: 2: nível exigido e atingido, hash da política, garantias com quem as sustenta, revisão humana que decide o ato e nunca a presença, assinaturas por papel e consentimento pelo hash do próprio texto exibido, publicado em /consentimentos. Recibos concluídos antes seguem a revisão 1 e verificam como antes.

A referência da pessoa entra como compromisso com a chave de referência do cliente e um sal por recibo; o Administrador vê a chave no painel, depois da passkey ou da senha, e cada exibição vai para a trilha de auditoria.

O ponto de conferência passa a apontar o anterior, e as ancoragens se encadeiam; a lista pública das cabeças fica vazia enquanto a ancoragem está desligada, até o contrato com a autoridade.

A revisão humana não aprova o que a presença negou.

A revisão, pela API ou pela fila da Hummand, não aprova ato com a presença negada pelo componente nem com as tentativas esgotadas. humano_vivo passa a ser sempre o veredito do componente, e a revisão feita pela API entra no recibo com a chave que decidiu.

O JWKS publica também as chaves aposentadas, para que recibos antigos continuem conferindo depois de uma troca.

O agente que fala MCP pede o mandato e confere a ação com recibo, com uma chave que não alcança mais nada.

Uma chave de API pode ser restrita a tipos de ato: cria só os que nomeia, e qualquer outro é recusado antes de qualquer efeito, assim como as demais operações de escrita. O painel tem um atalho que emite a chave do servidor MCP de mandato assim.

O SDK Python, hummand 0.4.0, e o núcleo do recibo, humanproof-core 0.8.1, estão no PyPI sob Apache-2.0. Com hummand[mcp], o servidor MCP de mandato dá ao agente três ferramentas: pedir o mandato, conferir se a ação cabe nele, com o recibo assinado inclusive na recusa, e consultá-lo. Nenhuma revoga.

O servidor avisa o agente; quem garante é o sistema que executa a ação, conferindo o recibo antes de agir. Testado de ponta a ponta em produção, com jornada real no celular.

A data de cada recibo passa a poder ser atestada por um terceiro que não é a Hummand. Versão de 2026-10-20, no ar desde 2026-10-24; a ancoragem fica desligada até o contrato com a autoridade.

Uma vez por dia, o ponto de conferência de cada cliente e cada recibo emitido, pelo hash, entram numa árvore cuja raiz recebe um carimbo do tempo de uma Autoridade de Carimbo do Tempo. Cada folha tem a sua prova, conferida antes de gravar; a autoridade recebe só a raiz, sem dado pessoal.

O dossiê leva a prova do recibo do ato, e quem recebe um dossiê compartilhado confere a ancoragem só com aquele recibo. O verificador em labs confere a prova com as raízes da ICP-Brasil embutidas, e a especificação pública passa à versão 1.3.

Em credenciamento: a ancoragem fica desligada até o contrato com uma autoridade credenciada na ICP-Brasil, e nenhuma prova foi emitida ainda.

Quem precisa acreditar na prova abre o dossiê do ato sem conta, e cada abertura vira um recibo.

O cliente gera, no dossiê de um ato terminado, um link com prazo para um destinatário e uma finalidade declarados; o link aparece uma única vez, e a Hummand guarda só o hash dele. A lista mostra quantas vezes cada link foi aberto, e o link pode ser revogado.

Quem recebe vê primeiro só o cabeçalho, que não gera recibo, porque a pré-visualização de mensageiro também abre links. Ao abrir o dossiê, sem a referência interna do cliente, a abertura é assinada como recibo de acesso de terceiro e aparece na linha do tempo do ato. Link revogado ou vencido deixa a tentativa registrada como negada.

No mesmo dia, o verificador em labs passou a conferir o pacote inteiro exportado do painel, e a especificação dos formatos ficou pública, com vetores de teste.