Le protocole

Cette section est la pièce maîtresse de la documentation. Agreely est un véritable protocole, et non un format propriétaire : chaque reçu, chaque demande et chaque document DID est bâti à partir de normes publiées (DID et justificatifs vérifiables du W3C, canonicalisation JSON RFC 8785, keccak256 d'Ethereum, preuves de Merkle d'OpenZeppelin, EdDSA et WebAuthn) câblées ensemble de sorte qu'un auditeur muni des artéfacts et de ces règles puisse vérifier un octroi sans faire confiance à Agreely.

Chaque page explique non seulement ce qu'est la construction mais pourquoi cette norme précise a été choisie. Commencez ici par l'identité, puis lisez canonicalisation et hachage, signatures et clés d'accès, le registre sur la chaîne et l'intégrité du document sur IPFS.

#Deux sortes d'identité

Agreely a deux sujets d'identité distincts, et ils utilisent des méthodes DID différentes à dessein. Ne les confondez pas :

• Les entreprises sont did:web:agreely.ca:c:{slug}. Agreely héberge le document DID de l'entreprise, lié au domaine réel et vérifié de l'entreprise.
• Les citoyens sont did:agreely:citizen:{opaque}. Une méthode conçue sur mesure, opaque et ancrée.

La méthode entreprise est traitée sous signatures et clés d'accès et documents DID. Cette page porte sur la méthode citoyen.

#did:agreely:citizen

Le format du DID citoyen est :

did:agreely:citizen:<26-char Crockford base32 of 16 random bytes>

Le suffixe est entièrement opaque. Il n'encode aucune identité réelle, seulement 128 bits d'aléa rendus en base32 Crockford (chiffres et lettres majuscules, à l'exclusion de I, L, O et U afin que la poignée soit sans ambiguïté lue à voix haute). Seize octets aléatoires s'encodent en exactement 26 caractères. Un exemple :

did:agreely:citizen:9F8K2M4P7Q1R3T5V8W0X2Y4Z6B

Le DID est la seule clé sur laquelle est indexée la couche citoyen; il est sans locataire. Chaque clé d'accès, clé de récupération et ligne d'historique de clés se joint par le DID, jamais par une entreprise. C'est la moitié de ce qui donne à Agreely sa non-corrélation : le côté citoyen ne sait rien du customerId d'une entreprise.

did:agreely:citizen garde l'identifiant stable et opaque pendant que les clés sous-jacentes tournent librement. L'identifiant est ancré sur la chaîne comme un engagement sans arête (un événement de création ou de rotation qui ne renvoie à aucun consentement), de sorte que son existence est à l'épreuve de la falsification sans rien exposer.

#L'historique des clés garde valides les anciens reçus

Les clés d'un DID changent au fil du temps, mais un reçu signé l'an dernier doit toujours se vérifier cette année. Le document DID citoyen est assemblé à partir de l'historique complet des clés, et chaque méthode de vérification porte une fenêtre d'autorité [validFrom, validUntil] :

{
  "id": "did:agreely:citizen:9F8K...#passkey-1",
  "controller": "did:agreely:citizen:9F8K...",
  "type": "WebAuthnAuthenticationKey2024",
  "publicKeyCose": "0x...",
  "validFrom": "2026-01-10T14:00:00Z",
  "validUntil": null
}

Une signature faite au temps T se résout vers la clé qui faisait autorité à T, même après que cette clé a été retirée par rotation. validUntil est présent même lorsqu'il vaut null, afin qu'un vérificateur puisse distinguer « encore valide » (null) de « expirée à » (un horodatage). Les clés de récupération sont exposées en tant que Ed25519VerificationKey2020 et sont autorisées uniquement pour la rotation du DID (capabilityInvocation), jamais pour signer un consentement.

Voir la forme complète dans documents DID.