Le cycle de vie du consentement

Un consentement dans Agreely traverse cinq étapes, chacune un artéfact distinct. L'entreprise émet une offre, la personne l'approuve au moyen d'une clé d'accès, cette réponse devient un reçu, le reçu met à jour un unique enregistrement d'application, et votre code lit cet enregistrement à chaque usage. Tout l'intérêt est que chaque étape laisse une preuve, de sorte que la check finale n'est pas un simple booléen mais la pointe d'une chaîne vérifiable.

#1. L'offre

L'entreprise émet une demande de consentement signée pour un ensemble de cellules du catalogue, livrée à la personne sous forme de lien profond sécurisé. L'offre est signée par la clé du DID de l'entreprise et s'engage envers une racine de Merkle sur les cellules (catégorie, finalité) exactement demandées, de sorte que la personne approuve précisément ce qui a été offert et que rien ne peut être substitué après coup.

#2. L'approbation par clé d'accès

La personne approuve par cellule dans le portail citoyen au moyen d'une clé d'accès WebAuthn. La clé d'accès signe un défi lié à la racine de Merkle de l'offre, ce qui rattache l'authentificateur d'un humain précis à un ensemble précis de cellules à un instant précis. L'approbation est granulaire : une personne peut approuver certaines cellules d'une offre et en refuser d'autres.

#3. Le ConsentReceipt

L'approbation devient un ConsentReceipt, un justificatif vérifiable (W3C Verifiable Credential) qui porte à la fois la signature de l'entreprise et l'assertion par clé d'accès du citoyen. C'est le registre portable et vérifiable de façon indépendante de ce qui s'est passé. Quiconque le détient peut vérifier le reçu sans faire confiance à Agreely.

Un consentement manuel ou hors ligne, où une personne signe sur papier plutôt que dans le portail, produit plutôt un reçu attesté par l'entreprise. Il ne porte que la signature de l'entreprise : l'entreprise atteste détenir un document signé à la main dont le hachage correspond. Il ne porte aucune assertion par clé d'accès, et il ne prouve pas qu'un humain a signé. Un consentement verbal, donné par téléphone, produit un reçu plus faible encore, documenté par l'entreprise : il nomme la version du script lu et ne porte aucune empreinte de document, parce qu'il n'y en a pas. Voir les paliers d'assurance ci-dessous.

#4. L'enregistrement d'application

Le reçu met à jour un unique enregistrement d'application faisant autorité, indexé par cellule et portant un consent_ref, un status et un assurance_tier. C'est la ligne que lit une vérification. Elle est indexée par le propre customer_id en clair de l'entreprise, et aucun DID de citoyen n'y est jamais inscrit. Cette séparation est ce qui empêche de joindre trivialement le côté entreprise et le côté citoyen; voir la non-corrélation.

#5. La vérification /v1

Votre code appelle la vérification /v1 synchrone, une lecture en refus par défaut de exactement ce statut d'application. Un retrait fait passer l'enregistrement à revoked, et la toute prochaine vérification refuse, sans aucune attente de la chaîne. La chaîne n'est jamais lue sur ce chemin; l'enregistrement d'application fait autorité à l'instant où un octroi ou un retrait est validé.

La réponse porte la fin du consentement, validUntil, et, après un retrait, revokedAt, l'instant à partir duquel Agreely tient le consentement pour retiré. Pour une case laissée vide sur une feuille signée, c'est la date de la signature; pour un retrait consigné par /withdrawal ou /revoke, c'est l'instant de la consignation, pas nécessairement celui où la personne l'a exprimé : cessez l'usage dès la demande de la personne et consignez le retrait sans délai. validUntil est une borne supérieure : un retrait y met fin plus tôt, et seul un système qui vérifie de nouveau l'apprend. Ne mettez donc jamais une vérification en cache.

#Le renouvellement et la chaîne de consentements

Un consentement n'est jamais réécrit. Quand il est renouvelé ou confirmé, un nouveau consentement prend le relais pour la même finalité, et la vérification le suit aussitôt; l'ancien reste consigné tel quel. Trois cas forment une telle chaîne :

• une nouvelle feuille signée sur papier remplace une feuille ou un appel encore en vigueur pour la même finalité;
• la feuille signée qui revient après un appel confirme le consentement verbal : ses finalités cochées passent dans un nouveau consentement attesté par l'entreprise, daté de l'appel;
• un appel peut renouveler une feuille dont la fin tombe dans les 30 jours civils. Ces 30 jours sont une règle de produit d'Agreely, pas un délai prévu par la loi.

Un maillon ne peut pas prendre fin avant celui qu'il remplace : Agreely traite un consentement plus court comme un retrait, qui se consigne comme tel. Un consentement signé par clé d'accès ne se renouvelle jamais par téléphone; il se renouvelle par une nouvelle demande en ligne.

#Le retrait s'attache à la finalité

Un retrait ne vise pas un enregistrement isolé, il vise la finalité. Retirer par n'importe quelle référence de la chaîne (le renouvellement ou la feuille qu'il renouvelle, l'appel ou la feuille qui l'a confirmé) retire au même instant le consentement en cours, et la vérification refuse dès l'appel suivant. Un consentement daté avant un retrait consigné pour la même finalité ne le rouvre jamais.

Le retrait reste toujours possible :

• après la fin de la relation, parce que le droit de retirer survit à la relation;
• pendant un défaut de paiement : la route /v1 de retrait est la seule qui ne répond jamais 402, parce que donner suite à un retrait est une obligation, pas un service payant. Toutes les autres routes refusent tant que la facturation n'est pas régularisée.

Un retrait consigné par l'organisation au nom de la personne est l'attestation de l'organisation, jamais la signature de la personne : sa réponse le dit (recordedOnBehalf: true, assurance: "company_attested").

#Paliers d'assurance

Deux vocabulaires décrivent la manière dont un consentement a été obtenu. Faites-les correspondre, ne les mélangez pas. /v1/check renvoie les deux : tier et assurance.

• full correspond à citizen_signed : le consentement a été approuvé par clé d'accès dans le portail.
• manual correspond à company_attested : il a été signé à la main sur une feuille, consignée par l'entreprise.
• verbal correspond à company_documented : il a été donné par téléphone et documenté par l'entreprise, sans aucun document.

L'ordre de force est full > manual > verbal. Un client qui ne connaît que les deux premières valeurs d'assurance doit traiter une valeur inconnue comme non acceptable.

#Ensuite

• Non-corrélation : pourquoi l'enregistrement d'application et le DID de citoyen sont tenus séparés.
• Frontières honnêtes : ce qu'un reçu attesté par l'entreprise prouve et ne prouve pas.
• Le protocole pour la cryptographie sous-jacente.