W3C

– DRAFT –
DPVCG Meeting Call

27 OCT 2021

Attendees

Present
:, beatriz, georg, harsh, julian, lisha, mark
Regrets
-
Chair
harsh
Scribe
harsh

Meeting minutes

Privacy Policy concepts

email with concepts and relation to DPV https://lists.w3.org/Archives/Public/public-dpvcg/2021Oct/0012.html

georg: this is privacy policy/notice, and based on what information should be provided as per GDPR A.13 and A.14

harsh: we need a way to 'package information' in a policy, and then that policy can be used as needed in a notice, or an agreement or documentation

harsh: so first we consider what information needs to go in and if these exist in DPV, then we can revisit specific applications like privacy notices

(shared screen showing concepts in spreadsheet)

georg: Expressing a policy is for a specific scope or context, e.g. for specific data subjects. It would be better if this was expressed by/in the policy itself.

mark: in consent receipts, we've added notice location and info about whether person has read the notice or the sign

harsh: is this a need for associating specific metadata defining scope for policy or a general description that can be done in text?

georg: there is a need to associate with specific concepts, e.g. category of data subject

mark: (discussion on notice and notice location)

mark: DPV should draw from other jurisdictions/laws besides GDPR e.g. Canada has higher requirements for consent than GDPR

harsh: DPVCG welcomes inputs from other jurisdictions, and specifically asks for submitting contributions similar to DPV-GDPR

harsh: next concept - hasPersonalDataHandling to link PDH to a Policy or to another PDH

georg: how to uniquely identify a PDH? Does it have a name or an id?

harsh: in sem-web, the IRI is the unique identity, but in case this is a non-sem-web implementation, then hasName or hasIdentifier could be used

georg: how to explain PDH to humans? where is the description?

harsh: in sem-web, you can annotate a PDH with label + description to summarise and provide overview respectively

harsh: for expressing country, it would be better to express it as Jurisdiction first and then derive Country or other jurisdictional categories from it

harsh: So for properties, there would be hasJurisdiction and hasCountry (as country is necessary in many use-cases)

harsh: the term 'Country' though has a clash with PersonalDataCategory of same name.

harsh: Additionally, the use of 'country' could be country where an entity is based in, headquartered, operates in, etc. So tricky to model this.

For authority, we add property hasAuthority to enable linking authorities to relevant concepts

Next Meeting

We will meet again in +1 week, on NOV-03 at 13:00 WET / 14:00 CET

Note the time changes due to end of daylight saving time

We will continue discussion on these concepts, and AOB

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).