Questions fréquentes sur l'identité et les identifiants numériques

Q : Quelle est la procédure étape par étape pour qu'un nouveau partenaire s'intègre en tant que partie de confiance ?

R : Suivez le guide par étapes Choisissez votre parcours.

Q : Combien de temps dure généralement le processus d'intégration des RP ?

R : En général, le processus d'intégration prend entre trois et cinq jours ouvrés.

Q : Comment suivre l'état de notre demande de partie de confiance après l'avoir envoyée ?

R : Si vous n'avez pas reçu de réponse au bout de cinq jours, veuillez contacter notre équipe d'assistance sur wallet-identity-rp-support@google.com.

Q : Où trouver le formulaire d'intégration des RP et la documentation officielle pour les développeurs ?

A:

• Formulaire d'intégration : Formulaire de contact pour les partenaires de confiance de Google Wallet
• Documentation pour les développeurs : Présentation de l'identité numérique

Q : Comment les informations que nous fournissons (comme le nom et le logo du produit) seront-elles utilisées dans l'expérience produit ?

R : Le nom et le logo du produit sont affichés sur l'écran de consentement visible par l'utilisateur pour l'aider à identifier la partie de confiance qui demande son identité numérique. Des URL et des liens vers des règles peuvent également être inclus dans l'expérience produit.

Q : Devons-nous signer les conditions d'utilisation si nous prévoyons d'utiliser l'environnement de bac à sable uniquement pour le développement et les tests ?

R : Non, il n'est pas nécessaire d'accepter les conditions d'utilisation pour effectuer des tests.

Q : Où trouver une implémentation de référence, un exemple de code ou une application de démonstration pour commencer ?

A:

• Dépôt GitHub : Identity Reference Implementation.
• Site Web de test : verifier.multipaz.org

Q : Qu'est-ce que le registre des vérificateurs et comment fonctionne-t-il ?

A: Le registre de vérificateurs agit en tant qu'autorité de certification qui intègre les clients en aval (RP finaux). La partie de confiance finale n'interagit pas directement avec Google Wallet.

Q : Quel est le processus d'intégration spécifique pour un registraire de vérificateurs et ses clients en aval ?

A: Consultez la procédure décrite dans le guide du bureau d'enregistrement du vérificateur.

Q : En quoi diffère-t-elle d'une intégration directe de RP ?

R : Les bureaux d'enregistrement de vérificateurs gèrent la relation de confiance pour leurs clients et l'intégration à Google Wallet en leur nom, tandis que les parties de confiance directes gèrent leur propre configuration avec Google.

Q : Dans le registre des vérificateurs, qui est ajouté à la liste d'autorisation dans la configuration de Google : le registre des vérificateurs, la partie de confiance finale ou les deux ?

R : Google ajoute le certificat CA racine du registraire de vérification à la liste d'autorisation. Le registre du vérificateur émet ensuite de nouveaux certificats d'entité finale pour chaque partie de confiance finale en aval.

Q : Comment les données circulent-elles entre la partie de confiance finale, le registre des vérificateurs et Google Wallet ?

R : Le bureau d'enregistrement du vérificateur envoie la requête API à Google Wallet pour le RP final. Google Wallet renvoie les données d'identification chiffrées au registre du vérificateur, qui les traite ensuite et envoie le signal final au RP final.

Q : Pour les solutions en marque blanche, est-il obligatoire d'afficher le nom du registraire du vérificateur dans le flux de consentement de l'utilisateur, ou peut-il s'agir uniquement du nom de la partie de confiance finale ?

R : Non. Le bureau d'enregistrement vérificateur peut choisir de ne pas afficher ses informations.

Q : Quels sont les types de clés et les courbes autorisés pour les autorités de certification racine et les certificats de tiers de confiance ?

R : Les certificats doivent être générés à l'aide de P-256/ECDSA.

Q : Pouvons-nous utiliser des certificats de signataire intermédiaires entre notre autorité de certification racine et les certificats d'entité finale de la partie de confiance ?

R : Oui. Vous pouvez stocker de manière sécurisée un certificat racine de longue durée (par exemple, dans un HSM) pour signer de manière peu fréquente des certificats intermédiaires opérationnels. Ces certificats intermédiaires peuvent ensuite être utilisés pour signer les certificats d'entité finale de la partie de confiance, ce qui facilite la rotation en cas de faille sans affecter la racine.

Q : Quelle est la durée de vie requise pour les certificats ?

R : Une durée de vie de 10 ans est tout à fait acceptable pour un certificat d'autorité de certification racine. Les certificats d'entité finale de la partie de confiance doivent généralement être renouvelés tous les ans environ pour garantir qu'ils peuvent être remplacés efficacement en cas de problème.

Q : Devons-nous gérer un certificat d'entité finale distinct pour chaque client de la partie de confiance ?

R : Oui. Pendant la période de lancement initiale, les agrégateurs doivent gérer des certificats distincts pour chaque RP en aval. Cela permet de configurer l'affichage par partie de confiance et de suivre précisément les utilisations abusives. Bien que cela ajoute une surcharge opérationnelle à grande échelle, nous prévoyons d'examiner d'autres solutions potentielles (comme l'utilisation de hachages de métadonnées RP) après le déploiement initial.

Q : Les partenaires sont-ils autorisés à posséder plusieurs certificats actifs simultanément ?

R : Oui, la configuration accepte un nombre illimité de certificats actifs par RP ou agrégateur, ce qui est utile pour les partenaires opérant sous différents noms commerciaux.

Q : Comment le nom distinctif (objet) doit-il être formaté ?

R : Le nom distinctif doit être unique pour chaque partenaire. Il s'agit d'un identifiant statique que Google utilise pour surveiller les requêtes entrantes des partenaires et garantir la confiance dans l'écosystème.

Q : Comment fonctionne la liaison de domaine ? Les origines doivent-elles être intégrées au certificat ?

R : Les domaines n'ont pas besoin d'être intégrés directement dans le certificat lui-même. À la place, la validation du domaine est effectuée à l'aide du paramètre d'origines attendues dans l'appel d'API. De plus, plusieurs domaines peuvent être associés de manière transparente à un seul certificat. Pour les requêtes non signées, la liaison est exécutée à l'aide du nom de domaine ou du package d'application, ainsi que d'une empreinte.

Q : Les informations sur l'agrégateur peuvent-elles être omises de l'UI de validation pour une expérience en marque blanche ?

R : Oui, les informations sur l'agrégateur (comme le nom, le logo, l'URL et les règles de confidentialité) sont complètement facultatives dans les métadonnées du vérificateur. Cela permet d'obtenir une solution entièrement en marque blanche, où seuls les détails de la partie de confiance finale sont présentés à l'utilisateur.

Q : Que devons-nous fournir pour commencer les tests dans l'environnement de bac à sable ?

R : D'un point de vue technique, il vous suffit de fournir votre certificat racine Sandbox. Le bac à sable est conçu pour refléter à l'identique l'environnement de production.

Q : En quoi le processus d'intégration diffère-t-il pour les bureaux d'enregistrement de vérificateurs (agrégateurs) par rapport aux parties de confiance directes ?

R : Les agrégateurs suivent un processus légèrement différent. Après avoir signé les conditions d'utilisation spécifiques du registraire vérificateur, l'intégration se divise en deux parties : un formulaire principal pour établir votre statut de registraire vérificateur, suivi d'un formulaire simplifié requis pour chaque partie de confiance que vous intégrez. Chaque envoi de RP nécessite généralement un enregistrement vidéo de l'intégration, et le processus d'examen prend généralement deux à trois jours ouvrés.

Q : Pouvons-nous intégrer des clients qui ont l'intention d'agir en tant qu'intermédiaires ou de revendre des services de validation à d'autres entités ?

R : Non. Le modèle et la préférence actuels de Google consistent à travailler directement avec les bureaux d'enregistrement de vérificateurs (agrégateurs) et leurs parties de confiance finales directes, plutôt que de prendre en charge des modèles de revendeurs ou d'intermédiaires imbriqués.

Q : Quel est le protocole sous-jacent pour les requêtes ? Quelles sont les versions compatibles ?

R : Le protocole principal est OpenID for Verifiable Presentations (OpenID4VP) version 1.0.

Q : Quelles annexes de la norme ISO 18013-7 (par exemple, les annexes B, C et D) sont prises en charge par Google pour la présentation des mDL ?

R : Google est compatible avec l'annexe D [actuellement en version préliminaire] (OpenID4VP utilisant l'API DC).

Q : Comment structurer correctement une requête API pour demander plusieurs identifiants dans une seule présentation utilisateur ?

R : Les deux types d'identifiants doivent être demandés dans un seul objet de requête dcql de la même requête JSON.

Q : L'API permet-elle de demander un identifiant générique sans lister tous les types d'identifiants possibles ?

R : Non.

Q : Comment l'API gère-t-elle la vérification de l'âge ? Pouvons-nous demander la date de naissance exacte ou seulement un signal "plus de X ans" ?

R : Les deux sont compatibles. Vous pouvez demander birth_date, age_in_years ou un signal "plus de X" protégeant la confidentialité. Les preuves à divulgation nulle de connaissance (ZKP, Zero-Knowledge Proofs) peuvent également être utilisées pour un signal vrai/faux.

Q : Quelles sont les exigences concernant notre infrastructure PKI ?

R : Les tiers de confiance ont besoin d'une infrastructure à clé publique (PKI) pour signer les requêtes. Les bureaux d'enregistrement de vérificateurs agissent en tant que leur propre autorité de certification.

Q : Pouvons-nous utiliser nos propres certificats existants ou devons-nous en obtenir un nouveau signé par Google ?

R : Les RP ont besoin d'un nouveau certificat signé par Google ou par un bureau d'enregistrement de vérificateurs. Pour les bureaux d'enregistrement de vérificateurs, Google fera confiance à votre certificat racine si vous suivez les étapes de la section "Établissement de la confiance" de la documentation.

Q : Quelle est la stratégie d'intégration recommandée pour le Web par rapport à une application Android ?

R : L'intégralité de la requête doit être générée côté serveur. Sur Android, utilisez l'API Credman. Sur le Web, utilisez l'API Digital Credentials (DC).

Q : Quels outils de débogage, de journalisation et d'observabilité sont disponibles pour les développeurs ?

R : Les partenaires peuvent utiliser l'alias d'assistance wallet-identity-rp-support@google.com. Aucun outil de journalisation ou d'observabilité spécifique n'est fourni.

Q : Quels sont les pièces d'identité numériques, les émetteurs et les justificatifs d'identité acceptés par pays et par région ?

R : Consultez la liste des régions prises en charge sur la page Émetteurs et certificats compatibles.

Q : Quand prévoyez-vous d'accepter les justificatifs d'autres pays ou régions ?

R : Nous ajoutons activement de nouvelles régions. Consultez la page des émetteurs compatibles pour vous tenir informé.

Q : L'utilisateur final reçoit-il une notification lorsqu'un justificatif est mis à jour par l'émetteur ?

R : Oui, l'utilisateur est informé et la mise à jour est appliquée automatiquement.

Q : Comment accéder à un environnement de bac à sable pour tester l'intégralité du flux ?

A : Le bac à sable est accessible à l'adresse Mode bac à sable.

Q : Quelle est la procédure à suivre pour que les partenaires qui ne sont pas basés dans une région où le programme a été officiellement lancé soient ajoutés à la liste d'autorisation pour les tests ?

R : Envoyez par e-mail les ID Gmail des portefeuilles de test à wallet-identity-rp-support@google.com.

Q : Quelle est la procédure à suivre pour activer un site Web ou une application de test à des fins de démonstration, afin que toute personne disposant d'un identifiant de production puisse le présenter ?

A: Les partenaires doivent suivre le processus d'intégration standard des RP, y compris une démonstration vidéo dans un bac à sable.

Q : Quelle est l'expérience utilisateur si un utilisateur n'a pas de pièce d'identité numérique ou si l'application Google Wallet n'est pas installée lorsqu'il lance un flux de validation ?

R : Les utilisateurs qui n'ont pas l'application sont redirigés vers le Play Store. Les utilisateurs qui n'ont pas d'ID peuvent en créer un directement dans le flux à l'aide de l'interface utilisateur en demi-écran.

Q : Pouvons-nous détecter de manière programmatique si un utilisateur dispose d'une pièce d'identité numérique dans son portefeuille avant de lui proposer l'option de validation ?

R : Non, l'API doit être appelée par l'utilisateur pour protéger la confidentialité.

Q : Pouvons-nous exiger que l'utilisateur déverrouille son appareil à l'aide d'une méthode biométrique avant de présenter un justificatif d'identité ?

R : L'authentification de l'utilisateur (biométrique, code ou schéma) est requise par défaut et ne peut pas être désactivée.

Q : Est-il possible de personnaliser l'ordre des attributs demandés sur l'écran de consentement utilisateur ?

R : Non, Google Wallet les réorganise par ordre alphabétique.

Q : Notre cas d'utilisation implique de partager à nouveau les données utilisateur avec des tiers. Est-ce autorisé par les conditions d'utilisation ?

R : Oui, des restrictions peuvent s'appliquer. Pour en savoir plus, consultez nos conditions d'utilisation.

Q : Quelle documentation est disponible concernant la sécurité, la fiabilité et l'accessibilité des solutions d'identité numérique pour nos besoins de conformité ?

R : Les partenaires peuvent se référer aux examens de sécurité de Trail of Bits.

Q : Quelles sont les capacités des preuves à divulgation nulle de connaissance (ZKP) pour la vérification de l'âge protégeant la confidentialité ?

A: La preuve à divulgation nulle de connaissance (ZKP, Zero-Knowledge Proof) est une méthode cryptographique qui permet à une personne (le prouveur) de prouver à un vérificateur qu'elle possède une certaine information d'identité ou qu'elle répond à un critère spécifique (par exemple, qu'elle a plus de 18 ans ou qu'elle détient un justificatif valide) sans révéler les données sous-jacentes elles-mêmes.

Q : Comment les différentes versions des circuits ZK sont-elles gérées ?

R : Les tiers de confiance doivent implémenter des services de vérification ZK pour demander les derniers circuits disponibles.

Q : Comment fonctionnent le partage et la gestion des identifiants sur plusieurs appareils, comme un téléphone et un accessoire connecté ?

R : Les identifiants sont provisionnés sur un seul appareil et ne peuvent pas être partagés.

Q : Comment Google gère-t-il la révocation d'un pass d'identité si un passeport est révoqué ?

R : Les utilisateurs peuvent supprimer des pass dans les paramètres de leur compte Google. En cas de perte d'un appareil, ils peuvent le signaler pour révoquer les identifiants.

Q : Comment la révocation d'un mDL est-elle gérée ? Est-ce en temps réel ?

R : Elle peut être déclenchée par l'utilisateur ou envoyée par l'émetteur (le DMV). Il est en temps réel si l'appareil est en ligne. Sinon, les objets de sécurité éphémères (MSO) expirent.

Q : Quelle est la règle de rotation des clés pour les parties de confiance ?

R : Nous vous recommandons de les renouveler tous les ans.

Q : Quelle est la version minimale d'Android compatible avec l'API Digital Credentials ?

R : Android 9 (niveau d'API 28) ou version ultérieure.

Q : Quelle est la version minimale de Chrome compatible avec l'API Digital Credentials ?

R : Chrome 128 ou version ultérieure.

Q : Quels sont les navigateurs compatibles avec l'API Digital Credentials ?

R : Vous trouverez des informations sur la compatibilité des navigateurs sur la page https://digitalcredentials.dev/ecosystem-support.

Q : Quels utilisateurs pourront ajouter une pièce d'identité lorsqu'un nouveau pays sera lancé ?

R : L'accès est basé sur le paramètre de pays de l'utilisateur dans le Play Store.

Q : L'API Digital Credentials fonctionne-t-elle avec iOS ?

R : Oui, l'API fonctionne avec les navigateurs compatibles, comme Safari. Toutefois, OpenID4VP n'est pas compatible avec Apple.