Confidentialité et effacement

Agreely est bâti pour que prouver le consentement n'exige pas de détenir les données, et pour qu'effacer le consentement détruise la déclaration lisible plutôt que de le promettre. Cette page couvre deux droits distincts qu'il est facile de confondre, ainsi que la destruction de clé qui soutient l'effacement de la propre copie d'Agreely.

#Le retrait n'est pas l'effacement

Deux droits différents se cachent derrière « cessez d'utiliser mes renseignements », et Agreely les tient séparés à dessein.

• Le retrait (P-39.1, art. 8 al. 1 (4°); A-2.1, art. 65 al. 1 (5°)) met fin à un consentement actif. Il fait passer l'enregistrement d'application à revoked, et la toute prochaine vérification refuse. Le retrait conserve délibérément un registre : le consentRef, le reçu et l'engagement ancré subsistent tous, car pouvoir prouver qu'un consentement a existé puis a été retiré, c'est ce qui permet à l'organisation de rendre compte de ses consentements (P-39.1, art. 3.1 al. 1; A-2.1, art. 52.2).
• L'effacement (P-39.1, art. 23; A-2.1, art. 73) est une demande de destruction. Ce n'est pas un changement de statut : il détruit par la clé la propre copie lisible qu'Agreely détenait pour la cellule et produit une demande que l'entreprise doit honorer dans ses propres systèmes. Agreely ne peut pas atteindre votre base de données, de sorte que l'effacement est la part d'Agreely plus votre obligation, et non un seul interrupteur.

Lorsqu'un renseignement repose sur une base déclarée autre que le consentement, l'effacement retire le consentement, qui ne peut plus être invoqué, mais l'entreprise conserve le renseignement sur cette autre base : la demande d'effacement est alors inscrite comme reportée, et le renseignement devra être détruit ou anonymisé lorsque les fins seront accomplies, sous réserve des délais prévus par la loi. La personne en est avisée avant de confirmer.

#L'effacement par destruction de clé

Agreely met en œuvre l'effacement de sa propre copie par cellule, comme une destruction de clé. Chaque cellule de consentement est liée par un engagement :

commitment = keccak256( JCS(claim) || salt32 )

Le salt de 32 octets est le seul secret de la cellule et la seule chose qui rend l'engagement réversible vers la déclaration. Effacer une cellule détruit ce sel (et les lignes de déclaration lisibles qui l'entourent), tout en conservant le commitment afin que les cellules survivantes du même consentement continuent de se vérifier par rapport à la racine de Merkle. La vérification synchrone refuse par défaut à l'instant où la transaction d'effacement est validée.

#La frontière honnête

Il est tentant d'affirmer que l'effacement est instantané et total partout. Il ne l'est pas, et Agreely énonce la frontière clairement plutôt que de surpromettre.

Concrètement, à l'instant où la transaction d'effacement est validée :

• le sel a disparu de la ligne en service, de sorte que le commitment conservé est un hachage à sens unique qui n'est pas réversible vers la déclaration;
• la ligne de déclaration lisible (le texte en clair de catégorie/finalité) est supprimée;
• la vérification synchrone refuse par défaut et le tableau de bord ne liste plus la cellule.

Ce qui subsiste encore, jusqu'à ce que la fenêtre de conservation s'écoule, est un résidu illisible qui ne porte aucune déclaration de catégorie ou de finalité : l'engagement sur la chaîne est un orphelin dont le sel est détruit, et le lien qui demeure relie un DID à un consent_ref aléatoire opaque. Les sauvegardes de la base de données conservent encore l'état antérieur : Agreely garde les sauvegardes complètes des 30 dernières nuits, avec le journal d'écriture anticipée qui les accompagne, et la destruction physique complète s'achève lorsque la dernière sauvegarde antérieure à l'effacement est écartée.

#Pourquoi le résidu ne porte aucune identité

L'effacement conserve un lien consent_ref-vers-DID comme frère de Merkle, sans que ce résidu porte de déclaration lisible : le consent_ref est une valeur aléatoire fraîche et opaque, et l'enregistrement d'application qui le reliait à la référence de client de l'entreprise est supprimé au moment de l'effacement. C'est ce qui permet à Agreely de conserver la preuve cryptographique d'un consentement tout en détruisant sa forme lisible. La frontière précise de ce que la séparation des deux côtés protège, et de ce qu'elle ne protège pas, se trouve sur la page Non-corrélation.

#Vérifiabilité indépendante

Les artéfacts que détient une personne ou un auditeur, soit le reçu, les documents DID et l'ancrage sur la chaîne, suffisent à vérifier la signature d'un octroi sans interroger la base de données d'Agreely. Le lien entre la clé et le domaine réel de l'entreprise, et l'état du consentement, se confirment en ligne (registre DID, DNS et lecture de la chaîne). Une limite demeure : la clé de signature de l'entreprise est hébergée par Agreely (voir frontières honnêtes, point 7). Voir la recette de vérification.

#Ensuite

• Non-corrélation : le modèle complet de non-corrélation entreprise/citoyen.
• Frontières honnêtes : pourquoi « détruit partout et en tout temps » est une affirmation qu'Agreely refuse de faire.