*Réunion de Co-construction normalisation Normalisation d'un protocole d'échange de données en topologie fédérée Projet QUOALISE

*2020-09-24 14h - 16h *Participants

  • Cyril - Projet SEN
  • Gautier - Projet SEN
  • Elias Martin - Projet SEN
  • François Bodin - RUDI
  • Luc Granier - HESPUL
  • Fabien Coutant - Enedis
  • Lydie Le Floch - Grdf

*Proposition d’ordre du jour - Logique de travail *- Réalisations techniques SEN1

Sélection d'un protocole : XMPP Mise en place de proxy sur la base de logiciels libres Objectifs du POC atteints, quelles sont les pistes d'avancée possible ?

*- Etat des lieux de la fédération - phases SEN2/SEN3

Ajout d'un canal de contrôle-commande, mis en test sur l'API Data Connect d'Enedis via un nouveau proxy Canal utilisé par l'application Viriya (prestation de services sur l'Autoconsommation Collective d'énergie solaire).

Proxy hébergé chez ALOEN (Agence Energie-Climat de Bretagne Sud, à Lorient), qui s'est déclarée utilisatrice de DataConnect. Application sous licence libre, pouvant être ré-instanciée par d'autres.

Travail en cours pour répondre à de nouveaux sujets : code en ligne sur https://github.com/consometers/data-connect-proxy

Candidature au “Energy Data Challenge” : https://energiedatachallenge.fr/ où seront mis en production ces outils.

*Questions :

  • Quel est la situation sur les consentements ? Comment gérer le consentement pour chaque usage/destinataire ?
      ◦ Pas traité pour le moment dans la fédération
      ◦ Les applications (clients XMPP) gèrent le consentement de manière monolithique, en chaînant entre leur utilisateur et la source "finale" des données.
      ◦ Authentification au niveau de l'application / green button Enedis pour le cas de DataConnect
      ◦ NB : Le consentement pour la transmission est collecté par Enedis pour la transmission, mais pas pour l'usage des données.
      ◦ Des défis restent : non-répudiabilité, consentement entre applications.
  • Question ouverte côté RUDI : est-il un tiers de confiance ? Avec une authentification par France connect pour les usagers...
      ◦ approche retenue : pas de consentement "micro" sur chaque usage, en se logguant sur chaque système
      ◦ passer par un identifiant unique : France Connect est retenu malgré limitations (étrangers, entreprises...)
      ◦ Réunions en cours pour passer à l'utilisation, sur des technologies OpenID "classiques".
      ◦ Evolution possible (à moyen terme) de FC vers un usage "pro" autorisé.
  • NB : pour DECLICS, on a fait les démarches auprès de FranceConnect et la réponse a été non. (à voir à quelle époque ?)
  • Interrogation partagées par PRIDE (L. Lebreton) qui pourrait être le sujet d'une réunion dédiée...
  • Avancées par rapport à une identité fédérée, non centralisée, orienté block chain
      ◦ https://identity.foundation/

*- Vos usages d'échange de données

RUDI : https://rudi.datarennes.fr/yeswiki/?PagePrincipale

  • fédération autour d'un portail
  • être dans la fédé = fournir une API normalisée (accès normalisé aux données d'une appli externe au portail)
  • normalisation de l'API en cours de travail, sur les métadonnées à partager
  • Logique retenue : normaliser les données chez les producteurs de données
  • possibilité de faire des recherches sur un catalogue de données
  • API REST (avec plusieurs domaines), tokens JWT : accès système, recherche, accès aux données
  • objectif = pas forcément l'échange mais plutôt la recherche normalisée sur les jeux de données (thésorus)
  • partie flux de données : voir dans quel mesure le format de données NRJ peut être utilisé par RUDI, et rien n’empêche d'avoir un proxy avec la fédération "XMPP" sur un noeud producteur
  • un noeud producteur défini comme "stockage + streaming de données" (transformé en stockage au fil du temps)
  • une fois connecté sur un noeud producteur, on est dans la fédération RUDI
  • éléments/rubriques des métadonnées : identifiants de jeux de données, identifiants formels, autorisations d'accès aux jeux de données, (conditions financières, SLA), couverture temporelle, géographique, mots clefs, statut consentement, méthodes d'anonymisation, => travail en cours pour formaliser les jeux de données
  • géographie : quasiment tout est spatialisé car centré sur la métropole
  • consentement : collaboration plus poussée à voir, y compris avec l'analyse récente du RGPD
  • 2 parties pour les metadonnées : le format, les schémas de données appuyés sur des normes
  • RUDI utilise le LoRA de la métropole up/down pour faire aussi du contrôle/commande (ex : données qualité de l'air depuis les bus)

HESPUL :

  • pas de partage de données, collecte pour animation
  • se positionne plutôt en tant que consommateur de données
  • intéressant : se connecter à la fédé pour éviter de se connecter à différents producteurs de données selon différentes méthodes d'accès et formalismes
  • france connect : se posent les mêmes questions pour l'authentification, mais avec des fonctions/données non-utiles (identité exacte), dont on ne peut pas justifier l'accès.
  • NOTA Post Réunion : https://franceconnect.gouv.fr/partenaires

Grdf :

  • membre de RUDI, au titre de "Centre-Ouest"
  • Sujet du consentement très principal
      ◦ Volet avec citoyen évident
      ◦ Volet entre partenaires voire à d'autres entreprises (urbanisme, ALECs) -> anonymiser pour éviter le consentement
  • Question de l'anonymisation à traiter pour pouvoir partager des données - entre producteurs/users RUDI.
      ◦ Atlas de la donnée à Rennes ? Assez "sur-mesure. Expérimentation autours des règles d'anonymisation, en créant des "ilôts", indépendants des mailles existantes (IRIS ou autre) respectant les 10pts de la règlementation.
  • GRDF ADICT (API) fonctionne depuis cet été (parcours tiers direct - recueille du consentement par le tiers) et depuis cette le consentement des titulaires est recueilli par GRDF pour le transfert des données à travers le Parcours Client Connect. 
  • Des échanges ont également eu lieu avec France connect (suivi par l'équipe nationale voit pour plus d'info)
  • D'autres expérimentations ont lieu sur d'autres régions (Lyon, La Rochelle...), mais encore beaucoup d'attente/expectations du national sur les opérations bretonnes.

*- Suite du groupe de travail 1 session sur le sujet suivant : identification/authentification centralisée VS consentement Remise en cause du XMPP ? A priori pas du point de vue de RUDI, car on n'est pas sur les mêmes fonctions. 1 session sur le sujet “métadonnées” et ses formalisations, appuyées sur des standards OK pour une réunion mensuelle par sujet, dates à fixer (sondage 27-30) + fixe le 22