API de Credenciales Digitales (2025): Soporte activo en Chrome y Safari

Última actualización: 30 de octubre de 2025

Un resumen rápido del 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:

Want to experience digital credentials in action?

Try Digital Credentials

¿Qué ha cambiado desde julio de 2025?

• Lanzado: Chrome 141 (30 de sep. de 2025) y Safari 26 (15 de sep. de 2025).
• Chrome: Agnóstico al protocolo (OpenID4VP y Anexo C de ISO 18013-7), multidispositivo en escritorio sobre CTAP.
• Safari: Solo-mdoc (org-iso-mdoc), flujo multidispositivo vía CTAP.
• Forma de la API: navigator.credentials.get(); nomenclatura requests/data; detección de características DigitalCredential.

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 mundo 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, discutiremos 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 las partes dependientes como para los emisores 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 consorcios bancarios pioneros 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 wallets y servicios nacionales de identidad digital. Sin embargo, estas soluciones a menudo estaban aisladas, limitadas geográficamente 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. 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 se está intensificando dramáticamente 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) procesos. 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 experience digital credentials in action?

Try Digital Credentials

Entender cómo funcionan 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: Una entidad (p. ej., gobierno, universidad, empleador) que tiene autoridad sobre cierta información de un sujeto y puede emitir una credencial digital que lo atestigüe.
2. Titular: El sujeto de la información (es decir, el usuario) que recibe la credencial del emisor y la almacena en un wallet digital. El titular controla cuándo y qué información de la credencial se comparte.
3. Verificador (o Parte Dependiente): 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 busca 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é fragmentos 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 implicación de pares de claves criptográficas. El emisor firma digitalmente la credencial, asegurando su autenticidad e integridad. El titular, a su vez, usa su clave privada, a menudo asegurada dentro de su wallet digital (que está protegido por el hardware del dispositivo), para probar el control sobre la credencial y autorizar su presentación a un verificador. Esto típicamente implica que el verificador presente un desafío (un dato aleatorio) que el 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 una licencia de conducir válida") 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 el 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 en 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, mDL ISO, VC de W3C, 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 VC del W3C. Añade evidencia de manipulación y prueba criptográfica, y siempre existe en un mundo de tres partes: emisor → titular → verificador.
• API de Credenciales Verificables: 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 (API DC): Una API de navegador / sistema operativo (JavaScript + conexiones nativas) que permite a un sitio web pedirle al wallet del dispositivo del usuario que presente cualquier credencial digital soportada (VC, mDoc ISO, SD-JWT…) de una manera que respete la privacidad.

Piensa en las VCs como un modelo de datos, la API de VC como una especificación de back-end, y la API DC 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 (API de VC - emisor ↔ wallet): El departamento de vehículos motorizados del estado 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 el wallet del usuario con su prueba criptográfica.
3. Solicitud (navigator.credentials.get() vía API DC - sitio web → navegador): El sitio web de la tienda de cervezas pregunta: "Muéstrame una prueba de que el usuario es ≥18."
4. Presentación (La API DC despacha al wallet → OpenID4VP (protocolo) → payload de VC): El wallet muestra una interfaz de consentimiento, el usuario aprueba, el wallet envía de vuelta una presentación verificable.
5. Verificación (API de VC - back-end de la tienda de cervezas): El back-end del sitio verifica la firma y el DID/clave pública del emisor; concede el acceso.

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

Por qué existe esta división:

• Modelo de datos interoperable (pruebas criptográficas, divulgación selectiva): Resuelto por el Modelo de Datos VC (y otros formatos).
• Endpoints REST estándar para sistemas de back-end: Resuelto por la API de VC.
• Handshake entre Wallet y sitio web que preserva la privacidad: Resuelto por la API DC.
• 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 API DC.

Puntos clave:

1. "Credencial digital" es el término general.
2. Credencial Verificable es un tipo de credencial digital con verificabilidad criptográfica incorporada.
3. La API de VC 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 el wallet que finalmente permite que esas credenciales fluyan sin problemas hacia las aplicaciones web, sin importar el formato concreto en el que estén.
5. Las tres piezas son complementarias, no compiten entre sí; 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.

Después de haber 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 el 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 los wallets digitales de los usuarios. Este esfuerzo se encuentra 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 de la especificación oficial se puede encontrar aquí: https://w3c-fedid.github.io/digital-credentials/.

Para octubre de 2025, la API se ha lanzado en versiones estables tanto de Chrome 141 (30 de sep. de 2025) como de Safari 26 (15 de sep. de 2025). La implementación de Chrome es agnóstica al protocolo, soportando tanto OpenID4VP como el Anexo C de ISO 18013-7, mientras que Safari soporta exclusivamente el protocolo org-iso-mdoc. Chrome lo soporta de forma nativa en Android a través de su sistema de Credential Manager y también soporta la API de Credenciales Digitales multidispositivo en escritorio a través de un traspaso QR respaldado por CTAP/BLE.

La API amplía 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 utilizar esta interfaz establecida en lugar de la propuesta anteriormente 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 envoltorio o intermediario seguro. 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 entrega, mejorando la seguridad y la privacidad al garantizar el consentimiento del usuario y evitar que los sitios web accedan silenciosamente a datos sensibles. Se pretende que los datos reales de la credencial en la respuesta sean opacos (cifrados) para el propio navegador, y que el descifrado e interpretación sean manejados por la parte dependiente y el 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 OpenID for Verifiable Presentations (OpenID4VP) y OpenID for Verifiable Credential Issuance (OpenID4VCI) de la Fundación OpenID.

• Origen y estandarización: org.iso.mdoc se refiere al formato de datos y al modelo de interacción para documentos móviles, principalmente licencias de conducir móviles (mDLs), estandarizado 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 ser compactos y eficientes. Especifica espacios de nombres y elementos de datos para atributos comunes de licencias de conducir y soporta fuertes características de seguridad criptográfica, incluyendo autenticación del emisor, 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 licencias 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 dirigidos a una amplia interoperabilidad para varios tipos de credenciales, no solo las 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) de 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 del 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 una parte dependiente necesita verificar afirmaciones de varios emisores.

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.

El 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 un wallet digital seguro para documentos de identidad y atestaciones. La arquitectura y el marco de referencia del EUDI Wallet planean explícitamente soportar tanto mdoc (particularmente para Licencias 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 formatos. Este doble soporte por parte de un proyecto de 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 empresas tecnológicas de EE. UU., podría incorporarse profundamente en las especificaciones finales del EUDI Wallet. 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 en GitHub.

El panorama de los navegadores para la API de Credenciales Digitales ya ha tomado forma, con Chrome 141 y Safari 26 ofreciendo soporte estable en septiembre de 2025. Existen diferencias notables en el enfoque y los niveles de soporte entre los navegadores.

Chrome lanzó la API de Credenciales Digitales en Chrome 141 (30 de sep. de 2025). La implementación de Chrome es agnóstica al protocolo: compatible con OpenID4VP y el Anexo C de ISO 18013-7 (mdoc en línea). El escritorio soporta la presentación multidispositivo desde wallets móviles a través de un canal respaldado por CTAP/BLE (traspaso QR), con la respuesta opaca para el navegador. La forma de la API se trasladó a navigator.credentials.get(); parámetros renombrados: providers → requests, request → data.

Detección de características:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

El Credential Manager de Android soporta nativamente OpenID4VP para la presentación y OpenID4VCI para la emisión, permitiendo que las aplicaciones de Android actúen como titulares y verificadores de credenciales usando estos estándares. Google señala un creciente soporte de wallets; Google Wallet es uno de los primeros en adoptarlo, y se han anunciado Samsung Wallet y 1Password.

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, WWDC25 confirmó esta estrategia. Safari 26 (iOS/iPadOS/macOS) se lanzó el 15 de septiembre de 2025 con soporte para la API de Credenciales Digitales, confirmando que su implementación soporta exclusivamente el protocolo org-iso-mdoc (con guion) para la presentación.

Esto se detalló en la sesión de WWDC25 Verificar documentos de identidad en la web. La API permite a los sitios web solicitar información verificable de documentos de identidad, como una licencia 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 la API de Credenciales Digitales de Safari.
• 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 sistema operativo primero analiza y valida la solicitud en un sandbox antes de pasarla a la aplicación del wallet, mejorando la seguridad.
• Extensible a aplicaciones: 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.
• Soporte multidispositivo: La presentación multidispositivo desde plataformas que no son de Apple utiliza CTAP para la proximidad después de un traspaso de código QR; la respuesta JS permanece cifrada/opaca para el navegador.

Apple proporcionó un ejemplo de código claro sobre cómo una parte dependiente 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 solidifica las estrategias divergentes en el mercado de navegadores. Mientras Chrome se basa en la flexible capa de transporte 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 de estándares negativa sobre 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 albedrío 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 deciden 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 puedan verse socavados si no se implementan con fuertes garantías de desvinculación, o si los usuarios no entienden completamente lo que se está compartiendo.
• Centralización de la confianza y el albedrío del usuario: Temores de que la API pueda conducir a una mayor centralización de la confianza y una reducción del albedrío del usuario, perpetuando los desequilibrios de poder sociales existentes.

Mozilla reconoce que una API de este tipo 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 procediera dentro del W3C en lugar de en foros potencialmente menos transparentes), el Consejo recomendó que el Grupo de Trabajo trabaje activamente para mitigar estos daños potenciales.

Tabla 1: Soporte de navegadores para la API de Credenciales Digitales y Protocolos (oct. de 2025)

Para las organizaciones (Partes Dependientes 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 (lanzado el 15 de sep. de 2025) soporta exclusivamente interacciones directas org-iso-mdoc (Anexo C de ISO 18013-7) a través de la API de Credenciales Digitales, y Chrome (lanzado el 30 de sep. de 2025) es agnóstico al protocolo soportando tanto OpenID4VP como el Anexo C de ISO 18013-7 (mdoc), las RPs que buscan el mayor alcance posible deben 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 diferentes parámetros de protocolo ("org-iso-mdoc" para Safari o "openid4vp" para flujos de Chrome/OID4VP) basados en la detección del navegador o las capacidades del user agent.
2. Procesar respuestas que pueden venir directamente en formato mdoc (Anexo C de ISO 18013-7) 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 a los de iOS o a los de Chrome/Android, dependiendo del camino elegido. Un enfoque pragmático, aunque más intensivo en desarrollo, es construir flexibilidad para manejar ambos.

Las Partes Dependientes 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 en 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. El wallet del titular revela entonces 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 e identificadores de elementos de datos predefinidos dentro del estándar mdoc.
• Divulgación selectiva en 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 las RPs especificar los tipos de credenciales y las afirmaciones individuales que necesitan. El wallet construye entonces una Presentación Verificable que contiene solo la información solicitada, si es compatible con el formato de la credencial y el wallet.

Las 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 el wallet también pueden diferir, requiriendo una lógica de análisis y validación distinta en el backend de la 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 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 un wallet de terceros compatible para recibir credenciales recién emitidas. Aunque las aplicaciones 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 las mDLs destinadas a Apple Wallet) a menudo está sujeta a los procesos y derechos específicos de Apple. Añadir una identificación a Apple Wallet, por ejemplo, es un flujo controlado que involucra a las autoridades emisoras estatales y a la verificación de Apple. Para la API de Credenciales Digitales en Safari, es probable que las interacciones se gestionen de cerca, con un enfoque principal en org.iso.mdoc presentado desde fuentes autorizadas, a saber, Apple Wallet mismo y aplicaciones de proveedores de documentos de terceros registradas.

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

Aunque Apple Wallet es el proveedor principal integrado para credenciales como las mDLs estatales, Apple ha introducido el framework IdentityDocumentServices para aplicaciones nativas de iOS. Esto permite a los desarrolladores de terceros crear 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 aplicación 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 IU "Proveedor de Documentos de Identidad" al proyecto. Esta extensión es responsable de mostrar la interfaz de autorización al usuario cuando se selecciona la aplicación durante un flujo de verificación basado en la web.

Esto significa que, si bien la creación de un wallet totalmente integrado 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 proveedora 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. Con Chrome 141 (30 de sep. de 2025) y Safari 26 (15 de sep. de 2025) ofreciendo ya soporte estable, la API ha pasado de ser experimental a estar lista para producción. A medida que el ecosistema continúa evolucionando, es crucial que tanto las partes dependientes 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 tarea considerable. Abordar las preocupaciones válidas planteadas por organizaciones como Mozilla con respecto a la privacidad, la exclusión y el albedrío del usuario es fundamental para garantizar que estas tecnologías sirvan a la humanidad. Los enfoques divergentes —la implementación agnóstica al protocolo de Chrome frente al enfoque solo-mdoc de Safari— significan que las partes dependientes y los emisores de wallets deben navegar por un panorama de doble protocolo en el futuro previsible.