> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/introduction-to-verification/learn/verifier-trust.md). # Verifier Trust When a user's wallet receives a credential request, it needs to answer two questions before presenting anything: *is this request really from the organization it claims to be?* and *has Blerify vetted that organization as a legitimate verifier?* Verifier trust is how Blerify answers both questions. Every verifier organization gets a signing certificate that authenticates its requests. The Blerify wallet learns which certificates to trust from a signed trust list it syncs from Blerify — so adding a new verifier never requires an app update, and revoking one takes effect within minutes. This page explains how the system works from the perspective of someone building on or integrating with the Blerify ecosystem. *** ## How it works Two independent mechanisms work together. **Request authentication** answers *"is this request really from that organization?"* Each organization has a signing certificate. Every credential request carries that certificate and is signed with the corresponding private key. The wallet verifies the signature before presenting anything. **Trust distribution** answers *"which organizations does Blerify vouch for?"* Blerify maintains a signed trust list describing every vetted verifier — its certificate anchor, its display name and logo, and what it's authorized to request. The wallet syncs this list from Blerify and uses it at request time. The two mechanisms are linked: the trust list tells the wallet which certificates to accept, and the request authentication uses those certificates. A request from an organization whose certificate isn't in the trust list is rejected, even if the signature is cryptographically valid. *** ## Verifier identity and key custody Every verifier organization gets exactly one signing identity — regardless of how many verification templates it creates. That identity is provisioned automatically the first time an organization publishes a verification template, with no manual configuration required. The practical design question is where the signing key lives. Blerify supports a spectrum of custody models: | Custody model | Key lives | When to use | | ------------------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | **Managed** | Blerify's key management infrastructure | Default — no infrastructure to operate | | **Issued** | Your own backend (Blerify-issued certificate) | You want to hold your own key but use a Blerify-issued certificate | | **Sovereign-lite** | Your own backend (self-signed certificate, pinned in the trust list) | Long-lived key, minimal rotation; the certificate itself is the trust anchor | | **Sovereign** | Your own certificate authority | Full PKI control, own CA hierarchy | The custody model doesn't affect what the user sees. In every case, the wallet renders the organization's vetted display name and logo from the trust list — not from the certificate. Blerify controls what appears on the user's consent screen, preventing one organization from impersonating another's brand. Leaf certificate rotation — short-validity certificates renewing on a schedule — is handled automatically in Managed and Issued tiers. In Sovereign-lite, the certificate *is* the trust anchor, so rotation requires a trust list update rather than a certificate-chain operation. *** ## How the wallet learns who to trust The wallet ships with two provisioned inputs: a pinned Blerify root key and a federation base URL. Everything else — organization names, logos, certificates, authorization policies — arrives signed and synced from Blerify. No app update is required when a new verifier is onboarded or an existing one is revoked. On first sync and periodically thereafter, the wallet: 1. Fetches the Trust Anchor Entity Configuration from the federation base URL and verifies it against the pinned root key 2. Enumerates all vetted verifier organizations 3. Fetches and verifies a signed statement for each organization, extracting its certificate anchor, display metadata, and what it's authorized to request 4. Fetches the revocation list and verifies it against the same root 5. Caches logos locally after verifying each image against a signed hash embedded in the statement — a swapped CDN image fails the check The result is a local trust store the wallet consults at request time, entirely without network access. Syncing is a background operation decoupled from any individual verification session. *** ## What the trust list contains For each vetted organization, the trust list carries: * **Certificate anchor** — the CA certificate (for Managed/Issued/Sovereign organizations) or the pinned certificate thumbprint (for Sovereign-lite). This is what the wallet validates incoming request certificates against. * **Display metadata** — the organization's vetted name and logo, curated by Blerify. The wallet never renders identity from the certificate's subject field. * **Authorization policy** — what credential types and claims the organization is permitted to request. The wallet enforces this at presentation time: a request that asks for more than the organization is authorized to receive is refused before the user sees a consent screen. * **Status** — whether the organization is active or revoked. Display metadata is controlled by Blerify and updated only through an explicit vetting process. An organization cannot change what the wallet shows on its consent screen by editing its own profile — the change only reaches the trust list after Blerify re-curates the entry. *** ## How a request is validated When a credential request arrives, the wallet establishes who sent it before considering what it's asking for: 1. **Find the anchor.** Walk the certificate chain in the request to find the first certificate that matches an entry in the local trust list. 2. **Validate the chain.** For CA-anchored entries, perform standard X.509 path validation from the leaf up to the trusted CA. For pinned-leaf entries, verify the presented certificate's thumbprint matches the registered pin exactly — no chain is walked. 3. **Check revocation.** Verify the anchor against the signed revocation list. Revocation is always positive evidence — an organization absent from the revocation list is not considered revoked. 4. **Check freshness.** Confirm revocation data is recent enough for the assurance level being requested. 5. **Verify the signature.** Validate the request signature against the leaf key that just passed chain validation. 6. **Enforce authorization.** Compare what the request is asking for against what the trust list says the organization is permitted to request. Requests that exceed the authorized set are refused. 7. **Render the consent screen.** Show the organization's vetted name and hash-verified logo from the trust list — never from the certificate subject. A request fails at the first step that doesn't pass. The wallet never falls back to trusting a certificate just because it's cryptographically valid. *** ## Revocation Revoking a verifier takes effect at the organization level. When an organization's trust anchor is revoked: * The revocation list is updated immediately and distributed with a shorter cache lifetime than the trust list itself * The wallet picks up the revocation on its next sync * All subsequent requests from that organization are refused, regardless of whether their signing certificates are individually valid Revocation uses positive evidence — a signed entry saying "this anchor was revoked at this time, for this reason." The wallet never infers revocation from an organization's absence in the trust list. This design choice means a network outage or a stale mirror can't silently re-trust a revoked verifier. Two revocation artifacts serve different consumers. The signed revocation list is what wallets check for organization-level revocation. An X.509 CRL serves the proximity verification flow — where an in-person verifier presents a reader certificate to the wallet over Bluetooth or NFC — because that flow uses standard X.509 reader authentication rather than the federation protocol. Both artifacts are derived from the same source. *** ## Display identity and brand protection A key property of the system is that the organization's display identity — the name and logo the user sees — is controlled by Blerify, not by the organization presenting the request. This works because: * Display metadata lives in the signed trust list, not in the certificate * Blerify curates display metadata through an explicit vetting process * The wallet verifies logo images against a hash embedded in the signed statement before rendering them * Changes to an organization's display metadata don't reach the trust list until Blerify re-curates the entry As a result, an organization cannot impersonate another's brand by modifying its certificate subject or self-asserting a different name in its request. The user always sees the identity Blerify has vetted. *** ## How this relates to assurance tiers Verifier trust is independent of assurance tiers. It determines *who* can request a presentation. Assurance tiers determine *what* evidence is collected during the presentation itself. The authorization policy in the trust list does constrain what a verifier can *ask for* — credential types and claim fields — but that's a permission control, not an assurance level. A verifier might be authorized to request a driving license and configured with a Standard tier requirement. Those are separate settings. For the full assurance model, see [Assurance Tiers](/introduction-to-verification/learn/assurance-tiers.md). *** ## Next steps **Continue to** [**Assurance Tiers**](/introduction-to-verification/learn/assurance-tiers.md) — what Basic, Standard, and Premium each prove, and how to choose the right tier for your use case. See also: [Platform Attestation](/introduction-to-verification/learn/platform-attestation.md) · [Get Started with a Verification](/introduction-to-verification/build/get-started.md) · [API Reference](https://dev.blerify.com) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.blerify.com/introduction-to-verification/learn/verifier-trust.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.