hummand.presencaavailable
- Is there a living human right now? Active challenge by an AWS-certified component; the receipt records the component and the version
- Step: live presence
- Real and mock adapter
Hummand presents
Sources
Live presence and match are native. The rest is plugged through the same interface,
with an honest label and a record in the receipt.
hummand.presenca, hummand.match and passkey available; Serpro in accreditation;
the others with adapter and mock, in target architecture.
Sources · what every step queriesNative or plugged,
labelled.
Every policy step queries a source through the same interface: a request goes in, a summary with no personal data comes out; the sensitive part stays encrypted and the transient part is discarded. Every source has an adapter with a real contract and a mock with the personas of the acceptance scenarios; the real one enters when accreditation or the client arrives. The receipt records the source, the component and the version.A source is where each confirmation comes from: Hummand’s own presence check or an external service, like the civil database. A mock is a test version of a source, which answers like the real one without querying it.
Category
ProductSources
Two native,
nine plugged.
Native
hummand.matchavailable
- Is it the same person as the reference the client gave? Transient comparison with the reference image
- Retention: captured image and template discarded; the client reference stays encrypted only while the act is open; afterwards, the hash remains
- Step: live presence, together with presence
Civil identity
serpro.datavalidin accreditation
- CPF, registration data and facial biometrics against the government database (driver licence, national ID)
- Step: civil identity, level 3
- Real and mock adapter; the response is minimized and the raw data never leaves. Accreditation in progress at Serpro, on their timeline
serpro.cpfin accreditation
- Registration status: regular, suspended, deceased holder
- Lookups: identity and exception-proof trigger
- Same contract as Datavalid
Federation and possession
govbr.oidctarget architecture
- Citizen authenticated at gov.br, with the account level: bronze, silver or gold
- Step: federated account
- Enters when a public-sector client pulls it
passkeyavailable
- Possession of the device, with user verification on it (WebAuthn); nothing biometric reaches Hummand
- Registered only after an approved presence; the receipt comes out at level 1
- Step: passkey
dispositivo.atestacaotarget architecture
- Intact app and device (Play Integrity, App Attest); requires the client's native app
- Step: passkey, as possession
Signature and document
icp.brasiltarget architecture
- Qualified signature (A1, A3, e-CPF): Hummand validates the chain and attaches it to the receipt
- Step: legal signature; the gov.br signature enters through the same step
ocr.documentotarget architecture
- Data and photo of the document (driver licence, ID card, passport); the photo becomes a transient reference for the match
- Step: attached document; the hash goes in the receipt
Vital status
crctarget architecture
- Death, marriage and birth certificates (CRC Nacional, Arpen agreement)
- Lookups: certificate and exception-proof trigger
- Restricted: only under agreement
sisobitarget architecture
- Deaths reported by registry offices (INSS)
- Lookup: exception-proof trigger
- Restricted: public bodies only
Sources
Out by choice
Bureaus, fraud scores, device fingerprinting, PEP and sanctions lists, geolocation or behaviour
as proof, age estimation from a face: not sources. SMS is only the delivery channel for the link.
Mock with a real contract
No real source enters before a client pulls it. Until then the adapter exists, has a contract and answers with the personas
of the acceptance scenarios; in production, a source that exists only as a mock responds as unavailable.
Where to start
hummand.presenca · hummand.matchLive presence and match
Availablenative, in production
- Question
- is there a living human right now, and is it the same person as the reference?
- Component
- liveness detection by an AWS-certified component, declared in the receipt
- Retention
- none after the act: the reference stays encrypted while the act is open; afterwards, only the hash
- Step
- live presence with match, level 2
serpro.datavalidCivil identity
In accreditationSerpro Datavalid, on their timeline
- Question
- who it is, against the government database (driver licence, national ID)?
- Minimization
- only the verdict persists, encrypted; the raw data never leaves
- Situation
- real and mock adapter ready; accreditation in progress
- Step
- civil identity, level 3
1.0
Verify a receipt
Paste the JSON and the public key. No account, nothing sent: it runs in your browser.
Open the verifier2.0