Policy
The client asks for the type and a minimum level; the policy resolves level, steps and sources,
and the version applied goes in the receipt.
The policy turns what the client asks into steps a person completes. Today there is one global, versioned policy; the per-client policy is born when the second client asks for a different one, and the structure already exists for that.
Every policy change creates a new version, and the receipt carries the version applied: the auditor knows which steps were required that day. The policy never reads the content of the act context; it only compares values the client marked as comparable, and the receipt records which keys were read.
Levels
Description
The client asks for a minimum level; the policy resolves the effective level. Never below the requested minimum, never below the type default without an explicit, recorded override. The receipt carries the level reached, not the one requested.
0.0Level 0 · no new humantarget architecture
Verification of a valid mandate or of strong possession. No new presence: the proof is the mandate, not the person.
Minimum steps: mandate verification, result. It is the level of the delegated act.
1.0Level 1 · strong possessiontarget architecture
Passkey or device attestation, with consent. It serves the short step-up, when the policy accepts a recent positive act.
Minimum steps: context transparency, general consent, passkey, result.
2.0Level 2 · live presence and same personavailable
A living person, now, and the same one as the reference the client gave. Native presence and match, with consent per step.
Steps: context transparency, general consent, biometric consent, live presence with match, result. It is the policy in production.
Recurring presence3.0Level 3 · presence and civil identitytarget architecture
Level 2 plus civil identity through a plugged source: Serpro Datavalid, in accreditation; or a gold gov.br account plus Serpro.
Steps: those of level 2 plus the identity lookup. It is the level of onboarding, of grants and of signatures.
SourcesSteps
Description
Every step has a fixed id, which the journey renders and the receipt records with result and timestamp. The five in production do not change; new ones are born in the catalogue and only get a screen when the act type that uses them exists.
1.0Context transparencyavailable
The person sees what they are authorizing: the context the client sent, in the clear only for them. The receipt gets the hash and the list of declared keys.
2.0General consentavailable
Versioned text, accepted with a timestamp; the hash of the text and the version go in the receipt.
3.0Biometric consentavailable
Separate from the general one, before any capture. Without it, the result is not released.
4.0Live presence and matchavailable
Active challenge by a certified third-party component, and transient comparison with the client's reference. Image and template are discarded; the result and the hash of the reference remain.
5.0Resultavailable
Positive, negative or inconclusive. Inconclusive only comes out of human review, and the review is a step-up by the person deciding.
6.0Civil identitytarget architecture
Plugged source, labelled in the receipt. Serpro Datavalid in accreditation; the response is minimized, the raw data never leaves.
7.0Federated account, passkey and attestationtarget architecture
gov.br over OIDC; passkey over WebAuthn; device attestation. Adapters with mock and real contract, no screen yet.
8.0Scope, attached document and grantee's presencetarget architecture
The mandate steps: the scope shown and consented; the document by hash; the presence of the person receiving the mandate, when required.
9.0Legal signature and mandate verificationtarget architecture
ICP-Brasil, gov.br or the receipt as an advanced signature; and the mandate verification of the delegated act, which resolves immediately.
The policy today
Description
One global, versioned line, for recurring presence. The per-client engine enters when the second client asks for a different policy; the structure is already built that way so the migration is never redone.
1.0Global, version 1available
The dashboard and the API read the effective policy: per type, the level, the steps, the deadline, the label and whether it is executable today, with the missing steps when it is not.
Global origin, not editable. Every change creates a new version, and the receipt carries the version applied.
See Docs2.0Overrides by contexttarget architecture
Conditions only over declared context keys, of primitive types: above a value, level 2; below another, level 1 with passkey.
Hummand never reads the content of the context; it only compares values the client marked as comparable.
3.0Reuse of a recent acttarget architecture
A window in minutes, the resulting level and the short steps. It applies to the transaction step-up and the operator's session; recurring presence never reuses.
4.0Per-client policy and exception escalationtarget architecture
Writing a per-client policy does not exist yet. Per-client exception-proof escalation and any policy other than the global one depend on it.
What we don't doVerify a receipt
Paste the JSON and the public key. No account, nothing sent: it runs in your browser.
Open the verifier