Preguntas frecuentes sobre la identidad y las credenciales digitales

En esta página, se responden las preguntas frecuentes sobre la integración con la Billetera de Google para la identidad y las credenciales digitales.

Integración y primeros pasos

P.: ¿Cuál es el proceso paso a paso para que un socio nuevo se incorpore como parte de confianza (RP)?

R.: Consulta los pasos en Cómo aceptar IDs de la Billetera en línea.

P.: ¿Cuál es la duración habitual del proceso de incorporación de RP?

R.: Por lo general, la incorporación debería tardar entre 3 y 5 días hábiles.

P.: ¿Cómo podemos hacer un seguimiento del estado de nuestra solicitud de parte dependiente (RP) después de enviarla?

R.: Si no recibiste una respuesta después de 5 días, comunícate con nuestro equipo de asistencia al cliente en wallet-identity-rp-support@google.com.

P.: ¿Dónde podemos encontrar el formulario de incorporación de RP y la documentación oficial para desarrolladores?

A:

P.: ¿Cómo se usará la información que proporcionamos (como el nombre y el logotipo del producto) en la experiencia del producto?

R.: El nombre y el logotipo del producto se muestran en la pantalla de consentimiento visible para el usuario para ayudarlo a identificar qué parte dependiente solicita su ID digital. Es posible que también se incluyan URLs y vínculos a las políticas en la experiencia del producto.

P.: ¿Debemos firmar las Condiciones del Servicio si solo planeamos usar el entorno de zona de pruebas para el desarrollo y las pruebas?

R.: No, aceptar las Condiciones del Servicio no es un paso obligatorio para realizar pruebas.

P.: ¿Dónde podemos encontrar una implementación de referencia, código de muestra o una aplicación de demostración para comenzar?

A:

Registradores de verificadores

P.: ¿Qué es el registrador de verificadores y cómo funciona?

R.: El registrador de verificadores actúa como una autoridad certificadora que incorpora clientes de nivel inferior (RP finales). El RP final no interactúa directamente con la Billetera de Google.

P.: ¿Cuál es el proceso de integración específico para un registrador verificador y sus clientes posteriores?

R.: Consulta los pasos en la Guía del registrador de verificadores.

P.: ¿En qué se diferencia de una integración directa de RP?

R.: Los registradores de verificadores administran la relación de confianza de sus clientes y manejan la integración con la Billetera de Google en su nombre, mientras que los RP directos administran su propia configuración con Google.

P.: En el registrador de verificadores, ¿quién se incluye en la lista de entidades permitidas en la configuración de Google: el registrador de verificadores, el RP final o ambos?

R.: Google incluye en la lista de entidades permitidas el certificado de CA raíz del registrador de verificadores. Luego, el registrador del verificador emite nuevos certificados de hoja para cada RP final de nivel inferior.

P.: ¿Cómo fluyen los datos entre el RP final, el registrador del verificador y la Billetera de Google?

R.: El registrador del verificador envía la solicitud de API a la Billetera de Google para el RP final. La Billetera de Google devuelve datos de credenciales encriptados al registrador del verificador, quien luego los procesa y envía el indicador final al RP final.

R.: No. El registrador de verificadores puede optar por no mostrar sus detalles.

P.: ¿Cuáles son los tipos de claves y las curvas permitidos para las CA raíz y los certificados de RP?

R.: Los certificados se deben generar con P-256 / ECDSA.

P.: ¿Podemos usar certificados de firma intermedios entre nuestra CA raíz y los certificados de hoja de RP?

R.: Sí. Puedes almacenar de forma segura un certificado raíz de larga duración (p.ej., en un HSM) para firmar con poca frecuencia certificados intermedios operativos. Luego, esos certificados intermedios se pueden usar para firmar certificados de entidad final de RP, lo que permite una rotación más sencilla en caso de incumplimiento sin afectar la raíz.

P.: ¿Cuál es la vida útil requerida para los certificados?

R.: Un período de vigencia de 10 años es perfectamente aceptable para un certificado de CA raíz. Por lo general, los certificados de hoja de RP final deben seguir un cronograma de renovación de aproximadamente 1 año para garantizar que se puedan rotar de manera eficiente si surgen problemas.

P.: ¿Necesitamos administrar un certificado de hoja independiente para cada cliente de la parte que confía (RP)?

R.: Sí. Durante el período de lanzamiento inicial, los agregadores deben administrar certificados separados para cada RP de nivel inferior. Esto permite configuraciones de pantalla por RP y un seguimiento preciso del abuso. Si bien esto agrega una sobrecarga operativa a gran escala, tenemos la intención de volver a analizar las posibles alternativas (como el uso de hashes de metadatos de RP) después del lanzamiento inicial.

P.: ¿Los socios pueden tener varios certificados activos de forma simultánea?

R.: Sí, la configuración admite cualquier cantidad de certificados activos por RP o agregador, lo que resulta útil para los socios que operan con varios nombres comerciales.

P.: ¿Cómo se debe formatear el nombre distinguido (sujeto)?

R.: El nombre distintivo debe ser único a nivel global por socio. Este identificador estático se usa para supervisar las solicitudes entrantes de los socios y garantizar la confianza en el ecosistema.

P.: ¿Cómo funciona la vinculación de dominios? ¿Es necesario que los orígenes estén incorporados en el certificado?

R.: No es necesario que los dominios estén incorporados directamente en el certificado. En cambio, la verificación del dominio se realiza con el parámetro expected origins dentro de la llamada a la API. Además, se pueden asociar varios dominios sin problemas a un solo certificado. En el caso de las solicitudes sin firma, la vinculación se ejecuta con el nombre de dominio o el nombre del paquete de la app junto con una huella digital.

P.: ¿Se pueden omitir los detalles del agregador en la IU de verificación para una experiencia de marca blanca?

R.: Sí, la información del agregador (como el nombre, el logotipo, la URL y la política de privacidad) es completamente opcional en los metadatos del verificador. Esto permite una solución completamente sin marca en la que solo se muestran al usuario los detalles del RP final.

P.: ¿Qué debemos proporcionar para comenzar a realizar pruebas en el entorno de zona de pruebas?

R.: Desde un punto de vista técnico, solo necesitas proporcionar tu certificado raíz de Sandbox. La zona de pruebas está diseñada para reflejar de forma idéntica el entorno de producción.

P.: ¿En qué se diferencia el proceso de incorporación para los registradores verificadores (agregadores) en comparación con los RP directos?

R.: Los agregadores se someten a un proceso ligeramente modificado. Después de ejecutar las Condiciones del Servicio específicas del Registrador de Verificadores, la admisión se divide en dos partes: un formulario principal para establecer tu estado como Registrador de Verificadores, seguido de un formulario optimizado que se requiere para cada RP individual que incorpores. Por lo general, cada envío de RP requiere una grabación de video de la integración, y el proceso de revisión suele tardar entre 2 y 3 días hábiles.

P.: ¿Podemos incorporar clientes que tengan la intención de actuar como intermediarios o revender servicios de verificación a otras entidades?

R.: No. El modelo y la preferencia actuales de Google son trabajar directamente con los registradores de verificadores (agregadores) y sus RP finales directos, en lugar de admitir modelos anidados de revendedores o intermediarios.

Integración técnica y API

P.: ¿Cuál es el protocolo subyacente para las solicitudes? ¿Qué versiones son compatibles?

R.: El protocolo principal es OpenID para presentaciones verificables (OpenID4VP) versión 1.0.

P.: ¿Qué anexos de la norma ISO 18013-7 (p. ej., anexos B, C y D) admite Google para la presentación de la mDL?

R.: Google admite el Anexo D [actualmente en borrador] (OpenID4VP con la API de DC).

P.: ¿Cómo estructuramos correctamente una solicitud a la API para solicitar varias credenciales en una sola presentación del usuario?

R.: Ambos tipos de credenciales se deben solicitar dentro de un solo objeto de consulta dcql en la misma solicitud JSON.

P.: ¿La API permite solicitar una credencial genérica sin enumerar todos los tipos de credenciales posibles?

Respuesta: No.

P.: ¿Cómo controla la API la verificación de edad? ¿Podemos solicitar la fecha de nacimiento exacta o solo un indicador de "mayor de X"?

R.: Se admiten ambos. Puedes solicitar birth_date, age_in_years o un indicador que preserve la privacidad "superior a X". Las pruebas de conocimiento cero (ZKP) también se pueden usar para un indicador verdadero/falso.

P.: ¿Cuáles son los requisitos para nuestra infraestructura de PKI?

R.: Los RP necesitan una PKI para firmar solicitudes. Los registradores de verificadores actúan como su propia CA.

P.: ¿Podemos usar nuestros certificados existentes o debemos obtener uno nuevo firmado por Google?

R.: Los RP necesitan un certificado nuevo firmado por Google o un registrador verificador. En el caso de los registradores de verificadores, Google confiará en tu certificado raíz si sigues los pasos de "Establecimiento de confianza" que se indican en la documentación.

R.: Toda la solicitud debe generarse del lado del servidor. En Android, usa la API de Credman; en la Web, usa la API de Credenciales digitales (DC).

P.: ¿Qué herramientas de depuración, registro y observabilidad están disponibles para los desarrolladores?

R.: Los socios pueden usar el alias de asistencia wallet-identity-rp-support@google.com. No se proporcionan herramientas específicas de registro o de observabilidad.

Credenciales y datos

P.: ¿Qué documentos de identidad digitales, entidades emisoras y credenciales se admiten por país y región?

R.: Consulta las regiones admitidas aquí: Supported Issuers and Certificates.

P.: ¿Cuándo planean admitir credenciales de nuevos países o regiones?

R.: Estamos agregando regiones de forma activa. Consulta la página de entidades emisoras admitidas para ver las actualizaciones.

P.: Cuando la entidad emisora actualiza una credencial, ¿el usuario final recibe una notificación?

R.: Sí, se le notifica al usuario y la actualización se aplica automáticamente.

P.: ¿Qué datos de credenciales, si los hay, almacena Google en sus servidores, especialmente en el contexto del RGPD?

R.: Google no guarda datos relacionados con las credenciales en sus servidores. Estos se almacenan de forma local y segura en el dispositivo del usuario.

Pruebas y entornos

P.: ¿Cómo obtenemos acceso a un entorno de zona de pruebas para probar el flujo completo de extremo a extremo?

R.: La zona de pruebas está abierta en Modo de zona de pruebas.

P.: ¿Cuál es el proceso para que los socios que no se encuentran en una región en la que se lanzó oficialmente la función se agreguen a la lista de entidades permitidas para realizar pruebas?

R.: Envía por correo electrónico los IDs de Gmail de las billeteras de prueba a wallet-identity-rp-support@google.com.

P.: ¿Cuál es el proceso para habilitar un sitio web o una app de prueba con fines de demostración, lo que permite que cualquier persona con una credencial de producción la presente?

R.: Los socios deben completar la integración estándar de RP, incluida una demostración de video en el entorno de pruebas.

Experiencia del usuario (UX)

P.: ¿Cuál es la experiencia del usuario si no tiene un documento de identidad digital o la app de la Billetera de Google instalada cuando inicia un flujo de verificación?

R.: Los usuarios que no tienen la app se dirigen a Play Store. Las personas que no tengan un ID pueden crear uno en el flujo con la IU de media pantalla.

P.: ¿Podemos detectar de forma programática si un usuario tiene un documento de identidad digital en su Billetera antes de mostrarle la opción de verificación?

R.: No, la API debe invocarse por el usuario para proteger la privacidad.

P.: ¿Podemos solicitarle al usuario que desbloquee su dispositivo con un dato biométrico antes de presentar una credencial?

R.: La autenticación del usuario (biométrica, PIN o patrón) es obligatoria de forma predeterminada y no se puede inhabilitar.

R.: No, la Billetera de Google los reordena alfabéticamente.

Seguridad y cumplimiento

P.: Nuestro caso de uso implica volver a compartir datos del usuario con terceros. ¿Esto está permitido según las Condiciones del Servicio?

R.: Sí, se pueden aplicar restricciones. Consulta nuestras Condiciones del Servicio para obtener más información.

P.: ¿Qué documentación está disponible sobre la seguridad, la confiabilidad y la accesibilidad de las soluciones de identidad digital para nuestros fines de cumplimiento?

R.: Los socios pueden consultar las revisiones de seguridad de Trail of Bits.

Funciones avanzadas y hoja de ruta

P.: ¿Cuáles son las capacidades de las pruebas de conocimiento cero (ZKP) para la verificación de edad que preserva la privacidad?

R.: La prueba de conocimiento cero (ZKP) es un método criptográfico que permite que una persona (el probador) demuestre a un verificador que posee cierta información de identidad o que cumple con un criterio específico (p. ej., ser mayor de 18 años, tener una credencial válida) sin revelar los datos subyacentes reales.

P.: ¿Cómo se controlan las diferentes versiones de los circuitos de ZK?

R.: Los RP deben implementar servicios de verificación de ZK para solicitar los circuitos disponibles más recientes.

P.: ¿Cómo funciona el uso compartido y la administración de credenciales en varios dispositivos, como un teléfono y un wearable?

R.: Las credenciales se aprovisionan en un solo dispositivo y no se pueden compartir.

Otros

P.: ¿Cómo maneja Google las revocaciones de pases de identificación si se revoca un pasaporte?

R.: Los usuarios pueden borrar los pases desde la configuración de la Cuenta de Google. Los dispositivos perdidos se pueden denunciar para revocar las credenciales.

P.: ¿Cómo se maneja la revocación de la mDL? ¿Es en tiempo real?

R.: El usuario puede activarla o la entidad emisora (DMV) puede enviarla. Es en tiempo real si el dispositivo está en línea; de lo contrario, los objetos de seguridad de corta duración (MSO) vencerán.

P.: ¿Cuál es la política de rotación de claves para los RP?

R.: Se recomienda la rotación anual.

P.: ¿Cuál es la versión mínima de Android compatible con la API de Digital Credentials?

R.: Android 9 (nivel de API 28) y versiones posteriores.

P.: ¿Cuál es la versión mínima de Chrome que admite la API de Digital Credentials?

R.: Chrome 128 y versiones posteriores.

P.: ¿Qué navegadores son compatibles con la API de Digital Credentials?

R.: Puedes encontrar detalles sobre la compatibilidad con navegadores aquí: https://digitalcredentials.dev/ecosystem-support

P.: ¿Qué usuarios podrán agregar un ID cuando se lance un país nuevo?

R.: El acceso se basa en la configuración del país del usuario en Play Store.

P.: ¿La API de Digital Credentials funciona con iOS?

R.: Sí, la API funciona con navegadores compatibles, como Safari. Sin embargo, Apple no admite OpenID4VP.