Dès qu’une intégration commence à partir d’août 2026, vérifiez le nouveau format de réponse : vp_token se trouve dans data, avec le champ protocol au niveau prévu par la documentation. Si une intégration existante est en migration, traitez les deux structures selon les consignes officielles ; dans les deux cas, l’analyse côté client ne valide pas le justificatif, et le serveur doit encore effectuer les contrôles cryptographiques. La documentation Android sur l’implémentation de la vérification par e-mail décrit la structure et la transition.
Cet article s’adresse aux développeurs Android dont le traitement des justificatifs d’adresse e-mail échoue après une évolution de la réponse, et aux responsables techniques qui doivent déterminer quel analyseur garder pendant une migration. Il concerne aussi les équipes QA chargées de vérifier le succès, le refus et le retour vers un code envoyé par e-mail.
Dernière mise à jour : 28 octobre 2026. Les changements de structure et les consignes de migration ont été vérifiés dans la documentation Android consacrée à l’implémentation et dans l’aperçu officiel de la vérification par e-mail.
Symptômes d’une réponse mal interprétée
Un échec d’analyse ne signifie pas nécessairement qu’aucun justificatif n’a été produit. Le premier indice est souvent une recherche de vp_token à la racine de la réponse qui renvoie une valeur absente, alors que la réponse suit la nouvelle disposition et place ce champ dans data. Une application peut alors afficher un message « justificatif indisponible », interrompre la création du compte ou proposer le parcours de repli, sans avoir réellement vérifié la charge utile attendue.
Nous commençons par distinguer trois couches, car elles exigent des corrections différentes :
- La réponse reçue par l’application : sa forme, ses champs et leur imbrication correspondent-ils au format attendu ?
- L’interprétation côté client : l’application lit-elle le bon chemin et traite-t-elle correctement les champs manquants ou inattendus ?
- La décision du serveur : le justificatif est-il cryptographiquement valide et acceptable pour cette opération ?
Il faut aussi distinguer une réponse mal formée d’un résultat légitimement indisponible. Une absence de justificatif, une réponse de refus ou une erreur de transport ne doivent pas être transformées en objet de succès vide. Inversement, constater que la racine ne contient pas vp_token ne suffit pas pour conclure à un refus : il faut examiner la structure effectivement reçue et la comparer à l’exemple officiel applicable.
Les limites ne se situent pas uniquement dans le parseur. Une branche d’ancienne structure peut encore être nécessaire pour une intégration en migration, mais elle risque de devenir une dépendance durable si elle n’est jamais testée séparément. Un test qui ne contrôle que l’interface peut passer alors que le serveur n’a pas vérifié le justificatif. Enfin, les journaux de production peuvent exposer des données personnelles si l’équipe y copie la réponse complète au lieu de ne conserver que des informations de diagnostic expurgées.
Structure à lire avant de modifier le parseur
La documentation Android décrit la réponse récente autour de protocol et data. Dans cette organisation, le jeton OpenID4VP est imbriqué dans data : l’application doit donc lire le chemin correspondant à cette structure, plutôt que supposer qu’un champ vp_token apparaît toujours à la racine. L’exemple officiel doit rester la référence pour le nom et le type des champs utilisés par votre intégration ; ne déduisez pas d’autres propriétés à partir d’une réponse d’essai isolée.
À titre de repère d’analyse, le chemin conceptuel devient data.vp_token lorsque l’objet observé est bien celui représenté par l’exemple officiel. Le champ protocol renseigne sur le protocole associé à la réponse ; il ne constitue ni le jeton lui-même, ni une preuve de validité. La spécification OpenID for Verifiable Presentations donne le contexte du protocole, mais ne remplace pas les consignes Android sur la réponse renvoyée à l’application.
Avant de changer le code, confrontez trois éléments : le moment où l’intégration a été commencée, le parcours effectivement exécuté et un échantillon de réponse expurgé. Si l’application est nouvelle, implémentez la forme actuelle. Si elle est existante et en migration, prenez en charge les structures demandées par les consignes officielles pendant la période concernée. Ne codez pas un mécanisme de détection fondé sur la seule présence d’un champ, sans vérifier la structure complète et le type de réponse : une valeur partielle ou inattendue ne doit pas être interprétée comme un justificatif exploitable.
| Situation d’intégration | Ce que le client doit examiner | Décision d’analyse | Preuve à conserver pour le test |
|---|---|---|---|
| Intégration commencée à partir d’août 2026 | protocol, puis la structure de data et l’emplacement de vp_token |
Implémenter le format récent, conformément à l’exemple Android | Réponse expurgée montrant la forme attendue et résultat du parseur |
| Intégration existante en migration | Structure reçue et consigne officielle applicable à l’intégration | Gérer les formes demandées par les consignes de migration, sans supposer que l’ancienne forme suffit | Résultat de test séparé pour chaque forme prise en charge |
| Champ absent, type inattendu ou réponse partielle | Présence et type des champs attendus, puis branche de refus ou d’erreur | Refuser de construire un succès à partir d’une réponse incomplète | Résultat négatif contrôlé et état final côté serveur |
Ce tableau sert à choisir une stratégie de lecture, pas à certifier un justificatif. La prise en charge d’un format indique seulement que l’application sait interpréter une réponse ; elle ne démontre pas l’authenticité du contenu.
Réparation selon le parcours d’intégration
Pour une nouvelle intégration, utilisez le format actuel dans le parseur et dans les tests de contrat. Évitez d’ajouter une lecture de l’ancien champ à la racine « au cas où » sans exigence de migration établie : cette précaution peut masquer une réponse inattendue et rendre l’échec plus difficile à diagnostiquer. Documentez plutôt la forme attendue, les champs obligatoires pour votre traitement et le comportement choisi si la réponse ne respecte pas ce contrat.
Pour une intégration existante, la compatibilité doit être bornée par les consignes officielles, et non par une date ou un calendrier de retrait supposé. La documentation précise les indications de migration à suivre ; vérifiez-la au moment de publier le changement, car la période et les détails d’implémentation peuvent évoluer. Gardez des tests distincts pour la forme ancienne et la forme récente, afin de repérer précisément celle qui échoue lors d’une mise à jour.
Nous recommandons une analyse explicite, avec des branches de refus observables, plutôt qu’une conversion silencieuse vers un objet interne par défaut. En pratique, le parseur devrait :
- recevoir la réponse sans présumer que le champ recherché est à la racine ;
- contrôler que la réponse et les objets imbriqués ont les types attendus ;
- identifier la structure reconnue selon le parcours d’intégration ;
- extraire le jeton uniquement depuis le chemin documenté ;
- envoyer au serveur les éléments nécessaires à sa validation, sans marquer le compte comme vérifié avant la décision serveur.
Ces étapes ne justifient pas de supposer un code d’erreur, un comportement de compatibilité ou une version précise de Credential Manager qui ne serait pas documentée. Elles définissent une méthode de diagnostic : comparer la réponse observée aux exemples officiels, appliquer la branche correspondant à l’intégration, puis vérifier séparément la décision du serveur.
Questions fréquentes sur l’analyse et la migration
Ces réponses précisent les choix de diagnostic qui sont faciles à confondre lors d’un changement de structure.
Où chercher vp_token dans la réponse récente ?
Dans le format documenté depuis août 2026, examinez d’abord les champs protocol et data, puis recherchez vp_token dans data. La valeur de protocol décrit le protocole associé ; elle ne remplace pas la charge utile. Pour fixer le chemin exact dans le code, partez de l’exemple officiel qui correspond à votre intégration et vérifiez les types réellement reçus.
Pourquoi l’ancien code de lecture ne trouve-t-il plus le jeton ?
Un analyseur qui recherche uniquement vp_token à la racine dépend de l’ancienne disposition. Si la réponse reçue utilise la structure où le champ est imbriqué dans data, cette recherche échoue sans que cela prouve l’absence de justificatif. Vérifiez le contenu expurgé, son imbrication et le type de réponse avant d’afficher un refus ou de lancer le parcours de repli.
Quels formats gérer pour une intégration nouvelle ou en migration ?
Une intégration commencée à partir d’août 2026 doit traiter le format récent décrit par la documentation Android. Pour une intégration existante en migration, suivez les consignes officielles de prise en charge des anciennes et nouvelles formes ; ne maintenez pas l’ancien chemin sans limite par simple précaution. Les exemples et avis officiels doivent guider le choix, plutôt qu’une hypothèse sur le calendrier de retrait.
Que doit vérifier le serveur après l’analyse côté client ?
Avant la création du compte ou la connexion, le serveur doit vérifier le justificatif selon les exigences de validation applicables : signature, émetteur, lien avec le détenteur et nonce original. L’application peut avoir réussi à lire une valeur d’adresse e-mail sans avoir établi qu’elle est authentique ni qu’elle est liée à la demande en cours. L’analyse cliente et la validation cryptographique sont deux résultats distincts.
Validation cryptographique côté serveur
Une fois le jeton extrait, le client ne doit pas le traiter comme une preuve suffisante pour ouvrir un compte ou confirmer une adresse. La documentation Android distingue l’analyse préliminaire côté application de la validation par le serveur. Le serveur doit vérifier l’authenticité du justificatif, son émetteur, la liaison au détenteur et le nonce original de la demande. Pour comprendre les objectifs de sécurité côté plateforme, consultez les consignes Android relatives à la confiance et à la sécurité des justificatifs numériques.
Le contrôle du nonce est essentiel à la liaison entre la demande et la réponse : le serveur doit vérifier la valeur liée à la demande originale, et non accepter une réponse uniquement parce qu’elle contient une adresse e-mail. De même, une extraction réussie du champ ne valide ni la signature ni l’identité de l’émetteur. Les détails de validation doivent suivre le profil et les exigences documentés pour l’intégration ; n’inventez pas de vérifications ou de codes d’erreur absents des références officielles.
L’état applicatif doit refléter cette séparation. Un état « réponse analysée » peut être utile pour le diagnostic, mais il ne doit pas être confondu avec « adresse vérifiée ». Seul le résultat positif de la validation serveur doit autoriser l’action protégée. Cette distinction rend les journaux plus utiles : en cas d’échec, l’équipe peut savoir si la rupture a eu lieu pendant la lecture du format, la transmission au serveur ou la vérification cryptographique.
Repli par code envoyé par e-mail
Le parcours de repli ne doit être déclenché qu’avec un état clairement défini : absence de justificatif disponible, réponse inexploitable ou refus de validation serveur. L’application doit expliquer que la vérification par justificatif n’a pas abouti et proposer une autre méthode prise en charge, sans laisser entendre que le code envoyé par e-mail a la même valeur probante que le justificatif numérique.
Pour vérifier le repli, nous séparons les assertions au lieu de déclarer le parcours réussi dès que le message arrive. Il faut contrôler que la demande d’envoi est déclenchée dans la bonne branche, que le message est reçu dans un environnement de test contrôlé, que le code saisi est accepté ou refusé selon le cas et que l’état final du compte correspond au résultat attendu. La réception d’un message prouve l’activité du chemin de messagerie ; elle ne prouve ni l’analyse correcte d’OpenID4VP, ni l’authenticité du justificatif.
Les tests d’interface doivent couvrir aussi les cas négatifs : réponse incomplète, champ mal typé, validation serveur refusée et absence de moyen de repli. Si l’application autorise une création de compte après un échec de validation simplement parce qu’un e-mail a été envoyé, le test a révélé un problème de logique, même lorsque la livraison du message fonctionne.
Pour organiser la collecte de preuves sans conserver inutilement des informations personnelles, les recommandations de protection des données dans les justificatifs vérifiables du modèle W3C donnent un cadre utile. Dans les journaux de test, gardez la structure nécessaire au diagnostic après expurgation et consignez séparément le résultat du serveur ; évitez les copies de jetons complets et les adresses réelles lorsqu’elles ne sont pas indispensables.
Régression isolée et limites des preuves
Les essais doivent porter sur votre propre application ou sur un environnement pour lequel l’équipe dispose d’une autorisation. Pour chaque parcours, consignez la forme de réponse expurgée, la branche du parseur utilisée et le résultat serveur. Cette séparation permet de reproduire une panne sans transformer un échantillon de données personnelles en pièce jointe de bogue.
Notre séquence de régression est la suivante :
- Exécuter une réponse conforme au format récent et vérifier l’extraction depuis
data. - Exécuter, pour une migration, un échantillon de l’ancienne forme si les consignes officielles exigent encore sa prise en charge.
- Envoyer une réponse où un champ attendu manque et vérifier que l’application ne crée pas un succès par défaut.
- Tester un type inattendu ou une structure imbriquée différente, puis confirmer que le diagnostic distingue l’échec d’analyse du refus métier.
- Forcer une validation serveur négative et vérifier que le compte ne passe pas à l’état vérifié.
- Déclencher le repli par code e-mail et vérifier séparément l’envoi, la réception contrôlée, la saisie et l’état final.
Les réponses utilisées dans ces tests doivent être représentatives des exemples officiels, sans extrapoler des codes d’erreur ou des garanties de compatibilité. Si les consignes d’implémentation ou de migration changent, adaptez les tests de contrat avant de modifier le parseur. Une suite qui ne couvre que le cas nominal ne permet pas de savoir si l’application confond un justificatif absent avec une réponse imbriquée.
Pour l’essai du parcours e-mail, une boîte de réception temporaire peut aider à observer le message de repli dans un environnement isolé. Elle ne permet toutefois pas de démontrer la validité d’un justificatif numérique, la réussite du nonce ou la livraison garantie dans toutes les conditions. Les conseils de FwdQuick sur l’hygiène des données de test peuvent compléter cette préparation ; pour examiner les modalités disponibles avant de choisir un dispositif de réception, consultez aussi la page d’accès à FwdQuick.
Le bon critère de réussite est donc composé de preuves séparées : le client a lu la forme attendue, le serveur a validé le justificatif, et le parcours de repli a atteint l’état prévu lorsque la validation n’était pas disponible. Pour tester uniquement la réception d’un code de secours dans un scénario autorisé, FwdQuick peut être envisagé comme une option de collecte de test ; cette vérification reste une preuve de messagerie, jamais une preuve de validité Digital Credentials.
Questions fréquentes
Où se trouve vp_token dans la nouvelle réponse Android ?
Dans le format documenté depuis août 2026, recherchez d’abord les champs protocol et data, puis lisez vp_token dans data. La valeur de protocol indique le protocole associé à la réponse ; elle ne remplace pas le contenu de la charge utile. Pour écrire le chemin exact dans votre code, partez de l’exemple officiel correspondant à votre intégration et vérifiez les types réels reçus.
Pourquoi un ancien analyseur ne trouve-t-il plus le jeton ?
Un analyseur qui ne vérifie que le champ vp_token à la racine dépend de l’ancienne disposition. Si la réponse suit maintenant la structure avec data, cette recherche peut échouer alors que la charge utile est présente à un niveau imbriqué. Confirmez la forme reçue avant de conclure à l’absence de justificatif, puis vérifiez si l’intégration relève d’un nouveau développement ou d’une migration.
Quels formats gérer pour une intégration nouvelle ou en migration ?
Une intégration commencée à partir d’août 2026 doit traiter le nouveau format décrit par la documentation Android. Pour une intégration existante en période de migration, suivez les consignes officielles relatives à la prise en charge des anciennes et nouvelles formes ; ne prolongez pas l’ancien chemin par simple précaution sans tenir compte des indications de retrait. Les exemples et avis officiels restent la référence.
Que doit encore contrôler le serveur après l’analyse côté client ?
Le serveur doit établir que le justificatif est authentique et acceptable avant d’autoriser la création ou l’ouverture d’un compte. Il lui revient notamment de vérifier la signature, l’émetteur, le lien avec le détenteur et la correspondance du nonce original. Lire une adresse e-mail dans l’application ne prouve aucun de ces éléments et ne constitue pas une validation cryptographique.
Choisissez votre itinéraire selon la durée de vie du message
Pour un seul message, créez une adresse temporaire ; pour les commandes, la récupération ou les notifications continues, connectez-vous et créez un alias de transfert.