Résumé

  • Le projet REGEXT sur les contacts vérifiés peut décrire les attributs contrôlés, la date, le vérificateur, la méthode, la preuve et le cadre de confiance, mais la plupart de ces éléments sont facultatifs et ne valent pas autorisation générale de divulgation.
  • Chaque opérateur devrait conserver un reçu de diffusion liant le résultat de vérification au public, au motif d’accès, aux champs remis et à une durée de validité. Ce reçu est une proposition éditoriale de Daniel Kade, pas une exigence de l’IETF.

La même vérification, trois décisions différentes

Un bureau d’enregistrement envoie un lien à l’adresse électronique fournie lors de la création d’un nom de domaine. Le destinataire clique, et l’opération est consignée. Pour l’équipe chargée des abus, ce geste peut indiquer qu’une boîte était joignable au moment du contrôle. Pour un internaute anonyme, le détail du procédé n’est pas nécessairement communicable. Pour une autorité authentifiée disposant d’un motif recevable, une information plus précise peut être pertinente.

Le fait initial ne change pas. Ce qui change, c’est le destinataire, la finalité et le fondement de la communication. Confondre ces dimensions revient à transformer un résultat technique circonscrit en certificat social permanent.

Cette confusion est d’autant plus probable qu’un format normalisé facilite la circulation des données. Un objet JSON bien structuré peut être recopié dans un portail, un dossier d’enquête, une plateforme de notation ou un entrepôt de données. À chaque reprise, les détails risquent de disparaître : d’abord le champ contrôlé, puis la méthode, puis la date. Il ne reste bientôt plus qu’une coche verte à côté d’une personne ou d’une organisation. La coche paraît simple ; elle est surtout devenue équivoque.

La portée réelle de la révision 04

La révision 04 de Registration Data Access Protocol (RDAP) Extension for Verified Contact Information date du 24 août 2026. Le Datatracker la présente comme un Internet-Draft actif dans le contexte du groupe REGEXT, au stade « Candidate for WG Adoption », avec l’état IESG « I-D Exists ». Elle n’a donc ni l’approbation formelle de l’IETF ni le statut d’une norme publiée. La mention « Standards Track » figurant dans l’en-tête indique une intention, pas une décision acquise.

Le texte propose d’ajouter aux objets d’entité RDAP un tableau verifiedContacts_data. Chaque élément peut indiquer les attributs vérifiés — courrier électronique, numéro de téléphone, adresse, nom ou date de naissance — ainsi que la date de vérification, le vérificateur, un identifiant d’opération, le cadre de confiance, la méthode, la catégorie de preuve, des remarques et des extensions. Plusieurs opérations peuvent cohabiter : une adresse postale et un courriel n’ont pas forcément été examinés ensemble ni selon le même régime.

Ce pluriel est une qualité essentielle. Il empêche, au niveau du modèle, qu’une opération limitée à un attribut soit nécessairement confondue avec l’ensemble du dossier. Mais il ne garantit pas que les interfaces conserveront cette nuance. C’est à l’opérateur et aux consommateurs de ne pas résumer le tableau par un unique booléen.

Presque tous les champs descriptifs sont facultatifs. Il faut donc lire ce qui est présent sans inventer ce qui manque. Une entrée déclarant seulement que le courriel a fait l’objet d’un contrôle de joignabilité ne prouve ni l’identité civile, ni la qualité de représentant, ni la propriété effective du domaine. Un cadre private renvoie à la politique de l’opérateur ; sans le texte et la version de cette politique, un tiers ne connaît pas réellement le niveau d’assurance.

La révision 04 précise aussi un point décisif : verificationDate correspond au moment où le procédé s’est achevé, et l’absence de cette date ne signifie pas que la vérification est actuelle. Même lorsqu’elle existe, la date n’est pas une échéance. La durée pendant laquelle un courriel, une adresse ou un nom peut être considéré comme suffisamment récent dépend de l’usage, des changements ultérieurs et de la politique locale.

Vérifier quoi, par quel moyen ?

Le projet distingue le procédé de la preuve. Une vérification de joignabilité suppose une action du destinataire, par exemple la saisie d’un code ou l’activation d’un lien. D’autres méthodes portent sur des propriétés documentaires, des registres, des moyens cryptographiques, une authentification, un jeton, une question de connaissance, une comparaison physique ou biométrique. Une même preuve peut être examinée de plusieurs façons ; une même méthode peut servir à plusieurs catégories de preuve.

La conclusion légitime dépend donc de la combinaison. Un clic reçu montre quelque chose sur l’accès à un canal à cet instant. Il ne démontre pas automatiquement qui, derrière ce canal, détient un droit juridique. Une pièce d’identité rapprochée d’un nom répond à une autre question, mais ne prouve pas nécessairement un mandat actuel au nom d’une société. La validation d’une adresse dans une base confirme encore autre chose.

Le terme « vérifié » n’est pas faux ; il est incomplet sans complément d’objet. La bonne phrase n’est jamais seulement « ce contact est vérifié », mais « tel attribut a été contrôlé de telle manière, sous tel cadre, à tel moment ». Une décision de confiance doit rester à la même échelle que la preuve.

La confidentialité commence avant le document brut

Ne pas publier la copie d’un passeport ou d’un relevé bancaire est une évidence. Il est moins évident que la simple catégorie de preuve peut elle-même être sensible. Savoir qu’une personne a produit un titre de séjour, qu’un registre de population a été consulté ou qu’une comparaison biométrique a eu lieu décrit une partie de son parcours d’identification.

Le projet énumère des catégories aussi diverses qu’une carte d’identité, un passeport, un justificatif de domicile, un document fiscal, un acte de naissance, une attestation écrite ou numérique et les journaux d’une validation électronique ou postale. Cette précision aide un destinataire autorisé à apprécier le procédé. Elle peut aussi fournir trop d’informations à un public qui n’en a pas besoin.

La section consacrée à la sécurité reconnaît explicitement les implications possibles pour la vie privée et impose au serveur de respecter les lois et politiques applicables lors de la divulgation. L’introduction envisage parallèlement un service RDAP public ou un service fermé réservé à des demandeurs légitimes ou à des autorités préalablement autorisés.

Ces deux passages interdisent une lecture paresseuse. Le format peut fonctionner dans plusieurs régimes d’accès ; il ne choisit pas à la place de l’exploitant ce que chaque public doit recevoir. Citer l’article 28 de NIS2 pour la collecte et le maintien de données d’enregistrement exactes et complètes ne transforme pas davantage la directive en ordre général de publier les métadonnées de contrôle. Collecter, maintenir, vérifier, donner accès et rendre public sont cinq décisions différentes.

Pourquoi la coche verte est un mauvais contrat

Une coche unique dissimule au moins cinq inconnues : l’objet exact, l’attribut contrôlé, la méthode et la preuve, l’âge du résultat, et le public auquel l’information était destinée. Elle peut rester affichée après un changement d’adresse, une reprise de boîte électronique, une révision de politique ou une correction du dossier.

Le problème se propage par copie. Un premier système conserve le détail ; un second ne garde que l’état ; un troisième transforme cet état en score. Lorsque l’erreur apparaît, le producteur initial peut corriger son service sans pouvoir rappeler toutes les représentations dérivées. Une donnée vraie à l’origine devient une réputation trompeuse parce que ses limites ne l’ont pas accompagnée.

Il faut donc rejeter deux raccourcis. Le premier consiste à traiter l’absence de métadonnées publiques comme l’absence de vérification. Le second consiste à traiter leur présence comme un droit de confiance illimité. La confidentialité et la qualité sont des axes distincts.

Le reçu de diffusion et de validité

La réponse opérationnelle est un reçu produit au moment où des données de vérification conservées deviennent une réponse RDAP. Il ne s’agit pas d’ajouter un nouveau champ au projet de protocole, mais de garder, chez l’opérateur, la trace de la décision de diffusion.

Le reçu associe l’objet RDAP et la liste exacte des attributs à l’identifiant de vérification, au vérificateur et à la date disponible. Il consigne la méthode, la catégorie de preuve et le cadre de confiance, avec la version précise de la politique qui donne un sens à ce cadre. Pour un cadre privé, cette version est particulièrement importante.

Il décrit ensuite le côté destinataire : public anonyme, utilisateur authentifié, équipe interne ou autorité ; identité du demandeur lorsque cela est requis ; finalité déclarée ; canal public ou restreint ; champs effectivement remis et champs masqués. La base juridique, contractuelle ou politique de l’accès doit être retrouvable, tout comme le responsable de la décision et la voie de réexamen.

Enfin, il fixe l’horizon de validité retenu par l’opérateur. Cet horizon ne modifie pas la sémantique de verificationDate. Il précise quand un nouveau contrôle est exigé, quels événements déclenchent un réexamen, comment une date absente est traitée et comment une opération corrigée, révoquée ou remplacée cesse d’être présentée comme actuelle.

Le reçu ne contient pas la pièce d’identité, les données biométriques ni un secret du vérificateur. Il conserve la logique de diffusion, pas la matière sensible elle-même.

Une adoption minimale et réversible

L’approche de Heng Lu — spécification initiale minimale, décisions futures localisées et adoption volontaire — offre ici un bon garde-fou. Des noms communs pour les attributs, méthodes et preuves améliorent l’interopérabilité. Ils n’obligent pas à imposer immédiatement une politique mondiale uniforme de divulgation.

Un opérateur peut commencer avec un seul attribut, un public authentifié, un cadre documenté et une durée de réexamen courte. Il peut utiliser le mécanisme de rédaction de RDAP pour expliquer qu’une donnée a été retenue sans révéler la nature de la preuve. Il peut mesurer les contestations, la fréquence des données périmées et les mauvais usages avant d’élargir l’accès.

La syntaxe partagée rend les expériences comparables. Le reçu local conserve la responsabilité. Ainsi, l’hétérogénéité initiale ne devient ni chaos opaque ni prétexte à centraliser prématurément toutes les décisions.

Sources