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

Última actualización: 26 de marzo de 2026

Un resumen rápido sobre el soporte de la API de Credenciales Digitales en los principales navegadores:

El mundo de las credenciales digitales avanza rápido. Aquí tienes una instantánea de los desarrollos clave y proyecciones:

Want to experience digital credentials in action?

Try Digital Credentials

¿Qué ha cambiado desde octubre de 2025?

• Cambio en la gobernanza del protocolo: El WG FedID del W3C eliminó el registro abierto de protocolos en el TPAC (noviembre de 2025) y ahora incluye directamente los protocolos soportados en la especificación: OpenID4VP, OpenID4VCI e ISO 18013-7 Anexo C. La API ya no es una "tubería tonta" o canal pasivo.
• Llegada de la emisión: Chrome 143 lanzó un Origin Trial para la emisión de credenciales a través de navigator.credentials.create(), expandiendo la API más allá de la mera presentación.
• Firefox implementando: A pesar de mantener su posición negativa sobre el estándar, Mozilla incorporó el código base en Firefox 149 y continúa trabajando en la experiencia de usuario (UX).
• Mandato condicional de la UE: El Marco de Referencia de Arquitectura (Topic F) de EUDI ahora requiere condicionalmente soporte para la API de Credenciales Digitales en todas las billeteras de los estados miembros.
• Adopción real: El DMV de California añadió soporte a su plataforma OpenCred (febrero de 2026).

Las credenciales digitales son un tema candente en el espacio de la identidad actual. A medida que nuestras vidas están cada vez más conectadas 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 tan 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 Digital Credentials API (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 de los navegadores y ofreceremos recomendaciones tanto para las partes confiantes (relying parties) como para los emisores de billeteras que navegan por este panorama en rápida evolución.

Demostrar la identidad de manera confiable 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 tergiversación y el fraude.

En algunos países surgieron soluciones, impulsadas principalmente por consorcios bancarios tempranos que desarrollaron servicios para aprovechar las relaciones de confianza existentes para la identificación en línea. Los gobiernos también intervinieron, aplicando o proporcionando billeteras 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 significativos e inconvenientes. Las videollamadas combinadas con la carga 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 importantes. Pueden llevar mucho tiempo, ser propensos al error humano o sesgo, y han sido frecuentemente expuestos como vulnerables a falsificaciones sofisticadas.

El desafío está escalando dramáticamente con la llegada de los deepfakes, técnicas avanzadas de suplantación impulsadas por IA y ataques de phishing cada vez más sofisticados. Estas tecnologías pueden crear evidencia de video, audio y documentos altamente realista pero completamente fabricada, haciendo 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 controles es una amenaza grave, particularmente para las instituciones financieras y cualquier servicio que requiera procesos robustos de Conozca a su Cliente (KYC). Este panorama de amenazas crecientes subraya la necesidad urgente de mecanismos de identidad y verificación en línea más seguros y verificables criptográficamente.

Want to experience digital credentials in action?

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 (ej. gobierno, universidad, empleador) que tiene autoridad sobre cierta información de un sujeto y puede emitir una credencial digital dando fe de esa información.
2. Titular (Holder): El sujeto de la información (es decir, el usuario) que recibe la credencial del emisor y la almacena en una billetera digital. El titular controla cuándo y qué información de la credencial se comparte.
3. Verificador (o Relying Party): Una entidad (ej. un sitio web, un servicio en línea) que necesita verificar cierta información sobre el titular para otorgar 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 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 firma digitalmente la credencial, asegurando su autenticidad e integridad. El titular, a su vez, utiliza su clave privada, a menudo asegurada dentro de su billetera digital (que está protegida 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 presenta un desafío (un dato aleatorio) que la billetera 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 respecto 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 a través de 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 (ej. "soy mayor de 18 años", "poseo una licencia de conducir válida") sin revelar el documento fuente completo. Aunque los sistemas subyacentes para 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 Billetera 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 datos en sí hasta cómo se presenta 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 código de barras, ISO mDL, W3C VC, SD-JWT, etc.). "Digital" no dice nada sobre verificabilidad criptográfica.
• Credencial Verificable (VC): 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 Credencial Verificable (VC API): Una interfaz de servicio REST/HTTP para emitir, almacenar, presentar y verificar VCs entre sistemas backend (emisores, billeteras, verificadores).
• API de Credenciales Digitales (DC API): Una API de navegador / sistema operativo (JavaScript + tubería nativa) que permite a un sitio web pedir a la billetera del lado 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 backend, y la DC API como la implementación frontend que presenta las credenciales a la Web. Todo por encima de la capa 1 (Capa de modelo de datos) es agnóstico del formato; todo por debajo depende del formato de la credencial.

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

El siguiente diagrama ilustra cómo estas capas trabajan juntas en un escenario del mundo real.

Nota 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 la 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 backend: Resuelto por la VC API.
• Apretón de manos Billetera ↔ 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) debajo de la DC API.

Puntos clave:

1. "Credencial digital" es el término paraguas.
2. Credencial Verificable es un tipo de credencial digital con verificabilidad criptográfica incorporada.
3. VC API es la tubería servidor-a-servidor para operaciones del ciclo de vida en VCs.
4. API de Credenciales Digitales (DC API) es el puente navegador-a-billetera que finalmente permite que esas credenciales fluyan suavemente hacia las aplicaciones web, cualquiera que sea el formato concreto en el que estén.
5. Las tres piezas son complementarias, no competidoras—se asientan en diferentes capas de la misma pila y juntas habilitan 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, enfocá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 actualmente en desarrollo para proporcionar una forma segura y estandarizada para que los sitios web soliciten y reciban información de identidad digital de las billeteras de los usuarios. Este esfuerzo se aloja principalmente dentro del Grupo de Trabajo de Identidad Federada del W3C (FedID WG), 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/.

A octubre de 2025, la API se ha lanzado en versiones estables tanto en Chrome 141 (30 de septiembre de 2025) como en Safari 26 (15 de septiembre de 2025). La implementación de Chrome soporta tanto OpenID4VP como ISO 18013-7 Anexo C, mientras que Safari soporta exclusivamente el protocolo org-iso-mdoc.

Importante (actualización de marzo de 2026): La relación de la API con los protocolos ha cambiado fundamentalmente. En el TPAC en noviembre de 2025, el WG FedID del W3C alcanzó consenso para eliminar el registro abierto de protocolos y en su lugar incluir directamente una lista finita de protocolos soportados en la especificación: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (para presentación), y openid4vci-v1 (para emisión). Se espera que los agentes de usuario rechacen protocolos no listados. Esto convierte al Grupo de Trabajo en un guardián de facto para futuras adiciones de protocolos — un compromiso deliberado para permitir una revisión holística de seguridad y privacidad de todo lo que fluye a través de la API (ver el Borrador de Trabajo actual).

La especificación ahora también cubre la emisión de credenciales a través de navigator.credentials.create(). Chrome 143 lanzó un Origin Trial para esto, permitiendo a los sitios web activar flujos de aprovisionamiento de billetera usando OpenID4VCI. Sin embargo, una vulnerabilidad de vinculación de selección de billetera — donde una aplicación de billetera maliciosa puede interceptar códigos de pre-autorización de emisión — sigue siendo una preocupación abierta. Los emisores gubernamentales han indicado que no adoptarán la emisión mediada por navegador hasta que esto se resuelva.

Chrome soporta presentación nativamente en Android a través de su sistema de Gestor de Credenciales y también soporta la API de Credenciales Digitales Multidispositivo en escritorio vía transferencia QR respaldada por CTAP/BLE.

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

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

async function requestCredential() {
    // Verificar soporte de la API de Credenciales Digitales
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Estos parámetros normalmente se obtienen del backend.
            // Definidos estáticamente aquí para propósitos de ilustración de extensibilidad del protocolo.
            const oid4vp = {
                protocol: "oid4vp", // Un ejemplo de solicitud OpenID4VP a billeteras. // Basado en https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Solicitud de Intercambio de Presentación, omitida por brevedad
                    },
                },
            };
 
            // crear un Controlador de Aborto
            const controller = new AbortController();
 
            // Llamar a la API de Credenciales Digitales usando la solicitud de presentación del backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Enviar la respuesta cifrada al backend para descifrado y verificación
            // Omitido por brevedad
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // escenario de respaldo, solo ilustrativo
        alert("La API de Credenciales Digitales no está soportada en este navegador.");
    }
}

Este ejemplo está tomado de aquí.

La API de Credenciales Digitales actúa esencialmente como un envoltorio seguro o intermediario. Permite al navegador mediar la solicitud de información de identidad, aprovechando las capacidades del sistema operativo subyacente para descubrir billeteras disponibles y credenciales 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 privacidad al asegurar el consentimiento del usuario y prevenir que los sitios web accedan silenciosamente a datos sensibles. La información real de la credencial en la respuesta está destinada a ser opaca (cifrada) para el propio navegador, con el descifrado e interpretación manejados por la parte confiante (RP) y la billetera/titular.

La API de Credenciales Digitales fue diseñada originalmente para ser completamente agnóstica del protocolo, actuando como una "tubería tonta" o canal pasivo con un registro abierto para que cualquier protocolo se registrara. Sin embargo, a enero de 2026, la especificación ahora nombra explícitamente los protocolos que soporta — se espera que los agentes de usuario rechacen los no listados. Las dos familias principales de protocolos actualmente codificadas en la especificación son: org.iso.mdoc (derivado de ISO 18013-5 y su extensión ISO 18013-7 "Anexo C") y las especificaciones de OpenID Foundation para 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 Licencias 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, estructura de datos y protocolos para presentación en persona (proximidad) usando tecnologías como NFC, Bluetooth o códigos QR. ISO/IEC 18013-7 extiende esto para habilitar la presentación en línea/remota de mDLs. La cadena de protocolo "org.iso.mdoc" está definida 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 licencias de conducir y soporta fuertes características de seguridad criptográfica, incluyendo autenticación del emisor, vinculación de dispositivo, autenticación del titular (vía 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 IDs nacionales. Está diseñado para escenarios de alta seguridad, tanto en persona (ej. controles de tráfico, verificación de edad para bienes restringidos) y en línea (ej. acceder a servicios del gobierno, verificación de identidad remota para apertura de cuentas bancarias).

• Origen y Estandarización: OpenID4VP (para presentación) y OpenID4VCI (para emisión) son especificaciones desarrolladas por la OpenID Foundation. Extienden OAuth 2.0 para soportar el intercambio de credenciales verificables. Estos son estándares abiertos dirigidos a una amplia interoperabilidad para varios tipos de credenciales, no solo gubernamentales. A principios de 2025, OpenID4VP está en etapas avanzadas de borrador (ej. draft 28 a abril). OpenID4VCI también está madurando.
• Modelo de Datos: OpenID4VP/VCI están diseñados para ser agnósticos del 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 Billetera del Titular conteniendo 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, proporcionar prueba de cualificaciones (ej. diplomas educativos, certificaciones profesionales), atestaciones de membresía, y más. Son muy adecuados para interacciones en línea donde una parte confiante necesita verificar afirmaciones de varios emisores.

Es importante reconocer que estos no son siempre 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 Billetera de Identidad Digital de la Unión Europea (EUDI) es una iniciativa importante que busca proporcionar a todos los ciudadanos y residentes de la UE una billetera digital segura para documentos de identidad y atestaciones. La arquitectura y el marco de referencia de la Billetera EUDI planean explícitamente soportar tanto mdoc (particularmente para Licencias de Conducir Móviles) como Credenciales Verificables del W3C, utilizando OpenID4VP y OpenID4VCI para 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 soporte dual por parte de un proyecto de gran escala subraya la importancia de ambas familias de protocolos.

Actualización de marzo de 2026: El compromiso de la UE con la API de Credenciales Digitales se ha vuelto más concreto. El Topic F del Marco de Referencia de Arquitectura (ARF) de EUDI ahora requiere condicionalmente que las Unidades de Billetera EUDI y las Partes Confiantes soporten la DC API para la presentación remota y flujos de emisión de atestaciones. Las condiciones incluyen que la DC API alcance el estatus de Recomendación del W3C y cumpla con expectativas sobre funcionalidad, neutralidad de navegador/SO, privacidad y protección contra denegación de servicio. El Consorcio Europeo de Billeteras (EWC) ha incorporado casos de prueba de la DC API en su programa de pruebas de conformidad, y el consorcio NOBID completó pilotos de pago usando OpenID4VP — el mismo protocolo que ahora transporta la DC API.

Sin embargo, esta dirección no está exenta de críticas, ya que algunos observadores notan que la API de Credenciales Digitales, fuertemente influenciada por las "Bigtech de EE.UU.", podría incorporarse profundamente en las especificaciones finales de la Billetera EUDI. Se han planteado preocupaciones sobre la influencia potencial 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. Por separado, la decisión de incluir rígidamente la referencia ISO 18013-7 en la especificación ha provocado una objeción de Ping Identity, argumentando que referenciar normativamente una especificación de pago entra en conflicto con los principios de la web abierta — una preocupación que podría surgir como una objeción formal cuando la especificación transite a Recomendación Candidata.

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

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

Detección de características:

if (typeof DigitalCredential !== "undefined") {
    // API de Credenciales Digitales soportada
}

El Gestor de Credenciales de Android soporta nativamente OpenID4VP para presentación y OpenID4VCI para emisión, permitiendo a las aplicaciones de Android actuar como titulares de credenciales y verificadores usando estos estándares. Google nota un creciente soporte de billeteras; Google Wallet es un adoptante temprano, con Samsung Wallet y 1Password anunciados.

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 contexto histórico, nuestro razonamiento fue el siguiente:

Como anticipamos correctamente, la 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 guiones) para la presentación.

Esto se detalló en la sesión de la WWDC25 Verify identity documents on the web. La API permite a los sitios web solicitar información verificable de documentos de identidad, como una licencia de conducir, almacenada en Apple Wallet o en aplicaciones de proveedores de documentos de terceros.

Puntos 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 presentación (verificación) de credenciales existentes. La emisión en Apple Wallet u otras aplicaciones sigue siendo un proceso separado, no basado en el navegador.
• Centrado en el Usuario y Seguro: El flujo es iniciado por un gesto del usuario y aprovecha un mecanismo de "solicitud parcial", donde el SO primero analiza y valida la solicitud en un entorno aislado (sandbox) antes de pasarla a la aplicación de billetera, 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 app.
• Soporte Multidispositivo: La presentación multidispositivo desde plataformas no Apple usa CTAP por proximidad después de una transferencia de código QR; la respuesta JS permanece cifrada/opaca para el navegador.

Apple proporcionó un ejemplo de código claro de cómo una parte confiante (relying party) usaría la API:

async function verifyIdentity() {
    try {
        // El servidor genera y firma criptográficamente los datos de la solicitud.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // La solicitud especifica el protocolo 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data contiene la solicitud mdoc firmada criptográficamente.
            data,
        };
 
        // La API debe ser llamada desde dentro de un gesto de usuario.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Enviar la respuesta cifrada de la billetera al servidor para descifrado y validación.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Mostrar los detalles verificados...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Manejar errores, ej. cancelación del usuario.
    }
}

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

Mozilla expresó originalmente una posición negativa sobre el estándar de la API de Credenciales Digitales. Sus preocupaciones, documentadas en detalle, son exhaustivas y están arraigadas en su misión de proteger la privacidad del usuario, la agencia y asegurar una web abierta y equitativa.

Las preocupaciones clave planteadas por Mozilla incluyen:

• Riesgos de Privacidad: Potencial para un mayor intercambio de datos personales y una reducción en el anonimato en línea si las solicitudes de credenciales digitales se vuelven comunes para interacciones triviales.
• Exclusión de Usuarios: Riesgo de que individuos que no pueden o eligen no usar credenciales digitales puedan ser excluidos de 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 conduzcan a un ecosistema fragmentado en lugar de uno universalmente interoperable.
• Divulgación Selectiva: Preocupaciones 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 vinculabilidad, o si los usuarios no entienden completamente qué se está compartiendo.
• Centralización de Confianza y Agencia del Usuario: Temores de que la API podría conducir a una mayor centralización de la confianza y una reducción en la agencia del usuario, perpetuando los desequilibrios de poder social existentes.

Si bien un Consejo del W3C anuló una objeción formal relacionada con estas preocupaciones (para permitir que el trabajo proceda dentro del W3C en lugar de lugares potencialmente menos transparentes), el Consejo recomendó que el Grupo de Trabajo trabaje activamente para mitigar estos daños potenciales.

Actualización de marzo de 2026 — Implementación en curso: A pesar de que la posición formal negativa permanece técnicamente sin cambios, Mozilla ha comenzado a implementar activamente la API de Credenciales Digitales. En el Q1 de 2026, el soporte base para la DC API llegó a Firefox 149 (detrás de una bandera de preferencia), rastreado bajo el meta bug 2004828. El código fuente está en mozilla-central, incluyendo DigitalCredential.cpp, enlaces WebIDL y tubería IPC. El trabajo en las solicitudes de permiso de escritorio y Android (bug 2010091, bug 2010093) está en curso.

Tres ingenieros de Mozilla — John Schanck, Martin Thomson y Benjamin VanderSloot — son miembros activos del Grupo de Trabajo FedID del W3C, y Schanck ha estado proporcionando retroalimentación sustantiva informada por la implementación en PRs clave de la especificación, incluyendo el algoritmo de presentación de credenciales y el algoritmo de preparación de solicitudes.

Este es un desarrollo significativo: mientras Mozilla mantiene sus preocupaciones sobre el potencial de la API para el mal uso, evidentemente está eligiendo dar forma a la API desde adentro — tanto a través del trabajo de especificación como de implementación — en lugar de ceder el diseño a otros proveedores de navegadores. Señala que la API de Credenciales Digitales probablemente está en camino hacia un soporte de tres navegadores, aunque con Mozilla presionando por barreras de privacidad más fuertes (incluyendo una propuesta de registro de transparencia para solicitudes de credenciales).

Tabla 1: Soporte de Navegadores para la API de Credenciales Digitales y Protocolos (Marzo 2026)

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

Dado que Safari (lanzado el 15 de septiembre de 2025) soporta exclusivamente interacciones directas org-iso-mdoc (ISO 18013-7 Anexo C) a través de la API de Credenciales Digitales, y Chrome (lanzado el 30 de septiembre de 2025) es agnóstico del protocolo soportando tanto OpenID4VP como ISO 18013-7 Anexo C (mdoc), los RPs que buscan el mayor alcance posible deben prepararse para soportar interacciones basadas en ambos enfoques.

Esto significa arquitectar sistemas que puedan manejar ambos caminos de protocolo, como se muestra a continuación.

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

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

• Divulgación Selectiva mdoc: org.iso.mdoc tiene sus propios mecanismos para la divulgación selectiva, típicamente involucrando al emisor creando hashes con sal de elementos de datos individuales. La billetera del titular entonces 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 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 definición de presentación de la solicitud. Esto permite a los RPs especificar los tipos de credenciales y afirmaciones individuales que necesitan. La billetera entonces construye una Presentación Verificable conteniendo solo la información solicitada, si está soportada por el formato de credencial y la billetera.

Los RPs necesitan mapear sus requisitos de datos específicos a estas estructuras de protocolo variables. 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 principios de minimización de datos. El formato y estructura de los datos divulgados devueltos por la billetera también pueden diferir, requiriendo lógica de análisis y validación distinta en el backend del RP.

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

Los emisores de billeteras enfrentan panoramas distintamente diferentes en iOS y Android con respecto a la creación de billeteras, integración del sistema e interacción con la API de Credenciales Digitales.

• Android: Generalmente ofrece un ecosistema más abierto. El Gestor de Credenciales de Android incluye una API de Titular que permite a las aplicaciones nativas de terceros registrarse como titulares de credenciales. Estas aplicaciones titulares registradas pueden entonces participar en flujos de presentación de credenciales mediados por el sistema, respondiendo a solicitudes de la API de Credenciales Digitales (vía Chrome) o verificadores de app nativa. Android también soporta explícitamente OpenID4VCI para la emisión de credenciales, permitiendo a los usuarios elegir una billetera de terceros compatible para recibir credenciales recién emitidas. Si bien las apps nativas son el foco principal para 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. Si bien las apps de billetera 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 mDLs destinadas a Apple Wallet) a menudo está sujeta a los procesos y derechos 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 proveedoras de documentos de terceros registradas.

El enfoque de "jardín amurallado" 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.

Si bien Apple Wallet es el proveedor principal integrado para credenciales como 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 confiables para la firma de solicitudes.
2. Implementar una Extensión de App: Añadir una Extensión de App de UI de "Proveedor de Documentos de Identidad" al proyecto. Esta extensión es responsable de mostrar la UI de autorización al usuario cuando la app es seleccionada durante un flujo de verificación basado en web.

Esto significa que, si bien crear una billetera totalmente integrada en iOS requiere construir una aplicación nativa y usar los frameworks específicos de Apple—no tecnologías web como PWAs—existe un mecanismo claro, aunque estrictamente controlado, para que las apps 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 solicitudes a Apple Wallet o cualquier otra app 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 septiembre de 2025) y Safari 26 (15 de septiembre de 2025) lanzando soporte de presentación estable, y Firefox 149 ahora llevando código de implementación base, la API está en camino hacia la cobertura de tres navegadores. Mantendremos este artículo actualizado a medida que cambie el panorama.

El período desde octubre de 2025 se ha definido por la maduración de la API de tubería experimental a estándar gobernado. La eliminación del registro abierto de protocolos en el TPAC (noviembre de 2025) es la señal más clara: el WG FedID del W3C ahora nombra y gobierna explícitamente los protocolos que la API soporta. Esto permite una revisión integral de seguridad y privacidad, pero también convierte al Grupo de Trabajo en un guardián — un compromiso deliberado con el que no todos los participantes se sienten cómodos (notablemente, la objeción por el muro de pago de ISO de Ping Identity sigue sin resolverse).

Mientras tanto, la API se está expandiendo de la presentación al ciclo de vida completo: El Origin Trial de emisión de Chrome 143 vía navigator.credentials.create() permite a los sitios web activar el aprovisionamiento de billeteras. Pero una vulnerabilidad de vinculación de selección de billetera — donde apps de billetera maliciosas pueden interceptar códigos de emisión — está bloqueando la adopción gubernamental de esta característica.

En el frente regulatorio, el Topic F del ARF de la UE requiere condicionalmente soporte de la DC API para todas las billeteras de estados miembros de EUDI, pendiente de que la especificación alcance la Recomendación del W3C. La adopción en el mundo real se está acelerando: el DMV de California ha añadido soporte de DC API, y se están desarrollando suites de pruebas de conformidad por el Consorcio Europeo de Billeteras.

Quedan desafíos. La realidad de doble protocolo (el soporte multiprotocolo de Chrome versus el enfoque solo mdoc de Safari) persiste para las partes confiantes. La cuestión de si los navegadores deben soportar todos los protocolos listados o solo uno está sin resolver — directamente ligada a las limitaciones de la plataforma de Apple. Y las consideraciones de privacidad siguen siendo la brecha más grande que impide el progreso hacia la Recomendación Candidata, con requisitos normativos para los criterios de inclusión de protocolos aún no escritos. Se estima que la especificación está a 1–2 años de la Recomendación del W3C.