Technical note for forensic experts: the Hummand receipt and dossier

1. What an act is and what remains of it

An act is a proof request that an organisation using Hummand makes to a person: to be present and be the same person as a reference photo, to authorise an action, to grant a mandate. The person completes the steps on their own phone, through an individual link. When the act ends, with any result (positive, negative, expired, cancelled, technical failure or revocation), Hummand issues a signed humanproof/1 receipt.

The receipt has two revisions. Since 2026-10-30T05:21:39Z (the cut-off date), Hummand issues revision 2, marked in the receipt by the member "revisao": 2. Receipts concluded up to the cut-off are revision 1, do not have that member and remain checkable with the earlier rules. A receipt without the mark concluded after the cut-off is rejected. The expert identifies the revision by the member; where the two differ, this note says which is which.

From the act, the expert may receive three things:

• The receipt, a signed JSON file. It is the piece that is checked without Hummand.
• The act dossier, printed, as PDF, in a .zip package or opened through a shared link. It brings together the receipt, the timeline, the consents and the accesses. In the timeline, each event carries its source: Signed (it is in the receipt and can be checked), Timestamp (attested by a Time Stamping Authority) or System record (an operational note by Hummand, worth the word of whoever keeps the record).
• The auditor package of a campaign or cycle: the list of acts as CSV, the receipts of a continuous stretch of the chain, the public key and, when there is one, the checkpoint.

None of these files contains an image, video, template or other biometric data. The person appears only through hashes and through the reference the customer uses internally, when the customer includes it in the list.

2. How the evidence is produced

In a presence act (level 2, the most common), the steps are these, each with its time recorded in the receipt:

1. Context and consent. The person sees what the proof is for and accepts the terms: the general consent and, separately, the biometric one. The receipt records each acceptance with the text version and the time. In revision 2, it also records the layer (geral, biometrico or escopo), the language and the hash of the very text the person saw; the texts are published, with version and hash, at hummand.com.br/en/consentimentos.
2. Live presence. An AWS component certified by iBeta under ISO/IEC 30107-3 decides whether a living person is in front of the camera. The decision is probabilistic, with the component’s threshold; the receipt records the verdict, not a score. In revision 1, the receipt identifies the component under fontes, and the version recorded there is that of the Hummand software that called it, not that of the component. In revision 2, fontes separates the vendor, the component, the component version (which may come as nao_informada), the Hummand software version (versao_adaptador), the environment (producao or homologacao) and, when there is one, the component’s certification, with scheme, laboratory, report and date.
3. Comparison with the reference. The captured face is compared with the reference photo the customer sent. The threshold is set by Hummand and is not published. The receipt records the verdict and the hash of the reference photo. In revision 2, the comparison policy appears by identifier and hash (evidencia_tecnica.politica_de_limiar), without its values.
4. Human review. An inconclusive case does not become a result on its own: it goes to review, either by Hummand, where the reviewer proves their own presence before deciding, or by the customer, through the integration. In revision 1, the receipt carries revisado_por: the id of the act in which the Hummand reviewer proved presence, or apikey: followed by the id of the customer’s key. In revision 2, it carries revisao_humana, with the path (emissor or cliente), the reviewer, the protocol and the time; the Hummand reviewer is now identified by the hash of the receipt in which they proved presence. The review decides the act, not presence: the live-presence guarantee is always the component’s verdict, and a review does not approve an act in which the component denied presence. In revision 2, each guarantee says who backs it (component, human review, customer’s statement, official registry or mandate), and no biometric guarantee is backed by a review.
5. Result and receipt. The recorded level is the one actually reached, not the one requested. In revision 2, the receipt carries both, the level the policy required and the level reached, and the version and hash of the policy applied. The receipt is built, signed and enters the customer’s chain.

Other levels change the steps: level 1 uses a passkey, level 3 adds civil identity through an official source (in accreditation), and level 0 is an agent’s action under a mandate, with no new person. The receipt states the level and the steps that took place. In revision 2, each step also says whether its time was measured or inherited from the end of the act (medido).

3. What ensures the receipt was not altered

• Canonical form. Before signing, the receipt is written in the canonical form of RFC 8785 (keys in order, no spaces, integers only). Anyone reproduces the same bytes from the file.
• Signature. ECDSA over the P-256 curve with SHA-256 (ES256). The private key stays in a managed key module it never leaves; the public key is published at gateway.hummand.com.br/.well-known/humanproof/keys.json. Changing a single character of the receipt makes the signature fail.
  • In revision 1, there is one signature, over the canonical form of the receipt without the assinatura field; the kid (which key) and alg (which algorithm) fields are inside what is signed.
  • In revision 2, there is a list assinaturas, one per role, and the one with the emissor role is mandatory. Each signs the canonical form of { "recibo": <the receipt without assinaturas>, "assinatura": { "papel", "kid", "alg" } }, so that role, key and algorithm are covered by the signature itself. The format allows per-key validity in the JWKS, and the key must be valid at the time ts_emitido; the current key has no declared term.
• Chain. Each receipt carries in prev_hash the hash of the same customer’s previous receipt, and the first points to a genesis derived from the customer’s identifier. A batch of receipts rebuilds the order and reveals a gap in the middle, insertion, reordering and forking. A chain may hold receipts of both revisions. The chain alone does not reveal a cut at the end (section 8).
• Checkpoint. A signed statement, with the same key, of how many receipts the customer had at a moment and which was the last. It only helps if whoever audits stored it before the check. In revision 2, each checkpoint carries the hash of the same customer’s previous checkpoint, and a checkpoint suppressed from the middle becomes visible to whoever kept its neighbours.
• Timestamp. The chain can be anchored in an RFC 3161 timestamp from an ICP-Brasil Time Stamping Authority, a third party that attests that the receipt or checkpoint already existed on a date. The format and the verifier are ready; in production, anchoring is not active yet. The public list of anchorings exists and stays empty until then. When the dossier carries the file ancoragem.json, there is anchoring for that receipt; when it does not, the receipt’s date is the one stated by Hummand.
• Accesses. Each opening of an act’s evidence, including by someone who receives a dossier through a shared link, produces a humanproof-acesso/1 access receipt, signed and in a chain of its own. The stated reason goes only as a hash.

4. How to check

There are three paths, from the simplest to the most independent. All give the same result for the same receipt.

A. In the browser. Open labs.hummand.com.br/en/verificar and drop the dossier or auditor package .zip, or paste the receipt. The check runs entirely in the browser; nothing is sent. The page fetches the key published by Hummand and checks signature, format, coherence and chain, in both revisions. The “Full report” shows each receipt field by field (in revision 2, also the sources with environment and certification, the reference commitment with its salt, the participants and the signatures per role), the fingerprint of each key and the SHA-256 of the verified batch, and prints to attach to the expert report.

B. On the command line. The humanproof-verify verifier is a binary that opens no network connection: it reads the receipt and the key from files and checks the same as the page. It is supplied to customers with a checksum; the expert can ask the customer or Hummand for it. It also checks a batch against a stored checkpoint and produces an HTML report to print.

C. Without any Hummand code. To check the signature with your own tools, on a revision 1 receipt:

1. Get the public key at the address above and pick the one with the receipt’s kid.
2. Remove the assinatura field from the receipt.
3. Write the rest in the canonical form of RFC 8785.
4. Decode the assinatura from base64url: 64 bytes, r followed by s.
5. Check the ECDSA P-256 signature with SHA-256 over the UTF-8 bytes of the canonical form, with the key’s x and y coordinates.
6. The receipt hash is the SHA-256 of the canonical form of the whole receipt, signature included. It is the value the next receipt in the chain carries in prev_hash and that the dossier states.

On a revision 2 receipt, steps 2 to 5 repeat for each item of assinaturas: remove the assinaturas field from the receipt, build { "recibo": <the rest>, "assinatura": { "papel", "kid", "alg" } } with that item’s values, write it in canonical form and check the item’s valor with the key of its kid. Check also that there is a signature with the emissor role. Step 6 is the same.

The file conferir.mjs does these steps, in both revisions, in under forty lines of JavaScript, for Node 18 or later, with no dependencies:

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

On a revision 1 receipt, the first line comes out as assinatura: confere.

It is meant for legitimate receipts and does not replace the verifier: it does not validate the format, does not reject a file with a repeated field or numbers outside the allowed form, and does not check the chain. It also does not check the key’s validity or state at issuance, does not require the signature with the emissor role and only reads ES256 keys, which is Hummand’s algorithm: an EdDSA key, which the format allows, it does not read. To test any implementation of your own, the specification carries test vectors with the expected result of each.

5. What each hash lets you check

In both revisions:

Field	How it is computed	Who can reproduce it
Receipt hash	SHA-256 of the canonical form of the whole receipt	Anyone
prev_hash	The hash of the same customer’s previous receipt	Anyone with the previous receipt
sujeito.referencia.hash	SHA-256 of the bytes of the reference photo the customer sent	The customer, with the original photo file
contexto.hash	SHA-256 of the canonical form (RFC 8785) of the context the customer sent	The customer, with the original context

Only in revision 1:

Field	How it is computed	Who can reproduce it
sujeito.ref_cliente_hash	HMAC-SHA256 of the customer’s internal reference, with a customer secret kept by Hummand	Hummand, on request; no one else
consentimentos[].texto_hash	SHA-256 of an identifier of the consent (purpose, scope and version), not of the text	Hummand, on request; the text of each version is requested from Hummand or the customer
motivo_hash (accesses)	SHA-256 of the stated reason, in the canonical form of a JSON string: in quotes, as in "conferir"	Whoever has the reason’s text, usually the customer

Only in revision 2:

Field	How it is computed	Who can reproduce it
sujeito.ref_compromisso, with ref_sal	HMAC-SHA256, with the customer’s reference key, over the receipt’s salt followed by the internal reference	The customer, with the reference key and the reference
participantes[].ref_compromisso, mandato.concessao.mandatario.ref_compromisso	As above, with the salt that comes next to each one	The customer, with the reference key and the reference
consentimentos[].texto_hash	SHA-256 of the canonical form of the text the person saw	Anyone, with the published text
politica.hash	Hash of the policy applied to the act type, in the version recorded next to it	Hummand, on request
evidencia_tecnica.politica_de_limiar.hash	Hash of the comparison policy, which is not published	Hummand
ingredientes[].hash of the attached document	SHA-256 of the document, declared by the customer	The customer, with the document
participantes[].presenca_recibo_hash, mandato.uso.mandato_recibo_hash	The hash of another receipt: a participant’s presence, the mandate grant	Anyone with the other receipt
motivo_hash (accesses)	SHA-256 of the canonical form of { "motivo": <text>, "sal": <motivo_sal> }, with the salt in the receipt itself	Whoever has the reason’s text
ato_recibo_hash, componentes[].conteudo_hash (accesses)	The hash of the opened act’s receipt and that of what was delivered	Whoever has the act receipt or the delivered content

In revision 1, ref_cliente_hash uses a secret because the plain hash of a national ID number can be reversed by trial, and tying a receipt to a specific person takes the original reference photo, whose hash anyone can check, or Hummand’s confirmation of the internal reference. In revision 2, this does not depend on Hummand: the customer, with the reference key, recomputes the commitment from the reference and checks it. Without the key, the commitment does not link two receipts of the same person, because the salt changes; the reference photo hash, when present, is the same in receipts that used the same photo.

6. Common expert questions

Was the receipt altered after it was issued? The signature answers. If it verifies against the published key, no character of the receipt has changed since it was signed.

When did the act happen? The times of creation, of each step and of conclusion are in the receipt and covered by the signature, but they are stated by Hummand. In revision 2, the receipt also carries ts_emitido, the time of signing, and says for each step whether its time was measured. A date attested by a third party exists when there is an anchoring proof for the receipt.

Could Hummand have fabricated or redone the receipt? Whoever holds the private key can sign. What limits a rewrite is outside Hummand: a checkpoint stored earlier by whoever audits, the package the customer received at the time and, when active, anchoring in a timestamp. Without any of these, the receipt’s existence on that date rests on Hummand’s word, and the expert report should say so.

Was there a living person? The receipt carries humano_vivo and identifies the component that decided; in revision 2, also the vendor, the environment and the component’s certification. It is the verdict of a third-party component, with a threshold; it is not certainty.

Was it the right person? The receipt states mesma_pessoa_da_referencia: the person was the same as in the photo the customer sent. It does not prove the photo was of the right person; that is the customer’s responsibility. Who the person is in the civil registry is only stated if identidade_civil is true.

Did the person consent? The receipt carries each accepted consent, with the text version and the time. In revision 1, the text of that version is requested from the customer or Hummand. In revision 2, the text is published, and the hash in the receipt checks against it.

Did anyone touch the evidence? Access receipts record each opening through the official path, with who opened it (by role and opaque identifier), the outcome and the time.

Are receipts missing? In a batch, the chain reveals a gap in the middle. For the end, compare with a checkpoint stored earlier.

7. What to ask for, and from whom

• From the customer: the dossier or auditor package as generated at the time; the original reference photo, to check the hash; the act’s original context, if any; checkpoints they stored; the text of the consents in the versions shown in a revision 1 receipt; on a revision 2 receipt, the check of ref_compromisso with their reference key.
• From Hummand, through the contact at hummand.com.br/en/contato: the command-line verifier, the text of the consents by version, confirmation of a revision 1 ref_cliente_hash and clarification about this note.

8. Limits

• The receipt states what the declared sources support, and nothing more. It does not estimate risk or probability and does not replace the customer’s process.
• The comparison with the reference does not prove the reference is legitimate.
• The chain alone does not reveal a cut at the end. Only a checkpoint stored earlier, or anchoring once it is active, does.
• An act that never became a receipt does not appear in any chain.
• The access receipt covers opening through the official path; access outside it produces no receipt.
• Coherence is the absence of internal contradiction, not external confirmation.
• Events marked “System record” in the dossier are not signed.
• This note describes the technical mechanism. The legal framing of the evidence is not its subject.

9. References

• Format specification, version 2.1: labs.hummand.com.br/en/especificacao, with the schemas and the test vectors of both revisions.
• Note “The humanproof/1 format”: labs.hummand.com.br/en/notas/the-humanproof-1-format.
• RFC 8785 (JSON Canonicalization Scheme), FIPS 186-5 (ECDSA), RFC 7518 (ES256), RFC 7517 (JWK), RFC 2104 (HMAC), RFC 3161 (timestamp), RFC 5652 (CMS), RFC 6962 (Merkle tree), RFC 7638 (key fingerprint).

10. Versions

• 1.2, of 2026-10-30: revision 2 of the receipt, issued since 2026-10-30T05:21:39Z. Section 1 says how to identify the revision; section 2 describes what revision 2 records of the consent, the sources (with the AWS component certified by iBeta), the comparison policy, the human review and the level; section 3, the signatures per role, per-key validity, the chained checkpoint and the list of anchorings, still empty; section 4, checking revision 2 and three limits of conferir.mjs this note did not declare; section 5 splits the hashes by revision; section 6 corrects the sentence that said the receipt carries the component’s version; sections 7 and 9 point to specification 2.1.
• 1.1, of 2026-10-29: section 2 said the component’s version was in the receipt; the version recorded is that of Hummand’s software. The review step now describes both paths, Hummand’s and the customer’s, and the rule that a review does not change the live-presence guarantee, fixed in the issuer on the same day.
• 1.0, of 2026-10-29: first version.