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

Cette page répond aux questions fréquentes sur l'intégration à Google Wallet pour les identités et les identifiants numériques.

Intégration et premiers pas

Q : Quelles sont les étapes à suivre pour qu'un nouveau partenaire s'intègre en tant que partie de confiance (RP) ?

R : Consultez la procédure Accepter des pièces d'identité issues de Wallet en ligne.

Q : Quelle est la durée habituelle du processus d'intégration des RP ?

R : L'intégration prend généralement entre trois et cinq jours ouvrés.

Q : Comment suivre l'état de notre demande de partie de confiance (RP) après l'envoi ?

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ù pouvons-nous trouver le formulaire d'intégration RP et la documentation officielle pour les développeurs ?

A:

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 s'affichent sur l'écran de consentement destiné aux utilisateurs pour les aider à identifier la partie de confiance qui demande leur identifiant numérique. Des URL et des liens vers les règles peuvent également figurer dans l'expérience produit.

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

R : Non, l'acceptation des conditions d'utilisation n'est pas obligatoire pour les tests.

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

A:

Bureaux d'enregistrement des validateurs

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

R : Le registre du validateur agit en tant qu'autorité de certification qui intègre les clients en aval (RP finaux). Le RP de fin n'interagit pas directement avec Google Wallet.

Q : Quel est le processus d'intégration spécifique pour un bureau d'enregistrement de validateurs et ses clients en aval ?

R : Consultez la procédure sur la page Guide du registraire de validation.

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

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

Q : Dans le registre des organismes de validation, qui est autorisé dans la configuration de Google : l'organisme de validation, la partie de confiance finale ou les deux ?

R : Google autorise le certificat CA racine du registraire du validateur. L'autorité d'enregistrement du validateur émet ensuite de nouveaux certificats de feuille pour chaque RP de point de terminaison en aval.

Q : Comment les données circulent-elles entre le RP final, le registraire du valideur et Google Wallet ?

R : Le registraire du vérificateur envoie la requête d'API à Google Wallet pour le RP final. Google Wallet renvoie les données d'identifiants chiffrées au Registre des validateurs, qui les traite ensuite et envoie le signal final au RP final.

R : Non. Le registraire de validation peut choisir de ne pas afficher ses coordonnées.

Q : Quels sont les types de clés et les courbes autorisés pour les CA racines et les certificats RP ?

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

Q : Pouvons-nous utiliser des certificats de signature intermédiaires entre notre autorité de certification racine et les certificats de feuille RP ?

R : Oui. Vous pouvez stocker de manière sécurisée un certificat racine à longue durée de vie (par exemple, dans un HSM) pour signer rarement des certificats intermédiaires opérationnels. Ces certificats intermédiaires peuvent ensuite être utilisés pour signer les certificats de feuille RP finaux, ce qui permet une rotation plus facile en cas de piratage 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 CA racine. Les certificats feuilles de l'End-RP doivent généralement être renouvelés tous les ans pour pouvoir être remplacés efficacement en cas de problème.

Q : Doit-on gérer un certificat feuille distinct pour chaque client Relying Party (RP) ?

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 des configurations d'affichage par RP et un suivi précis des utilisations abusives. Bien que cela ajoute une surcharge opérationnelle à grande échelle, nous prévoyons de réexaminer les alternatives potentielles (comme l'utilisation de hachages de métadonnées RP) après le déploiement initial.

Q : Les partenaires sont-ils autorisés à avoir plusieurs certificats actifs en même temps ?

R : Oui, la configuration accepte un nombre illimité de certificats actifs par fournisseur d'identité ou agrégateur. C'est utile pour les partenaires qui exercent leurs activités sous différents noms commerciaux.

Q : Quel format doit respecter le nom distinctif (sujet) ?

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

Q : Comment fonctionne l'association 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 au certificat. Au lieu de cela, la validation du domaine est effectuée à l'aide du paramètre "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 package du domaine ou de l'application, ainsi que d'une empreinte.

Q : Est-il possible d'omettre les informations sur l'agrégateur dans l'interface utilisateur de validation pour une expérience en marque blanche ?

R : Oui, les informations sur l'agrégateur (nom, logo, URL et règles de confidentialité, par exemple) sont entièrement facultatives dans les métadonnées du validateur. Cela permet de créer une solution entièrement en marque blanche où seuls les détails du point de réparation et d'essai sont affiché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, vous n'avez besoin de fournir que votre certificat racine du bac à sable. Le bac à sable est conçu pour refléter à l'identique l'environnement de production.

Q : En quoi le processus d'intégration des bureaux d'enregistrement (agrégateurs) de validation diffère-t-il de celui des RP directs ?

R : Les agrégateurs suivent un processus légèrement modifié. Après l'exécution des conditions d'utilisation spécifiques de Verifier Registrar, l'ingestion est divisée en deux parties : un formulaire principal pour établir votre statut de Verifier Registrar, suivi d'un formulaire simplifié requis pour chaque RP que vous intégrez. Chaque envoi de RP nécessite généralement un enregistrement vidéo de l'intégration. L'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 actuel de Google et sa préférence sont de travailler directement avec les registres de validation (agrégateurs) et leurs RP finaux directs, plutôt que de prendre en charge les modèles de revendeurs ou d'intermédiaires imbriqués.

Intégration technique et API

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

R : Le protocole principal est OpenID pour les présentations vérifiables (OpenID4VP) version 1.0.

Q : Quelles annexes de la norme ISO 18013-7 (par exemple, les annexes B, C et D) Google prend-il en charge 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 d'API pour demander plusieurs identifiants dans une même présentation utilisateur ?

R : Les deux types d'identifiants doivent être demandés dans un seul objet de requête dcql dans 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 validation de l'âge ? Pouvons-nous demander la date de naissance exacte ou uniquement un signal "plus de X ans" ?

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

Q : Quelles sont les exigences concernant notre infrastructure PKI ?

R : Les RP ont besoin d'une PKI pour signer les requêtes. Les bureaux d'enregistrement de validateurs agissent comme leur propre autorité de certification.

Q : Pouvons-nous utiliser nos 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 un registraire de validation. Pour les bureaux d'enregistrement de validateurs, Google fera confiance à votre certificat racine si vous suivez les étapes d'établissement de la confiance décrites dans la documentation.

R : L'intégralité de la demande 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.

Identifiants et données

Q : Quels sont les identifiants numériques, les émetteurs et les identifiants acceptés par pays et par région ?

R : Pour connaître les régions disponibles, consultez Émetteurs et certificats acceptés.

Q : Quand prévoyez-vous d'accepter les identifiants de nouveaux pays ou régions ?

R : Nous ajoutons activement de nouvelles régions. Consultez la page des émetteurs acceptés pour en savoir plus.

Q : Lorsqu'un émetteur met à jour un identifiant, l'utilisateur final reçoit-il une notification ?

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

Q : Quelles données d'identification Google stocke-t-il sur ses serveurs, le cas échéant, en particulier dans le contexte du RGPD ?

R : Google n'enregistre pas les données liées aux identifiants sur ses serveurs. Elles sont stockées localement et de manière sécurisée sur l'appareil de l'utilisateur.

Tests et environnements

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

R : Le bac à sable est ouvert à l'adresse Mode bac à sable.

Q : Comment les partenaires qui ne sont pas basés dans une région où la fonctionnalité a été officiellement lancée peuvent-ils être ajoutés à la liste d'autorisation pour les tests ?

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

Q : Comment activer un site Web ou une application de test à des fins de démonstration, en permettant à toute personne disposant d'un identifiant de production de la présenter ?

R : Les partenaires doivent effectuer l'intégration standard au programme de partenaires, y compris une démonstration vidéo dans le bac à sable.

Expérience utilisateur

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

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

Q : Pouvons-nous détecter par programmation si un utilisateur possède 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 demander à l'utilisateur de déverrouiller son appareil avec une méthode biométrique avant de présenter un identifiant ?

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

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

Sécurité et conformité

Q : Notre cas d'utilisation implique le re-partage des 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 : Quelles sont les ressources documentaires disponibles concernant la sécurité, la fiabilité et l'accessibilité des solutions d'identité numérique à des fins de conformité ?

R : Les partenaires peuvent consulter les examens de sécurité Trail of Bits.

Fonctionnalités avancées et feuille de route

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

R : 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 une pièce d'identité valide) sans révéler les données sous-jacentes.

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

R : Les RP doivent implémenter des services de validation ZK pour demander les derniers circuits disponibles.

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

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

Autres

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

R : Les utilisateurs peuvent supprimer des pass dans les paramètres de leur compte Google. Les appareils perdus peuvent être signalés pour révoquer les identifiants.

Q : Comment la révocation des cartes d'identité numériques 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 (DMV). Elle est en temps réel si l'appareil est en ligne. Dans le cas contraire, les objets de sécurité de courte durée (MSO) expirent.

Q : Quelles sont les règles de rotation des clés pour les RP ?

R : Nous vous recommandons de renouveler votre mot de passe 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 version 128 ou ultérieure.

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

R : Vous trouverez des informations sur les navigateurs compatibles sur cette 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 dépend du 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 tels que Safari. Toutefois, OpenID4VP n'est pas compatible avec Apple.