How It Works
Blerify is built on the W3C Verifiable Credentials model: three parties — an issuer, a holder, and a verifier — exchange signed digital credentials without any of them needing to trust a central database. This page explains how the model works end-to-end, how Blerify validates credentials, and how the assurance model determines what you can rely on from each verification.
The three participants
Issuer
Creates and cryptographically signs a credential, then delivers it to the holder
Issuance
Holder
Stores the credential on their device, decides what to share and with whom
ID Wallet
Verifier
Asks the holder to present a credential and checks its validity
Verification
These three roles never need to communicate directly with each other. The trust between them is established by the credential's cryptographic signature and by the Blerify Trust Registry, which records which issuers are authorized to issue which credential types.
End-to-end flow
1 — Issuance
The issuer creates a credential containing the holder's data — name, document number, qualification, or whatever the use case requires — signs it with their private key, and delivers it to the holder's wallet.
Issuer backend ──▶ Blerify Issuance API ──▶ Signed credential
│
▼
Holder's WalletThe credential is signed once at issuance and never modified afterward. If the issuer later revokes it, they update the revocation registry. The credential in the wallet remains unchanged, but any subsequent verification will reflect the revoked status.
2 — Holding
The holder receives the credential into the Blerify Wallet via a QR code, a deep link, or a push notification. The wallet stores the credential on-device, encrypted at rest, and unlockable only with the holder's biometric or PIN.
The holder controls consent: when a verifier requests a credential, the wallet shows them exactly which fields will be shared before anything leaves the device.
3 — Presentation
The holder presents the credential to the verifier. This can happen in three ways:
Same-device — the holder is on a mobile web page or inside a native app. A button or deep link opens the Blerify Wallet on the same phone. They approve with their biometric, and the app or page receives the result.
Cross-device — the holder is at a desktop. They scan a QR code with their phone. The wallet opens, they approve, and the desktop page updates.
App-to-app — the holder is inside a native mobile app. A deep link opens the wallet directly. The wallet finishes and returns focus to the calling app.
In all three cases, the holder's explicit approval is required before any data leaves their device.
4 — Verification
The verifier's backend creates a verification session with Blerify and gets back a transaction_id. The verifier's frontend uses that to build a QR code or deep link for the holder. The wallet submits a signed presentation directly to Blerify. The verifier's backend polls for the result.
The verifier's backend is the only party that calls the Blerify API. The service account token that authenticates those calls must never be exposed to a browser or mobile app.
What Blerify validates
When a credential is presented, Blerify runs all of these checks automatically:
Signature
The credential was signed by a key belonging to a registered issuer
Trust chain
The issuer is in the Trust Registry and authorized to issue this credential type
Revocation
The issuer has not revoked this credential
Expiry
The credential is within its validity period
Holder binding
The presentation was made by the person who controls the credential's private key
Replay protection
The presentation includes a fresh nonce — it cannot be reused
You don't implement any of these checks. You receive a structured result on each one and apply your own access policy on top.
The Trust Registry
The Trust Registry is the source of truth for who can issue what. When Blerify validates a credential, it checks the registry to confirm:
The issuer exists and is active
The issuer is authorized to issue the specific credential type being presented
The issuer's signing key matches what's recorded in the registry
The Trust Registry uses Blerify's DID method (did:lac1) to anchor issuer identities on a public ledger. This means the trust chain is verifiable by anyone — including verifiers outside the Blerify ecosystem.
See Decentralized Root of Trust for the full technical model.
Credential formats
W3C Verifiable Credentials are JSON documents signed as JWTs. The schema is flexible — issuers define their own claim types. Commonly used for soft credentials: licenses, badges, KYC status, employment records.
ISO 18013 mDocs are binary CBOR documents following the ISO 18013-5 standard for mobile driving licenses. The schema is defined by the ISO standard and uses standardized field names and namespaces. Used for government identity documents.
Both formats travel over OpenID4VP, the same presentation protocol. The validation pipeline detects the format and routes to the appropriate verification path automatically.
Assurance tiers
Not all verifications carry the same weight. Blerify reports an assurance_level — BASIC, STANDARD, or PREMIUM — alongside every verification result. The tier reflects what can be independently proven to you, not just what the wallet asserts.
Basic
The credential is cryptographically valid, the issuer is trusted, the credential isn't revoked, and the holder presented it in real time. Compatible with any OpenID4VP wallet.
Standard
Everything in Basic, plus the signing key is proven to reside in tamper-resistant hardware (TEE or Secure Enclave). The verifier receives a hardware attestation certificate chain they can validate independently against Google or Apple roots.
Premium
Everything in Standard, plus the person physically holding the device is confirmed to be the credential subject. Blerify captures a live selfie from within the wallet, compares it against the photo embedded in the signed credential, and returns the result.
The tier you receive depends on the wallet submitting the proof. Any OpenID4VP wallet achieves Basic. Standard and Premium require the Blerify Wallet, which submits hardware attestation evidence alongside the credential presentation.
The assurance_level in the response reflects what was actually achieved in that session. You set the minimum you require for your use case; Blerify tells you what was delivered.
See Assurance Tiers for the full model, including the informative mapping to eIDAS and NIST frameworks.
Privacy model
Selective disclosure. When a verifier requests a credential, they specify which fields they need. The wallet shows a consent screen listing exactly those fields. The holder approves or declines. Blerify only forwards what the holder approved.
No call home. The issuer is not notified when a holder presents a credential. Blerify does not maintain a presentation log accessible to issuers. The issuer's involvement ends at issuance.
On-device storage. Credentials are stored in the Blerify Wallet on the holder's device, not in a Blerify cloud database. If the holder uninstalls the wallet, the credentials are gone from Blerify's systems.
No biometric storage. When Premium assurance is requested, Blerify compares a live selfie against the photo embedded in the credential, then immediately deletes both. Blerify stores only the boolean result and a confidence score. There is no face database, no biometric template, and nothing to breach beyond a pass/fail flag.
Next steps
Issue your first W3C credential — Issuance: Get Started
Verify your first credential — Verification: Get Started
Understand how trust anchors work — Decentralized Root of Trust
Learn how assurance tiers map to eIDAS and NIST — Assurance Tiers
Last updated