Compartir a través de

Preguntas más frecuentes (P+F)

Esta página contiene las preguntas más frecuentes sobre las credenciales verificables y las identidades descentralizadas. Las preguntas están organizadas en las siguientes secciones.

Conceptos básicos

¿Qué es un DID?

Los identificadores descentralizados (DID) son identificadores únicos que se pueden usar para proteger el acceso a los recursos, firmar y comprobar credenciales, así como facilitar el intercambio de datos entre aplicaciones. A diferencia de los nombres de usuario y las direcciones de correo electrónico tradicionales, las entidades y la propiedad y el control de los propios DID (ya sea una persona, un dispositivo o una empresa). Los DID existen de forma independiente a cualquier organización externa o intermediario de confianza. La especificación del identificador descentralizado de W3C explica los DID de manera más detallada.

¿Por qué se necesita un DID?

La confianza digital hace del todo necesario que los participantes posean y controlen sus identidades, y la identidad comienza con el identificador. En una época en la que todos los días se producen vulneraciones de sistemas y ataques a los jugosos repositorios centralizados de identificadores, la descentralización de identidades se está convirtiendo en una necesidad de seguridad perentoria para los consumidores y las empresas. Las personas que poseen y controlan sus identidades pueden intercambiar datos y pruebas verificables. Los entornos de credenciales distribuidos permiten automatizar muchos de los procesos empresariales que actualmente se realizan manualmente y requieren una gran cantidad de trabajo.

¿Qué es una credencial verificable?

Las credenciales forman parte de nuestras vidas diarias. Las licencias de conductor se usan para afirmar que somos capaces de operar un vehículo motor. Los títulos universitarios se pueden usar para afirmar nuestro nivel de educación y los pasaportes emitidos por el gobierno nos permiten viajar entre países y regiones. Las credenciales verificables constituyen un mecanismo para expresar este tipo de credenciales en la Web de una forma criptográficamente segura que respete la privacidad y pueda verificarse automáticamente. La especificación de credenciales verificables de W3C explica las credenciales verificables de manera más detallada.

Preguntas conceptuales

¿Qué ocurre cuando un usuario pierde su teléfono? ¿Puede recuperar su identidad?

Existen varios mecanismos de recuperación que se pueden ofrecer a los usuarios, cada uno con sus propias ventajas. Microsoft actualmente está evaluando diferentes opciones y enfoques de diseño de recuperación que resulten cómodos y seguros, al tiempo que respeten la privacidad y la capacidad de autogobierno de los usuarios.

¿Cómo puede un usuario confiar en una solicitud de un emisor o comprobador? ¿Cómo puede saber si el DID de una organización es real?

Implementamos la especificación de configuración de DID conocidos de Decentralized Identity Foundation para conectar un DID a los nombres de dominio más conocidos de un sistema existente. Todos los DID que se crean mediante Verified ID de Microsoft Entra tienen la opción de incluir un nombre de dominio raíz que se codificará en el documento de DID. Consulte este artículo sobre la Vinculación de dominio al identificador distribuido para obtener más información sobre dominios vinculados.

¿Cuáles son las limitaciones de tamaño de una credencial verificable en el Id. verificado?

  • Para la solicitud de emisión: 1 MB
  • Foto en la credencial verificable: 1 MB
  • Resultado de devolución de llamada de 10 MB sin recepción

¿Cuáles son los requisitos de licencias?

No hay requisitos de licencia especiales para emitir credenciales verificables.

¿Cómo puedo restablecer el servicio Verified ID de Microsoft Entra?

El restablecimiento requiere que opte por no participar y vuelva a inscribirse en el servicio de Verified ID de Microsoft Entra. La configuración existente de credenciales verificables se restablece y el inquilino obtiene un nuevo DID que se usará durante la emisión y presentación.

  1. Siga las instrucciones para optar por no participar.
  2. Siga los pasos de implementación de Verified ID de Microsoft Entra para volver a configurar el servicio.
    1. Si va a configurar manualmente Verified ID, elija una ubicación para que Azure Key Vault esté en la misma región o una más cercana. Elegir la misma región evita problemas de rendimiento y latencia.
  3. Termine de configurar el servicio de credenciales verificables. Debe volver a crear las credenciales.
    1. También debe emitir nuevas credenciales porque el inquilino ahora contiene un nuevo DID.

¿Cómo puedo comprobar la región de mi inquilino de Microsoft Entra?

  1. En Azure Portal, vaya a Microsoft Entra ID para la suscripción que usa para la implementación de la Id. verificada de Microsoft Entra.

  2. En Administrar, seleccione Propiedades.

    Captura de pantalla de las opciones para eliminar configuración y darse de baja.

  3. Consulte el valor de País o Región. Si el valor es un país o una región de Europa, el servicio de Verified ID de Microsoft Entra se configurará en Europa.

¿Id. verificada por Microsoft Entra admite ION como su método DID?

Verified ID admitió el método DID:ION en vista previa hasta diciembre de 2023.

¿Cómo cambio desde did:ion a did:web?

Si quiere pasar a did:web desde did:ion, puede seguir estos pasos a través de la API de administración. Cambiar la entidad requiere volver a emitir todas las credenciales:

Exportar definiciones existentes de credenciales DID:ION

  1. Para la entidad did:ion, use el portal para copiar todas las definiciones de reglas y visualización de las credenciales existentes.
  2. Si tiene más de una entidad, debe usar las API de administración si la entidad did:ion no es la predeterminada. En el inquilino de Id. verificada, conéctese mediante la API de administración, enumere las entidades para obtener el identificador de entidad de la entidad did:ion. A continuación, use la API enumerar contratos para exportarlos y guardar el resultado en un archivo para que pueda volver a crearlos.

Creación de una entidad did:web

  1. Con la API de incorporación, cree la nueva entidad did:web. Como alternativa, si el inquilino solo tiene una entidad did:ion, también puede optar por no recibir el servicio, seguido de una operación de participar para reiniciar con las configuraciones de Id. verificada. En este caso, puede elegir entre la configuración rápida y manual.
  2. Si va a configurar una entidad did:web mediante la API de administración, debe llamar a generar documento de DID para generar dicho documento y llamar a generar un documento conocido y, a continuación, cargar archivos JSON en la ruta de acceso conocida correspondiente.

Volver a crear definiciones de credenciales

Al crear su nueva entidad did:web, debe volver a crear las definiciones de credenciales. Puede hacerlo a través del portal si ha optado por no participar y volver a participar, o bien debe usar la API create contact para volver a crearlos.

Actualización de aplicaciones existentes

  1. Actualice cualquiera de las aplicaciones existentes (aplicaciones de emisor o comprobador) para usar el nuevo did:web authority. En el caso de las aplicaciones de emisión, actualice también la dirección URL del manifiesto de credenciales.
  2. Pruebe los flujos de emisión y comprobación de la nueva entidad did:web. Cuando las pruebas se concluyan correctamente, continúe con el paso siguiente para la eliminación de la entidad did: ion.

Eliminar entidad did: ion

Si no optó por no participar y se volvió a inscribir, deberá quitar su entidad antigua did:ion. Use la API eliminar entidad para eliminar la entidad did:ion.

Sí, después de volver a configurar el servicio, el inquilino tiene un nuevo uso de DID para emitir y comprobar las credenciales verificables. Debe asociar el nuevo DID al dominio.

¿Es posible solicitar a Microsoft que recupere "DID antiguos"?

No, en este momento no es posible conservar el DID del inquilino después de optar por no participar en el servicio.

No puedo usar ngrok, ¿qué hago?

En los tutoriales para implementar y ejecutar los ejemplos se describe el uso de la herramienta ngrok como proxy de aplicación. A veces, los administradores de TI bloquean el uso de esta herramienta en redes corporativas. Como alternativa, puede implementar el ejemplo en Azure App Service y ejecutarlo en la nube. Los vínculos siguientes le ayudarán implementar el ejemplo correspondiente en Azure App Service. El plan de tarifa Gratis será suficiente para hospedar el ejemplo. Para cada tutorial, primero debe crear la instancia de Azure App Service, a continuación, omitir la creación de la aplicación, ya que ya tiene una, y después, seguir con el tutorial de la implementación.

Independientemente del idioma del ejemplo que use, se usa el nombre de host de Azure AppService (https://something.azurewebsites.net) como punto de conexión público. No es necesario configurar nada más para que funcione. Si realiza cambios en el código o la configuración, deberá volver a implementar el ejemplo en Azure AppServices. La solución de problemas o depuración no es tan fácil como ejecutar el ejemplo en el equipo local, donde los seguimientos en la ventana de la consola muestran errores, pero puede lograr casi lo mismo mediante el flujo de registro.

Protección de red para eventos de devolución de llamada

La API Solicitar servicio usa devoluciones de llamada a una dirección URL proporcionada por la aplicación de usuario de confianza. Esta dirección URL debe ser accesible desde el sistema de Id. verificada para recibir las devoluciones de llamada. Las devoluciones de llamada proceden de la infraestructura de Azure en la misma región que el inquilino de Microsoft Entra. Si necesita proteger la red, tiene dos opciones.

  • Usar etiquetas de servicio del firewall de Azure,AzureCloud.
  • Usar el intervalo CIDR publicado para configurar el firewall. Debe usar un valor de AzureCloud.regions que coincida con la ubicación en la que se ha implementado el inquilino de Microsoft Entra para configurar el firewall para permitir que el tráfico de devolución de llamada desde la API Solicitar servicio pase a través de él. Por ejemplo, si la entidad está en la UE, debe elegir todos los intervalos CIDR de AzureCloud.northeurope, westeurope, etc., en la configuración de los firewalls.

Escaneo del código QR

En la documentación, la instrucción scan the QR code hace referencia a escanearlo con la aplicación móvil Microsoft Authenticator, a menos que se indique lo contrario. Es posible escanear el código QR con la aplicación de cámara del dispositivo móvil, que luego inicia Microsoft Authenticator. Para que esto funcione, el controlador de protocolo para openid-vc:// debe estar registrado para Microsoft Authenticator. Si se ha registrado otra aplicación móvil, no se abrirá Authenticator.

En los teléfonos móviles Android, los problemas conocidos de escanear el código QR son:

  • En Android 9 y versiones anteriores, escanear el código QR con la aplicación de cámara no funciona y no hay ninguna otra solución alternativa que usar la aplicación Microsoft Authenticator para escanearlo.
  • En teléfonos Android con perfiles profesionales y personales, cada perfil tiene su propia instancia de la aplicación Microsoft Authenticator. Si tiene una credencial en la aplicación Authenticator del perfil de trabajo e intenta escanear un código QR mediante la aplicación de cámara desde el perfil personal, se abrirá la aplicación Authenticator personal. Esto produce un error porque la credencial está en el perfil de trabajo, no en la personal. El mensaje de error dice: "Tendrá que agregar este identificador comprobado e intentarlo de nuevo".

Pasos siguientes