[e2esdk]: évaluer le SDK

[revolunet]

Mettre en oeuvre le SDK pour évaluer :

• coût d'implémentation/complexité dans une app
• aspects UX (login, restore...)
• backups/risques
• performances (fichiers)

idéalement on travaille sur un use-case réel ou réutilisable

On pourrait par ex tester sur une branche dédiée de EDS ?

[matmut7]

Tout à fait !

Est-ce qu'avant on essaie de se faire la main sur un projet plus simple comme template ou les formulaires E2EE ?

[revolunet]

on se prend une journée pour tenter d'ajouter le use-case des formulaires sur template ?

• des users anonymes peuvent poster des données/fichiers (formulaire)
• des users authentifiés peuvent afficher ces données et se les partager

[revolunet]

Prérequis :

• serveur de test e2esdk
• local running template@hasura dev environment

Etapes possibles :

• Ajouter un formulaire dans le front + devtool
• Créer une table pour recevoir les résultats côté db (hasura)
• Ajouter e2esdk dans le submit du form + submit hasura
• Vérifier que ça record bien en db
• Logguer/registre e2esdk auto au login des admins
• Afficher la liste des résultats déchiffrée
• Ajouter un exemple avec upload fichiers

Reflexion à mener sur l'intégration avec des auths tierces et l'UX

[revolunet]

Next steps :

• decrypt and zod parse the encrypted data (ex)
• add example file encrypt/upload/download/decrypt
• add sharing example

[matmut7]

Déchiffrement implémenté ✔
SocialGouv/template#154

Points de retour jusqu'ici :

• manque documentation de l'API : on doit s'inspirer de code déjà fait pour savoir quelles méthodes du client utiliser
• possiblement, en plus de la doc d'API, une doc d'usages typiques (formulaires, messages simples, fichiers, etc.)
• confusion entre nameFingerprint et payloadFingerprint et leur utilité respective cf PR
• comment share avec un utilisateur qui n'existe pas encore côté applicatif et/ou e2e (ex: un email)
• comment avoir un seul formulaire statique dans mon appli (par exemple de contact) au lieu de créer dynamiquement les buckets dans mon applicatif ?
  • cette fonction nous force à fournir la clé publique dans le hash de l'URL sans laisser la possibilité de la fournir autrement
• DevTools : nécessité de créer un composant dans l'applicatif au lieu de simplement l'importer du SDK ?
• possiblement, certains usages pourraient-ils être encore plus abstraits par le SDK ?
• quid possibilité de restore ses données locales (login+clés) via un MDP en plus de pouvoir rajouter des devices

[revolunet]

• Reste à faire

  • Demo template
    • PR pour découpler le url hash de la public key du form
    • ajouter exemple de file encrypt/upload/download/decrypt (WIP)
    • envoi invitation de partage : il faut pouvoir lister les users applicatifs et s'assurer qu'ils ont un compte e2esdk
    • tests revoke un user avec qui on a partagé / rotate de clé
    • test re-édition de formulaire
    • backup de clé
  • Documentation:
    • usage guide pours les devs PR
    • améliorer la TSDoc
  • voir si besoin d'ajouter des APIs plus haut niveau
    • ex: wrapper initializeEncryptedFormLocalState + encryptFormData
    • PR pour ajouter le component DevTools : issue

• Notes :

  • en cas de rotation de clé, comment gérer le resharing des clés (ex: exclusion d'un utilisateur)
  • prévoir enrollement des users qui doivent recevoir la donnée
  • Bob invite Alice qui n'existe pas encore :
    • inviter Alice côté applicatif
    • sign up Alice côté app puis côté e2esdk (webhook pour assurer le creation de l'identité)
    • notifier a Bob l'identité e2esdk de Alice pour qu'il puisse lui partager les clés (et lui affecter des permissions)
    • seules les réponses envoyées après cette dernier étape seront déchiffrables
  • quel mécanisme pour backup de clé côté utilisateur ?
  • quid suppression d'un utilisateur applicatif qui a share des clés ?
  • UX: quid changement de device sur une meme application