Ce qu'est Agreely

Agreely est un protocole de reddition de comptes du consentement. Voyez-le comme un permis de conduire pour l'accès aux données : avant que votre code utilise un renseignement personnel à une fin donnée, il vérifie si la personne a bel et bien autorisé cet usage, et la réponse est un oui ou un non unique et faisant autorité. Dès que la personne révoque, le permis est déchiré et la toute prochaine vérification répond non.

Sous l'API à un seul appel se trouve un petit ensemble délibéré de primitives cryptographiques. Chaque octroi produit un reçu signé que quiconque peut vérifier hors ligne, le registre de ce qui s'est passé est ancré sur la chaîne pour qu'on ne puisse le réécrire en douce, et l'effacement est une destruction de clé plutôt qu'une promesse. Résultat : un consentement que vous pouvez prouver, et non un consentement que vous avez seulement journalisé.

Le problème de la Loi 25

La Loi 25 du Québec a fait de la reddition de comptes du consentement une obligation légale. Il ne suffit plus de recueillir une case cochée; une organisation doit pouvoir démontrer, après coup, que le consentement a été donné, exactement ce qu'il couvrait, qu'il a été respecté tant qu'il était actif, et qu'il a cessé de l'être à l'instant même de son retrait. La plupart des équipes savent recueillir le consentement. Très peu savent le prouver d'une manière qui résiste à un régulateur ou à un auditeur.

L'écart est structurel. Le consentement vit généralement sous forme de booléen dans une base de données applicative : facile à écrire, facile à écraser, impossible à prouver intact après coup, et déconnecté des chemins de code qui touchent réellement aux données. Agreely comble cet écart avec des reçus vérifiables, un ancrage sur la chaîne et une vérification synchrone que votre code appelle directement.

Le modèle mental de l'appel unique

Il y a une seule question à laquelle Agreely répond, de façon synchrone, à chaque usage de données :

Ce client a-t-il accordé cette catégorie de données pour cette finalité, maintenant?

import { Agreely } from "@agreely/sdk";

const agreely = new Agreely({ apiKey: process.env.AGREELY_API_KEY! });

if (await agreely.check("cust_8812", "Phone number", "Billing")) {
  // ...you may use the phone number for billing
}

check() renvoie un booléen. allow est le seul true. Une cellule révoquée, expirée, effacée ou jamais accordée vaut false. La vérification lit un seul enregistrement d'application indexé, ce qui la rend rapide, et elle fonctionne en refus par défaut : si Agreely est injoignable, la réponse par défaut est le refus.

Deux côtés, un seul protocole

Agreely fonctionne comme deux applications sur un seul protocole, plus une API de serveur à serveur.

  • L'application entreprise (agreely.ca) est le tableau de bord où une organisation déclare son catalogue, émet des demandes de consentement, surveille l'application et consulte les pistes de vérification. Voir le guide entreprise.
  • Le portail citoyen (my.agreely.ca) est l'endroit où une personne approuve, révise et retire son consentement au moyen d'une clé d'accès. Il n'a aucun locataire et ne voit jamais les identifiants de client d'une entreprise. Voir le portail citoyen.
  • L'API /v1 est la surface synchrone de serveur à serveur qu'appelle votre code, avec des SDK TypeScript et PHP et un CLI pensé pour les agents.

Les deux applications sont des processus distincts qui ne partagent jamais d'identifiant de client. Ce qui relie l'approbation d'un citoyen à l'enregistrement d'application d'une entreprise est une seule référence opaque, par cellule, et c'est pourquoi les deux côtés ne peuvent pas être joints trivialement. Voir la non-corrélation.

Ce qu'Agreely n'est PAS

Agreely ne détient jamais les données de vos clients

Agreely n'est ni un coffre-fort de données, ni une CDP, ni une base de données client. Il ne stocke jamais le numéro de téléphone, le courriel, ni l'enregistrement lui-même. Il stocke la preuve du consentement pour une cellule (client, catégorie, finalité) ainsi que les artéfacts cryptographiques qui permettent à quiconque de vérifier cette preuve. Vos données restent dans vos systèmes; Agreely prouve ce à quoi la personne a consenti.

Ce n'est pas non plus :

  • Une mémoire-cache à lire une fois et à croire sur parole. Chaque check() est un appel frais et faisant autorité. Mettre en cache un allow pendant qu'une révocation arrive est une faute d'exactitude.
  • Une plateforme de gestion du consentement (CMP) ni une bannière de témoins. Celles-ci recueillent un signal; Agreely rend ce signal prouvable, révocable et applicable au point d'usage.
  • Un produit de chaîne de blocs. La chaîne est la couche d'inviolabilité, jamais le chemin de lecture. La vérification synchrone n'y touche jamais.

Un démarrage rapide en 60 secondes

Le chemin le plus court de zéro à une barrière fonctionnelle est le démarrage rapide : installez un SDK, définissez une seule variable d'environnement, et encapsulez un usage de données dans un seul check().

Où aller ensuite

  • Démarrage rapide protège une fonctionnalité en moins d'une minute.
  • Notions de base est le modèle mental : catalogues, la grille (catégorie, finalité), la vérification, la révocation et l'effacement.
  • Guide entreprise est la visite guidée du tableau de bord pour l'opérateur, du catalogue aux demandes de consentement jusqu'à la vérification.
  • Portail citoyen montre comment une personne approuve et retire son consentement au moyen d'une clé d'accès.
  • Le protocole est la pièce maîtresse : did:agreely, canonicalisation, engagements keccak256, la construction de Merkle, les suites de signature et le registre sur la chaîne.
  • Référence de l'API et la spécification /v1 interactive.