Planteamiento y alcance
La empresa desea reemplazar parte de su flujo de verificación de documentos con la Digital Credentials API mediada por el navegador. ¿Cómo decidirías si adoptarla, si comenzar con la presentación o la emisión, y cómo controlarías los riesgos de compatibilidad y privacidad?
Qué evalúa el entrevistador
- Separar la capacidad de la API, el ecosistema de credenciales y los resultados de negocio en lugar de tratar un borrador de estándar como una red ya lista.
- Distinguir los flujos de presentación y emisión junto con sus diferentes socios y riesgos.
- Cuantificar la cobertura, la tasa de finalización, el costo de revisión manual, las pérdidas por fraude y las rutas de recuperación.
- Incorporar la minimización de datos, el consentimiento, las alternativas y las condiciones de parada en la toma de decisiones.
Preguntas para clarificar
- ¿El objetivo es el inicio de sesión, la verificación de edad, la apertura de cuentas o la emisión de una nueva credencial?
- ¿Qué billeteras, formatos de credenciales y dispositivos tienen los usuarios objetivo, y cómo se medirá la cobertura?
- ¿Qué campos son obligatorios y cuáles pueden usar divulgación selectiva o revisión manual?
- ¿Qué permite que un usuario continúe cuando falla la verificación, una billetera no está disponible o una credencial expira o es revocada?
Estructura de respuesta en 30 segundos
Comenzaría con un flujo de presentación de alto valor y bajo riesgo de pérdida como una pequeña prueba piloto, en lugar de reemplazar todos los flujos de identidad. Compararía la API, la ruta manual y la actual en términos de finalización, tiempo, costo y fraude, mientras mido la cobertura de billeteras y credenciales. La minimización de datos, el consentimiento explícito, la interoperabilidad y una ruta de respaldo son requisitos indispensables para el lanzamiento. Solo después de que se cumplan las métricas de cobertura, privacidad y operativas evaluaría la emisión o mercados más amplios.
Análisis detallado paso a paso
1. Definir los límites del producto
El Working Draft del W3C del 1 de junio de 2026 describe la mediación del agente de usuario para presentar y emitir credenciales digitales. Define una capa de coordinación entre el navegador y el ecosistema de credenciales, no un formato de documento universal, una red de billeteras o una conclusión legal de identidad. El discovery de producto debe evaluar “el navegador puede iniciar el flujo” de manera independiente a “el negocio puede confiar en el resultado”.
2. Separar la presentación y la emisión
La presentación solicita una credencial que el usuario ya posee; sus riesgos se centran en la disponibilidad de la billetera, la elección del usuario, los campos divulgados y la verificación. La emisión requiere además la elegibilidad del emisor, el formato de la credencial, la vinculación de claves, el ciclo de vida y la revocación, lo que genera más trabajo de alianzas y cumplimiento normativo. Conviene comenzar con un escenario que utilice credenciales existentes en lugar de construir una red de emisión al mismo tiempo.
3. Establecer criterios de decisión medibles
Utiliza un grupo de control y compara la finalización de extremo a extremo, el tiempo P50/P95, el costo por verificación, la derivación a revisión manual, los rechazos por fraude y el volumen de soporte. Segmenta por dispositivo, billetera, navegador y cohorte de usuarios para que los promedios no oculten brechas. Cuenta por separado los fallos de la API, las cancelaciones de usuarios, las expiraciones y las revocaciones; el éxito técnico no equivale al éxito del negocio.
4. Diseñar la privacidad, la confianza y el respaldo
Solicita únicamente los campos necesarios para el propósito, conserva los avisos de consentimiento y de finalidad, y restringe los datos de las credenciales en los registros. El verificador comprueba la confianza en el emisor, las firmas, la validez y la revocación en lugar de confiar en la salida del cliente. Los dispositivos no compatibles, el rechazo de la billetera y los fallos de red recurren a la ruta manual o de documentos existente. Define umbrales de parada para incidentes de privacidad, quejas o tasas de finalización, y pausa la prueba piloto si se cruza alguna línea crítica.
Respuesta de muestra de alta calidad
No reemplazaría la verificación de identidad solo porque un navegador exponga una API. Elegiría un flujo de presentación con credenciales existentes y un costo de fallo acotado, mediría la cobertura de billeteras y navegadores, y realizaría una comparación controlada de finalización, tiempo, costo, derivación manual y fraude. La presentación y la emisión son decisiones independientes; la emisión añade trabajo sobre elegibilidad del emisor, interoperabilidad de formatos y ciclo de vida de revocación. El producto solicita únicamente los campos necesarios, registra el consentimiento y el servidor verifica el emisor, la firma, la validez y la revocación. Los flujos no compatibles, cancelados y expirados regresan a la ruta existente. Una vez cumplidas las líneas de parada de cobertura, privacidad y quejas, expandiría el mercado o evaluaría la emisión.
Errores comunes
- Tratar el Working Draft como una red universal compatible con todas las regiones, navegadores y billeteras.
- Mezclar la presentación con la emisión y subestimar las alianzas de emisores, formatos y revocación.
- Medir únicamente el éxito de las llamadas a la API en lugar de la finalización, la derivación manual y los resultados de fraude.
- Registrar credenciales en bruto o solicitar campos de identidad no relacionados con el propósito.
- No contar con una alternativa fuera de la API, impidiendo que los dispositivos no compatibles abran una cuenta.
- Ejecutar una prueba piloto sin grupo de control, segmentos de mercado o líneas de parada explícitas.
Preguntas y respuestas de seguimiento
¿Por qué comenzar con la presentación?
Se basa en credenciales y billeteras existentes y tiene un alcance menor que una red de emisión. Permite validar el valor para el usuario, la cobertura y la calidad de la verificación antes de emprender un proyecto de emisión independiente.
¿Cómo decides si la cobertura es suficiente?
Segmenta los dispositivos objetivo, navegadores, billeteras y cohortes de usuarios; luego define una tasa mínima de finalización basada en datos reales del embudo en lugar de una sola tabla de compatibilidad. Los usuarios con baja cobertura deben conservar una alternativa equivalente.
¿Cuándo debería detenerse la prueba piloto?
Predefine umbrales para la tasa de finalización, incidentes de privacidad, quejas, pérdidas por fraude y costos manuales. Si una métrica crítica cruza su límite, detén el incremento de tráfico, preserva las evidencias de auditoría y decide si corregir o retirar la solución.