Glossary

What the client asks of a person, with a type and a level.

A catalogue type, a minimum guarantee level and an opaque context. The policy resolves the steps; each step queries a source; when it finishes, the act leaves a receipt. Positive, negative, inconclusive, expired, cancelled or failed.

The type says which question the act answers; the level, how much guarantee.

Twelve types in the catalogue, from recurring presence to signature. Four levels: 0, no new human; 1, strong possession; 2, live presence and same person; 3, presence and civil identity. The receipt carries the level reached, not the one requested.

One stage of the journey, with a fixed id, a result and a timestamp.

Context transparency, general consent, biometric consent, live presence with match and result are the five in production. Each step queries a source and enters the receipt.

Turns type and level into steps; the version goes in the receipt.

Today one global, versioned policy. The per-client policy, with overrides over declared context keys and reuse of a recent act, enters when the second client asks for a different one.

What a step queries, through the same interface, with a label in the receipt.

Live presence and match are native. Civil identity, federated account, possession, signature, document and vital status are plugged: adapter with real contract and mock; the real one enters with accreditation or with the client.

Is there a living human right now, and is it the same person as the reference?

Active challenge by a certified third-party component, and transient comparison with the client's reference image. Image and template are discarded; the result and the hash of the reference remain.

General before everything; biometric before any capture.

Versioned texts; every acceptance records the timestamp, the hash of the text and the version, and the receipt carries them. The general one never unlocks biometrics.

What the act leaves: signed, chained, hashes only.

A JSON object with what happened (type, level, result, steps, sources, guarantees, consents, policy) and everything about the person hashed. Signed with ES256 over the RFC 8785 canonical form; verifiable without Hummand.

Every receipt points to the same client's previous one by hash.

The first one points to a genesis derived from the client id. A batch rebuilds the order from the hashes, in any input order, and exposes removal, insertion and forking.

The key that verifies the receipt, published; the kid says which one.

The private key lives in a managed key module and never leaves it. The public key is published as a JWKS at gateway.hummand.com.br/.well-known/humanproof/keys.json; the kid inside the receipt selects the key, and rotation is by kid.

Checks signature, format, coherence and chain, without Hummand.

The same Rust implementation runs on the server, on the command line (humanproof-verify) and in the browser, in WebAssembly, sending nothing.

A new presence in the middle of a process, because of a sensitive action.

Transaction, registration or operator. The policy may accept a recent positive act and shorten to level 1 with a passkey; recurring presence never reuses.

Two distinct humans approved, each with presence.

Two operator step-ups chained in a group, with the requirement of distinct humans; composite receipt, one per operator, linked by the group.

A human with proven presence authorizes a person or an agent, with scope and deadline.

The mandate leaves a receipt with the scope (actions, limits, validity, revocable). A delegated act is an action under mandate: it checks that the mandate exists, is valid, was not revoked and covers the action; no new presence, level 0.

An act opened by an external trigger, with an escalation policy.

The origin is the client or a vital-status source, on request; the trigger reference enters hashed, never the reason. The default escalates to level 3. The source only triggers; the proof is still the presence.

Every record has its own key; erasing is destroying the key.

The data key of every record is wrapped by the master key in the key module. Destroying it makes the ciphertext unrecoverable: that is erasure on request and by retention period.

Available, in accreditation, target architecture.

Every capability carries one of the three, on every surface: code, docs, site. Available is in production; in accreditation exists in the code and depends on a third party; target architecture exists in the catalogue, the engine or the plan, with no screen, no provider or no phase started.

A tenant is a client; sandbox is the test mode that puts no receipt in the chain.

Every client is a tenant, isolated by row in the database, with scoped API keys and its own secret for the reference hashes. In sandbox the result is simulated and nothing consumes presence or enters the receipt chain.