Intégrité du document sur IPFS

Un reçu prouve qu'une personne a consenti. Cette page porte sur l'autre moitié de la question : à quoi elle a consenti. Le document de consentement, c'est la divulgation de l'article 8 (les fins, les moyens, la conservation, les destinataires, le responsable, et le reste), et il est le même pour tout le monde : il ne dépend d'aucun citoyen. À la publication d'une version immuable, Agreely épingle ce document sur IPFS via Lighthouse et en obtient un CID, puis ancre ce CID sur la chaîne.

Un CID prouve le document, pas le consentement

Le CID est une copie publique et vérifiable de la divulgation, rien de plus. Il ne prouve pas qu'un citoyen a consenti (cette preuve vit uniquement dans le reçu signé, et n'est jamais sur IPFS) et il ne contient aucun renseignement personnel. IPFS porte le document; le reçu porte le consentement. Ne confondez jamais les deux.

La charge utile épinglée

Ce qui est épinglé est délibérément public et sans arête. C'est exactement la divulgation que l'entreprise doit montrer à quiconque, et rien d'autre :

{
  "code": "acme-billing-v3",
  "name": "Facturation et recouvrement",
  "version": "3",
  "effectiveDate": "2026-06-01",
  "disclosure": {
    "fins": "...",
    "moyensCollecte": "...",
    "categories": ["..."],
    "conservation": "...",
    "retraitConsentement": "...",
    "destinataires": ["..."],
    "communicationHorsQuebec": "...",
    "droits": "...",
    "responsable": { "...": "..." },
    "decisionAutomatisee": "..."
  },
  "responsable": { "...": "..." },
  "automatedDecision": "..."
}

La charge utile ne porte jamais un DID, un customerId, un sel, un engagement ni un reçu. Elle est sans citoyen par construction : il n'y a rien à corréler et rien à effacer, parce qu'il n'y a aucune personne à l'intérieur.

L'épinglage est facultatif à l'exécution : sans clé Lighthouse configurée, il est simplement désactivé, et un échec d'épinglage ne fait jamais échouer une publication. La publication du document ne dépend donc pas de la disponibilité d'IPFS.

Comment le CID se lie au consentement

Le CID entre dans le flux de consentement par un descripteur de document, signé par l'entreprise, ajouté sans casser la compatibilité sous offer.document dans l'offre signée :

{
  "offer": {
    "document": {
      "code": "acme-billing-v3",
      "name": "Consentement facturation v3",
      "version": "3",
      "effectiveDate": "2026-01-01",
      "ipfsCid": "bafybeib..."
    },
    "disclosureHash": "0x…sha256…"
  }
}

Parce que le descripteur fait partie de l'offre, il est couvert par le companySig de l'entreprise (voir signatures et clés d'accès). À l'approbation, il est recopié dans le reçu sous consent.document, de sorte que le reçu détenu pointe vers la version exacte de la divulgation qui était en vigueur.

L'ancrage de document sur la chaîne

keccak256( utf8(cid) ) est ancré sur Base comme un ancrage de document à émission seule et sans arête : un bytes32 opaque, sans aucun renseignement personnel et sans lien vers un quelconque consentRef. Voir le registre sur la chaîne pour la forme exacte de l'événement.

Vérification

Deux contrôles facultatifs s'ajoutent à la recette de vérification du reçu. Ils n'altèrent aucun des quatre contrôles de base; ils renforcent la question du à quoi :

  • La copie de la divulgation (disclosureCopy) : le SDK ou la CLI récupère la copie IPFS au CID du reçu, calcule 0x + sha256( JCS(disclosure) ), et le compare au disclosureHash du reçu. Une égalité prouve que la copie publique est bit pour bit la divulgation que l'entreprise a signée.
  • L'ancrage de document sur la chaîne (documentAnchor) : le SDK ou la CLI recalcule keccak256( utf8(cid) ) et vérifie sa présence sur la chaîne. Cela prouve que le document existait sur la chaîne, pas qu'un consentement a été donné.

Les deux sont mis en œuvre par la vérification d'un reçu en TypeScript.

Rien de la cryptographie de consentement figée ne change

L'intégrité du document est une couche additive. Le défi WebAuthn, la racine de Merkle par cellule, le reçu signé et le disclosureHash (toujours 0x + SHA-256 de la divulgation canonicalisée) sont inchangés. Si IPFS ou la chaîne sont hors ligne, les quatre contrôles de base d'un reçu se vérifient toujours; vous perdez seulement la confirmation renforcée du à quoi.

Ensuite