> 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/assurance-tiers.md). # Assurance Tiers Blerify evaluates every credential presentation against one of three assurance tiers — Basic, Standard, or Premium. This page explains what each tier proves, how the evidence is collected, and how platform differences affect what's achievable on Android versus iOS. *** ## What the tiers are Blerify's tiers are Blerify-specific definitions. They are not claims of formal equivalence with eIDAS levels or NIST Authenticator Assurance Levels, though the [mapping to those frameworks](#relationship-to-eidas-and-nist) is informative. The names Basic, Standard, and Premium were chosen deliberately to avoid implying certifications that consumer smartphones don't currently hold end-to-end. Each tier represents what a verifier can **independently confirm** from the evidence included in the presentation — not what the wallet does internally. A third-party wallet may use hardware-backed key storage and enforce biometric authentication, but if it doesn't include the attestation evidence, the verifier has no way to confirm it. The tier reflects the provable guarantee, not the internal security posture. *** ## The three tiers ### Basic Basic validates that the credential is cryptographically intact, currently valid, and was presented by the device that holds the bound key. What Basic proves: | Property | How it's proven | | ------------------------------ | ------------------------------------------------------------------------------------ | | Credential not tampered | Issuer signature over the credential data | | Credential not revoked | Revocation check against the trust registry | | Session is fresh | Nonce binding — the response is tied to this specific request | | Presenter holds the device key | Device authentication — the wallet signs a challenge with the credential's bound key | What Basic does not prove: whether the device key lives in tamper-resistant hardware, whether the device running the wallet is genuine, or whether the person presenting the credential is the person it was issued to. Any wallet that implements OpenID4VP — the open standard wallets and verifiers use to exchange credential presentations — can achieve Basic. Third-party wallets that don't include Blerify's attestation extensions are classified as Basic regardless of their internal security architecture. **Typical use cases:** low-risk credential checks, age verification, access control, third-party wallet integrations. *** ### Standard Standard builds on Basic by adding cryptographic proof that the credential's signing key was created inside tamper-resistant hardware — a Trusted Execution Environment (TEE) or StrongBox on Android, or the Secure Enclave on iOS — and by collecting a signed audit evidence package. Additional properties Standard proves: | Property | How it's proven | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Key resides in tamper-resistant hardware | Key attestation included in the presentation; the verifier validates the certificate chain independently | | Biometric authentication required to sign | Attested in the key attestation certificate chain (Android); self-reported by the wallet (iOS) | | Key invalidated if new biometrics are enrolled | Attested in the key attestation certificate chain (Android); self-reported by the wallet (iOS) | | Audit trail with session correlation | `signed_evidence` JWT signed by Blerify, containing IPs, geolocation, device metadata, and all evidence fields | On **Android**, key attestation is a hardware-signed X.509 certificate chain. The chain records where the key lives (`TRUSTED_ENVIRONMENT` or `STRONG_BOX`), whether biometric authentication is required to use it (`auth_timeout_seconds: 0` means biometrics are required on every signing operation with no reuse window), whether the key is destroyed if new biometrics are enrolled on the device (`invalidated_on_enrollment_change: true`), and which authentication types are accepted. This chain is generated at key-creation time by the hardware and is static — the key's location and access controls can't change after the key is created. On **iOS**, the equivalent is an Apple App Attest attestation. App Attest proves that a genuine, unmodified instance of the registered wallet app on real Apple hardware possesses the signing key. It does not cryptographically prove Secure Enclave residency or biometric binding the same way Android's certificate chain does — those properties are self-reported by the wallet. See [Platform Attestation](/introduction-to-verification/learn/platform-attestation.md) for the full comparison. Standard also includes a telemetry package automatically assembled by Blerify: the wallet's IP address captured when it submits attestation data, the verifier's session IP if provided when initiating the session, an IP correlation flag, server-side geolocation of both IPs with a country-match flag, device model and OS version, and a document render — an image of the credential with only the disclosed fields legible and everything else blurred, for audit and manual review. All of this travels in `signed_evidence`, a JWT signed by Blerify that any third party can verify against Blerify's public key. None of this adds friction for the user. The wallet submits attestation data on a background channel; Blerify captures IPs and geolocation automatically; the signed JWT is emitted when the session completes. The user sees the same consent screen and biometric prompt as in Basic. Standard is only achievable with a Blerify wallet that implements the attestation extensions. **Typical use cases:** identity verification, KYC, account opening, standard banking operations, government service integrations. *** ### Premium (coming soon) Premium builds on Standard by adding device integrity verification and server-side biometric verification. It answers a question the lower tiers cannot: is the person presenting this credential the same person the credential was issued to? Premium is coming soon — the properties below describe what it proves once available. Additional properties Premium proves: | Property | How it's proven | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Device and app are genuine | Device attestation (Play Integrity on Android) | | Presenter is the credential subject | Server-side liveness — anti-spoofing analysis plus face comparison against the portrait embedded in the credential | | Anti-spoofing | Passive and active attack detection: photo, video replay, deepfake, 3D mask | The liveness check runs on Blerify's infrastructure, not on the device. This produces independent evidence — the result comes from a party the verifier can audit, not from the user's own device. It also means server-side anti-spoofing catches sophisticated attacks that on-device checks miss. The liveness data is processed and immediately deleted. Blerify retains only the boolean result and a match confidence score. No biometric templates are stored. Premium also optionally provides an anti-coercion signal derived from the same camera frames captured during the liveness challenge. Gaze tracking and micro-expression analysis run silently alongside the liveness check, invisible to both the user and any potential coercer. If anomalies are detected, they're reported in the result — the flow is never interrupted and no error is shown to the user. Your backend decides how to act on the signal. **iOS and device attestation:** iOS has no equivalent of Android's Play Integrity API for third-party apps. On iOS, `device_attestation` is always `null` with `device_attestation_reason: "platform_not_available"`. This is a structural platform limitation, not a failure. The Premium delta on iOS comes entirely from the liveness layer, which works identically on both platforms. Premium requires a Blerify wallet. **Typical use cases:** high-value banking operations (loan applications, contract signing), legal proceedings, regulated processes that require independent identity re-proofing. *** ## Choosing a tier The right tier depends on the consequence of being wrong. **Use Basic when** you need to confirm a credential is valid and the presenter holds it, and the downside of a false positive is limited. Any standards-compatible wallet works. **Use Standard when** you need confidence that the credential is bound to real hardware and authorized by its holder's biometric. Appropriate for KYC, account opening, and most government and financial service integrations. The additional evidence is collected transparently — no extra friction for the user. **Use Premium when** you need to independently confirm the person physically present is the credential subject (coming soon). Suited to high-value operations where the cost of identity fraud is significant: loans, contract signing, legal proceedings. Adds a liveness step of a few seconds. You can run different tiers for different operations within the same product. A bank might verify at Standard for standard transfers and require Premium for loan applications. **Decision shorthand.** Ask what the consequence of being wrong is: * *A teenager bypassing your age gate with an older sibling's credential* → Basic is enough. * *An attacker opens an account in a stolen identity's name* → Standard raises the bar to needing physical access to the real person's phone and their biometrics. * *An attacker signs a high-value contract as someone else* → Premium adds liveness, making this essentially impossible without the real person physically present. *** ## Evidence fields The verification response includes an `evidence` object alongside the credential claims. Each field tells you what was checked and what was confirmed. For the full field-level schema and request/response examples, see the [API reference](https://dev.blerify.com). ### Basic | Field | Source | Description | | ----------- | ------- | ----------------------------------------- | | `timestamp` | Blerify | Exact time the presentation was processed | ### Standard (includes Basic) | Field | Source | Description | | -------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `wallet_ip` | Blerify | IP address of the wallet's connection to Blerify when submitting attestation data | | `client_reported_ip` | Verifier | IP of the user's web session, when one was reported at session creation; absent otherwise | | `ip_match` | Blerify | Whether `wallet_ip` and `client_reported_ip` match, when both are present. A mismatch isn't necessarily suspicious (NAT, VPN, mobile carrier) but is a useful audit signal | | `geolocation` | Blerify | Server-side IP geolocation for both IPs: country, region, and city per IP, plus a country-match flag. A risk signal, not location proof — defeatable with a VPN | | `device_model` | Key attestation (Android) / wallet (iOS) | Device model. Attested by hardware on Android; self-reported on iOS | | `os_version` | Key attestation (Android) / wallet (iOS) | OS version and patch level. Attested by hardware on Android; self-reported on iOS | | `device_metadata.attested` | Blerify | `true` when device model and OS version come from the hardware-attested certificate chain; `false` on iOS | | `key_attestation` | Wallet + Blerify | Whether the signing key resides in tamper-resistant hardware and how it's protected. See [Key attestation fields](#key-attestation-fields) | | `document_render` | Wallet | Image of the credential rendered by the wallet with disclosed fields legible and all others blurred. Intended for audit and manual review | | `signed_evidence` | Blerify | JWT signed by Blerify containing the full result and all evidence fields. Verifiable by any third party against Blerify's public key. Blerify does not retain this by default beyond the session TTL — you are the custodian | Of these, **`document_render` is the item a Standard rule requires** — its absence fails the verification with `required_fields_missing`. The other fields are collected when the wallet can provide them and arrive as `null` with a `_reason` otherwise. ### Premium (includes Basic and Standard) — coming soon | Field | Source | Description | | ----------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `device_attestation` | Play Integrity (Android) / not available (iOS) | Device and app integrity. Confirms the device runs a genuine manufacturer image, has a locked bootloader, runs the legitimate app binary, and has recent security patches. Always `null` on iOS with `device_attestation_reason: "platform_not_available"` | | `liveness_verification` | Blerify | Server-side liveness result: `verified` (boolean), `match_confidence` (0–1), `spoof_detected` (boolean) | | `coercion_check` | Wallet + Blerify | Anti-coercion analysis from the liveness session: `status` (`CLEAR`, `GAZE_ANOMALY`, or `EXPRESSION_ANOMALY`), `method` (`"facial"`), `alert` (boolean convenience flag). Produced silently; never interrupts the flow | ### Key attestation fields The `key_attestation` object and its `key_biometric_binding` sub-object describe the hardware-level key guarantees: | Field | Android | iOS | | -------------------------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------- | | `security_level` | `STRONG_BOX` or `TRUSTED_ENVIRONMENT`, extracted from the hardware-signed certificate | `SECURE_ENCLAVE`, self-reported by the wallet | | `security_level_attested` | `true` | `false` | | `key_biometric_binding.biometric_required` | Attested — extracted from the key attestation certificate | Self-reported by the wallet | | `key_biometric_binding.auth_type` | Attested — e.g. `FINGERPRINT`, `FACE`, or `DEVICE_CREDENTIAL` | Self-reported by the wallet | | `key_biometric_binding.auth_timeout_seconds` | Attested — `0` means biometrics required on every operation, no reuse window | Self-reported by the wallet | | `key_biometric_binding.invalidated_on_enrollment_change` | Attested — `true` means the key is destroyed if new biometrics are added to the device | Self-reported by the wallet | | `key_biometric_binding.attested` | `true` | `false` (always) | The `auth_type` and `biometric_required` fields reflect the authentication factor bound to the key at creation time. On devices without a strong biometric enrolled, the key is bound to the device passcode or PIN — `auth_type` will be `["DEVICE_CREDENTIAL"]` and `biometric_required` will be `false`. This is accurate, not a downgrade: the key is still in hardware and requires user authentication on every signing operation. ### StrongBox versus TEE on Android Android devices report either `STRONG_BOX` or `TRUSTED_ENVIRONMENT` as the `security_level`. Both are accepted at Standard and Premium. A TEE (Trusted Execution Environment) is a hardware-isolated execution environment on the same processor, present on virtually all Android devices since 2016. A StrongBox is a dedicated tamper-resistant security processor with its own CPU and storage — present on many current flagships but not universally available on mid-range hardware. StrongBox offers stronger isolation guarantees than a TEE. Both security levels appear in `evidence.key_attestation.security_level` so you can apply your own acceptance policy if a specific use case demands StrongBox. For most integrations, accepting both is the right default. ### Absence reasons When an optional evidence field is absent, a companion `_reason` field explains why. The reason field is always present — it's `null` when the evidence field itself is populated. | Value | Meaning | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `null` | The evidence field is populated — no absence to explain | | `"platform_not_available"` | The platform has no API for this capability (e.g., `device_attestation` on iOS) | | `"wallet_not_supported"` | The wallet doesn't implement the Blerify extension | | `"not_requested"` | The verifier didn't configure this tier or feature | | `"user_declined"` | The user denied a required permission (e.g., camera for liveness) | | `"failed"` | The check was attempted but rejected (e.g., spoof detected, integrity check failed) | | `"attestation_not_supported"` | The device has a hardware key store but predates the Key Attestation API — the key is likely hardware-backed but this can't be cryptographically proven | The distinction between `"platform_not_available"` and `"user_declined"` matters for policy decisions. A user who refuses liveness is a different risk signal than a platform that structurally can't provide device attestation. Your verification policy can treat them differently. *** ## Platform attestation asymmetry Android and iOS provide fundamentally different attestation capabilities. They are not equivalent mechanisms with minor differences — the underlying architectures differ. ### Key attestation On **Android**, the key attestation certificate chain is generated by the hardware at key-creation time and signed by the TEE or StrongBox. Key properties including biometric requirements, authentication timeout, and invalidation behavior are all embedded in the signed certificate. On **iOS**, there is no Apple API that produces an equivalent certificate for Secure Enclave keys in third-party apps. App Attest proves that a genuine, unmodified instance of the registered wallet app on real Apple hardware created and holds the key. Key properties like biometric binding are self-reported by the wallet. The `key_biometric_binding.attested` field is always `false` on iOS. This does not mean iOS keys are less secure. The Secure Enclave enforces the access controls the wallet configured — including requiring Face ID or Touch ID for every signing operation and invalidating the key when biometric enrollment changes. The limitation is that these controls cannot be independently verified remotely. Apple has not provided a public API for this in third-party apps. ### Device attestation Android provides Play Integrity, which independently verifies that the device uses a certified manufacturer image, has a locked bootloader, runs the legitimate app binary, and has recent security patches applied. iOS has no equivalent API for third-party apps. `device_attestation` is always `null` on iOS with `_reason: "platform_not_available"`. This is a structural platform limitation, not a failure. ### Summary by tier and platform | Evidence | Basic | Standard Android | Standard iOS | Premium Android | Premium iOS | | ----------------------------------- | ----- | ---------------- | ------------ | --------------- | --------------- | | Credential valid | ✅ | ✅ | ✅ | ✅ | ✅ | | Holder binding | ✅ | ✅ | ✅ | ✅ | ✅ | | Key in hardware (attested) | — | ✅ | — | ✅ | — | | Key in hardware (self-reported) | — | — | ✅ | — | ✅ | | Biometric binding (attested) | — | ✅ | — | ✅ | — | | Biometric binding (self-reported) | — | — | ✅ | — | ✅ | | Audit telemetry + `signed_evidence` | — | ✅ | ✅ | ✅ | ✅ | | Device integrity (Play Integrity) | — | — | — | ✅ | ❌ not available | | Liveness + face match | — | — | — | ✅ | ✅ | ### Recommended policy for iOS Standard Accept Standard on iOS the same way you accept it on Android. An iOS device with `security_level_attested: false` and `key_biometric_binding.attested: false` is not a downgrade or a fraud signal — it reflects Apple's architectural choice not to expose an equivalent hardware attestation API to third-party developers. The Secure Enclave still enforces biometric requirements on every signing operation. If your use case requires hardware-attested key properties regardless of platform, apply a platform-neutral control rather than treating these fields as a failure condition. For use cases where the absence of hardware attestation on iOS is unacceptable, Premium closes the gap — App Attest confirms the wallet app and device are genuine, and liveness independently re-proves the presenter's identity. *** ## `effective_tier` versus `assurance_level` Your verification rule specifies an `assurance_level` — the tier you're requesting. The response also carries `effective_tier`, kept for backward compatibility: **on a `COMPLETED` result the two always match.** There is no silent downgrade — if evidence your rule requires is missing, the verification fails with an explicit reason instead of completing at a lower tier. The tier measures which classes of evidence arrived and were validated, not whether the content of that evidence is favorable. A Standard result can still contain `ip_match: false` or `geolocation.country_match: false` — those are content signals you evaluate against your own risk policy; they don't change the tier. What happens when evidence is missing depends on how your rule classifies each item: * **Required** — if the item never arrives (including when the user is on a third-party wallet that doesn't implement Blerify's extensions at all), the session finalizes as `FAILED` with `reason: "required_fields_missing"`, and the `message` field lists what was missing. * **Optional** — the session completes at your configured tier; the missing evidence field comes back `null` and its `_reason` field tells you why. *** ## Non-repudiation at Standard Standard establishes a chain of evidence that makes it difficult for a credential holder to credibly deny having authorized a presentation. Each element addresses a specific argument: | Argument | Why it doesn't hold | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | "Someone copied my key" | The key resides in tamper-resistant hardware and cannot be extracted or duplicated. Key attestation proves this cryptographically | | "Someone used my key without my consent" | Every signing operation requires the holder's biometric with no reuse window (`auth_timeout_seconds: 0`) | | "Someone enrolled their biometrics on my device" | The key is automatically destroyed if new biometrics are added (`invalidated_on_enrollment_change: true`) | | "The evidence was fabricated" | The `signed_evidence` JWT is signed by Blerify and verifiable by any third party against Blerify's public key — it cannot be altered without detection | On Android, each element in this chain is hardware-attested — the properties are signed by the TEE or StrongBox, not asserted by the wallet. On iOS, the properties are self-reported but corroborated at Premium by App Attest confirming the wallet app and device are genuine. *** ## Zero biometric storage Blerify's liveness model at Premium is structurally different from traditional identity verification services. Traditional providers store a face image or a biometric embedding. They become custodians of biometric data subject to strict obligations under GDPR and equivalent laws. If their infrastructure is breached, biometric data is permanently exposed — unlike passwords, faces cannot be changed. Blerify eliminates this risk by design. The credential issued by an authority already contains the holder's portrait, signed by the issuer. Blerify does not store a reference photo. When Premium verification runs, the selfie captured during liveness and the portrait extracted from the credential are compared and immediately deleted. The only artifact retained is the boolean result and a confidence score. Your backend never receives a face image, a template, or any biometric data. For the full technical detail on how this works, see [Biometric Binding](/introduction-to-verification/learn/biometric-binding.md). *** ## Relationship to eIDAS and NIST This section is informative. Blerify's tiers are not claims of formal regulatory equivalence. | Blerify tier | Closest eIDAS level | Closest NIST AAL | PSD2 SCA | | ------------ | ------------------- | ---------------- | ------------------------- | | Basic | \~Low | \~AAL1 | Below SCA (single factor) | | Standard | \~Substantial | \~AAL2 | Satisfies SCA | | Premium | Exceeds scope | Exceeds scope | Exceeds SCA | **Standard and \~AAL2 / \~eIDAS Substantial.** The device biometric that activates the hardware-bound signing key qualifies as multi-factor authentication under both frameworks — something you have (the device with the key in hardware) plus something you are (the biometric that activates it). The mapping is informative because consumer phones meet the security bar functionally but don't hold the end-device certifications required for a formal compliance claim. **Why Premium doesn't map to eIDAS High or NIST AAL3.** Premium exceeds the authentication requirements of both — it adds server-side liveness and independent face matching, neither of which those frameworks mandate for authentication. However, both require hardware certifications at the highest tiers that consumer smartphones meet only partially at the end-device level. This is an industry-wide limitation for consumer phone-based wallets, not specific to Blerify. Blerify uses its own tier names to avoid implying certifications that don't yet exist end-to-end for consumer devices. *** ## Configuring tier requirements You set the required assurance tier in your verification rule in the Portal. A verification either completes at that tier or fails with an explicit reason — there is no in-between outcome. For the full evidence response schema, request parameters, and verification configuration details, see the [API reference](https://dev.blerify.com). *** ## Next steps **Continue to** [**Biometric Binding**](/introduction-to-verification/learn/biometric-binding.md) — how the credential's signing key is bound to the user's biometrics, what each tier guarantees about that binding, and where the limits are. See also: [Platform Attestation](/introduction-to-verification/learn/platform-attestation.md) · [Read a Verification Result](/introduction-to-verification/build/read-a-verification-result.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/assurance-tiers.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.