The definitions of the OSLO Consent associated classes, attributes and relationships should stem from definitions of existing data models and ontologies (such as GConsent, DPV, and CCCEV) as much as possible.

To give a few examples:

• Consent: As per Article 4(11) of the GDPR, ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; In the case of this ontology, 'Consent' is a concept as well as a tangible entity (something that has a provenance record). To separate this distinction with relation to the data subject, the Consent class represents the consent of the data subject in its entirely, including any history and annotations for it.
  Source: https://openscience.adaptcentre.ie/ontologies/GConsent/docs/ontology#Consent
• LegalBasis: The Legal basis used to justify processing of personal data.
  Source: https://w3c.github.io/dpv/dpv/#LegalBasis
• Criterion: A condition for evaluation or assessment.
  Source: https://semiceu.github.io/CCCEV/releases/2.00/

Whenever a definition needs to be created, input should be sought from the GDPR regulation in the first instance and from other formal sources in the second instance. To give an example:

• DataRetention: the retention of the personal data which should be lawful where it is necessary, for exercising the right of freedom of expression and information, for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, on the grounds of public interest in the area of public health, for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, or for the establishment, exercise or defence of legal claims.
  Source: https://eur-lex.europa.eu/eli/reg/2016/679/oj

Comments, suggestions or questions on this approach are most welcome.

The association Consent.isUpdatedConsentFor is visible on the UML class diagram but is missing in the specification. Plausible reasons: the association has no external uri (= no uri-tag) and there is no alternative package-tag to tell the toolchain which package is going to privide the baseURI necessary to form the associations uri.

Reasons for this:

• DPV is in version 0.8 (sept 2022) and close to version 1.0, as opposed to GConsent which is in version 0.5 since 2018.
• GConsent only covers Consent as a LegalBasis, DPV covers all kinds.
• At the same time Consent is covered in an exhaustive way in DPV, GConsent not really adds something.
• DPV has PersonalDataHandling as the central class, in stead of treating one aspect of it as central (namely the Consent).

De GDPR voorziet ook een zwaardere categorie van toestemming, namelijk de uitdrukkelijke toestemming voor wat betreft de verwerking van bijzondere categorieën van gegevens. Moet dit hier ook een plaats krijgen?

De entiteit LegalBasis is geen ideale benaming. Ik begrijp weliswaar dat het uit een andere standaard komt, maar dat lijkt aan te geven dat het altijd om een ‘wettelijke’ basis moet gaan, terwijl dat niet klopt. De verwerkingsgrond (of rechtsgrond) moet steeds rechtmatig zijn, niet per se wettelijk. Bon het is semantiek, maar daar gaat het hier uiteraard wel om. De ICO (de Britse toezichthouder) gebruikt de term ‘Lawfull basis’, wat dus m.i. een accuratere en betere term is. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/

DPV classes and definitions are used in this data model, but the status of its publication is unclear. Hence, the most recent author has been contacted to check the status of the vocabulary.

The definition for https://purl.eu/doc/applicationprofile/consent/#Consent%3Ais%20provided%20by%20data%20subject

states
Indicates that the consent is given by the data subject.

That expects a boolean as range and not a Data Subject class.

It should be
the data subject that has given the consent

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.

Description
In the current version of the model there is a relation Consent.isProvidedToAgent. As an Agent can be not only a DataController (and also a DataRequester but in issue #9 we argue that this class is unnecessary) but also a DataSubject, it is now possible for a DataSubject to ask Consent for the Processing of PersonalData (of a DataSubject). Altough it is possible of course that someone that has been the DataSubject in a previous request for Consent, the moment an Agent asks himself for Consent he becomes a DataController and is no longer the DataSubject. (One cannot be DataSubject and DataController for the same Consent.)

Solution
Remove the association Consent->Agent.

Wat moet ik begrijpen onder ‘PersonalDataHandling’? Dit lijkt me de verwerkingsactiviteit te zijn? Zo ja, dan lijkt dit mij geen goede term (zelfs al komt dit opnieuw van een andere standaard). De GDPR gebruikt ‘processing activities’. De entiteit processing uit GConsent komt denk ik beter overeen met wat er daar bedoeld moet worden.

The codelists with hierarchies that can be based on the lists and definitions from DPV should be made by creating an entire taxonomy in SKOS concept schemes. In the concept scheme you can then refer to a definition of the term ‘elsewhere’, a corresponding class in DPV.

The name of this property (missing still several definitions) suggests that one cannot create an webpage that is informative enough for a human based on the information in the model.

Because "human readible" is very subjective. E.g. does it has to be in Dutch nicely written text? Or is a picture of the data also acceptable?
Also this raises the discussion whether the intend is to share the legal document (contract) of 50 pages or a condensed representation of that document. (typical issue when dealing with consent).

Secondly if we refer to a Document then usually the goal is not machine processing of that document, but for humans.
So more informative naming could be

• "data_retention_policy_document": the document describing the data retention policy.
• etc. for the others
  That gives meaning to the document that is associated with rather then stressing the "usage objective".

Hi

Some properties seem to have as intention a codelist as range.
This is not properly encoded in the EAP and thus no skos:Concept range is created.

Hi,

This is plain error: https://purl.eu/doc/applicationprofile/consent/#Legal%20Basis
The URI for Legal basis is NOT https://dpvcg.github.io/dpv/#LegalBasis
but the URI found according to

"The canonical URL for DPV is https://w3id.org/dpv# which contains (this) specification. The namespace for DPV terms is https://w3id.org/dpv#, the suggested prefix for is dpv, and this document along with its various serializations are available on GitHub.
"

Description
The PersonalDataHandling class from the DPV ontology is introduced in the model (which mostly is based on the GConsent Ontology). PersonalDataHandling has an attribute legalBasis to point to the LegalBasis on which the handling (being the Processing for some Purpose) is based. LegalBasis has several subclasses and Consent is one of them (others are: Contract, LegalObligation, VitalInterest etc.). So, while DPV::PersonalDataHandling.legalBasis points to an instance of a LegalBasis like a Consent or a Contract, OSLO::PersonalDataHandling points to a LegalResource, eg an article in the GDPR. If this was intentionally, better change the name of the attribute to avoid confusion.
Remark that OSLO::Consent.isGivenFor(PersonalDataHandling) is actually the inverse of DPV::PersonalDataHandling.legalBasis although specialised for Consents only. It would be interesting for future reuse of OSLO::PersonalDataHandling in other contexts than Consent (PersonalDataHandling eg for Contracts, LegalObligations etc.) to stay with the DPV approach.

Solution
Add LegalBasis as a superclass of Consent, repurpose legalBasis as an association with LegalBasis and rename the original attribute.

Voor wat de entiteit ‘Delegation’ betreft zal je rekening moeten houden met de gebruikelijke Belgische regels van vertegenwoordiging (wettelijk, gerechtelijk of conventioneel) lijkt me, om na te gaan of iemand rechtsgeldig voor een andere persoon toestemming kan verlenen.

During the workshop dd. 2021-09-23, the importance of the nature of the relationship between the data subject and the data consumer was mentioned. The willingness to give consent or not can depend on it. To be able to better understand where and how relationships fit into the story, we would like to get some more use cases that highlight and clarify the difference between the relationship and the purpose.

This example was given in the workshop: I want to share my wage with a certain bank because I want a loan, not because I also already have a bank account there. So, it is important that they have access because I want a loan, not because I have a bank account. Note that this also implies that someone can have several relationships with the same organisation.

It was also mentioned that purpose and/or relationship should be very specific. ‘Getting a loan’ is not the same as ‘getting a mortgage loan for my first house’. We need a very clear and unambiguous way to explain the context in which we can use the data subject’s data.

We invite the community to provide additional cases and examples to clarify the importance of specifying the relationship between the data subject and data consumer, in addition to specifying the purpose of the consent.

Dear WG,

The URIs such as https://w3id.org/GConsent#Consent are part of a draft ontology.

This forms a risk in maintenance (both semantic as persistence of the URI).
The WG should consider a strategy when these are not anymore supported.

kr,

Bert

Description
In use case 1 Kate (the Datasubject) gives Consent (let's call it Consent1) to KBC to use her payslips for mortgage evaluation. And she gives another Consent (Consent2) to SDWorx (in the role of the outsourced HR of the company she really works for? or does she work for SDWorx?) to share her payslips for mortgage evaluation. As the GDPR requires a Consent to be specific, we have two Consents here in my opinion: one for using the payslips and one for sharing the payslips.
Moreover, I doubt that this is the typical case. I would think that Kate, in the case of applying for a mortgage loan, would provide KBC with her payslips herself. It would be more interesting to describe a more typical case in stead of an exception.
I also wonder how this use case 1 is handled: it is not SDWorx that asks for Consent2 here, it is KBC that (apart form asking Consent1 for using the data) asks for Consent2 and then somehow transfers it to SDWorx. And what if SDWorx indeed does the HR for the company she works for then SDWorx is only a Processor, and it's her company that should get her Consent2.

Solution
Describe use case 1 with two Consents in stead of one. Or simplify the use case so that only one Consent has to be given (Consent1) as Kate herself hands over her payslips.

Een toestemming moet steeds een actieve handeling inhouden, goed geïnformeerd zijn, vrij gegeven en voldoende specifiek. Daarnaast moet de verwerkingsverantwoordelijke de toestemming steeds kunnen bewijzen en moet de toestemming even eenvoudig kunnen ingetrokken worden als hij verleend is. Ik zie niet al deze aspecten terugkomen in het applicatiemodel. Lijkt het jullie nuttig om deze hier nog in te verwerken?

Most authentication systems are bound to specific individuals (or organisations). Credential consents (e.g., every nurse has consent to access my blood group information) are also important, however. There are two approaches for this:

• The first approach is role-based, e.g. every nurse/doctor/etc.
• A second approach is credential-based, e.g. every legally registered healthcare practitioner.

During the workshop dd. 2021-09-23, the credential-based approach was generally preferred. The Core Criterion and Core Evidence Vocabulary and W3C’s Verifiable Credentials could perhaps serve as modelling suggestions.

Description
In both use case diagrams the Agents asking/getting Consent are (relation isProvidedToAgent) presented as DataRequesters are actually DataControllers. Both KBC and UZ Gent are the ones that "determine processing & purpose" of the data. Only when the Consent is a GivenConsent the processing can start, but at the moment of the request KBC and UZ already have determined that they want to do something with the data, providing they actually get the Consent.
Also it is possible that no data is requested at all, for example that by using their website you agree terms & conditions without any data exchange. So, not everyone asking for Consent can be considered a DataRequester.
Another issue here is that the term DataRequester is not used at all in the GDPR. There are other parties between the Controller and the Processor which are called ThirdParties (of which Recipient is a special case), but that's it. It would not be wise to introduce terms that are not mentioned in the GDPR, one could atmost consider to subclass DataController with DataRequester.

Solution
Not use the term DataRequester but stay with the legal GDPR term DataController.

How do we model contextual requirements that need to be satisfied for the Consent to be valid, e.g. medical staff are only allowed to access my medical records in case of a medical emergency when I’m not able to give explicit consent myself.

Inspiration can be drawn from example 3 in GConsent, where this is considered to be an implicit consent through delegation.

Hi,

The class https://purl.eu/doc/applicationprofile/consent/#Location is mapped on prov-o:Location, why is it not locn:Location as in OSLO-generiek? (SEMIC Core Vocabularies).

Description
OSLO::PersonalData is based on GConsent::PersonalData. In OSLO it is modeled as a regular class, meant to describe the category and type (and even the format) of PersonalData. In GConsent however this class is a metaclass, its a class of classes ie the class of all possible classes of PersonalData. An instance of this class is a class description, eg of the class Accountinfo. It has attributes and associations, everything a real class has.
This phenomenon, that the same data-element can be a class (Accountinfo) and an instance of a class (of the class PersonalData) is called "punning". Advantage in this case is that at the same time you say what type of PersonalData you are dealing with and you describe the actual details of the class (for Accountinfo eg name, contactinfo, registration number... ). Disadvantage is that maybe you do not have such a description (but you will at least always have a definition and some other info if you resolve the uri of the concept).
Worth mentioning is that how OSLO describes PersonalData resembles more the way DPV does it: DPV::PersonalDataHandling has an attribute hasPersonalDataCategory to describe what kind of PersonalData that will be processed.
So both methods could be made available to describe PersonalData by also adding the attribute hasPersonalDataCategory to PersonalDataHandling and at the same time staying with the metaclass approach for PersonalData.

Solution
Make Personaldata a metaclass + add the attribute hasPersonalDataCategory to PersonalDataHandling.

In GConsent as well as in OSLO Consent the codelist ConsentStatus mixes types of Consent (ExpressedConsent, ImpliedConsent etc) with the status of a Consent (ValidForProcessing with GivenConsent, InvalidForProcessing with values Expired, Invalidated etc). this hampers applications that want to filter eg on ExpressedConsents only for subsequent processing. In the DPV ontology both type and status are seperate.

live data is now encoded as a boolean. This property is hard to interpret. Do you mean is live data or is not live data?

Current definition: Stating if the data should be a snapshot (i.e., not live data) or if the consent requires access to the latest version of the data (i.e., live data)

The issue with boolean as range is that the semantics of the true/false may shift over time. Better approach is to turn it into a property having a code list as value.

code: livedata/snaphot = 'the data is a snapshot'
code: livedata/livedata = 'the data is the latest, ignoring any caching in the middle'

Hi,

the class https://purl.eu/doc/applicationprofile/consent/#Information%20Required is dangling. It is not used at all.
Even the class label in CCCEV is "Information Requirement".

So this seems to me an error.

Hi

What is the semantics for https://purl.eu/doc/applicationprofile/consent/#Filter property period of time?
The definition is just the label.

That is not a definition.
Is it the validity period of the filter?
Is it the period of creation of the filter?

Due to the datamodel being closely linked to GDPR, the legal validity of the datamodel is more sensitive than others. Meaning that the wording, definitions and content need to follow the rules defined within GDPR and no room for ambiguity should be left open. All this to avoid the model being inapplicable. Hence, we are wondering if anyone has some input on the legal validity or how this could be double checked in advance.

Secondly, a reflection was made during the workshops whether "Consent" is the right word because it has a different meaning in different countries and regions. This is currently being looked into but any input on the topic is welcome.

Hi,

In https://purl.eu/doc/applicationprofile/consent/#Consent the application profile obliges to provide for a Consent:

• creation time
• is consent for data subject
• is provided by data subject
• is provided by delegation
• is provided to delegation
• is provided to controller
• location
• medium
• notice
• status

I am suprised to see that delegation is mandatory and also notice, and for medium I have no clue what is the value to provide.
If delegation is mandatory, please a usage note with the explanation.

Vraag is of afstemming nodig is met ISO/IEC 27560 Privacy technologies - Consent record information structure.

It is important that all the Agents involved in a Consent are unambiguously identifiable, e.g. the Data Subject/Controller/Provider/Receiver.

Regarding Persons, it was mentioned during the workshop dd. 2021-09-23 that the combination of the national register number and name is not suitable. Identifiers are considered as personal information, so you need to have consent to be able to use them. WebIDs and DIDs were given as alternatives.

For Organisations, a similar identifier is needed. An additional complexity was also mentioned of (1) some organisations not having legal identifiers and (2) the need to identify a sub-organisation, e.g. the marketing department of Google.

We invite the community to further discuss the various identification methods. Note that it is also possible to leave the exact way to identify Agents as out-of-scope for this standard by assuming that an Agent will be identified by some kind of “identifier” that will be dependent on the specific application/implementation.

The editors are in the meanwhile checking the legal validity of the model. It should not be the intention to develop a standard for consents that turn out to not have a legal basis (because certain information is missing and/or is defined too broadly). That’s why we are reaching out to the relevant parties to inform us on the legal requirements and constraints regarding consents. Nevertheless, we invite the community to share their knowledge on this topic.

Question: how does this specification coincides/overlaps/relates with
https://data.vlaanderen.be/doc/applicatieprofiel/contactvoorkeuren/
and related data standards?

In these, a form of consent is described w.r.t. the processing by public organisations.

Hi,

the prefix OSLO in
https://purl.eu/doc/applicationprofile/consent/#Legal%20Basis%3AoSLO%3Ais%20legal%20basis%20for

should not be there.

Datamodel: Consent.

Probleem: Momenteel zijn Datasubject, Datacontroller, ThirdParty niet gemodelleerd als subklassen van Agent. Daardoor kunnen ze niet bijkomend als Persoon of Organisatie getypeerd worden en beschreven worden met attributen van deze klassen zoals naam vd Persoon of van de Organisatie etc.

°°Oplossing**: Kopie van Agent maken in Hulppakket, daarna Datasubject, DataController en ThirdParty subklasse maken van deze klasse.

In het huidige model is het mogelijk om meerdere datasets te koppelen aan één instemming maar het is niet mogelijk deze te bepalen met voorwaarden zoals de periode. Dit is essentiele functionaliteit voor verschillende van onze use cases.
vb: Ik heb de laatste drie loonbrieven nodig of de loonbrieven van de laatste drie maanden of loonbrieven van minsten drie maanden niet ouder dan ...

Een mogelijke oplossing zou kunnen zijn de periode toe te voegen als een attribuut aan de klasse personal data zoals besproken tijdens onze call van 7/1/22.

Hi

in https://purl.eu/doc/applicationprofile/consent/#Expiry the expiry frequency is the sole mandatory property.
That means that in all cases the expiry frequency must be given.

Was this the intend? If so, please add this explicit in the usage note on Expiry class. As I could image every easily a case where only temporal restrictions are used.

Bij de enumeration ConsentStatus: ‘ImplicitlyGiven’ kan nooit een geldige manier zijn om toestemming te geven. Ik denk dat dit ook afkomstig is van een andere standaard, maar een impliciete of stilzwijgende toestemming kan nooit geldig zijn in het kader van de GDPR (in het contractenrecht daarentegen soms wel).

A Consent can be limited in time, e.g. you are allowed to view my monthly income until 2021-12-31. However, more complex expiry conditions can also be imagined, e.g.

• frequency (e.g. 5 times)
• periodically (e.g. once every month)
• event-based (e.g. until I switch jobs)
• etc.

It is an open question how to model these heterogeneous kinds of expiry conditions and whether a suitable expression language already exists.

Het feit dat de entiteiten PersonalData en DataRetentiondata niet gerelateerd zijn aan de verwerkingsactiviteit (dus nu PersonalDataHandling en Processing) lijkt met niet te kloppen. Er zijn namelijk andere voorwaarden die de bewaartermijn kunnen bepalen dan de toestemming, bovendien hangt die retentieperiode echt wel samen met de verwerkingsactiviteit. Ook de ‘PersonalData’ staat daar niet helemaal juist volgens mij. Je geeft toestemming voor een verwerkingsactiviteit. Het doeleinde bepaalt welke persoonsgegevens je daarvoor nodig hebt, dus wat vreemd dat dit enkel aan de entiteit consent hangt.

Bepaalde eigenschappen ontbreken cardinaliteiten.

Description
MinorDataSubject, while also being a subclass of Datasubject, is now defined as a subclass of Person. It should be Datasubject that is defined as a subclass of Person. Which infers that also a MinorDataSubject is a Person.

Solution
Make DataSubject a subclass of Person in stead of MinorDataSubject.

Wijst momenteel naar Delegation, is eerder bedoeld voor associatie van Consent met DataController.

How do we find a balance between keeping the simplicity of a consent, i.e. making sure that the data subject reads and understands to what they they are giving consent, while at the same time, having a consent that is complete, specific and detailed enough to be legally valid and to cover everything that is needed to delineate the consent.

A few suggestions were made:


• separate the metadata and the categorisation of the consent;

• create a concise and an expanded representation of the consent;
• create trees/hierarchies for personal data categories.

The association Consent.isContingentOn is visible on the UML class diagram but is missing in the specification. Plausible reasons: the association has no external uri (= no uri-tag) and there is no alternative package-tag to tell the toolchain which package is going to privide the baseURI necessary to form the associations uri.

Description
In use case 2 Medilab is actually a DataProcessor working under the responsability of the DataController which we believe is UZ Gent (see issue #9). It is UZ Gent that asks for Consent and has determined to proces the Datasubject's medical record for the purpose of medical emergencies. Medilab holds the record for UZ Gent and enables consultation after checking that UZ Gent has the patient's Consent. It does not ask for Consent itself and UZ Gent remains responsible.
DataProcessor is a term defined in the GDPR. The GDPR also provides a class ThirdParty, which is considered anyone else except the DataSubject and the DataController involved in the Processing. If we consider DataProcessor a subclass of ThirdParty, we can describe who processes the data for the DataController.
In use case 1 KBC is apart from being a DataController for Consent1, a ThirdParty for Consent2 (see #8 where we state that there are actually two Consents) as the Processing is of the type DataSharing.

Solution
Add ThirdParty. Add DataProcessor as a subclass of ThirdParty. Add an attribute involvedThirdParty to the class Processing. Change the objectdiagram of use case 2 accordingly.

Als ik het goed lees wordt DataProcessor als specialisatie van ThirdParty beschouwd? Dat is vreemd, een verwerker is net géén derde bij de verwerking. Derden zijn alle andere partijen dan verwerkingsverantwoordelijke, verwerker of betrokkene.