Forums Aux Questions (FAQ)

  • Article

Cette page contient des questions fréquemment posées sur les Justificatifs vérifiables et l’identité décentralisée. Les questions sont organisées dans les sections suivantes.

Concepts de base

Qu’est-ce qu’un identificateur décentralisé (DID) ?

Les identificateurs décentralisés (DID) sont des identificateurs uniques utilisés pour sécuriser l’accès aux ressources, signer et vérifier les informations d’identification, et faciliter l’échange de données entre les applications. Contrairement aux noms d’utilisateur et aux adresses e-mail traditionnels, les entités détiennent et contrôlent elles-mêmes les DID (qu’il s’agisse d’une personne, d’un appareil ou d’une société). Les identificateurs décentralisés existent indépendamment de toute organisation externe ou de tout intermédiaire approuvé. La spécification W3C sur les identificateurs décentralisés explique les DID en détail.

Pourquoi avons-nous besoin d’un identificateur décentralisé ?

La confiance numérique exige que les participants possèdent et contrôlent leurs identités, et une identité commence au niveau de l’identificateur. À une époque de failles système et d’attaques quotidiennes d’envergure dirigées contre les identificateurs centralisés, la décentralisation des identités devient un besoin de sécurité critique pour les consommateurs et les entreprises. Les individus possédant et contrôlant leurs identités sont en mesure d’échanger des données et des preuves vérifiables. Un environnement d’informations d’identification distribuées permet l’automatisation de nombreux processus d’entreprise qui sont actuellement manuels et fastidieux.

Que sont les Justificatifs vérifiables ?

Les informations d’identification font partie de notre vie quotidienne. Les permis de conduire attestent de notre capacité à utiliser un véhicule à moteur. Les diplômes universitaires attestent de notre niveau d’éducation, et les passeports délivrés par les autorités publiques nous permettent de voyager dans différents pays/régions. Les Justificatifs vérifiables constituent un mécanisme permettant d’exprimer ces types d’informations d’identification sur le web d’une manière sécurisée sur le plan du chiffrement, respectueuse de la confidentialité et vérifiable par un ordinateur. La spécification W3C sur les identificateurs décentralisés décrit les justificatifs vérifiables en détail.

Questions conceptuelles

Que se passe-t-il quand un utilisateur perd son téléphone ? Peut-il récupérer son identité ?

Il existe plusieurs façons d’offrir un mécanisme de récupération aux utilisateurs. Chacune présente ses propres inconvénients. Microsoft évalue actuellement diverses options et conçoit des approches de récupération, à la fois pratiques et sécurisées, qui respectent la confidentialité et l’indépendance des utilisateurs.

Comment un utilisateur peut-il faire confiance à une demande émanant d’un émetteur ou d’un vérificateur ? Comment peut-il savoir si un identificateur décentralisé est bien celui d’une organisation ?

Nous implémentons la spécification Well Known DID Configuration de la DIF (Decentralized Identity Foundation) pour pouvoir connecter un identificateur décentralisé émis par un système existant connu, à des noms de domaine. Chaque DID créé avec Vérification d’identité Microsoft Entra peut inclure un nom de domaine racine qui est encodé dans le document du DID. Consultez l’article intitulé Lier votre domaine à votre identificateur distribué pour en savoir plus sur les domaines liés.

Quelles sont les limites de taille des justificatifs vérifiables dans la vérification d’identité ?

  • Pour la requête d’émission - 1 Mo
  • Photo dans les justificatifs vérifiables - 1 Mo
  • Résultat de rappel - 10 Mo sans reçu

Quelles sont les conditions de licence ?

Il n’existe aucune exigence particulière en matière de licence pour émettre des justificatifs vérifiables.

Comment réinitialiser le service ID vérifié Microsoft Entra ?

Pour procéder à la réinitialisation, vous devez vous désengager du service Vérification d’identité Microsoft Entra et vous engager à nouveau. Votre configuration de justificatifs vérifiables existante est réinitialisée. Votre locataire obtient un nouveau DID à utiliser pendant l’émission et la présentation.

  1. Suivez les instructions de refus.
  2. Passez aux étapes de déploiement de l’ID vérifié Microsoft Entra pour reconfigurer le service.
    1. Si vous configurez manuellement ID vérifié, choisissez un emplacement tel que votre coffre de clés Azure se trouve dans la même région ou la région plus proche. Le choix de la même région permet d’éviter les problèmes de performances et de latence.
  3. Terminez la configuration de votre service de justificatifs vérifiables. Vous devez recréer vos justificatifs.
    1. Vous devez également émettre de nouveaux justificatifs, car votre locataire détient maintenant un nouvel identificateur décentralisé.

Comment vérifier la région de mon locataire Microsoft Entra ?

  1. Dans le portail Azure, accédez à Microsoft Entra ID pour trouver l’abonnement que vous utilisez pour votre déploiement d’ID vérifié Microsoft Entra.

  2. Sous Gérer, sélectionnez Propriétés.

    Capture d’écran de suppression de paramètres et de refus.

  3. Consultez la valeur du Pays ou de la Région. Si la valeur est un pays ou une région en Europe, votre service Vérification d’identité Microsoft Entra est configuré en Europe.

La Vérification d’identité Microsoft Entra prend-elle en charge ION comme méthode DID ?

La Vérification d’identité prenait en charge la méthode DID:ION en préversion jusqu’au mois de décembre 2023, après quoi elle a été supprimée.

Comment passer à did:web à partir de did:ion ?

Si vous souhaitez passer à did:web à partir de did:ion, vous pouvez effectuer ces étapes via l’API d’administration. La modification de l’autorité nécessite la ré-émission de toutes les informations d’identification :

Exporter des définitions d’informations d’identification did:ion existantes

  1. Pour l’autorité did:ion, utilisez le portail afin de copier toutes les définitions d’affichage et de règles des informations d’identification existantes.
  2. Si vous avez plusieurs autorités, vous devez utiliser les API d’administration si l’autorité did:ion n’est pas l’autorité par défaut. Sur le locataire avec Vérification d’identité, connectez-vous à l’aide de l’API d’administration et listez les autorités pour obtenir l’ID d’autorité de l’autorité did:ion. Utilisez ensuite l’API Lister les contrats pour les exporter et enregistrer le résultat dans un fichier afin de pouvoir les recréer.

Création d’une autorité did:web

  1. À l’aide de l’API d’intégration, créez la nouvelle autorité did:web. En guise d’alternative, si votre locataire n’a qu’une seule autorité did:ion, vous pouvez également effectuer une désactivation du service suivie d’une opération d’activation pour redémarrer avec des configurations ID vérifié. Dans ce cas, vous pouvez choisir entre une configuration rapide et manuelle.
  2. Si vous configurez une autorité did:web à l’aide de l’API d’administration, vous devez appeler Générer un document de DID pour générer votre document DID, appeler Générer un document connu, puis charger les fichiers JSON vers le chemin d’accès reconnu respectif.

Recréer des définitions d’informations d’identification

Une fois que vous avez créé votre autorité did:web, vous devez recréer vos définitions d’informations d’identification. Vous pouvez le faire par le portail si vous avez désactivé puis réactivé le service, ou vous devez utiliser l’API créer un contrat pour les recréer.

Mettre à jour les applications existantes

  1. Mettez à jour l’une de vos applications existantes (applications émettrices/vérificatrices) pour qu’elle utilise le nouveau did:web authority. Pour les applications émettrices, mettez également à jour l’URL du manifeste d’informations d’identification.
  2. Testez les flux d’émission et de vérification à partir de la nouvelle autorité did:web. Une fois les tests réussis, passez à l’étape suivante pour la suppression de l’autorité did:ion.

Supprimer l’autorité did:ion

Si vous n’avez pas désactivé le service puis procédé à une réintégration, vous devez supprimer votre ancienne autorité did:ion. Utilisez l’API supprimer l’autorité pour supprimer l’autorité did:ion.

Oui, après avoir reconfiguré votre service, votre locataire a un nouvel identificateur décentralisé pour émettre et vérifier les justificatifs vérifiables. Vous devez associer votre nouvel identificateur décentralisé à votre domaine.

Est-il possible de demander à Microsoft de récupérer d’« anciens identificateurs décentralisés » ?

Non, à ce stade, il n’est pas possible de conserver le DID de votre tenant (locataire) après avoir refusé le service.

Je ne peux pas utiliser ngrok, que dois-je faire ?

Les tutoriels pour le déploiement et l’exécution des exemples décrivent l’utilisation de l’outil ngrok en tant que proxy d’application. Cet outil est parfois bloqué par les administrateurs informatiques et ne peut pas être utilisé dans les réseaux d'entreprise. Une alternative consiste à déployer l’exemple sur Azure App Service et à l’exécuter dans le cloud. Aidez-vous des liens suivants pour déployer l’exemple respectif sur Azure App Service. Le niveau tarifaire Gratuit est suffisant pour héberger l’exemple. Dans chaque tutoriel, vous devez d’abord créer l’instance Azure App Service, mais ignorer la création de l’application car vous en avez déjà une, puis continuer le tutoriel avec le déploiement.

Quel que soit le langage de l’exemple que vous utilisez, le nom d’hôte Azure AppService https://something.azurewebsites.net est utilisé comme point de terminaison public. Vous n’avez pas besoin de configurer quelque chose de supplémentaire pour le faire fonctionner. Si vous apportez des modifications au code ou à la configuration, vous devez redéployer l’exemple sur Azure AppServices. La résolution des problèmes/le débogage n’est pas aussi facile que l’exécution de l’exemple sur votre ordinateur local, dans laquelle des traces envoyées vers la fenêtre de console vous indiquent des erreurs, mais vous pouvez obtenir presque le même résultat en utilisant le flux de journal.

Renforcement du réseau pour les événements de rappel

L’API de service de requête utilise des rappels vers une URL fournie par l’application par partie de confiance. Cette URL doit être accessible à partir du système Vérification d’identité pour permettre la réception des rappels. Les rappels proviennent de l’infrastructure Azure, depuis la même région que votre tenant (locataire) Microsoft Entra. Si vous devez renforcer votre réseau, vous avez deux options.

  • Utilisez les étiquettes de service du Pare-feu Azure AzureCloud.
  • Utilisez la plage CIDR publiée pour configurer votre pare-feu. Vous devez utiliser AzureCloud.regions, qui correspond à l’emplacement où votre tenant (locataire) Microsoft Entra est déployé pour configurer votre pare-feu afin de laisser passer le trafic de rappel provenant de l’API de service de requête. Par exemple, si votre tenant (locataire) se trouve dans l’UE, vous devez choisir toutes les plages d’adresses CIDR dans AzureCloud.northeurope, .westeurope, etc., et les ajouter à la configuration de votre pare-feu.

Analyse du code QR

Dans la documentation, l’instruction scan the QR code fait référence à son analyse avec l’application mobile Microsoft Authenticator, sauf indication contraire. Vous pouvez analyser le code QR avec l’application liée à l’appareil photo du téléphone mobile, qui lance ensuite Microsoft Authenticator. Pour que cela fonctionne, le gestionnaire de protocole de openid-vc:// doit être inscrit auprès de Microsoft Authenticator. Si une autre application mobile a été inscrite à la place, Authenticator ne s’ouvre pas. Sur certaines anciennes versions mobiles d’Android, l’analyse du code QR avec l’application liée à l’appareil photo ne fonctionne pas. Il n’existe pas d’autre solution de contournement que celle qui consiste à utiliser l’application Microsoft Authenticator pour l’analyser.

Étapes suivantes