Point of Verification
A Point of Verification (POV) is a reusable verification configuration you create once in the Blerify Portal. It defines what credential data to request, which issuing entity to trust, what level of assurance to require, and which wallets to accept. At runtime, your backend references a POV by its UUID — Blerify handles the protocol, the wallet interaction, and the result.
How it works
When you create a POV, you make four decisions:
What data to request — which credential claims the user must share
Which issuer to trust — which organization issued the credential you'll accept
What assurance level to require — how much security evidence to collect
Which wallets to accept — which certified wallets can present credentials
At runtime, your backend calls the Blerify Verification API with the POV's UUID. Blerify reads the configuration, presents the request to the user's wallet, and returns the result. You never write credential protocol logic — the POV drives all of it.
Setup (once in the Portal) Runtime (each verification)
┌──────────────────────────┐ ┌──────────────────────────┐
│ Create POV: │ │ Your backend calls the │
│ • Data to request │ │ Verification API with: │
│ • Trusted issuer │ → │ • template UUID │
│ • Assurance level │ │ • redirect_uri │
│ • Accepted wallets │ └──────────────────────────┘
└──────────────────────────┘If your requirements change — different claims, a stricter assurance level, a new trusted issuer — you update the POV in the Portal. Your integration code doesn't change.
What data to request
The Portal provides a visual claim selector. You pick a credential type — for example, an ISO 18013 mDoc — then select which fields you need. The Portal generates the underlying credential query automatically; you never write it by hand.
Request only what you actually need. The user sees exactly which fields are being shared on the wallet's consent screen and must explicitly approve. Requesting more than necessary adds friction without improving your result.
Common patterns:
Age verification
Age over 18 (single boolean — no other personal data shared)
Identity verification
Family name, given name, date of birth, document number
Account opening
Identity fields + portrait + document number + issue date + expiry date
If you configure Premium assurance and your data selection doesn't include a portrait, the Portal adds it automatically. Portrait is required for the facial liveness comparison that Premium performs.
Which issuer to trust
You select an issuing entity from the Portal's catalog — for example, a national identity authority. You pick a name you recognize, not a certificate fingerprint or a registry address. Blerify maps your selection to the corresponding trust chain.
At runtime, when a user presents a credential, Blerify verifies that the credential's signing certificate traces back to the issuing entity you selected. If the chain doesn't match your POV's trust configuration, the credential is rejected — even if the cryptographic signature is otherwise valid.
This is separate from revocation. Trust chain validation answers "is this issuer authorized to issue this credential type?" Revocation checking answers "has this specific credential been invalidated?" Blerify performs both checks automatically on every verification.
When an issuing authority rotates its signing certificates, Blerify updates its trust registry. Your POV continues working without any changes on your end.
Assurance levels
Each POV requires one of three assurance levels — Basic, Standard, or Premium — which determines what security evidence Blerify collects during verification. See Assurance Tiers for what each level proves and how the evidence is structured.
Basic
Credential validity, issuer trust, revocation check, holder binding
Age gates, access control, low-risk identity checks
Standard
Hardware key attestation, biometric binding evidence, signed audit record
KYC, account opening, standard banking operations
Premium
Device integrity, server-side liveness, facial anti-coercion
Loans, high-value transactions, regulated onboarding
Platform note. Device attestation behaves differently across platforms. On Android, it produces a hardware-signed integrity verdict. On iOS, it returns null with an explanatory reason field because Apple provides no equivalent API for third-party apps. Blerify surfaces this distinction explicitly in the evidence so you know exactly what was and wasn't attested. For a full breakdown of per-platform behavior, see Platform Attestation.
Degradation. If a wallet doesn't support the assurance level your POV requests, Blerify accepts the presentation at the highest level the wallet can reach and reports the actual level in effective_tier in the result. You compare effective_tier against your requirement and decide whether to proceed.
Accepted wallets
Blerify maintains a catalog of certified wallets — wallets it has tested for correctness, security, and compatibility with its extension protocol. You select from this catalog when configuring a POV.
Each wallet in the catalog has a maximum achievable assurance level:
Third-party OpenID4VP wallet (no Blerify extensions)
Basic
Blerify-compatible wallet (extensions, no liveness SDK)
Standard
Blerify wallet (full extensions + liveness)
Premium
If you configure a POV at Standard but select a wallet that only supports Basic, the Portal warns you. You can save the configuration anyway; at runtime, Blerify degrades gracefully and reports the effective level in the result.
Transport policy
The transport policy controls which presentation mechanism Blerify uses for web-based verification flows.
DC-API only — Blerify uses the browser's native Digital Credentials API, which uses Bluetooth for cross-device flows. The browser and the wallet must be physically close. This prevents relay attacks where an attacker forwards a verification request across a network. Requires Chrome 128+ or Safari 26+.
DC-API preferred — Blerify uses DC-API when the browser supports it and falls back to a QR code for older browsers. QR codes have no proximity requirement. An attacker still cannot forge a request — the wallet validates the cryptographic signature on every request object.
The Portal sets a default transport policy based on your assurance level:
Basic
DC-API preferred
Standard
DC-API only
Premium
DC-API only
You can override the default. Overriding Standard or Premium to DC-API preferred requires an explicit acknowledgment that you're accepting relay risk in exchange for broader browser compatibility.
Transport policy applies only to web flows. In app-to-app scenarios — your native mobile app invoking the wallet directly — relay attacks are not a practical threat. The operating system binds Universal Links and App Links to your app's signing certificate at the OS level, so an attacker can't intercept or redirect the handoff without compromising the device.
Note: DC-API transport enforcement is planned for a future release. Until it ships, all web verification flows use the QR-based protocol regardless of this setting. Configure the policy now; it takes effect automatically when the feature is available.
Validation at save time
The Portal validates your configuration before saving. Some issues are corrected automatically; others block saving.
Premium selected, portrait not in the claim request
Adds portrait automatically and shows a notice
Selected wallet's maximum level is below the configured assurance level
Shows a warning; allows saving
No wallets selected
Blocks saving
No claims selected
Blocks saving
Next steps
Continue to Get Started with Verification — create your first POV and run a working verification end to end.
See also: Assurance Tiers · Biometric Binding · Platform Attestation · API Reference
Last updated