En ma qualité de président de l'équipe responsable de la deuxième étape du processus accéléré d'élaboration de politiques (EPDP) sur la spécification temporaire relative aux données d'enregistrement des gTLD, j'ai le plaisir de vous informer que l'équipe EPDP a fait des progrès fondamentaux dans le développement d'un système normalisé d'accès et de divulgation (SSAD) des données d'enregistrement non publiques, la pièce maîtresse de la deuxième étape de notre travail.
La semaine dernière, nous avons tenu trois journées très productives de travail au siège de l'ICANN, à Los Angeles. Avant cette rencontre, l'équipe EPDP avait discuté d'un large éventail de cas réels d'utilisation, afin de comprendre les besoins et les contraintes à considérer lors d'une demande de données d'enregistrement non publiques. En se basant sur les points communs identifiés entre les différents cas d'utilisation, notre personnel de soutien a élaboré le « Brouillon Zéro [DOCX, 5.45 MB] ». Ce document, qui présentait les éléments de base et les principes directeurs proposés, avait pour but de dynamiser nos discussions sur le développement du SSAD.
Modèle SSAD « hamburger »
Pour expliquer ce modèle de manière simple, l'équipe EPDP s'est servi d'une analogie et a proposé un « modèle hamburger ». Le SSAD « hamburger » est constitué de trois composantes d'importance égale.
- Partie supérieure du « pain hamburger » : composée d'éléments de base en lien avec les demandeurs de données (côté demande), à savoir des individus ou des entités qui sollicitent l'accès à des données d'enregistrement non publiques.
- Partie inférieure du « pain hamburger » : composée d'éléments de base en lien avec les fournisseurs (côté offre), à savoir des registres et des bureaux d'enregistrement qui détiennent des données d'enregistrement gTLD.
- Partie du milieu « steak haché » : une interface qui détermine les modalités d'interaction entre le côté offre et le côté demande, conformément aux politiques établies par l'équipe EPDP. Des délibérations supplémentaires seront nécessaires pour déterminer à quoi ressemblera l'interface et comment les requêtes seront traitées.
Les trois composantes du hamburger SSAD sont constituées d'importants éléments de base, avec plusieurs politiques qui orientent leur mise en œuvre.
- Côté demande : les éléments de base sont nécessaires pour déterminer, entre autres, qui peut demander des données d'enregistrement, de quelle manière ces requêtes sont formulées et si le demandeur est légitime.
- Côté offre : les opérateurs de registres et les bureaux d'enregistrement doivent prendre certaines mesures et répondre aux demandes conformément aux principes établis dans les éléments de base.
- Interface du système : peut comporter plusieurs options. Par exemple, les demandes de données peuvent venir d'un seul portail ou de plusieurs portails, et leur validité peut être confirmée par une simple vérification des données d'identification, par le biais d'une accréditation ou bien par d'autres moyens de vérification.
Bien que l'équipe EPDP ait accepté le modèle hamburger comme le point de départ de ses délibérations, beaucoup de travail reste à faire pour convenir des politiques et des détails opérationnels du SSAD. À la réunion de Los Angeles, notre objectif a été de prendre un certain nombre de décisions fondamentales par rapport au système d'un point de vue architectural.
Réunion de Los Angeles
Le premier jour, nous nous sommes réunis avec le président-directeur général de l'ICANN, Göran Marby, et les représentants de l'organisation ICANN qui sont en contact avec le Comité européen de la protection des données (CEPD). Cette réunion nous a aidés à mieux comprendre quels devraient être les prochains pas de l'équipe pour obtenir des retours du CEPD par rapport aux hypothèses de politiques sur lesquelles se base le modèle d'accès unifié (UAM). Nos discussions ont également porté sur les dossiers les plus pressants, à savoir le partage de responsabilités entre les acteurs impliqués dans le traitement des demandes de données, la possibilité que la responsabilité repose sur des organisations externes, et l'éventuel rôle que pourrait jouer l'ICANN.
Après nos échanges avec Göran et l'équipe de l'organisation ICANN, nous avons fait un point pour savoir où nous en étions et avons réfléchi à la meilleure manière de mettre à profit dans notre travail d'élaboration de politiques les informations que nous avions reçues. En utilisant le « brouillon zéro » comme base de notre travail, nous avons consacré le reste de la réunion à développer plusieurs éléments de base, selon des priorités établies à travers une enquête. Ces éléments sont :
- Authentification, autorisation, accréditation de demandeurs.
- Catégorisation d'utilisateurs.
- Buts visés par la demande de données d'enregistrement non publiques.
- Politique régissant les recherches, y compris l'accès en bloc et la recherche inverse.
Nous avons aussi discuté de l'avis juridique de Bird & Bird LLP, notre conseiller juridique externe. Les avis juridiques fournissent des orientations sur des aspects tels que : les rôles et les responsabilités des parties impliquées dans le SSAD, la mise en place du test d'équilibrage vis-à-vis du RGPD et l'éventuelle automatisation des réponses dans le SSAD, etc.
À la fin de la réunion, nous sommes parvenus à un accord préliminaire sur le fait que le SSAD devrait être automatisé et ses fonctions normalisées autant que possible. Nous sommes aussi convenus d'un certain nombre de mesures à prendre pour faire avancer notre travail, dont notamment le développement d'un éventuel modèle d'accréditation et une réflexion pour déterminer qui prend la décision finale de divulguer les données d'enregistrement non publiques. Nous continuerons à travailler sur chaque élément de base, tout en analysant les contraintes structurelles et architecturales du SSAD afin parvenir à un accord sur la manière dont le système devrait fonctionner.
Les trois journées de réunions en personne se sont avérées un moyen efficace d'utiliser le temps limité dont dispose l'équipe de travail. Nous avons engagé des dialogues constructifs qui nous ont permis d'établir la voie à suivre pour répondre aux inquiétudes de toutes les parties prenantes à travers un processus ascendant et multipartite.
Au nom de l'équipe EPDP, je souhaite remercier Gina Bartlett, de CBI, pour son travail de facilitation qui nous a aidés à rester concentrés et à garder un bon rythme de travail. Un grand merci également au personnel de soutien de l'équipe EPDP, ainsi qu'au personnel de l'organisation ICANN qui a facilité notre travail à Los Angeles.
Prochaines étapes
Il nous reste encore beaucoup à faire. La prochaine étape pour l'équipe EPDP consistera à faire un suivi des mesures à prendre, à rassembler les produits de notre travail et à produire le « Brouillon 1.0 » pour mieux clarifier notre vision du SSAD. Nous devons également établir un plan pour organiser de manière efficace les délibérations de l'équipe lors des séances de l'ICANN66.
À Montréal, l'équipe EPDP organisera quatre séances, dont une journée complète de travail le samedi 2 novembre. Nous invitons les personnes qui souhaitent suivre notre travail à participer à la séance plénière qui aura lieu le lundi 4 novembre, pendant laquelle nous ferons un point sur les progrès accomplis depuis la réunion de Los Angeles et chercherons à obtenir des retours de la communauté de l'ICANN.
En savoir plus
Les transcriptions, enregistrements et documents produits par l'équipe EPDP lors de la réunion de Los Angeles sont publiés dans cette page wiki.
Pour en savoir plus sur l'équipe de l'organisation ICANN qui s'occupe d'interagir avec le CEPD, n'hésitez pas à consulter cette présentation [PDF, 10.5 MB].