> 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/es/introduccion-a-la-verificacion/learn/assurance-tiers.md). # niveles de garantía Blerify evalúa cada presentación de credenciales frente a uno de tres niveles de garantía — Básico, Estándar o Premium. Esta página explica qué demuestra cada nivel, cómo se recopila la evidencia y cómo las diferencias entre plataformas afectan lo que se puede lograr en Android frente a iOS. *** ## Qué son los niveles Los niveles de Blerify son definiciones específicas de Blerify. No son afirmaciones de equivalencia formal con los niveles eIDAS ni con los Niveles de Garantía del Autenticador de NIST, aunque la [correspondencia con esos marcos](#relationship-to-eidas-and-nist) es informativa. Los nombres Básico, Estándar y Premium se eligieron deliberadamente para evitar implicar certificaciones que los teléfonos inteligentes de consumo no poseen actualmente de extremo a extremo. Cada nivel representa lo que un verificador puede **confirmar de manera independiente** a partir de la evidencia incluida en la presentación — no de lo que hace internamente la billetera. Una billetera de terceros puede usar almacenamiento de claves respaldado por hardware y aplicar autenticación biométrica, pero si no incluye la evidencia de atestación, el verificador no tiene forma de confirmarlo. El nivel refleja la garantía que se puede demostrar, no la postura de seguridad interna. *** ## Los tres niveles ### Básico Básico valida que la credencial está criptográficamente íntegra, actualmente vigente y fue presentada por el dispositivo que contiene la clave vinculada. Qué demuestra Básico: | Propiedad | Cómo se prueba | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Credencial no alterada | Firma del emisor sobre los datos de la credencial | | Credencial no revocada | Verificación de revocación contra el registro de confianza | | La sesión es reciente | Vinculación con nonce — la respuesta está ligada a esta solicitud específica | | El presentador posee la clave del dispositivo | Autenticación del dispositivo — la billetera firma un desafío con la clave vinculada de la credencial | Qué no demuestra Básico: si la clave del dispositivo vive en hardware resistente a manipulaciones, si el dispositivo que ejecuta la billetera es genuino o si la persona que presenta la credencial es la misma a la que se le emitió. Cualquier billetera que implemente OpenID4VP — el estándar abierto que las billeteras y los verificadores usan para intercambiar presentaciones de credenciales — puede alcanzar Básico. Las billeteras de terceros que no incluyen las extensiones de atestación de Blerify se clasifican como Básico, independientemente de su arquitectura de seguridad interna. **Casos de uso típicos:** comprobaciones de credenciales de bajo riesgo, verificación de edad, control de acceso, integraciones con billeteras de terceros. *** ### Estándar Estándar se basa en Básico al agregar una prueba criptográfica de que la clave de firma de la credencial se creó dentro de hardware resistente a manipulaciones — un Entorno de Ejecución Confiable (TEE) o StrongBox en Android, o el Secure Enclave en iOS — y al recopilar un paquete firmado de evidencia de auditoría. Propiedades adicionales que demuestra Estándar: | Propiedad | Cómo se prueba | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | La clave reside en hardware resistente a manipulaciones | Atestación de clave incluida en la presentación; el verificador valida la cadena de certificados de forma independiente | | Se requiere autenticación biométrica para firmar | Atestado en la cadena de certificados de atestación de clave (Android); informado por la billetera (iOS) | | La clave se invalida si se registran nuevos datos biométricos | Atestado en la cadena de certificados de atestación de clave (Android); informado por la billetera (iOS) | | Registro de auditoría con correlación de sesión | `signed_evidence` JWT firmado por Blerify, que contiene direcciones IP, geolocalización, metadatos del dispositivo y todos los campos de evidencia | En **Android**, la atestación de clave es una cadena de certificados X.509 firmada por hardware. La cadena registra dónde reside la clave (`TRUSTED_ENVIRONMENT` o `STRONG_BOX`), si se requiere autenticación biométrica para usarla (`auth_timeout_seconds: 0` significa que se requieren biometrías en cada operación de firma sin ventana de reutilización), si la clave se destruye si se registran nuevas biometrías en el dispositivo (`invalidated_on_enrollment_change: true`), y qué tipos de autenticación se aceptan. Esta cadena se genera en el momento de crear la clave por el hardware y es estática: la ubicación de la clave y los controles de acceso no pueden cambiar después de que la clave se crea. En **iOS**, el equivalente es una atestación de Apple App Attest. App Attest demuestra que una instancia genuina y sin modificaciones de la aplicación de billetera registrada en hardware Apple real posee la clave de firma. No prueba criptográficamente la residencia en Secure Enclave ni la vinculación biométrica de la misma manera que la cadena de certificados de Android — esas propiedades las informa la billetera. Consulta [Atestación de plataforma](/es/introduccion-a-la-verificacion/learn/platform-attestation.md) para la comparación completa. Estándar también incluye un paquete de telemetría ensamblado automáticamente por Blerify: la dirección IP de la billetera capturada cuando envía los datos de atestación, la IP de sesión del verifier si se proporciona al iniciar la sesión, una bandera de correlación de IP, geolocalización del lado del servidor de ambas IP con una bandera de coincidencia de país, modelo del dispositivo y versión del sistema operativo, y un renderizado del documento — una imagen de la credencial con solo los campos divulgados legibles y todo lo demás difuminado, para auditoría y revisión manual. Todo esto viaja en `signed_evidence`, un JWT firmado por Blerify que cualquier tercero puede verificar con la clave pública de Blerify. Nada de esto añade fricción para el usuario. La billetera envía los datos de atestación por un canal en segundo plano; Blerify captura las IP y la geolocalización automáticamente; el JWT firmado se emite cuando la sesión se completa. El usuario ve la misma pantalla de consentimiento y la solicitud biométrica que en Básico. Estándar solo es posible con una billetera de Blerify que implemente las extensiones de atestación. **Casos de uso típicos:** verificación de identidad, KYC, apertura de cuentas, operaciones bancarias estándar, integraciones con servicios gubernamentales. *** ### Premium (próximamente) Premium se construye sobre Estándar al agregar verificación de integridad del dispositivo y verificación biométrica del lado del servidor. Responde una pregunta que los niveles inferiores no pueden responder: ¿la persona que presenta esta credencial es la misma a la que se le emitió la credencial? Premium está por llegar — las propiedades siguientes describen lo que prueba una vez disponible. Propiedades adicionales que prueba Premium: | Propiedad | Cómo se prueba | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | El dispositivo y la aplicación son genuinos | Atestación del dispositivo (Play Integrity en Android) | | El presentador es el sujeto de la credencial | Prueba de vida del lado del servidor — análisis antisuplantación más comparación facial con el retrato incrustado en la credencial | | Antisuplantación | Detección de ataques pasivos y activos: foto, reproducción de video, video manipulado con IA, máscara 3D | La comprobación de prueba de vida se ejecuta en la infraestructura de Blerify, no en el dispositivo. Esto produce evidencia independiente — el resultado proviene de una parte que el verifier puede auditar, no del propio dispositivo del usuario. También significa que la antisuplantación del lado del servidor detecta ataques sofisticados que las verificaciones en el dispositivo no detectan. Los datos de la prueba de vida se procesan y se eliminan de inmediato. Blerify conserva solo el resultado booleano y una puntuación de confianza de coincidencia. No se almacenan plantillas biométricas. Premium también proporciona opcionalmente una señal anti-coacción derivada de los mismos fotogramas de cámara capturados durante el desafío de prueba de vida. El seguimiento de la mirada y el análisis de microexpresiones se ejecutan en silencio junto con la comprobación de prueba de vida, invisibles tanto para el usuario como para cualquier posible coaccionador. Si se detectan anomalías, se informan en el resultado — el flujo nunca se interrumpe y no se muestra ningún error al usuario. Tu backend decide cómo actuar sobre la señal. **iOS y atestación del dispositivo:** iOS no tiene un equivalente de la API Play Integrity de Android para aplicaciones de terceros. En iOS, `device_attestation` siempre es `null` con `device_attestation_reason: "platform_not_available"`. Esta es una limitación estructural de la plataforma, no una falla. La diferencia de Premium en iOS proviene por completo de la capa de prueba de vida, que funciona idénticamente en ambas plataformas. Premium requiere una billetera de Blerify. **Casos de uso típicos:** operaciones bancarias de alto valor (solicitudes de préstamo, firma de contratos), procesos legales, procesos regulados que requieren una revalidación independiente de la identidad. *** ## Cómo elegir un nivel El nivel adecuado depende de la consecuencia de equivocarse. **Usa Básico cuando** necesitas confirmar que una credencial es válida y que el presentador la posee, y el impacto de un falso positivo es limitado. Cualquier billetera compatible con estándares funciona. **Usa Estándar cuando** necesitas confianza de que la credencial está vinculada a hardware real y autorizada por la biometría de su titular. Adecuado para KYC, apertura de cuentas y la mayoría de las integraciones con servicios gubernamentales y financieros. La evidencia adicional se recopila de forma transparente — sin fricción adicional para el usuario. **Usa Premium cuando** necesitas confirmar de forma independiente que la persona físicamente presente es el sujeto de la credencial (próximamente). Adecuado para operaciones de alto valor donde el costo del fraude de identidad es significativo: préstamos, firma de contratos, procesos legales. Añade un paso de prueba de vida de unos segundos. Puedes ejecutar distintos niveles para distintas operaciones dentro del mismo producto. Un banco podría verificar en Estándar para transferencias estándar y exigir Premium para solicitudes de préstamo. **Atajo de decisión.** Pregúntate cuál es la consecuencia de equivocarte: * *Un adolescente que elude tu control de edad con la credencial de un hermano mayor* → Básico es suficiente. * *Un atacante abre una cuenta a nombre de una identidad robada* → Estándar eleva el requisito a necesitar acceso físico al teléfono de la persona real y a su biometría. * *Un atacante firma un contrato de alto valor haciéndose pasar por otra persona* → Premium añade prueba de vida, haciendo esto esencialmente imposible sin que la persona real esté físicamente presente. *** ## Campos de evidencia La respuesta de la verificación incluye un `evidencia` objeto junto con las declaraciones de la credencial. Cada campo te dice qué se comprobó y qué se confirmó. Para ver el esquema completo a nivel de campo y los ejemplos de solicitud/respuesta, consulta el [Referencias de la API](https://dev.blerify.com). ### Básico | Campo | Fuente | Descripción | | ----------------- | ------- | --------------------------------------------- | | `marca de tiempo` | Blerify | Hora exacta en que se procesó la presentación | ### Estándar (incluye Básico) | Campo | Fuente | Descripción | | -------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `billetera_ip` | Blerify | Dirección IP de la conexión de la billetera con Blerify al enviar datos de atestación | | `client_reported_ip` | Verifier | IP de la sesión web del usuario, cuando se reportó una al crear la sesión; de lo contrario, ausente | | `ip_match` | Blerify | Si `billetera_ip` y `client_reported_ip` coinciden, cuando ambos están presentes. Una discrepancia no es necesariamente sospechosa (NAT, VPN, operador móvil), pero es una señal útil de auditoría | | `geolocalización` | Blerify | Geolocalización de IP del lado del servidor para ambas IP: país, región y ciudad por IP, más un indicador de coincidencia de país. Una señal de riesgo, no una prueba de ubicación — se puede evadir con una VPN | | `device_model` | Atestación de clave (Android) / billetera (iOS) | Modelo del dispositivo. Atestado por hardware en Android; autoinformado en iOS | | `os_version` | Atestación de clave (Android) / billetera (iOS) | Versión del sistema operativo y nivel de parche. Atestado por hardware en Android; autoinformado en iOS | | `device_metadata.attested` | Blerify | `true` cuando el modelo del dispositivo y la versión del sistema operativo provienen de la cadena de certificados atestada por hardware; `false` en iOS | | `key_attestation` | billetera + Blerify | Si la clave de firma reside en hardware resistente a manipulaciones y cómo está protegida. Consulta [Campos de atestación de la clave](#key-attestation-fields) | | `document_render` | billetera | Imagen de la credencial renderizada por la billetera con los campos revelados legibles y todos los demás difuminados. Pensada para auditoría y revisión manual | | `signed_evidence` | Blerify | JWT firmado por Blerify que contiene el resultado completo y todos los campos de evidencia. Verificable por cualquier tercero frente a la clave pública de Blerify. Blerify no conserva esto por defecto más allá del TTL de la sesión — tú eres el custodio | De estos, **`document_render` es el elemento que requiere una regla Estándar** — su ausencia hace que la verificación falle con `required_fields_missing`. Los demás campos se recopilan cuando la billetera puede proporcionarlos y llegan como `null` con un `_reason` de lo contrario. ### Premium (incluye Básico y Estándar) — próximamente | Campo | Fuente | Descripción | | ----------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `device_attestation` | Play Integrity (Android) / no disponible (iOS) | Integridad del dispositivo y de la aplicación. Confirma que el dispositivo ejecuta una imagen genuina del fabricante, tiene un cargador de arranque bloqueado, ejecuta el binario legítimo de la aplicación y cuenta con parches de seguridad recientes. Siempre `null` en iOS con `device_attestation_reason: "platform_not_available"` | | `liveness_verification` | Blerify | Resultado de vitalidad del lado del servidor: `verificado` (boolean), `match_confidence` (0–1), `spoof_detected` (boolean) | | `coercion_check` | billetera + Blerify | Análisis anticoerción de la sesión de vitalidad: `status` (`CLEAR`, `GAZE_ANOMALY`, o `EXPRESSION_ANOMALY`), `method` (`"facial"`), `alert` (indicador booleano de conveniencia). Se produce silenciosamente; nunca interrumpe el flujo | ### Campos de atestación de la clave El `key_attestation` objeto y su `key_biometric_binding` subobjeto describen las garantías de la clave a nivel de hardware: | Campo | Android | iOS | | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------- | | `security_level` | `STRONG_BOX` o `TRUSTED_ENVIRONMENT`, extraído del certificado firmado por hardware | `SECURE_ENCLAVE`, informado por la billetera | | `security_level_attested` | `true` | `false` | | `key_biometric_binding.biometric_required` | Atestado — extraído del certificado de atestación de la clave | Informado por la billetera | | `key_biometric_binding.auth_type` | Atestado — p. ej. `FINGERPRINT`, `FACE`, o `DEVICE_CREDENTIAL` | Informado por la billetera | | `key_biometric_binding.auth_timeout_seconds` | Atestado — `0` significa que se requieren biometrías en cada operación, sin ventana de reutilización | Informado por la billetera | | `key_biometric_binding.invalidated_on_enrollment_change` | Atestado — `true` significa que la clave se destruye si se agregan nuevas biometrías al dispositivo | Informado por la billetera | | `key_biometric_binding.attested` | `true` | `false` (siempre) | El `auth_type` y `biometric_required` Los campos reflejan el factor de autenticación vinculado a la clave en el momento de su creación. En dispositivos sin una biometría fuerte registrada, la clave se vincula al código de acceso o PIN del dispositivo — `auth_type` será `["DEVICE_CREDENTIAL"]` y `biometric_required` será `false`. Esto es correcto, no es una degradación: la clave sigue estando en hardware y requiere autenticación del usuario en cada operación de firma. ### StrongBox frente a TEE en Android Los dispositivos Android reportan cualquiera de `STRONG_BOX` o `TRUSTED_ENVIRONMENT` como el `security_level`. Ambos se aceptan en Estándar y Premium. Un TEE (Entorno de ejecución confiable) es un entorno de ejecución aislado por hardware en el mismo procesador, presente en prácticamente todos los dispositivos Android desde 2016. Un StrongBox es un procesador de seguridad dedicado y resistente a la manipulación, con su propia CPU y almacenamiento — presente en muchos modelos insignia actuales, pero no disponible de forma universal en hardware de gama media. StrongBox ofrece garantías de aislamiento más sólidas que un TEE. Ambos niveles de seguridad aparecen en `evidence.key_attestation.security_level` para que puedas aplicar tu propia política de aceptación si un caso de uso específico exige StrongBox. Para la mayoría de las integraciones, aceptar ambos es el valor predeterminado correcto. ### Motivos de ausencia Cuando un campo opcional de evidencia está ausente, un campo complementario `_reason` explica por qué. El campo de motivo siempre está presente — se completa `null` cuando el propio campo de evidencia tiene contenido. | Valor | Significado | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `null` | El campo de evidencia tiene contenido — no hay ausencia que explicar | | `"platform_not_available"` | La plataforma no tiene una API para esta capacidad (p. ej., `device_attestation` en iOS) | | `"billetera_no_soportada"` | La billetera no implementa la extensión de Blerify | | `"not_requested"` | El verifier no configuró este nivel ni esta función | | `"user_declined"` | El usuario denegó un permiso requerido (p. ej., la cámara para la verificación de presencia) | | `"failed"` | Se intentó la comprobación, pero fue rechazada (p. ej., se detectó una suplantación, falló la comprobación de integridad) | | `"attestation_not_supported"` | El dispositivo tiene un almacén de claves de hardware, pero es anterior a la API de atestación de claves; es probable que la clave esté respaldada por hardware, pero no se puede demostrar criptográficamente | La distinción entre `"platform_not_available"` y `"user_declined"` es importante para las decisiones de política. Un usuario que rechaza la verificación de presencia es una señal de riesgo distinta de una plataforma que, estructuralmente, no puede proporcionar atestación del dispositivo. Tu política de verificación puede tratarlos de forma diferente. *** ## Asimetría de atestación de la plataforma Android e iOS ofrecen capacidades de atestación fundamentalmente diferentes. No son mecanismos equivalentes con diferencias menores: las arquitecturas subyacentes son distintas. ### Atestación de clave En **Android**, la cadena de certificados de atestación de clave es generada por el hardware en el momento de crear la clave y firmada por el TEE o StrongBox. Las propiedades de la clave, incluidos los requisitos biométricos, el tiempo de espera de autenticación y el comportamiento de invalidación, están todas incrustadas en el certificado firmado. En **iOS**, no existe una API de Apple que produzca un certificado equivalente para claves de Secure Enclave en aplicaciones de terceros. App Attest demuestra que una instancia genuina y no modificada de la app de billetera registrada en hardware Apple real creó y posee la clave. Las propiedades de la clave, como la vinculación biométrica, son auto reportadas por la billetera. La `key_biometric_binding.attested` el campo siempre está `false` en iOS. Esto no significa que las claves de iOS sean menos seguras. La Secure Enclave aplica los controles de acceso que configuró la billetera — incluyendo exigir Face ID o Touch ID para cada operación de firma e invalidar la clave cuando cambia el registro biométrico. La limitación es que estos controles no pueden verificarse de forma independiente de manera remota. Apple no ha proporcionado una API pública para esto en aplicaciones de terceros. ### Atestación de dispositivo Android proporciona Play Integrity, que verifica de forma independiente que el dispositivo usa una imagen certificada del fabricante, tiene el gestor de arranque bloqueado, ejecuta el binario legítimo de la app y tiene aplicados parches de seguridad recientes. iOS no tiene una API equivalente para aplicaciones de terceros. `device_attestation` siempre es `null` en iOS con `_reason: "platform_not_available"`. Esta es una limitación estructural de la plataforma, no un fallo. ### Resumen por nivel y plataforma | Evidencia | Básico | Android Estándar | iOS Estándar | Android Premium | iOS Premium | | ------------------------------------------- | ------ | ---------------- | ------------ | --------------- | --------------- | | Credencial válida | ✅ | ✅ | ✅ | ✅ | ✅ | | Vinculación del titular | ✅ | ✅ | ✅ | ✅ | ✅ | | Clave en hardware (atestiguada) | — | ✅ | — | ✅ | — | | Clave en hardware (autodeclarada) | — | — | ✅ | — | ✅ | | Vinculación biométrica (atestiguada) | — | ✅ | — | ✅ | — | | Vinculación biométrica (autodeclarada) | — | — | ✅ | — | ✅ | | Telemetría de auditoría + `signed_evidence` | — | ✅ | ✅ | ✅ | ✅ | | Integridad del dispositivo (Play Integrity) | — | — | — | ✅ | ❌ no disponible | | Prueba de vida + coincidencia facial | — | — | — | ✅ | ✅ | ### Política recomendada para iOS Estándar Acepta Estándar en iOS de la misma manera que lo aceptas en Android. Un dispositivo iOS con `security_level_attested: false` y `key_biometric_binding.attested: false` no es una degradación ni una señal de fraude — refleja la decisión arquitectónica de Apple de no exponer una API equivalente de atestación de hardware a desarrolladores de terceros. El Secure Enclave sigue imponiendo requisitos biométricos en cada operación de firma. Si tu caso de uso requiere propiedades de clave atestiguadas por hardware sin importar la plataforma, aplica un control independiente de la plataforma en lugar de tratar estos campos como una condición de falla. Para los casos de uso en los que la ausencia de atestación de hardware en iOS sea inaceptable, Premium cierra la brecha — App Attest confirma que la aplicación de billetera y el dispositivo son genuinos, y la prueba de vida vuelve a verificar de forma independiente la identidad de quien presenta. *** ## `effective_tier` frente a `assurance_level` Tu regla de verificación especifica un `assurance_level` — el nivel que estás solicitando. La respuesta también incluye `effective_tier`; conservado para compatibilidad hacia atrás: **en un `COMPLETED` resultado, ambos siempre coinciden.** No hay una degradación silenciosa: si falta evidencia que tu regla requiere, la verificación falla con una razón explícita en lugar de completarse en un nivel inferior. El nivel mide qué clases de evidencia llegaron y fueron validadas, no si el contenido de esa evidencia es favorable. Un resultado Estándar todavía puede contener `ip_match: false` o `geolocation.country_match: false` — esos son indicadores de contenido que evalúas contra tu propia política de riesgo; no cambian el nivel. Lo que sucede cuando falta evidencia depende de cómo tu regla clasifica cada elemento: * **Requerido** — si el elemento nunca llega (incluso cuando el usuario está en una billetera de terceros que no implementa en absoluto las extensiones de Blerify), la sesión se finaliza como `FAILED` con `reason: "required_fields_missing"`y el `message` campo enumera lo que faltaba. * **Opcional** — la sesión se completa en el nivel que configuraste; el campo de evidencia faltante regresa `null` y su `_reason` campo te indica por qué. *** ## No repudio en el nivel Estándar El nivel Estándar establece una cadena de evidencia que dificulta que el titular de una credencial niegue de forma creíble haber autorizado una presentación. Cada elemento aborda un argumento específico: | Argumento | Por qué no es válido | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Alguien copió mi clave" | La clave reside en hardware resistente a manipulaciones y no puede extraerse ni duplicarse. La atestación de la clave lo demuestra criptográficamente | | "Alguien usó mi clave sin mi consentimiento" | Cada operación de firma requiere la biometría del titular sin ventana de reutilización (`auth_timeout_seconds: 0`) | | "Alguien registró su biometría en mi dispositivo" | La clave se destruye automáticamente si se agregan nuevos datos biométricos (`invalidated_on_enrollment_change: true`) | | "La evidencia fue fabricada" | El `signed_evidence` JWT está firmado por Blerify y es verificable por cualquier tercero con la clave pública de Blerify — no puede alterarse sin detección | En Android, cada elemento de esta cadena cuenta con atestación de hardware — las propiedades están firmadas por el TEE o StrongBox, no declaradas por la billetera. En iOS, las propiedades son autodeclaradas pero corroboradas en Premium por App Attest, que confirma que la app de la billetera y el dispositivo son genuinos. *** ## Sin almacenamiento biométrico El modelo de detección de vida de Blerify en Premium es estructuralmente diferente de los servicios tradicionales de verificación de identidad. Los proveedores tradicionales almacenan una imagen facial o una representación biométrica. Se convierten en custodios de datos biométricos sujetos a obligaciones estrictas bajo el RGPD y leyes equivalentes. Si su infraestructura se ve comprometida, los datos biométricos quedan expuestos de forma permanente — a diferencia de las contraseñas, los rostros no pueden cambiarse. Blerify elimina este riesgo por diseño. La credencial emitida por una autoridad ya contiene el retrato del titular, firmado por el emisor. Blerify no almacena una foto de referencia. Cuando se ejecuta la verificación Premium, la selfie capturada durante la detección de vida y el retrato extraído de la credencial se comparan y se eliminan de inmediato. El único artefacto conservado es el resultado booleano y una puntuación de confianza. Tu backend nunca recibe una imagen facial, una plantilla ni ningún dato biométrico. Para conocer todos los detalles técnicos de cómo funciona esto, consulta [Vinculación biométrica](/es/introduccion-a-la-verificacion/learn/biometric-binding.md). *** ## Relación con eIDAS y NIST Esta sección es informativa. Los niveles de Blerify no constituyen afirmaciones de equivalencia regulatoria formal. | Nivel de Blerify | Nivel eIDAS más cercano | AAL de NIST más cercano | SCA de PSD2 | | ---------------- | ----------------------- | ----------------------- | -------------------------------- | | Básico | \~Bajo | \~AAL1 | Por debajo de SCA (factor único) | | Estándar | \~Sustancial | \~AAL2 | Cumple con SCA | | Premium | Excede el alcance | Excede el alcance | Excede SCA | **Estándar y \~AAL2 / \~eIDAS Sustancial.** La biometría del dispositivo que activa la clave de firma vinculada al hardware califica como autenticación multifactor bajo ambos marcos — algo que tienes (el dispositivo con la clave en hardware) más algo que eres (la biometría que la activa). La equivalencia es informativa porque los teléfonos de consumo cumplen funcionalmente con el nivel de seguridad, pero no cuentan con las certificaciones del dispositivo final requeridas para una declaración formal de cumplimiento. **Por qué Premium no se corresponde con eIDAS High ni con NIST AAL3.** Premium supera los requisitos de autenticación de ambos — añade detección de vida del lado del servidor y comparación facial independiente, ninguna de las cuales esos marcos exigen para la autenticación. Sin embargo, ambos requieren certificaciones de hardware en los niveles más altos que los teléfonos inteligentes de consumo cumplen solo parcialmente a nivel del dispositivo final. Esta es una limitación de toda la industria para billeteras basadas en teléfonos de consumo, no específica de Blerify. Blerify usa sus propios nombres de niveles para evitar implicar certificaciones que todavía no existen de extremo a extremo para dispositivos de consumo. *** ## Configuración de requisitos de nivel Estableces el nivel de garantía requerido en tu regla de verificación en el Portal. Una verificación termina en ese nivel o falla con un motivo explícito — no hay un resultado intermedio. Para conocer el esquema completo de respuesta de evidencia, los parámetros de solicitud y los detalles de configuración de la verificación, consulta el [Referencias de la API](https://dev.blerify.com). *** ## Próximos pasos **Continúa con** [**Vinculación biométrica**](/es/introduccion-a-la-verificacion/learn/biometric-binding.md) — cómo la clave de firma de la credencial está vinculada a la biometría del usuario, qué garantiza cada nivel sobre esa vinculación y dónde están los límites. Ver también: [Atestación de plataforma](/es/introduccion-a-la-verificacion/learn/platform-attestation.md) · [Leer un resultado de verificación](/es/introduccion-a-la-verificacion/build/read-a-verification-result.md) · [Referencias de la API](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/es/introduccion-a-la-verificacion/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.