> 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/how-it-works.md). # Cómo funciona Cada credencial en Blerify involucra a tres partes: un **emisor** que la crea (un gobierno, una universidad, un empleador), un **titular** que la lleva en la billetera de su teléfono, y un **verifier** que la verifica. Lo que hace potente al modelo es lo que falta: no hay una base de datos central a la que nadie tenga que recurrir ni en la que tenga que confiar. La credencial misma contiene la prueba. Este diseño sigue el Estándar de Credenciales Verificables de W3C. Esta página explica cómo funciona eso de extremo a extremo: cómo se emite una credencial, cómo se verifica y cuánto puedes confiar en cada verificación. *** ## Los tres participantes | Participante | Qué hacen | Producto de Blerify | | ------------ | -------------------------------------------------------------------------------- | ------------------- | | **Emisor** | Crea y firma criptográficamente una credencial, y luego se la entrega al titular | Emisión | | **titular** | Almacena la credencial en su dispositivo, decide qué compartir y con quién | Billetera de ID | | **Verifier** | Le pide al titular que presente una credencial y verifica su validez | Verificación | Estos tres roles nunca necesitan comunicarse directamente entre sí. La confianza entre ellos se establece mediante la firma criptográfica de la credencial y mediante el Registro de Confianza de Blerify, que registra qué emisores están autorizados para emitir qué tipos de credenciales. *** ## Flujo de extremo a extremo ### 1 — Emisión El emisor crea una credencial que contiene los datos del titular — nombre, número de documento, calificación, o lo que requiera el Caso de uso —, la firma con su clave privada y la entrega a la billetera del titular. ``` backend del emisor ──▶ API de Emisión de Blerify ──▶ credencial firmada │ ▼ Billetera del titular ``` La credencial se firma una vez en el momento de la emisión y nunca se modifica después. Si el emisor la revoca más adelante, actualiza el registro de revocación. La credencial en la billetera permanece sin cambios, pero cualquier verificación posterior reflejará el estado revocado. ### 2 — En espera El titular recibe la credencial en la Blerify billetera mediante un código QR, un enlace profundo o una notificación push. La billetera almacena la credencial en el dispositivo, cifrada en reposo y desbloqueable únicamente con la biometría o el PIN del titular. El titular controla el consentimiento: cuando un verifier solicita una credencial, la billetera les muestra exactamente qué campos se compartirán antes de que nada salga del dispositivo. ### 3 — Presentación El titular presenta la credencial al verifier. Esto puede ocurrir de tres maneras: **Del mismo dispositivo** — el titular está en una página web móvil o dentro de una aplicación nativa. Un botón o enlace profundo abre la Blerify billetera en el mismo teléfono. Aprueba con sus datos biométricos y la aplicación o página recibe el resultado. **Entre dispositivos** — el titular está en un escritorio. Escanea un código QR con su teléfono. La billetera se abre, aprueba y la página de escritorio se actualiza. **De app a app** — el titular está dentro de una aplicación móvil nativa. Un enlace profundo abre la billetera directamente. La billetera termina y devuelve el foco a la aplicación que la llamó. En los tres casos, se requiere la aprobación explícita del titular antes de que cualquier dato salga de su dispositivo. ### 4 — Verificación El backend del verifier crea una sesión de verificación con Blerify y recibe un `transaction_id`. El frontend del verifier usa eso para generar un código QR o un enlace profundo para el titular. La billetera envía una presentación firmada directamente a Blerify. El backend del verifier consulta periódicamente el resultado. ```mermaid sequenceDiagram participant VB as Verifier Backend participant Blerify participant VF as Verifier Frontend participant W as Billetera del titular VB->>Blerify: Crear sesión de verificación Blerify-->>VB: transaction_id Note over VB,VF: Backend entrega transaction_id al frontend VF->>W: Mostrar código QR / enlace profundo W->>Blerify: Enviar presentación firmada VB->>Blerify: Consultar el resultado Blerify-->>VB: Datos verificados ``` El backend del verifier es la única parte que llama a la API de Blerify. El token de la cuenta de servicio que autentica esas llamadas nunca debe exponerse a un navegador o una app móvil. *** ## Qué valida Blerify Cuando se presenta una credencial, Blerify ejecuta automáticamente todas estas comprobaciones: | Comprobación | Qué verifica | | -------------------------------- | ------------------------------------------------------------------------------------------------ | | **Firma** | La credencial fue firmada por una clave perteneciente a un emisor registrado | | **Cadena de confianza** | El emisor está en el Registro de confianza y está autorizado para emitir este tipo de credencial | | **Revocación** | El emisor no ha revocado esta credencial | | **Vencimiento** | La credencial está dentro de su período de validez | | **Vinculación del titular** | La presentación fue realizada por la persona que controla la clave privada de la credencial | | **Protección contra repetición** | La presentación incluye un valor aleatorio de un solo uso nuevo — no puede reutilizarse | No implementas ninguna de estas verificaciones. Recibes un resultado estructurado en cada una y aplicas tu propia política de acceso encima. *** ## El Registro de confianza El Registro de confianza es la fuente de verdad de quién puede emitir qué. Cuando Blerify valida una credencial, verifica el registro para confirmar: * El emisor existe y está Activa * El emisor está autorizado para emitir el tipo específico de credencial que se presenta * La clave de firma del emisor coincide con lo registrado en el registro El Registro de confianza usa el método DID de Blerify (did:lac1) para anclar las identidades de los emisores en un libro mayor público. Esto significa que la cadena de confianza es verificable por cualquiera, incluidos los verificadores fuera del ecosistema de Blerify. Ver [Raíz de confianza descentralizada](/es/registro-de-confianza/decentralized-root-of-trust.md) para el modelo técnico completo. *** ## Formatos de credenciales **Credenciales verificables de W3C** son documentos JSON firmados como JWTs. El esquema es flexible — los emisores definen sus propios tipos de afirmaciones. Se usan comúnmente para credenciales blandas: licencias, insignias, estado KYC, registros laborales. **mDocs ISO 18013** son documentos binarios CBOR que siguen el estándar ISO 18013-5 para licencias de conducir móviles. El esquema está definido por el estándar ISO y usa nombres de campo y espacios de nombres estandarizados. Se usan para documentos de identidad gubernamentales. Ambos formatos viajan de la misma manera, sobre OpenID4VP — el protocolo abierto que las wallets usan para presentar credenciales a los verificadores. El flujo de validación detecta el formato y lo enruta automáticamente a la ruta de verificación adecuada. *** ## niveles de garantía No todas las verificaciones tienen el mismo peso. Blerify reporta un `assurance_level` — `Básico`, `STANDARD`, o `PREMIUM` — junto a cada resultado de verificación. El nivel refleja lo que puede demostrarse de forma independiente ante ti, no solo lo que afirma la billetera. | Nivel | Lo que prueba | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Básico** | El credential es criptográficamente válido, el emisor es de confianza, el credential no está revocado y el titular lo presentó en tiempo real. Funciona con cualquier billetera que siga el Estándar de presentación abierto. | | **Estándar** | Todo lo de Básico, más que la clave de firma se demuestra que reside en hardware resistente a manipulaciones (TEE o Secure Enclave). El verifier recibe una cadena de certificados de atestación de hardware que puede validar de forma independiente contra las raíces de Google o Apple. | | **Premium** (próximamente) | Todo lo de Estándar, más se confirma que la persona que sostiene físicamente el dispositivo es el sujeto de la credencial. Blerify captura una selfie en vivo desde la billetera, la compara con la foto incrustada en la credencial firmada y devuelve el resultado. | El nivel que recibes depende de la billetera que envía la prueba. Cualquier billetera que siga el estándar abierto logra Básico. Estándar y Premium requieren la Blerify Wallet, que envía evidencia de atestación de hardware junto con la presentación de la credencial. Tú eliges el nivel cuando configuras la verificación. Si la billetera no puede proporcionar la evidencia que requiere ese nivel, la verificación falla con un motivo explícito en lugar de completarse silenciosamente en un nivel inferior. Ver [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md) para el modelo completo, incluida la correspondencia informativa con los marcos eIDAS y NIST. *** ## Modelo de privacidad **Divulgación selectiva.** Cuando un verificador solicita una credencial, especifica qué campos necesita. La billetera muestra una pantalla de consentimiento que enumera exactamente esos campos. El titular aprueba o rechaza. Blerify solo reenvía lo que el titular aprobó. **Sin llamadas a casa.** El emisor no recibe una notificación cuando un titular presenta una credencial. Blerify no mantiene un registro de presentaciones accesible para los emisores. La participación del emisor termina en la emisión. **Almacenamiento en el dispositivo.** Las credenciales se almacenan en la Blerify Wallet en el dispositivo del titular, no en una base de datos en la nube de Blerify. Si el titular desinstala la billetera, las credenciales desaparecen de los sistemas de Blerify. **Sin almacenamiento biométrico.** Cuando se solicita la garantía Premium, Blerify compara una selfie en vivo con la foto incrustada en la credencial y luego borra ambas de inmediato. Blerify solo almacena el resultado booleano y un puntaje de confianza. No hay base de datos facial, no hay plantilla biométrica y no hay nada que comprometer más allá de un indicador de aprobado/reprobado. *** ## Próximos pasos * Emite tu primera credencial W3C — [Emisión: Empezar](/es/introduccion-a-la-emision/build/get-started.md) * Verifica tu primera credencial — [Verificación: Empezar](/es/introduccion-a-la-verificacion/build/get-started.md) * Entender cómo funcionan los anclajes de confianza — [Raíz de confianza descentralizada](/es/registro-de-confianza/decentralized-root-of-trust.md) * Aprender cómo los niveles de garantía se asignan a eIDAS y NIST — [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md) --- # 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/how-it-works.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.