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.
La clé d'accès signe la racine, pas la déclaration en clair
Le défi que signe la clé d'accès est lié à la racine de Merkle de l'offre. Cela suffit à prouver que la personne a approuvé exactement ces cellules, et cela signifie que le côté citoyen n'a jamais à détenir l'identifiant de client en clair de l'entreprise pour produire une approbation valide.
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é. 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é.
Paliers d'assurance
Deux vocabulaires décrivent la manière dont un consentement a été obtenu. Faites-les correspondre, ne les mélangez pas.
- L'énumération de stockage est
fulloumanual.fullsignifie que le consentement est passé par l'approbation par clé d'accès dans le portail;manualsignifie qu'il a été recueilli hors ligne et attesté par l'entreprise. - Le libellé public, sur le reçu et dans la réponse de
/v1/check, estcitizen_signedoucompany_attested.fullcorrespond àcitizen_signed;manualcorrespond àcompany_attested.
Les deux paliers s'appliquent de façon identique
Un consentement citizen_signed porte l'assertion par clé d'accès de la personne. Un consentement company_attested est l'attestation par l'entreprise qu'elle détient un document signé à la main dont le hachage correspond, et il ne prouve pas qu'un humain a signé. Au moment de la vérification, les deux s'appliquent exactement de la même façon : seul le libellé du palier diffère, de sorte qu'un lecteur peut juger de la force de la preuve sous-jacente.
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.