Preguntas frecuentes sobre la identidad y las credenciales digitales

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

Incorporación y primeros pasos

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

R.: Sigue la guía paso a paso en Elige tu ruta.

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

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

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

R.: Si no recibes 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 para el usuario para ayudarlo a identificar qué parte usuaria solicita su ID digital. Es posible que también se incluyan URLs y vínculos a 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, un código de muestra o una aplicación de demostración para comenzar?

A:

Registradores 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 downstream (RP finales). La RP final no interactúa directamente con la Billetera de Google.

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

R.: Consulta los pasos en la Guía para registradores de verificadores.

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

R.: Los registradores de verificadores administran la relación de confianza para sus clientes y controlan la integración con la Billetera de Google en su nombre, mientras que las partes de confianza directas administran su propia configuración con Google.

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

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

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

A: El registrador de verificadores envía la solicitud a la API a la Billetera de Google para el RP final. La Billetera de Google devuelve los datos de credenciales encriptados al registrador del verificador, que luego los procesa y envía la señal final a la RP final.

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

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

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

P.: ¿Podemos usar certificados de firmante intermedios entre nuestra AC raíz y los certificados de entidad final de la parte de confianza?

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 hoja de RP final, lo que permite una rotación más sencilla en caso de una vulneración sin afectar la raíz.

P.: ¿Cuál es la duración requerida para los certificados?

R.: Una vida útil de 10 años es perfectamente aceptable para un certificado de la AC 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 de confianza (RP)?

R.: Sí. Durante el período de lanzamiento inicial, los agregadores deben administrar certificados independientes para cada RP downstream. Esto permite realizar configuraciones de visualización por RP y un seguimiento preciso de los abusos. Si bien esto agrega sobrecarga operativa a gran escala, tenemos la intención de revisar posibles alternativas (como el uso de hashes de metadatos de RP) después del lanzamiento inicial.

P.: ¿Los socios pueden tener varios certificados activos al mismo tiempo?

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

P.: ¿Qué formato debe tener el nombre distinguido (asunto)?

R: El nombre distinguido debe ser único a nivel global para cada socio. Este sirve como un identificador estático que Google 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? ¿Los orígenes deben estar incorporados en el certificado?

R.: No es necesario que los dominios estén incorporados directamente en el certificado. En su lugar, la verificación de dominio se realiza con el parámetro de orígenes esperados dentro de la llamada a la API. Además, se pueden asociar varios dominios sin problemas con un solo certificado. En el caso de las solicitudes sin firma, la vinculación se ejecuta con el nombre del dominio o 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 dentro de los metadatos del verificador. Esto habilita una solución de marca blanca completa en la que solo se muestran al usuario los detalles de la 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 debes proporcionar tu certificado raíz de la zona de pruebas. 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 de los registradores de verificadores (agregadores) del de 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 simplificado que se requiere para cada RP individual que incorpores. Cada envío de RP suele requerir 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 directas, en lugar de admitir modelos de revendedores o intermediarios anidados.

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., los anexos B, C y D) admite Google para la presentación de 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 pedir 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 una señal de verdadero o falso.

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

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

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

R.: Las partes de confianza necesitan un certificado nuevo firmado por Google o un registrador verificador. En el caso de los registradores 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 se debe generar del lado del servidor. En Android, usa la API de Credman; en la Web, usa la API de Digital Credentials (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 ni de observabilidad.

Credenciales y datos

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

R.: Consulta las regiones admitidas aquí: Entidades emisoras y certificados admitidos.

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

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

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

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

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 el modo de zona de pruebas.

P.: ¿Cuál es el proceso para que los socios que no se encuentran en una región de lanzamiento oficial 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, de modo que cualquier persona con una credencial de producción pueda presentarlo?

R.: Los socios deben completar la incorporación estándar de RP, incluida una demostración en video de la zona 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?

A: Los usuarios que no tienen la app son dirigidos a Play Store. Quienes 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, el usuario debe invocar la API para proteger la privacidad.

P.: ¿Podemos exigir que el usuario 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 de los usuarios con terceros. ¿Se permite esto según las Condiciones del Servicio?

R.: Sí, es posible que se apliquen 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 a una persona (el probador) demostrar 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 o tener una credencial válida) sin revelar los datos subyacentes reales.

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

R.: Las RP deben implementar servicios de verificador de ZK para solicitar los circuitos más recientes disponibles.

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 controla Google las revocaciones de pases de identificación si se revoca un pasaporte?

R: Los usuarios pueden borrar 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? ¿Se exportan en tiempo real?

R.: El usuario puede activarla o el emisor (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 las 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 admiten 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 documento de identidad cuando se lance un país nuevo?

R.: El acceso se basa en el parámetro de configuración de 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.