Vérifiez les documents d’identité sur le web

Bonjour ! Je m’appelle Erik et je suis ingénieur au sein de l’équipe Cartes et Apple Pay. Bonjour, je m’appelle Marcos, ingénieur en normes dans l’équipe WebKit. Nous allons vous monter comment simplifier la vérification d’identité en ligne avec des documents d’identité numériques. Que vous soyez développeur de sites web souhaitant optimiser vos processus de vérification d’identité, développeur d’apps cherchant à intégrer des fonctionnalités d’authentification, ou tout simplement passionné par l’identité numérique, cette séance est faite pour vous. Les documents d’identité numériques se démocratisent et permettent de regrouper différents documents officiels, qu’il s’agisse de permis de conduire ou d’autres justificatifs délivrés par un gouvernement. Ces documents d’identité numériques ont des atouts majeurs par rapport aux documents traditionnels, notamment une utilisation simplifiée en ligne. Aujourd’hui, pour prouver mon identité en ligne, je dois souvent charger des photos de ma carte d’identité physique. Cette approche n’est avantageuse ni pour l’utilisateur ni pour l’entreprise qui cherche à authentifier l’identité. Et elle ne fournit pas une bonne expérience utilisateur, car celui-ci doit tout d’abord retrouver sa carte d’identité. Il doit ensuite trouver un arrière-plan approprié pour prendre une photo tout en veillant à ce que la photo soit nette et bien visible. D’autre part, l’entreprise doit créer une solution complexe capable de traiter ces photos et de vérifier leur authenticité. Tout ceci est vraiment compliqué à gérer. Les documents mobiles ou « mdocs » sont un exemple de format de document d’identité numérique qui vise à résoudre ce problème. Les mdocs ont des propriétés uniques. D’un côté, ces éléments sont spécifiés dans la norme ISO 18013-5. Ils sont ainsi compatibles entre différentes plates-formes.

Ils assurent aussi une meilleure confidentialité pour les utilisateurs. Si quelqu’un a seulement besoin de connaître mon nom et mon âge, je ne devrais pas avoir à fournir d’autres d’informations. Avec les mdocs, c’est possible. Ils offrent enfin des fonctionnalités de sécurité supérieures à celles d’une pièce d’identité physique, ce qui les rend plus fiables. Par exemple, les données stockées dans un mdoc sont authentifiées par une signature numérique de l’émetteur. Les entreprises garantissent ainsi la fiabilité des informations reçues. Les pièces d’identité stockées dans Cartes d’Apple sont basées sur le format mdoc et respectent les normes ISO 18013.

Les utilisateurs peuvent aujourd’hui présenter leur pièce d’identité dans l’app Cartes d’Apple à certains points de contrôle de sécurité des aéroports américains, dans certains commerces et établissements, et dans tous les Apple Store aux États-Unis. Les gens peuvent aussi utiliser leur pièce d’identité dans certaines apps qui utilisent notre API Verify with Wallet. Si vous avez une app et souhaitez adopter l’API Verify with Wallet pour effectuer la vérification d’identité, regardez la séance « What’s new in Wallet and Apple Pay » de la WWDC22. Certaines juridictions ont aussi créé des apps de fournisseurs de documents au format mdoc. Ces apps permettent aux utilisateurs de stocker et d’utiliser leurs documents d’identité en personne. Pour simuler une administration locale, nous avons conçu une app de démonstration qui gère les permis de conduire. Nous l’appelons : Local Driving Authority. Nous annonçons des améliorations pour cette catégorie d’apps de fournisseurs de documents et pour les pièces d’identité dans Cartes. Dans les prochaines versions, nous intégrerons l’API Digital Credentials du W3C pour demander des mdocs via Safari et WebKit. Je vais vous expliquer comment ça marche. Supposons que je souhaite louer un vaisseau spatial auprès de Spaceship Rentals. Je suis sur Safari et j’ai déjà sélectionné mon vaisseau spatial et mon itinéraire sur leur site web. Je me retrouve à l’étape de vérification de mon identité. Je vais appuyer sur le bouton « Vérifier l’identité ». Ce bouton déclenche l’API JavaScript Digital Credentials. Mon permis de conduire est stocké dans deux apps : l’app Local Driving Authority et Cartes d’Apple. L’interface de ce sélecteur d’apps me permet de choisir l’app que je souhaite utiliser pour la vérification d’identité.

Pour l’instant, je vais utiliser Cartes d’Apple.

Un formulaire de consentement s’affiche pour vérification. Je peux voir qui demande les détails de mon identité grâce à l’icône de la marque et au nom. Je peux aussi voir les éléments spécifiques demandés et s’ils ont l’intention de stocker ces informations ou non. Je vais approuver cette vérification d’identité avec Face ID. Nous voyons maintenant que ces informations ont été ajoutées sur le site web de Spaceship Rentals. C’est super, non ?

Dis Erik, ça a très bien fonctionné sur un iPhone. Et si j’étais sur un Mac ? Excellente question. Je vais vous montrer.

Me revoici dans Safari, mais cette fois-ci sur mon Mac. Je suis toujours sur le site web de Spaceship Rentals que j’ai utilisé auparavant.

Je vais cliquer sur le bouton Vérifier l’identité. Un message m’invite à continuer sur mon iPhone. Une notification s’affiche sur mon iPhone pour me permettre de terminer la vérification de mon identité. Je vais appuyer dessus et voir la même option pour choisir l’app que je souhaite utiliser. Je vais utiliser à nouveau Cartes d’Apple. Le même formulaire de consentement s’affiche : je peux voir qui fait cette demande, quels éléments sont demandés et si ces infos seront conservées. J’accepte la demande et je confirme avec Face ID.

Génial ! Nous voyons que les informations du document ont été renvoyées à Spaceship Rentals sur mon Mac. Nous avons ajouté la prise en charge de Safari sur Mac ainsi que la vérification d’identité multiplateforme standardisée pour d’autres systèmes d’exploitation et navigateurs. Même si je loue mon vaisseau spatial à partir d’une autre plate-forme ou un autre navigateur, je peux toujours utiliser mon identité sur l’iPhone. Pour y parvenir, je vais scanner le code QR affiché par le navigateur. Les flux que vous venez de voir ont été conçus en respectant plusieurs normes. Il utilise l’API Digital Credentials du W3C, en particulier le profil de requête défini dans les normes ISO 18013-7, annexe C et ISO 18013-5. Le protocole FIDO CTAP est utilisé pour le flux multiplateforme. Cela signifie que le code utilisé par un site pour s’intégrer aux plates-formes Apple est également compatible avec d’autres navigateurs et apps qui décident d’adopter ces mêmes normes.

L’expérience a été pensée pour être accessible sur plusieurs plate-formes. Elle prend donc en charge l’iPhone, l’iPad et le Mac, ainsi que d’autres navigateurs et systèmes d’exploitation. Peu importe où l’utilisateur se trouve sur Internet, il peut utiliser les documents de son iPhone pour confirmer son identité. Enfin, nous avons créé des API pour les fournisseurs de documents pour les plate-formes Apple. Elles permettent à des apps comme Local Driving Authority d’apparaître en tant qu’option lors d’un flux de vérification d’identité. Je vais vous montrer en détail les démos que vous venez de voir et vous expliquer leur fonctionnement. La vérification mdoc sur le web commence lorsqu’un utilisateur visite un site web sur un navigateur. Le site web contacte ensuite son serveur afin qu’il crée et signe une requête mdoc. Lorsque le site web reçoit la requête, il peut utiliser l’API Digital Credentials. Quand l’utilisateur effectue une action pour commencer la vérification d’identité, le site web appelle l’API Digital Credentials avec la requête.

Le navigateur transmet ensuite cette requête au système d’exploitation. Celui-ci se base sur la requête et l’interaction utilisateur pour choisir une source de document à consulter, qui peut être une app de fournisseur de documents installée sur l’appareil ou même un autre appareil.

Une fois la décision prise, la requête est transmise à la source de document appropriée pour traitement. L’utilisateur va ensuite autoriser la publication de son document. Ensuite, une réponse chiffrée est renvoyée par la source du document, jusqu’au site web demandeur. Enfin, le site web envoie cette réponse à son serveur pour déchiffrement et validation.

Avec un peu de recul, nous pouvons mieux comprendre les différents éléments qui constituent une vérification mdoc en ligne sur les plate-formes Apple. Il existe deux points d’entrée distincts pour ceux d’entre vous qui souhaitent utiliser ce flux. Si vous êtes développeur d’une app de fournisseur de documents sous iOS, l’API Document Provider peut vous intéresser. Cette API permet à votre app iOS de s’afficher comme une option pour réaliser une vérification mdoc en ligne.

Si vous êtes un site web intéressé par la vérification d’identité en ligne, vous devez implémenter l’API Digital Credentials du W3C, ainsi que la logique associée de traitement des requêtes et des réponses. Je vais explorer ce sujet plus en détail.

En général, un site web doit suivre trois étapes pour demander un mdoc.

D’abord, quand l’utilisateur se rend sur le site pour vérifier son identité, ce dernier doit demander à son serveur de générer et de signer une requête de document. Ensuite, lorsque l’utilisateur est prêt à effectuer une vérification d’identité, le site doit transmettre la requête au navigateur via l’API Digital Credentials du W3C.

Enfin, à la réception d’une réponse, le site doit envoyer la réponse chiffrée à son serveur pour déchiffrement et validation. Marcos, tu m’as l’air d’être un bon développeur Full Stack. Veux-tu nous expliquer comment le site de Spaceship Rentals peut intégrer une étape de vérification d’identité dans son processus de paiement ? Bien sûr. Tout d’abord, je vais vous montrer comment créer et signer une requête à l’aide de l’API Digital Credentials du W3C. La requête que nous allons créer sera conforme à la norme ISO 18013-7, annexe C. La requête peut être divisée en deux parties : une requête d’appareil et les informations de chiffrement. Voyons ces éléments de plus près. La requête d’appareil contient deux informations cruciales. Elle contient une liste de demandes de documents, où je peux déclarer le document que je veux demander à l’utilisateur. Spaceship Rentals veut vérifier un permis de conduire. Je vais donc utiliser la chaîne docType pour les permis de conduire mobiles dans la structure. Ensuite, j’ajoute les propriétés spécifiques du permis de conduire que je souhaite demander en utilisant un ensemble standardisé d’espaces de noms et d’identificateurs d’éléments. Ici, je vais demander le nom et le prénom de la personne, si elle est âgée de plus de 21 ans, sa photo d’identité et son permis de conduire.

L’autre paramètre important dans la requête d’appareil est ce que l’on appelle la liste « Reader Authentication All ». C’est là que le site web signe la requête. Nous allons utiliser cette propriété plus tard. Je vais donc l’ignorer pour l’instant. La deuxième partie de la demande concerne les informations de chiffrement. C’est là que je peux ajouter les paramètres utilisés par le fournisseur de documents pour chiffrer la réponse.

Je dois générer un nonce pour le chiffrement. Le nonce est une fonctionnalité de sécurité importante qui nous protège contre les attaques par relecture. Je vais également générer une paire de clés de chiffrement du destinataire. Cette paire de clés sera utilisée dans le chiffrement de la réponse du document. Je vais placer la clé publique du destinataire dans la structure d’informations de chiffrement et je vais garder la clé privée du destinataire pour l’utiliser plus tard. Je vais pouvoir ainsi déchiffrer plus tard la réponse du document. Je dois donc la garder en sécurité sur mon serveur. Voilà à quoi ressemble une requête complète.

Une fois la demande créée, je peux passer à sa signature. Les exigences de signature de la requête peuvent varier en fonction des apps de fournisseur de documents. Spaceship Rentals doit accepter les pièces d’identité dans l’app Cartes d’Apple. Je vais donc signer la requête d’accès à Cartes.

Avant de pouvoir signer la requête, je dois obtenir un certificat de signature auprès d’Apple Business Connect. Pour cela, vous devez générer une paire de clés de signature et envoyer une demande de signature de certificat à Apple Business Connect. Une fois le certificat obtenu, je peux passer à ce que je dois faire au moment de l’exécution. Ensuite, je dois générer une transcription de session à l’aide de deux informations : l’URL d’origine de mon site web et la structure d’informations de chiffrement que j’ai générée précédemment. Cette transcription de session est également utilisée pour les opérations ultérieures. Dès que j’ai la transcription de session, je suis prêt à signer. À cette fin, je vais utiliser la paire de clés de signature et le certificat de signature envoyés par Apple Business Connect. Il en résulte une structure d’authentification signée.

Je peux ensuite placer cette structure d’authentification signée pour Cartes dans la liste Reader Authentication All. Ce mécanisme est défini dans la norme ISO 18013-5. Sachez que d’autres apps de fournisseur de documents peuvent avoir des exigences légèrement différentes pour la signature de la requête. Je veux accepter des documents depuis l’app Local Driving Authority, mais elle exige que je signe la requête avec un certificat complètement différent de celui qui m’a été envoyé.

Reader Authentication All étant une liste, je peux signer ma requête plusieurs fois. J’ai donc créé une nouvelle structure d’authentification signée en utilisant le certificat de l’administration locale. Je peux l’insérer à côté de la structure d’authentification signée pour Cartes.

J’ai la requête et l’étape suivante consiste à la transmettre au navigateur via l’API Digital Credentials du W3C en JavaScript. Nous pouvons récupérer les données de la requête que nous avons créées sur le serveur et les placer dans le dictionnaire de demandes. Je précise ici qu’il s’agit d’une requête « mdoc » via la propriété « protocol » en utilisant la chaîne standardisée « org-iso-mdoc ». Nous allons appeler la méthode navigator.credentials.get et attendre sa réponse. Cet appel de méthode permet au navigateur d’afficher l’interface du système pour qu’un utilisateur sélectionne un identifiant numérique. Sachez que l’appel de la méthode get doit être effectué via une action de l’utilisateur, comme un clic ou une pression sur un bouton. Une fois la réponse reçue, nous pouvons la renvoyer au serveur pour déchiffrement. Les réponses sont sérialisables en JSON. Elles peuvent donc être renvoyées au serveur à l’aide de l’API Fetch ou XHR. En cas de problème, l’API Digital Credentials du W3C fournit des exceptions pour faciliter le redémarrage de votre programme. Vous pouvez aussi choisir de revenir à une méthode de vérification d’identité existante, comme le scan d’une pièce d’identité chargé via un formulaire HTML. Très bien ! Testons notre code pour nous assurer qu’il fonctionne bien. Fantastique ! Quand j’appuie sur le bouton « Vérifier l’identité », l’interface du système s’affiche. Cela signifie que notre requête fonctionne. Et je vois à la fois Cartes et l’app Local Driving Authority comme options pour l’utilisateur. Qu’en penses-tu, Erik ? Tout à l’air parfait Marcos. Avant de passer à l’étape suivante, je vais vous parler de la sécurité de ce processus. Vous devez vous assurer que vous avez mis en place des mesures de sécurité adéquates lorsque vous traitez des données d’identification. Vous devez vous poser les questions suivantes : Qui demande les données d’identification ? Ces données sont-elles protégées ? Sont-elles authentiques ? Ou ont-elles été copiées ? Je vais examiner chacune des mesures de sécurité qui existent dans les normes pour répondre à ces questions.

Vous avez déjà vu l’authentification des requêtes. C’est ainsi que le site web demandeur peut s’identifier et que les apps de fournisseur de documents peuvent aider les utilisateurs à comprendre qui effectue la requête. Cela se fait via un certificat qui est utilisé pour signer la requête.

Puis, nous avons le chiffrement des réponses. La réponse est chiffrée de bout en bout à l’aide d’une clé générée par le serveur du site web demandeur. Cela empêche d’autres parties de lire les données d’identité, y compris le navigateur et le système d’exploitation. L’authentification de l’émetteur est utilisée pour prouver l’authenticité des données d’identité. Le site web demandeur peut ainsi déterminer qui a émis les données et s’il faut leur faire confiance. Cela empêche également la modification des données renvoyées. Et enfin, l’authentification mdoc empêche la duplication des données. Le site web demandeur peut donc vérifier que le mdoc qu’il a reçu provient du même appareil que celui sur lequel il a été émis. Il est donc impossible de dupliquer le mdoc sur plusieurs appareils.

Marcos, pourquoi ne pas nous montrer comment ces propriétés de sécurité entrent en jeu lors du traitement de la réponse ? Bien sûr ! C’est parti !

La dernière chose que je dois faire pour terminer l’implémentation de Spaceship Rentals est de gérer la réponse du fournisseur de documents. Comme pour la requête, le format de réponse JavaScript est défini dans l’annexe C de la norme ISO 18013-7. La réponse contient également deux propriétés. Le texte chiffré que je dois déchiffrer. Et la clé que l’app du fournisseur de documents a générée dans le cadre du chiffrement. Le texte est chiffré à l’aide d’un chiffrement à clé publique hybride, ou HPKE, défini dans la norme RFC-9180.

Les entrées pour le déchiffrement incluent à la fois le texte chiffré et la clé publique de l’expéditeur de la réponse. Elle inclut également la clé privée du destinataire que nous avons générée précédemment sur le serveur lors de la compilation de la demande. Et l’entrée finale est la même transcription de session que celle que nous avons générée pour signer la requête. Le résultat de cette opération est une réponse de l’appareil déchiffrée. Chaque document de la réponse contient un objet de sécurité mobile. Cet objet est immuable et signé par l’émetteur. Il contient des informations cruciales pour valider l’authenticité des données renvoyées. L’objet de sécurité mobile est authentifié via la structure d’authentification de l’émetteur. Cette structure contient un certificat de signataire de document qui doit d’abord être validé. Pour ce faire, il est enchaîné à un certificat racine de l’autorité émettrice approuvée que l’émetteur publie. Le serveur Spaceship Rentals gère une liste des certificats racines approuvés de l’autorité de certification afin de déterminer les mdocs à accepter. Si un certificat de signataire de document n’est pas approuvé, nous devons ignorer la réponse. Après avoir vérifié le certificat, je dois maintenant valider la signature. Une fois la structure d’authentification de l’émetteur validée, je peux passer à la validation de l’objet de sécurité mobile. Il y a un certain nombre de validations à faire ici, et surtout, je dois valider l’authenticité des éléments qui ont été retournés. Ces éléments retournés peuvent être trouvés dans les « espaces de noms de l’émetteur ». Par exemple, nous pouvons voir ici que le prénom de « Kelly » a été renvoyé. Mais avant de pouvoir l’utiliser, je dois prouver que cet élément n’a pas été altéré. Pour ce faire, nous créons un digest sur l’ensemble de la structure d’information de l’élément. Puis, nous comparons ce digest à un digest particulier qui existe dans l’objet de sécurité mobile. Je peux trouver le digest à comparer en utilisant l’identificateur de digest fourni dans la structure de l’élément. Une fois les digests comparés, je peux être sûr que les données sont authentiques. Enfin, je dois valider l’authentification du mdoc. L’objet de sécurité mobile contient une clé publique d’appareil. Cette clé est unique à l’appareil sur lequel le document a été émis. Je vais ensuite utiliser cette clé pour valider la structure d’authentification de l’appareil. Je confirme ainsi que le document provient de l’appareil sur lequel il a été délivré. Et voilà comment traiter la réponse. Ce que nous avons vu ici n’est qu’un aperçu des étapes requises pour confirmer la validité de la réponse. Pour plus de détails sur la démarche à suivre pour la validation, consultez la norme ISO 18013-5. Je vais maintenant tester le reste du flux. Je vais sélectionner Cartes pour répondre à la requête de Spaceship Rentals, puis m’authentifier. Nous voyons que le flux fonctionne et que les informations ont été déchiffrées et validées par Spaceship Rentals. Nous pouvons enfin faire un tour dans notre vaisseau spatial de location ! Erik, ton avis ? Bon travail ! Je vais récapituler quelques avantages clés mis en évidence lors de cette implémentation. Tout d’abord, l’API Digital Credentials propose, sans aucun doute, une expérience utilisateur inégalée pour la vérification d’identité en ligne. L’intégration avec l’API signifie que votre site web a accès à des fonctionnalités conviviales, comme les flux interappareils. Ensuite, les sites web demandant des mdocs utilisent un ensemble commun de normes. Grâce à ces normes, votre code sera compatible avec tous les navigateurs qui les respectent, ce qui garantit une meilleure compatibilité entre les différentes plate-formes. Et enfin, l’API est tout simplement plus sécurisée. Outre les protections mentionnées précédemment, cette API permet aux apps de fournisseur de documents d’effectuer une validation de domaine sur le site web demandeur. Les attaques de phishing sont ainsi plus difficiles à réaliser.

Cela conclut l’implémentation nécessaire pour l’intégration avec l’API Digital Credentials du W3C. Nous avons créé et signé une requête, l’avons envoyée via l’API Digital Credentials et avons traité la réponse chiffrée. Je vais maintenant me concentrer sur le site web pour demander un mdoc à l’API Document Provider que nous avons développée pour permettre aux apps de participer à la vérification des mdoc en ligne. Lors de la vérification d’identité avec Spaceship Rentals, j’ai eu en option une deuxième app : Local Driving Authority. Voici l’app que nous avons créée et qui peut stocker mon permis de conduire.

Si je choisis l’app Local Driving Authority, nous pouvons voir cette interface d’autorisation s’afficher. Cette interface est fournie par une extension d’app d’interface utilisateur que l’app implémente. Si vous avez déjà une app iOS qui fournit des documents, vous pourrez facilement ajouter cette extension à votre app pour activer la vérification d’identité en ligne.

Cette expérience est possible grâce à l’ajout d’un nouveau framework pour les documents d’identité : IdentityDocumentServices. Je vais vous expliquer comment ça fonctionne. La première étape se déroule en dehors de votre extension d’app. Chaque fois que votre app fournit un document d’identité pouvant être présenté, vous enregistrez ce document auprès d’iOS. Il peut ainsi être affiché dans l’interface sélectionnée. Lorsque vous enregistrez votre document, vous indiquez le type de document et les autorités de certification approuvées pour autoriser le site web demandeur. iOS conserve ensuite l’enregistrement de ce document localement sur l’appareil.

Vient ensuite le flux de vérification d’identité. L’utilisateur va déclencher ce flux. iOS utilise alors les enregistrements de documents stockés pour déterminer quelles apps peuvent répondre à la demande. Puis, l’interface sélectionnée précédemment s’affiche.

L’utilisateur sélectionne l’app qu’il souhaite utiliser. iOS envoie ensuite une requête partielle à l’app du fournisseur de documents à utiliser. Vous vous demandez peut-être ce qu’est une requête partielle. La requête d’appareil ISO 18013 entrante comporte plusieurs éléments contenant des données brutes et analysables sous forme de blobs. Ceux-ci sont encodés de cette manière pour permettre aux fournisseurs de documents de calculer et de valider les signatures. Mais, l’analyse de données brutes provenant d’un site web, sans validation préalable par l’utilisateur, risque de compromettre la sécurité des composants du système qui gèrent les données personnelles. Pour atténuer ce problème, le système analyse plutôt une partie de cette requête dans un sandbox sécurisé. Avant d’analyser la requête, le système d’exploitation valide les signatures de la requête. Il en résulte une requête partielle qui contient les informations nécessaires à la création d’une interface utilisateur, notamment les demandes de documents et les certificats d’authentification.

Votre app recevra cette requête partielle, que vous pourrez utiliser pour créer l’interface à afficher dans votre extension d’app.

Ensuite, une fois que l’utilisateur a autorisé la publication de son document, la requête complète ISO 18013 de l’appareil est transmise à l’app du fournisseur de documents pour utilisation. À ce stade, l’app du fournisseur de documents compare les deux requêtes pour s’assurer qu’elles sont cohérentes, puis elle valide les signatures dans la requête d’appareil ISO 18013.

Une fois validée, l’app peut créer sa réponse pour le document et la chiffrer sur le site web demandeur.

La réponse est ensuite renvoyée à iOS, qui la transmet au site web. Marcos, tu connais Swift ? Je m’y connais un peu oui. Parfait. Notre administration locale a besoin d’aide pour son app, peux-tu l’aider à intégrer les API Document Provider ? Bien sûr. C’est parti ! OK ! Nous devons tout d’abord mettre en œuvre l’étape d’enregistrement. Cette étape doit avoir lieu une fois que l’app Local Driving Authority a créé un mdoc. Toutes les actions d’enregistrement se font via le type IdentityDocumentProviderRegistrationStore. Je vais donc initialiser ce store. Ensuite, je vais instancier un objet MobileDocumentRegistration. Cet objet contient les informations nécessaires à l’enregistrement d’un mdoc. Les permis de conduire sont délivrés par les autorités locales compétentes. Je vais donc indiquer le type de document pour les permis mobiles. Vous pouvez le voir par la chaîne mobileDocumentType « mDL ». Ensuite, je peux indiquer les identifiants de clé d’autorité approuvés. Mon app s’affiche ainsi aux moments appropriés. Si une requête non signée par l’une de ces autorités de certification est reçue, mon app sera masquée dans le formulaire de sélection. Je fournis ensuite un identifiant de document. Cet identifiant peut facilement renvoyer vers l’emplacement où je stocke mon mdoc dans mon app. Une fois mon objet d’enregistrement créé, je peux appeler la méthode addRegistration() pour l’enregistrer dans iOS.

J’ai donné aux utilisateurs de mon app la possibilité de supprimer leur permis de conduire. S’ils suppriment leur permis de conduire, je veux m’assurer que mon app ne s’affiche plus comme option. Je peux y parvenir en supprimant l’enregistrement qui correspond au permis de conduire supprimé. J’utilise pour cela la méthode removeRegistration(). J’y ajoute l’identifiant de document qui correspond à l’enregistrement du mdoc créé précédemment. Il peut arriver que mon app doive interroger les enregistrements stockés par le système. La propriété registrations me permet d’effectuer cette opération. Je peux ensuite parcourir la liste des enregistrements retournés pour les inspecter. Vient ensuite l’ajout de l’extension d’app d’interface à mon app.

Je peux y parvenir en ajoutant une nouvelle cible à mon projet Xcode et en sélectionnant le modèle « Identity Document Provider ».

Cela va générer l’extension à implémenter. Le code peut être ajouté à deux endroits. La méthode performRegistrationUpdates() est appelée lorsqu’un utilisateur autorise l’app Local Driving Authority à effectuer une vérification d’identité en ligne. Cette méthode doit vérifier tous les mdocs stockés dans l’espace de stockage de mon app et s’assurer qu’ils sont enregistrés dans iOS. L’autre endroit pour le code est le contenu « ISO 18013 Mobile Document Request Scene ». C’est là que je peux créer l’interface d’autorisation qui s’affiche lorsque l’utilisateur sélectionne mon app. Pour implémenter l’interface utilisateur, je vais définir une RequestAuthorizationView et y ajouter le contexte reçu. Voyons la mise en œuvre de cette nouvelle vue. La vue prend en charge un ISO18013MobileDocumentRequestContext, qui est fourni par l’extension d’app. Ce type contient les informations de la demande et la méthode de rappel requise pour envoyer une réponse.

Lors de l’implémentation du contenu de cette vue, nous avons trois éléments principaux de l’interface. J’ai besoin de créer une vue qui contient des informations sur la personne qui effectue la requête et ce qu’elle demande. Je vais donc définir une RequestInfoView qui prend la requête que je reçois de l’objet context. C’est la requête partielle dont Erik a parlé plus tôt. Ensuite, je dois ajouter le bouton permettant à l’utilisateur d’accepter la vérification d’identité. Je vais donc appeler une méthode acceptVerification() que j’ai définie sur ma vue. Exécutons tout cela. Quand je suis prêt à accepter la vérification, j’appelle la méthode sendResponse() sur l’objet context de la requête. Cette méthode accepte une fermeture. La fermeture reçoit un paramètre rawRequest. C’est là qu’intervient la requête d’appareil ISO 18013. Une fois la requête d’appareil reçue, je dois la comparer à la requête partielle de l’objet context de la requête. Je dois maintenant valider la signature de la requête brute. Je peux ainsi confirmer que le site web est bien celui auquel mon app fait confiance.

Une fois que la requête semble correcte, je vais créer et chiffrer la réponse au document. Et je renvoie les données de réponse obtenues à partir de la fermeture. Cette réponse est ensuite renvoyée au site web demandeur.

Voilà donc comment implémenter la méthode acceptVerification().

La dernière chose pour compléter notre interface est un bouton « Refuser ». Pour l’ajouter, il suffit d’appeler la méthode cancel du contexte de la requête.

Et voilà l’implémentation de base de l’app Local Driving Authority, Erik. Merci, Marcos.

Voilà qui conclut notre présentation du flux de vérification mdoc en ligne. Les deux API dont nous avons parlé offrent une grande souplesse et vous permettent de mettre en place diverses solutions de vérification d’identité sur vos sites web. Nous pensons que c’est la meilleure solution pour la vérification d’identité en ligne. Avant de nous quitter, voici quelques étapes à suivre pour commencer à intégrer l’API Digital Credentials. Si vous êtes développeur de sites web et souhaitez demander des informations d’identité à partir des pièces d’identité enregistrées dans Cartes, enregistrez-vous sur Apple Business Connect pour obtenir un certificat. Pour obtenir des informations d’identité auprès d’autres apps, notamment celles d’administrations publiques, nous vous invitons à les contacter afin de connaître leurs conditions spécifiques d’intégration. Si vous êtes un développeur d’app et souhaitez fournir des documents d’identité, utilisez plutôt l’extension d’app Identity Document Provider dans votre app. Et quelle que soit l’API que vous utilisez, consultez les différentes normes que nous avons abordées pendant cette séance. Ces ressources utiles vous aideront à comprendre les détails du processus d’implémentation.

Merci beaucoup d’avoir regardé notre séance et bonne WWDC !