Een ConsentReceipt is het ontvangsbewijs dat de DataController aan het DataSubject zou moeten geven van zijn Consent met een PersonalDataHandling. Nu geven we Consent voor een bepaalde verwerking van onze PersonalData, maar kunnen we die maar moeilijk herroepen of betwisten (vergelijk het met een kasticket: als je je aankoop niet kan bewijzen krijg je geen garantie op het gekochte product). In DPV wordt wel degelijk gewag gemaakt hiervan, in §5.4.5 van de DPV Primer wordt een voorbeeld van een dergelijk receipt opgevoerd, vertegenwoordigd in de DPV spec door de klasse ConsentRecord. Het voorbeeld is gebaseerd op ISO 27560, op zijn beurt gebaseerd op de zgn Kantara specificatie (zie issue #49 voor meer info). Doel van deze specificaties is het invoeren van een verplichting op dergelijke receipts te ondersteunen met een gestandaardiseerd formaat. Fundamentele vraag mbt OSLO-Consent is of we verder gaan met de klasse Consent of met ConsentRecord. Consent wordt door DPV neergezet als de LegalBasis van een dataverwerking (PersonalDataHanbdling), in DPV ligt de nadruk vooral op de verwerking en minder op de Consent (hoewel inverse relaties bestaan, bvb deze van PersonalDataHandling.hasLegalBasis is LegalBasis.hasPersonalDataHandling). Als het gaat over het werkelijk vastleggen van een Consent bvb om als receipt te dienen is ConsentRecord mogelijk meer aangewezen. OPMERKING: deze wordt in DPV neergezet als een specialisatie van TechnicalAndOrganisationalMeasure (via een ganse reeks subklassen). De verschillende types daarvan worden in OSLO-Consent momenteel gemodelleerd dmv een codelijst. Maw: als we met ConsenRecord verder zouden gaan dan heeft dit grote consequenties voor het huidig model.
Een ConsentReceipt is het ontvangsbewijs dat de DataController aan het DataSubject zou moeten geven van zijn Consent met een PersonalDataHandling. Nu geven we Consent voor een bepaalde verwerking van onze PersonalData, maar kunnen we die maar moeilijk herroepen of betwisten (vergelijk het met een kasticket: als je je aankoop niet kan bewijzen krijg je geen garantie op het gekochte product). In DPV wordt wel degelijk gewag gemaakt hiervan, in §5.4.5 van de DPV Primer wordt een voorbeeld van een dergelijk receipt opgevoerd, vertegenwoordigd in de DPV spec door de klasse ConsentRecord. Het voorbeeld is gebaseerd op ISO 27560, op zijn beurt gebaseerd op de zgn Kantara specificatie (zie issue #49 voor meer info). Doel van deze specificaties is het invoeren van een verplichting op dergelijke receipts te ondersteunen met een gestandaardiseerd formaat. Fundamentele vraag mbt OSLO-Consent is of we verder gaan met de klasse Consent of met ConsentRecord. Consent wordt door DPV neergezet als de LegalBasis van een dataverwerking (PersonalDataHanbdling), in DPV ligt de nadruk vooral op de verwerking en minder op de Consent (hoewel inverse relaties bestaan, bvb deze van PersonalDataHandling.hasLegalBasis is LegalBasis.hasPersonalDataHandling). Als het gaat over het werkelijk vastleggen van een Consent bvb om als receipt te dienen is ConsentRecord mogelijk meer aangewezen. OPMERKING: deze wordt in DPV neergezet als een specialisatie van TechnicalAndOrganisationalMeasure (via een ganse reeks subklassen). De verschillende types daarvan worden in OSLO-Consent momenteel gemodelleerd dmv een codelijst. Maw: als we met ConsenRecord verder zouden gaan dan heeft dit grote consequenties voor het huidig model.