Reddition de comptes du consentement

La reddition de comptes du consentement, c'est pouvoir prouver, après coup, que le consentement a été donné, ce qu'il couvrait, et qu'il a été respecté jusqu'à l'instant même de son retrait. Agreely modélise cela avec une poignée d'objets qui s'emboîtent proprement.

#Les objets

• Catalogue les paires (catégorie, finalité) déclarées par l'organisation. Une déclaration des données que vous détenez et des raisons pour lesquelles vous les détenez, et la source des vues présentées au citoyen.
• Demande de consentement une offre émise à une personne pour un ensemble d'éléments du catalogue. Elle est signée par l'entreprise et livrée sous forme de lien profond sécurisé.
• Reçu le justificatif vérifiable (Verifiable Credential) signé et vérifiable de façon indépendante qui consigne la réponse de la personne, en portant à la fois la signature de l'entreprise et l'assertion par clé d'accès de la personne. Un consentement manuel ou hors ligne produit plutôt un reçu attesté par l'entreprise, qui ne porte que la signature de l'entreprise.
• Enregistrement d'application la ligne de statut unique faisant autorité que lit une vérification, indexée par cellule pour un client donné et portant un consentRef, un statut (active, revoked, expired ou erased) et un palier d'assurance. Elle n'inscrit jamais de DID de citoyen.
• Vérification l'autorisation ou le refus synchrone pour une cellule (customer, category, purpose).

#La grille (catégorie, finalité)

Une entrée de catalogue est une cellule dans une grille : une catégorie de données (quoi) croisée avec une finalité (pourquoi). Phone number x Billing est une cellule différente de Phone number x Marketing. Le consentement est toujours accordé, vérifié, révoqué et effacé à cette granularité de cellule, jamais au niveau du « client » ou des « données » dans leur ensemble.

Chaque entrée de catalogue porte un libellé d'affichage lisible et une clé normalisée. La clé est le libellé rogné, dont les espaces internes sont réduits et qui est mis en minuscules. Le catalogue, l'approbation et la vérification s'indexent tous sur ces chaînes normalisées identiques octet pour octet, et c'est pourquoi chaque surface d'API accepte le libellé brut lisible et le normalise côté serveur. Les clients ne doivent jamais normaliser.

#La vérification : synchrone, lecture unique, refus par défaut

La vérification est le cœur de l'application. Elle résout une cellule (company, customer, category, purpose) en autorisation ou refus en lisant exactement une chose : le statut de l'enregistrement d'application de cette cellule, au moyen d'une seule lecture indexée par cellule.

no record        -> deny  / status "none"     (default-deny)
status "active"  -> allow / status "active"   + consentRef
"revoked"        -> deny  / status "revoked"  + consentRef
"expired"        -> deny  / status "expired"  + consentRef
"erased"         -> deny  / status "erased"   + consentRef

Trois propriétés rendent cela digne de confiance :

1. Un refus est un 200. Une décision, autorisation ou refus, est toujours un résultat réussi. Le refus n'est pas une erreur; seuls l'authentification, la validation, la limite de débit et les pannes sont des erreurs.
2. La chaîne n'est jamais lue. Le statut de l'enregistrement d'application fait autorité à l'instant où un octroi ou une révocation est validé. La vérification ne touche jamais au registre sur la chaîne, à l'indexeur, ni à aucun état d'ancrage. La chaîne est une preuve, pas le chemin de lecture.
3. Refus par défaut. L'absence d'enregistrement refuse par défaut, et un Agreely injoignable refuse par défaut dans tous les SDK. Autoriser exige un enregistrement positif, active.

#Révocation granulaire instantanée

Une révocation fait passer l'enregistrement d'application de ce seul consentRef à revoked au moyen d'une seule écriture indexée. Comme la vérification lit ce même statut, la toute prochaine vérification refuse, sans aucune attente de la chaîne. Il n'y a aucun délai de propagation, aucune mémoire-cache à invalider, et aucune fenêtre de cohérence à terme.

La révocation est indexée par consentRef et limitée à la ligne active, de sorte que révoquer une cellule remplacée (dont le consentRef a été redirigé par un ré-octroi ultérieur) ne correspond à aucune ligne et ne peut jamais refuser un octroi plus récent et valide.

#Vérifiabilité indépendante

Chaque octroi produit un reçu qu'un auditeur peut vérifier sans faire confiance à Agreely : recalculer l'engagement à partir de la déclaration et du sel, vérifier l'inclusion de Merkle par rapport à la racine ancrée, vérifier la signature de l'entreprise par rapport à la clé du DID de l'entreprise, et vérifier l'assertion par clé d'accès de la personne par rapport à la clé COSE qui était valide au moment de l'octroi. La recette de vérification parcourt les quatre contrôles.

#Ensuite

• Le cycle de vie du consentement : l'offre, l'approbation par clé d'accès, le reçu, l'enregistrement d'application, la vérification et les deux paliers d'assurance.
• Non-corrélation : pourquoi le côté entreprise et le côté citoyen ne peuvent pas être joints trivialement pour réidentifier une personne.
• Confidentialité et effacement : l'effacement par destruction de clé et la frontière de destruction honnête.
• Frontières honnêtes : ce qu'Agreely prouve et ce qu'il ne prouve délibérément pas.
• Le protocole pour la cryptographie sous-jacente.