Demandes de consentement
Une demande de consentement est une offre signée, faite à un client, pour un ensemble de cellules du catalogue. Elle est livrée sous forme de lien profond sécurisé (et envoyée par courriel) que la personne concernée ouvre pour examiner l'offre et y consentir par clé d'accès dans le Portail citoyen.
Ce que porte une demande
- Les éléments : les cellules du catalogue visées par l'offre.
- L'identifiant client de l'entreprise (
customer_id) : votre propre identifiant pour ce client, jamais un identifiant décentralisé de citoyen. - Le courriel du destinataire : là où le lien est envoyé.
- La date de validité (
valid-until) : au-delà, l'offre expire. - La langue du destinataire : français ou anglais, pour que l'offre soit présentée dans la langue de la personne concernée.
- Les champs relatifs au mineur (article 4.1) : un indicateur « est un mineur », le consentement parental, et par qui il est donné.
Conditions d'émission
Émettre une demande exige un domaine vérifié et une clé de signature
active. La raison est directe : une offre est signée au nom de
l'entreprise, pour qu'elle soit vérifiable de façon indépendante. Sans
identité did:web frappée par la vérification du domaine et sans clé de
signature active, il n'y a rien pour signer l'offre, et l'émission est bloquée.
La vérification du domaine vient en premier
Si l'émission est bloquée, la cause la plus fréquente est un domaine non vérifié ou l'absence de clé de signature active. Voir Domaine et image de marque pour vérifier le domaine et gérer les clés.
Le cycle de vie
Une demande passe par un ensemble de statuts précis :
- pending (
pending) : émise, en attente de la réponse de la personne concernée. - approved (
approved) : la personne concernée a consenti. - refused (
refused) : la personne concernée a refusé. - expired (
expired) : la date de validité est passée sans réponse. - revoked_before_action (
revoked_before_action) : l'entreprise a annulé l'offre avant que la personne concernée n'ait agi.
Une demande approuvée produit le consentement en vigueur pour les cellules visées; c'est ce statut que lira ensuite une vérification, comme décrit dans les Notions de base.
Émettre par l'API
La même demande peut être émise par l'API /v1 : POST /v1/consent-requests,
sous la portée (scope) issue. L'émission accepte une clé
d'idempotence, de sorte qu'un envoi rejoué ne crée pas une offre en double.
C'est la voie à privilégier pour émettre en lot ou intégrer l'émission dans vos
propres parcours.
Voir la Référence de l'API pour le contrat complet, ainsi que le SDK TypeScript, le SDK PHP et la CLI pour émettre depuis votre code ou votre terminal.
Consentement hors ligne, attesté par l'entreprise
Toutes les personnes concernées ne disposent pas d'une clé d'accès. Pour le cas
sans clé d'accès (par exemple une personne âgée qui signe sur papier), il existe
une voie distincte : le consentement hors ligne, attesté par
l'entreprise. La personne concernée détient un PDF signé à la main, et
l'entreprise consigne ce consentement sous la portée (scope) attest.
Une voie distincte, pas un raccourci
Le consentement attesté ne porte pas d'assertion par clé d'accès de la personne concernée : c'est l'entreprise qui atteste avoir recueilli un consentement papier. C'est une voie légitime pour les cas sans clé d'accès, distincte de l'offre signée que la personne approuve elle-même. Elle exige la portée attest et un justificatif conservé.
Voir le Portail citoyen et le guide du consentement hors ligne pour le parcours complet côté personne concernée.
Ensuite
- Le catalogue : les cellules qu'une demande peut viser.
- Documents de consentement : la divulgation sous laquelle la personne concernée consent.
- Référence de l'API :
POST /v1/consent-requests, idempotence et portées. - Portail citoyen : ce que voit et fait la personne concernée.