API de Credenciales Digitales (2025): Chrome y Safari (WWDC25)

Última actualización: 15 de julio de 2025 (después de la WWDC25)

Un rápido vistazo al soporte de la API de Credenciales Digitales en los principales navegadores:

El mundo de las credenciales digitales avanza rápidamente. Aquí tienes un resumen de los desarrollos y proyecciones clave:

Las credenciales digitales son un tema candente en el espacio de la identidad en este momento. A medida que nuestras vidas se conectan cada vez más con el ámbito digital, la necesidad de formas seguras, centradas en el usuario y que preserven la privacidad para afirmar nuestra identidad y cualificaciones en línea nunca ha sido más crítica. Los métodos tradicionales están mostrando su edad, y la demanda de soluciones más robustas es palpable.

En este artículo, nuestro objetivo es discutir el estado actual de la API de Credenciales Digitales, un desarrollo importante que promete remodelar cómo interactuamos con la información de identidad en la web. Exploraremos sus mecanismos subyacentes, los protocolos que soporta, la adopción actual en los navegadores y ofreceremos recomendaciones tanto para los terceros de confianza (relying parties) como para los emisores (issuers) de wallets que navegan por este panorama en rápida evolución.

Probar la identidad de manera fiable y segura ha sido un desafío persistente en la arquitectura de la web durante muchos años. Si bien internet facilitó una conectividad e intercambio de información sin precedentes, también abrió nuevas vías para la suplantación de identidad y el fraude.

En algunos países, surgieron soluciones, impulsadas principalmente por los primeros consorcios bancarios que desarrollaron servicios para aprovechar las relaciones de confianza existentes para la identificación en línea. Los gobiernos también intervinieron, imponiendo o proporcionando servicios y wallets de identidad digital nacionales. Sin embargo, estas soluciones a menudo estaban aisladas, geográficamente limitadas y no eran universalmente interoperables.

La alternativa para la verificación de identidad en muchas regiones ha implicado tradicionalmente procesos de alta fricción. La verificación física en una oficina de correos, por ejemplo, introduce retrasos e inconvenientes significativos. Las videollamadas combinadas con la subida de documentos se convirtieron en una alternativa más digital, seguidas por el auge más reciente del escaneo automatizado de documentos y las pruebas de vida (liveness checks). A pesar de sus avances, estos métodos tienen inconvenientes significativos. Pueden consumir mucho tiempo, ser propensos a errores humanos o sesgos, y se ha demostrado con frecuencia que son vulnerables a falsificaciones sofisticadas.

El desafío está aumentando drásticamente con la llegada de los deepfakes, técnicas avanzadas de suplantación de identidad impulsadas por IA y ataques de phishing cada vez más sofisticados. Estas tecnologías pueden crear pruebas de video, audio y documentos muy realistas pero completamente fabricadas, lo que hace increíblemente difícil para los sistemas tradicionales, e incluso para las herramientas de verificación impulsadas por IA, distinguir a los usuarios genuinos de los fraudulentos. El potencial para crear identidades sintéticas o manipular datos biométricos para eludir las comprobaciones es una amenaza grave, especialmente para las instituciones financieras y cualquier servicio que requiera procesos robustos de Conoce a tu Cliente (KYC). Este panorama de amenazas en aumento subraya la necesidad urgente de mecanismos de identidad y verificación en línea más seguros y criptográficamente verificables.

Want to try digital credentials yourself in a demo?

Try Digital Credentials

Entender cómo operan las credenciales digitales implica observar a los actores clave involucrados y las diferentes capas tecnológicas que permiten su funcionalidad.

En su núcleo, el concepto de credenciales digitales, especialmente en el contexto de las nuevas API web, gira en torno a un modelo de tres partes:

1. Emisor (Issuer): Una entidad (p. ej., gobierno, universidad, empleador) que tiene autoridad sobre cierta información de un sujeto y puede emitir una credencial digital que atestigua esa información.
2. Titular (Holder): El sujeto de la información (es decir, el usuario) que recibe la credencial del emisor (issuer) y la almacena en una wallet digital. El titular controla cuándo y qué información de la credencial se comparte.
3. Verificador (Verifier o Relying Party): Una entidad (p. ej., un sitio web, un servicio en línea) que necesita verificar cierta información sobre el titular para conceder acceso a un servicio o recurso. El verificador solicita la información necesaria al titular.

Este modelo de tres partes es importante porque tiene como objetivo poner al usuario (titular) en control de sus propios datos. A diferencia de los sistemas de identidad tradicionales donde los datos pueden almacenarse centralmente o compartirse entre partes sin la intermediación directa del usuario, este modelo enfatiza el consentimiento del usuario y la divulgación selectiva. El titular decide qué piezas de información compartir de una credencial para una transacción específica, en lugar de revelar la credencial completa.

Un aspecto fundamental de estos sistemas es la participación de pares de claves criptográficas. El emisor (issuer) firma digitalmente la credencial, asegurando su autenticidad e integridad. El titular, a su vez, utiliza su clave privada, a menudo asegurada dentro de su wallet digital (que está protegida por el hardware del dispositivo), para demostrar el control sobre la credencial y autorizar su presentación a un verificador. Esto generalmente implica que el verificador presente un desafío (un dato aleatorio) que la wallet del titular firma usando la clave privada asociada con la credencial. El verificador puede entonces usar la clave pública correspondiente para confirmar la firma, autenticando así la presentación.

Esta explicación es neutral en cuanto al protocolo, ya que los principios básicos de emisión, tenencia y verificación a través de desafíos criptográficos son comunes en las diferentes tecnologías subyacentes.

Este artículo se concentra en la verificación de credenciales digitales y el principio de divulgación selectiva, permitiendo a los usuarios probar atributos específicos (p. ej., "Soy mayor de 18 años", "Poseo un permiso de conducir válido") sin revelar el documento fuente completo. Si bien los sistemas subyacentes para las credenciales digitales pueden soportar características como Firmas Electrónicas Cualificadas (QES) y capacidades de firma remota (como se ve en soluciones integrales como la Wallet de Identidad Digital de la UE para firmas legalmente vinculantes), el enfoque aquí, particularmente para la API de Credenciales Digitales, está en la aserción de identidad y la verificación de atributos para interacciones en línea, no principalmente en estas funcionalidades de firma más amplias.

Para entender cómo funcionan las credenciales digitales, es útil visualizar un modelo de capas. Cada capa aborda un aspecto diferente del ecosistema, desde el formato de los datos en sí hasta cómo se presentan a un usuario en un navegador web. Este artículo se centra principalmente en la API de Credenciales Digitales, que opera en la capa de presentación.

Terminología Clave:

• Credencial digital: Cualquier credencial legible por máquina (PDF con un código de barras, ISO mDL, W3C VC, SD-JWT, etc.). "Digital" no dice nada sobre la verificabilidad criptográfica.
• Credencial Verificable: Un tipo de credencial digital, definida por el Modelo de Datos de VC del W3C. Añade evidencia de manipulación y prueba criptográfica, y siempre vive en un mundo de tres partes: emisor → titular → verificador.
• API de Credenciales Verificables (VC API): Una interfaz de servicio REST/HTTP para emitir, almacenar, presentar y verificar VCs entre sistemas de back-end (emisores, wallets, verificadores).
• API de Credenciales Digitales (DC API): Una API de navegador / sistema operativo (JavaScript + componentes nativos) que permite a un sitio web pedir a la wallet del dispositivo del usuario que presente cualquier credencial digital soportada (VC, ISO mDoc, SD-JWT…) de una manera que respete la privacidad.

Piensa en las VCs como un modelo de datos, la VC API como una especificación de back-end, y la DC API como la implementación de front-end que presenta las credenciales a la Web. Todo lo que está por encima de la capa 1 (Capa de modelo de datos) es agnóstico al formato; todo lo que está por debajo depende del formato de la credencial.

Flujo de extremo a extremo (ejemplo: verificación de edad en línea):

1. Emisión (VC API - emisor ↔ wallet): El DMV estatal emite una Credencial Verificable que dice "El titular es mayor de 18 años".
2. Almacenamiento (App de Wallet - SO): La credencial se guarda en la wallet del usuario con su prueba criptográfica.
3. Solicitud (navigator.credentials.get() a través de DC API - sitio web → navegador): El sitio web de una tienda de licores pregunta: "Muéstrame una prueba de que el usuario es ≥18".
4. Presentación (DC API despacha a la wallet → OpenID4VP (protocolo) → payload de VC): La wallet muestra una interfaz de consentimiento, el usuario aprueba, la wallet envía de vuelta una presentación verificable.
5. Verificación (VC API - back-end de la tienda de licores): El back-end del sitio verifica la firma y el DID/clave pública del emisor (issuer); concede el acceso.

Observa cómo los datos son una VC, el transporte en la Web es la DC API, el protocolo de intercambio subyacente es OpenID4VP, y la comprobación del lado del servidor utiliza la VC API.

Por qué existe esta división:

• Modelo de datos interoperable (pruebas criptográficas, divulgación selectiva): Resuelto por el Modelo de Datos de VC (y otros formatos).
• Endpoints REST estándar para sistemas de back-end: Resuelto por la VC API.
• Handshake entre Wallet y sitio web que preserva la privacidad: Resuelto por la DC API.
• Diferentes niveles de confianza / tipos de documentos (ID gubernamental vs. certificado de curso): Resuelto usando el formato correcto (ISO mDoc para IDs de alta seguridad; W3C VC para afirmaciones generales) bajo la DC API.

Puntos clave:

1. "Credencial digital" es el término general.
2. La Credencial Verificable es un tipo de credencial digital con verificabilidad criptográfica incorporada.
3. La VC API es la fontanería de servidor a servidor para operaciones del ciclo de vida de las VCs.
4. La API de Credenciales Digitales es el puente entre el navegador y la wallet que finalmente permite que esas credenciales fluyan sin problemas hacia las aplicaciones web, sin importar el formato concreto en el que se encuentren.
5. Las tres piezas son complementarias, no competidoras: se sitúan en diferentes capas de la misma pila y juntas permiten una identidad segura y centrada en el usuario en la Web abierta.

Habiendo explorado los participantes y la arquitectura general en capas de las credenciales digitales, este artículo profundizará ahora en la capa de presentación, centrándose específicamente en la API de Credenciales Digitales y su estado actual.

Como componente crucial en la capa de presentación, la API de Credenciales Digitales es un estándar web que se está desarrollando actualmente para proporcionar una forma segura y estandarizada para que los sitios web soliciten y reciban información de identidad digital de las wallets digitales de los usuarios. Este esfuerzo se aloja principalmente dentro del Grupo de Trabajo de Identidad Federada (FedID WG) del W3C, habiendo migrado del Grupo Comunitario FedID en abril de 2025. El borrador oficial de la especificación se puede encontrar aquí: https://w3c-fedid.github.io/digital-credentials/.

En 2025, la API todavía se describe como en proceso de cambios significativos. Esto resalta su fase de desarrollo activo. A pesar de esto, su potencial es significativo. Chrome ha sido el primero en lanzar algo público, con su Origin Trial, permitiendo a los desarrolladores experimentar con sus capacidades. Chrome también soporta esto de forma nativa en Android a través de su sistema Credential Manager y recientemente también ha publicado soporte para el uso de la API de Credenciales Digitales Cross-Device en escritorio.

La API extiende la API de Gestión de Credenciales existente al permitir solicitudes de credenciales digitales a través de navigator.credentials.get(). Según el Explicador de Credenciales Digitales del W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), la API ha vuelto a usar esta interfaz establecida en lugar de la previamente propuesta navigator.identity. Un sitio web solicita una credencial digital llamando a navigator.credentials.get() con parámetros específicos para credenciales digitales.

Aquí hay un ejemplo ilustrativo de cómo un sitio web podría llamar a la API para solicitar una credencial usando OpenID4VP:

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Este ejemplo está tomado de aquí.

La API de Credenciales Digitales actúa esencialmente como un contenedor seguro o intermediario. Permite que el navegador medie la solicitud de información de identidad, aprovechando las capacidades del sistema operativo subyacente para descubrir wallets y credenciales disponibles que coincidan con la solicitud. El navegador y el SO pueden entonces presentar una interfaz de usuario consistente para seleccionar la credencial y autorizar su liberación, mejorando la seguridad y la privacidad al garantizar el consentimiento del usuario y evitar que los sitios web accedan silenciosamente a datos sensibles. Los datos reales de la credencial en la respuesta están destinados a ser opacos (cifrados) para el propio navegador, con el descifrado e interpretación manejados por el tercero de confianza (relying party) y la wallet/titular.

La API de Credenciales Digitales está diseñada para ser agnóstica al protocolo, lo que significa que puede soportar varios protocolos subyacentes para el intercambio de credenciales. Sin embargo, dos familias principales de protocolos son centrales para las implementaciones y discusiones actuales: org.iso.mdoc (derivado de ISO 18013-5 y su extensión ISO 18013-7 "Anexo C") y las especificaciones de la Fundación OpenID, OpenID for Verifiable Presentations (OpenID4VP) y OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Origen y Estandarización: org.iso.mdoc se refiere al formato de datos y modelo de interacción para documentos móviles, principalmente permisos de conducir móviles (mDLs), estandarizados por la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC). El estándar fundamental es ISO/IEC 18013-5, que define la aplicación mDL, la estructura de datos y los protocolos para la presentación en persona (proximidad) utilizando tecnologías como NFC, Bluetooth o códigos QR. ISO/IEC 18013-7 extiende esto para permitir la presentación en línea/remota de mDLs. La cadena de protocolo "org.iso.mdoc" se define específicamente en ISO/IEC TS 18013-7 (Anexo C) para su uso con APIs como la API de Credenciales Digitales.

• Modelo de Datos: Los mdocs tienen una estructura de datos estrictamente definida basada en CBOR (Concise Binary Object Representation) para compacidad y eficiencia. Especifica espacios de nombres y elementos de datos para atributos comunes de permisos de conducir y soporta fuertes características de seguridad criptográfica, incluyendo autenticación del emisor (issuer), vinculación al dispositivo, autenticación del titular (a través de retrato), cifrado de sesión y divulgación selectiva.

• Casos de Uso Típicos: Principalmente documentos de identidad emitidos por el gobierno como permisos de conducir e identificaciones nacionales. Está diseñado para escenarios de alta seguridad, tanto en persona (p. ej., controles de tráfico, verificación de edad para productos restringidos) como en línea (p. ej., acceso a servicios gubernamentales, verificación de identidad remota para la apertura de cuentas bancarias).

• Origen y Estandarización: OpenID4VP (para presentación) y OpenID4VCI (para emisión) son especificaciones desarrolladas por la Fundación OpenID. Extienden OAuth 2.0 para soportar el intercambio de credenciales verificables. Son estándares abiertos destinados a una amplia interoperabilidad para varios tipos de credenciales, no solo gubernamentales. A principios de 2025, OpenID4VP se encuentra en etapas avanzadas de borrador (p. ej., borrador 28 en abril). OpenID4VCI también está madurando.
• Modelo de Datos: OpenID4VP/VCI están diseñados para ser agnósticos al formato de credencial. Pueden transportar Credenciales Verificables (VCs) del W3C en formatos JSON/JSON-LD o JWT, mdocs, SD-JWTs y otros formatos. El modelo de interacción implica una Solicitud de Autorización del Verificador (RP) y una respuesta de la Wallet del Titular que contiene un vp_token (Token de Presentación Verificable). La divulgación selectiva se gestiona típicamente usando lenguajes de consulta como Presentation Exchange (DIF PE) o el más nuevo Digital Credentials Query Language DCQL.
• Casos de Uso Típicos: Amplia gama de aplicaciones, incluyendo verificación de identidad, prueba de cualificaciones (p. ej., diplomas educativos, certificaciones profesionales), atestaciones de membresía y más. Son muy adecuados para interacciones en línea donde un tercero de confianza (relying party) necesita verificar afirmaciones de varios emisores (issuers).

Es importante reconocer que no siempre son mutuamente excluyentes. OpenID4VP puede, por ejemplo, usarse para solicitar y transportar un [org.iso.mdoc]. La elección a menudo depende del caso de uso específico, el tipo de credencial y los participantes del ecosistema.

La Wallet de Identidad Digital de la Unión Europea (EUDI) es una iniciativa importante que tiene como objetivo proporcionar a todos los ciudadanos y residentes de la UE una wallet digital segura para documentos de identidad y atestaciones. La arquitectura y el marco de referencia de la Wallet EUDI planean explícitamente soportar tanto mdoc (particularmente para Permisos de Conducir Móviles) como Credenciales Verificables del W3C, utilizando OpenID4VP y OpenID4VCI para los flujos de presentación y emisión. La implementación de referencia incluye soporte para OpenID4VP transfiriendo mDocs y OpenID4VCI para emitir PIDs y mDLs en formatos mDoc y SD-JWT-VC. Este doble soporte por parte de un proyecto de tan gran escala subraya la importancia de ambas familias de protocolos. Sin embargo, esta dirección no está exenta de críticas, ya que algunos observadores señalan que la API de Credenciales Digitales, fuertemente influenciada por las "grandes tecnológicas de EE. UU.", podría incorporarse profundamente en las especificaciones finales de la Wallet EUDI. Se han planteado preocupaciones sobre la posible influencia de entidades no pertenecientes a la UE en una pieza crítica de la infraestructura de la UE, como se discute en foros comunitarios como esta discusión de GitHub.

El panorama de los navegadores para la API de Credenciales Digitales todavía se está configurando, con notables diferencias en el enfoque y los niveles de soporte.

Google Chrome, particularmente en Android, ha sido uno de los primeros en adoptar e implementar la API de Credenciales Digitales. Han realizado Origin Trials y la han integrado con el Credential Manager nativo de Android. La implementación de Chrome aprovecha principalmente OpenID4VP como el protocolo para solicitar credenciales a través de la llamada a la API navigator.credentials.get(). Aunque OpenID4VP en sí mismo es agnóstico al formato y puede transportar org.iso.mdoc o Credenciales Verificables del W3C como payloads, el énfasis práctico de Google parece estar en el flujo OpenID4VP como mecanismo de transporte. El Credential Manager de Android también soporta nativamente OpenID4VP para la presentación y OpenID4VCI para la emisión. Esto permite que las aplicaciones de Android actúen como titulares y verificadores de credenciales utilizando estos estándares.

En versiones anteriores de este artículo, predijimos que el enfoque de Apple divergiría del de Google al centrarse en el protocolo org.iso.mdoc. Para el contexto histórico, nuestro razonamiento fue el siguiente:

Como anticipamos correctamente, la WWDC25 confirmó esta estrategia. En la conferencia, Apple anunció oficialmente el soporte para la API en Safari 26 (que se lanzará con iOS 26 y otras actualizaciones del SO en otoño de 2025), confirmando que su implementación soporta exclusivamente el protocolo org.iso.mdoc para la presentación.

Esto se detalló en la sesión de la WWDC25 Verificar documentos de identidad en la web. La API permite a los sitios web solicitar información verificable de documentos de identidad, como un permiso de conducir, almacenados en Apple Wallet o en aplicaciones de proveedores de documentos de terceros.

Conclusiones clave de la implementación de Apple:

• Solo MDOC: La API utiliza exclusivamente la cadena de protocolo "org-iso-mdoc", basada en el estándar ISO/IEC 18013-7 Anexo C. No hay soporte para OpenID4VP en la implementación de Safari de la API de Credenciales Digitales.
• Solo Presentación: La API es para la presentación (verificación) de credenciales existentes. La emisión en Apple Wallet u otras aplicaciones sigue siendo un proceso separado, fuera del navegador.
• Centrado en el Usuario y Seguro: El flujo se inicia con un gesto del usuario y aprovecha un mecanismo de "solicitud parcial", donde el SO primero analiza y valida la solicitud en un sandbox antes de pasarla a la aplicación de la wallet, mejorando la seguridad.
• Extensible a Apps: Además de Apple Wallet, las aplicaciones de terceros pueden actuar como proveedores de documentos implementando el nuevo framework IdentityDocumentServices y una extensión de aplicación.

Apple proporcionó un ejemplo de código claro sobre cómo un tercero de confianza usaría la API:

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Esta confirmación consolida las estrategias divergentes en el mercado de navegadores. Mientras que Chrome se basa en la capa de transporte flexible de OpenID4VP, Apple está aprovechando su profunda inversión en el ecosistema mdoc de ISO para proporcionar una solución altamente integrada y segura, aunque menos flexible, adaptada a los documentos de identidad oficiales.

Mozilla ha expresado formalmente una "posición negativa" sobre la propuesta de la API de Credenciales Digitales tal como está actualmente. Sus preocupaciones son exhaustivas y se basan en su misión de proteger la privacidad del usuario, su agencia y garantizar una web abierta y equitativa.

Las principales preocupaciones planteadas por Mozilla incluyen:

• Riesgos de Privacidad: Potencial de un mayor intercambio de datos personales y una reducción del anonimato en línea si las solicitudes de credenciales digitales se vuelven comunes para interacciones triviales.
• Exclusión de Usuarios: Riesgo de que las personas que no pueden o eligen no usar credenciales digitales puedan ser excluidas de los servicios y comunidades en línea. Las credenciales emitidas por el gobierno, un caso de uso principal, pueden no alinearse con la elección de presentación de identidad de un individuo.
• Problemas de Interoperabilidad: Preocupaciones sobre una proliferación de formatos de credenciales que conduzca a un ecosistema fragmentado en lugar de uno universalmente interoperable.
• Divulgación Selectiva: Inquietudes de que los beneficios de privacidad de la divulgación selectiva podrían verse socavados si no se implementan con fuertes garantías de no vinculación, o si los usuarios no entienden completamente lo que se está compartiendo.
• Centralización de la Confianza y la Agencia del Usuario: Temores de que la API pueda llevar a una mayor centralización de la confianza y una reducción de la agencia del usuario, perpetuando los desequilibrios de poder sociales existentes.

Mozilla reconoce que dicha API podría ofrecer utilidad sobre los métodos ad-hoc existentes para la presentación de credenciales, pero enfatiza que las nuevas características de la plataforma web deben demostrar que mejoran la web en general y priorizan los intereses de los usuarios. Si bien un Consejo del W3C desestimó una objeción formal relacionada con estas preocupaciones (para permitir que el trabajo proceda dentro del W3C en lugar de en lugares potencialmente menos transparentes), el Consejo recomendó que el Grupo de Trabajo trabaje activamente para mitigar estos posibles daños.

Tabla 1: Soporte de Navegadores para la API de Credenciales Digitales y Protocolos

Para las organizaciones (Terceros de Confianza o RPs) que pretenden solicitar y verificar credenciales digitales de los usuarios, el panorama actual requiere una cuidadosa planificación estratégica.

Dado que Safari, con su significativa cuota de mercado, probablemente priorizará las interacciones directas con org.iso.mdoc a través de la API de Credenciales Digitales, y Chrome/Android están enfatizando OpenID4VP (que puede transportar mdocs u otros formatos de Credenciales Verificables), los RPs que buscan el mayor alcance posible deberían prepararse para soportar interacciones basadas en ambos enfoques.

Esto significa diseñar sistemas que puedan:

1. Iniciar solicitudes de credenciales a través de la API navigator.credentials.get(), especificando potencialmente diferentes parámetros de protocolo ("org.iso.mdoc" u "openid4vp") basados en la detección del navegador o las capacidades del user agent.
2. Procesar respuestas que pueden venir directamente en un formato mdoc o como un vp_token a través de OpenID4VP, que luego necesita ser analizado para extraer la credencial subyacente (que podría ser a su vez un mdoc u otro formato de VC).

Aunque esto añade complejidad, intentar forzar a todos los usuarios por un único camino de protocolo probablemente excluirá a una parte sustancial de la base de usuarios, ya sea los de iOS o los de Android/Chrome, dependiendo del camino elegido. Un enfoque pragmático, aunque más intensivo en desarrollo, es construir flexibilidad para manejar ambos.

Los Terceros de Confianza deben ser muy conscientes de que incluso al solicitar la misma pieza lógica de información (p. ej., "¿es el usuario mayor de 21 años?"), cómo se define esto en una solicitud y cómo se devuelve en una respuesta puede diferir significativamente entre una consulta directa de mdoc y una consulta de OpenID4VP (que podría usar Presentation Exchange o DCQL).

• Divulgación Selectiva de mdoc: org.iso.mdoc tiene sus propios mecanismos para la divulgación selectiva, que típicamente implican que el emisor cree hashes con sal de elementos de datos individuales. La wallet del titular luego revela solo los elementos solicitados junto con sus sales, permitiendo al verificador confirmarlos contra los hashes sin ver otros datos. La solicitud de elementos específicos está ligada a espacios de nombres predefinidos e identificadores de elementos de datos dentro del estándar mdoc.
• Divulgación Selectiva de OpenID4VP: OpenID4VP típicamente usa un lenguaje de consulta como Presentation Exchange (DIF PE) o el más nuevo Digital Credentials Query Language (DCQL) incrustado dentro de la presentation_definition de la solicitud. Esto permite a los RPs especificar los tipos de credenciales y las afirmaciones individuales que necesitan. La wallet luego construye una Presentación Verificable que contiene solo la información solicitada, si es soportado por el formato de la credencial y la wallet.

Los RPs necesitan mapear sus requisitos de datos específicos a estas diferentes estructuras de protocolo. Es crucial entender los matices de cómo se implementa y solicita la divulgación selectiva en cada protocolo para asegurar que solo se soliciten y procesen los datos mínimos necesarios, adhiriéndose así a las mejores prácticas de privacidad y los principios de minimización de datos. El formato y la estructura de los datos divulgados devueltos por la wallet también pueden diferir, requiriendo una lógica de análisis y validación distinta en el backend del RP.

Para las entidades que buscan emitir credenciales digitales y proporcionar aplicaciones de wallet para los titulares, el entorno del sistema operativo juega un papel crucial.

Los emisores (issuers) de wallets se enfrentan a panoramas claramente diferentes en iOS y Android en lo que respecta a la creación de wallets, la integración con el sistema y la interacción con la API de Credenciales Digitales.

• Android: Generalmente ofrece un ecosistema más abierto. El Credential Manager de Android incluye una Holder API que permite a las aplicaciones nativas de terceros registrarse como titulares de credenciales. Estas aplicaciones de titular registradas pueden entonces participar en los flujos de presentación de credenciales mediados por el sistema, respondiendo a las solicitudes de la API de Credenciales Digitales (a través de Chrome) o de verificadores de apps nativas. Android también soporta explícitamente OpenID4VCI para la emisión de credenciales, permitiendo a los usuarios elegir una wallet de terceros compatible para recibir credenciales recién emitidas. Aunque las apps nativas son el foco principal para las capacidades completas de titular de credenciales, el sistema está diseñado para una participación más amplia.

• iOS: Apple mantiene un control más estricto sobre su ecosistema. Aunque las aplicaciones de wallet de terceros pueden existir en la App Store, su capacidad para integrarse profundamente como titulares de credenciales a nivel de sistema para credenciales de alta seguridad (como los mDLs destinados a Apple Wallet) a menudo está sujeta a los procesos y permisos específicos de Apple. Añadir una ID a Apple Wallet, por ejemplo, es un flujo controlado que involucra a las autoridades emisoras estatales y la verificación de Apple. Para la API de Credenciales Digitales en Safari, las interacciones probablemente serán gestionadas de cerca, con un enfoque principal en org.iso.mdoc presentado desde fuentes autorizadas, a saber, la propia Apple Wallet y aplicaciones de proveedores de documentos de terceros registradas.

El enfoque de "jardín vallado" de Apple está bien establecido, y su implementación de credenciales digitales no es una excepción. Sin embargo, la WWDC25 aclaró el camino para la participación de terceros.

Aunque Apple Wallet es el proveedor principal e integrado para credenciales como los mDLs estatales, Apple ha introducido el framework IdentityDocumentServices para aplicaciones nativas de iOS. Esto permite a los desarrolladores de terceros construir aplicaciones que pueden aprovisionar y presentar sus propios documentos de identidad.

Para participar en el flujo web, una app nativa debe:

1. Registrar Documentos: Usar el IdentityDocumentProviderRegistrationStore para registrar los mdocs que la app gestiona con el sistema operativo. Este registro incluye el tipo de documento y las autoridades de certificación de confianza para la firma de solicitudes.
2. Implementar una Extensión de App: Añadir una Extensión de App de UI "Identity Document Provider" al proyecto. Esta extensión es responsable de mostrar la interfaz de autorización al usuario cuando se selecciona la app durante un flujo de verificación basado en la web.

Esto significa que, si bien la creación de una wallet totalmente integrada en iOS requiere construir una aplicación nativa y usar los frameworks específicos de Apple —no tecnologías web como las PWAs— existe un mecanismo claro, aunque estrictamente controlado, para que las aplicaciones de terceros actúen como proveedores de documentos junto a Apple Wallet. Esto confirma que la interacción con la API de Credenciales Digitales en Safari es gestionada por el SO, que luego despacha las solicitudes a Apple Wallet o a cualquier otra aplicación de proveedor de documentos registrada y autorizada.

La API de Credenciales Digitales representa un avance significativo en el espacio de la identidad digital, ofreciendo un enfoque más seguro, centrado en el usuario y que preserva la privacidad para la verificación de identidad y la presentación de credenciales. A medida que el ecosistema evoluciona, es crucial que tanto los terceros de confianza como los emisores de wallets se adapten y abracen el potencial de esta nueva tecnología. Mantendremos este artículo actualizado a medida que cambie el panorama.

Sin embargo, persisten los desafíos. Lograr una verdadera interoperabilidad global entre diferentes formatos de credenciales, protocolos e implementaciones de wallets es una empresa significativa. Abordar las preocupaciones válidas planteadas por organizaciones como Mozilla con respecto a la privacidad, la exclusión y la agencia del usuario es primordial para garantizar que estas tecnologías sirvan a la humanidad. La fragmentación actual en el soporte de navegadores y el énfasis en los protocolos significa que los terceros de confianza y los emisores de wallets deben navegar por un panorama complejo por el momento.