Re: DPV Semantics

The Fashion ID case provides a definition of joint-controllers:

   - ECJ:
   http://curia.europa.eu/juris/document/document.jsf;jsessionid=50031DE4E5702AF005AAC0D620E29FC2?text=&docid=216555&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=7511916
   - Advocate General:
   http://curia.europa.eu/juris/document/document.jsf;jsessionid=50031DE4E5702AF005AAC0D620E29FC2?text=&docid=209357&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=7511916

A lack of an ‘arrangement’ does not qualify joint controllers as not joint
controllers.


The ECJ gives a definition of joint controller.


The Advocate General (point 87) says that, when joint controllership is
established, the "GDPR appears to be introducing a new regime of joint
liability in its Article 26", and also says that (point 88) "On the one
hand, Article 26(1) of the GDPR makes it possible for joint controllers to
‘determine their respective responsibilities for compliance with the
obligations’. On the other hand, however, Article 26(3) of the GDPR makes
it clear that the ‘data subject may exercise his or her rights’ ‘in respect
of and against each of the controllers’ *irrespective of any such
arrangement*. Any of the joint controllers can thus be held liable for the
data processing in question."


Georg

On Tue, Jun 30, 2020 at 4:38 PM Joss Langford <joss@coelition.org> wrote:

> I agree that you need to be a bit careful with classifications around
> joint controllers.
>
>
>
> When joint controllers take on the role of the controller together:
>
>    - Either both have all the responsibilities/capabilities of the
>    controller and their ‘arrangement’ just specifies who leads in any area
>    (sometimes called controllers-in-common); or
>    - The neither controller has all the responsibilities/capabilities
>    alone and the ‘arrangement’ specifies exclusive
>    responsibilities/capabilities.
>
>
>
> The latter case arises in pseudonymised-at-source implementations.
>
>
>
> A test for “joint-controllers or each controller is a separate controller”
> under GDPR could the existence of an ‘arrangement’.
>
>
>
> Joss
>
>
>
>
>
>
>
>
>
> This message is private and confidential. If you have received this
> message in error, please notify us and remove it from your system.
>
> Coelition is a non-for-profit company limited by guarantee registered in
> England & Wales (8402657) 12th Floor 6 New Street Square, London, England,
> EC4A 3BF
>
>
>
> *From:* Georg Philip Krog <georg@signatu.com>
> *Sent:* 30 June 2020 14:35
> *To:* Harshvardhan J. Pandit <me@harshp.com>
> *Cc:* Data Privacy Vocabularies and Controls Community Group <
> public-dpvcg@w3.org>
> *Subject:* Re: DPV Semantics
>
>
>
> Thanks Harsh,
>
>
>
> Here are some comments to your numbered points:
>
>
>
> 1)
>
> Should the Data Controller address be convertible into geographic
> coordinates?
>
> https://www.bing.com/api/maps/sdkrelease/mapcontrol/isdk/searchbyaddress
>
> https://developers.google.com/maps/documentation/geocoding/intro
>
>
>
> 2)
>
> If two controllers participate in one and the same data processing action,
> the two controllers are either joint-controllers or each controller is a
> separate controller. Hence, Controller has the sub-class Separate
> Controller or Joint Controller?
>
>
>
> 5)
>
>
>
> An example:
>
> On Linkedin, (1) a controller collects my personal data, (2) which I on
> Linkedin made publicly available and which originate from me.
>
> The controller can name the source where s/he collected the data
> (Linkedin), but cannot with certainty state that it was I who made the data
> publicly available and that the data originated from me (i.e. I wrote the
> text and made the photo of myself).
>
> When the controller does not collect the data directly from the data
> subject, the GDPR Article 14.2(f) wants specified (1).
>
>
>
> 11)
>
> I do not think it is necessary to provide a list of third countries since
> an adopter would need to state recipient name and recipient country and
> then provide a transfer legal basis. If the transfer happens within the EU,
> then the controller needs legal basis within GDPR Art 6 or 9.
>
> Best regards,
>
> Georg
>
>
>
>
>
> On Tue, Jun 30, 2020 at 11:17 AM Harshvardhan J. Pandit <me@harshp.com>
> wrote:
>
> Hello. Thank you Georg for providing the data.
>
> This email concerns ACTION-140 Share missing concepts in dpv for privacy
> policy generation
> https://www.w3.org/community/dpvcg/track/actions/140
>
> 1) Identity (Data Subject Identity, Data Controller Identity, etc.)
> - In the semantic web (AFAIK) uses the IRI as the identity of the entity
> - In legal terms, however, identity refers to something else e.g.
> company name, number, address, etc. as the fields reflect
> - The question for DPVCG, then, is - how do we represent or suggest
> these be represented?
> - There are external vocabularies (e.g. FOAF) that define some of the
> semantics required here (e.g. name, address) that we should suggest for
> use. And if there is some specific legal requirement that is not
> captured/provided by existing (well-defined) work then we should provide
> that through DPV
> - Pros: flexibility and freedom to define attributes as required e.g.
> address as string or granular street name, post-code, etc.
> - Cons: adopters might want a single vocabulary i.e. DPV should provide
> all required concepts
>
> 2) Joint Controller
> - Should this be a sub-class of Controller given that a Joint Controller
> acts as a Controller? (IMHO - yes)
>
> 3) Data Processor
> - This is defined in dpv - https://www.w3.org/ns/dpv#dpv:DataProcessor
>
> 4) Personal data
> - This is defined in dpv -
> https://www.w3.org/ns/dpv#dpv:PersonalDataCategory
>
> 5) Source of personal data
> - IMO it is unclear whether this is an attribute associated with data
> collection i.e. where was data collected from OR origin i.e. where did
> this data originate from
> - We also (probably) need to define what/who the data was collected from
> - How to specify this?
>
> We already have a property 'location' within Technical measures that
> concerns storage restriction - to an uinformed mind this property would
> appear to also be suitable for use with source of personal data. But I
> do not think this is appropriate (see below)
> IMHO the source of personal data *is* associated with its collection and
> therefore should be defined as an attribute of processing.
>
> Doing something like this -
>
> x a dpv:Collect ;
>    dpv:location "phone" .
>
> has inherent problems:
> a) it is not clear whether the location specifies location of processing
> or data
> b) it does not specify who/what the data was collected from - of course
> one could add another fact using e.g. prov:Agent
>
> Therefore, I would propose having properties for (a) source (b)
> agent/entity.
>
> That being said, there can be multiple sources of data e.g. smartphone,
> web-browser, smartwatch. How they should be represented depends on the
> interpretation whether they are separate instances of processing for
> each device or a single instance of processing with multiple sources. Do
> we support both these interpretations? (IMHO we should)
>
> 6) Agents missing in DPV
> - Joint Data Controller
> - DPO
> - Controller representative
> - Processor representative (representative should be an abstract category?)
> - DPA (data protection authority)
>
> 7) GDPR specific items
> - There are some (very) GDPR specific items in the list e.g. legal basis
> and obligations for contract
> - If these are to be defined, they have to be done within dpv-gdpr
>
> 8) Puporse
> - this is defined in dpv - https://www.w3.org/ns/dpv#purpose
>
> 9) Processing categories
> - this is defined in dpv - https://www.w3.org/ns/dpv#processing
>
> 10) Automated decision making
> - this is defined in dpv -
> https://www.w3.org/ns/dpv#dpv:isAutomatedDecisionMaking
> - Logic of automated decision making: DPV does not provide a way to
> describe this currently
> - Describing the logic means we should provide a way to describe logic
> of processing in general (same concepts)
> - Describing consequences would also be similar to the above
> - How to do this?
>
> 11) Data Transfer
> - dpv currently has transfer as a processing category
> https://www.w3.org/ns/dpv#transfer
> - To specify location of transfer, again - we have a location property
> which should be used - which means changing its definition
> - And we already have storage as a restriction
> https://www.w3.org/ns/dpv#storage
> - The larger question here is what the location specifies - location of
> where the data will end up or location of recipient (this affects how
> the property is defined and used). To me, data transfer location would
> indicate where the data ends up being located in. This should be
> clarified in the definition.
> - For location identification, adopters should be able to use their
> preferred method e.g. ISO country codes, plain strings
> - Do we provide a list of "third countries" under GDPR? (IMHO this is
> complicated - not my cup of tea!)
>
> 12) Technical organisational measures
> - This is defined in dpv -
> https://www.w3.org/ns/dpv#dpv:TechnicalOrganisationalMeasure
>
> 13) Data Storage period
> - This is defined in dpv - https://www.w3.org/ns/dpv#storage-duration
> - criteria to determined storage period is currently not defined, so how
> to associate this with storage duration?
> - I see some common semantics in providing explanation of processing,
> effects of processing, criteria to determine storage period - can we
> leverage this to provide a generic attribute that can be tacked on
> anything to provide more information and/or explanations? dpv already
> has a "measure implemented by" property which is not directly applicable
> but related https://www.w3.org/ns/dpv#measure-implemented-by
>
> 14) Time limit for data erasure
> - Is this defined in DPV? And is this separate from data storage
> duration? To my understanding, does data storage indicate time duration
> the data will be stored for, whereas time duration for data erasure when
> the data will be erased *after* the storage period???
> - We define duration of data storage (see above)
>
> 15) Recipients
> - this is defined in dpv - https://www.w3.org/ns/dpv#recipient
>
> 16) Legitimate interest
> - this is GDPR specific as a legal basis
> - we currently do not provide any means to specify the specifics of
> legitimate interest e.g. description. To my understanding, a
> semantic-web property should be used to indicate this, but which?
> rdfs:comment? Should DPV provide a generic property for annotating with
> additional information within the context of DPV (as opposed to RDFS
> being super-generic)?
> - we currently do not provide a way to indicate the legitimate interest
> is associated with controller or third party -> how to do this?
>
> 17) Legal Basis
> - this is defined in dpv - https://www.w3.org/ns/dpv#legal-basis
> - GDPR specific legal basis are defined in dpv-gdpr
>
> 18) Rights
> - We do not have the concept of rights in DPV - this needs to be added
> - Where to define them? PersonalDataHandling? To my understanding,
> rights are obligations that are based on context e.g. if data is
> collected from data subject then the data subject has the right to
> obtain this data (right to data portability) - which means the right is
> only valid in the context where a) processing is 'collect' b) source of
> data is data subject.
> - For now, we should atleast provide the concept of Legal Right, and the
> GDPR specific rights can (should?) be added to dpv-gdpr
>
> @Georg (FYI) the email loses formatting in plain-text on the mailing
> list https://lists.w3.org/Archives/Public/public-dpvcg/2020May/0014.html
> We can put these tables in the wiki for better persistence.
>
> Regards,
> Harsh
>
> On 29/05/2020 13:51, Georg Philip Krog wrote:
> > Hi everyone,
> >
> > I and Signatu contribute with new field values for the DPV taken from
> > the GDPR across Art 13 (Privacy Policy), 14 (Privacy Policy), 15
> > (access right information) and 30 (Records of processing activities).
> >
> > Please have a look:
> >
> > Value categories      DPV     GDPR Art 13     GDPR Art 14     GDPR Art
> 15     GDPR Art
> > 30.1  GDPR Art 30.2
> > Data Subject  FALSE
> >
> >
> >       A description of the categories of data subjects and of the
> > categories of personal data, GDPR Article 30.1(c).
> > Data Controller Identity      FALSE   Data Controller Identity, GDPR Art
> > 13.1(a)       Data Controller Identity, GDPR Art 14.1(a)
> >       The name of the Data Controller, GDPR Article 30.1(a)   Data
> > Controller Identity, GDPR Art 30.2(a)
> > Data Controller Contact Details       FALSE   Data Controller Contact
> > Details, GDPR Art 13.1(a)     Data Controller Major task for the day:
> > - [ ] [[id:34a7168f-0c0b-458e-8241-8983b94b0972][Send email to
> > Cristiana with ideas]]
> > - [ ] DPVCG - [[id:a7af1cc8-e004-4409-9570-8b37b351cb17][Future
> > Deliverables and Timeline]]
> >
> > Minor tasks for the day:
> > - [ ] DPVCG - [[id:00839c20-4191-4870-9d32-d63498e1a8f7][Review
> > Signatu's privacy-policy concepts]]
> > - [ ] DPVCG - [[id:a1ec628d-dc21-4cb7-9af1-c56bbb59dc4f][Review
> > Signatu's concepts for Art13/14 and ISO29184]]
> > - [ ] DPVCG - [[id:3cf2308e-d3ed-4308-80b2-f772de407cb2][Review
> > Signatu's personal data categories concepts]]
> > - [ ] DPVCG - [[id:2cc99f78-81db-4df3-95eb-03d15379f23b][Review
> > Signatu's purpose concepts]]
> > - [ ] DPVCG - [[id:5e7a8427-f15e-4130-8bce-b65332ece50c][Review
> > SPECIAL's presentation shared by Axel]]
> >
> > If I'm bored, I should do:
> > - [ ] [[id:bc663445-8737-4ba8-a0c2-76b27a74121c][re-organise folders
> > for PhD -> general research]]
> > - [ ] [[id:c79106af-a2d8-4b25-8032-1cbabffc2291][Plan upcoming
> > potential publications]]
> > Contact Details, GDPR Art 14.1(a)
> >       Data Controller Contact Details, GDPR Article 30.1(a)   Data
> > Controller Contact Details, GDPR Art 30.2(a)
> > Data Controller Representative        FALSE   Data Controller
> Representative,
> > GDPR Art 13.1(a)      Data Controller Representative, GDPR Art 14.1(a)
>
> >
> >       Data Controller Representative, GDPR Art 30.2(a)
> > Data Protection Officer       FALSE   Data Protection Officer of Data
> > Controller, GDPR Art 13.1(b)  Data Protection Officer of Data
> > Controller, GDPR Art 14.1(b)
> >       Data Protection Officer of Data Controller, GDPR Article 30.1(a)
> > Data Protection Officer, GDPR Art 30.2(a)
> > Data Protection Office Contact Details        FALSE   Data Protection
> Officer
> > Contact Details, GDPR Art 13.1(b)     Data Protection Officer Contact
> > Details, GDPR Art 14.1(b)
> >       Data Protection Officer Contact Details, GDPR Article 30.1(a)
> > Joint Controller      FALSE
> >
> >
> >       The joint controller, where applicable, GDPR Article 30.1(a)
> > Data Processor        FALSE
> >
> >
> >
> >       The Data Processor, GDPR Art 30.2(a)
> > Data Processor Representative         FALSE
> >
> >
> >
> >       The Data Processor Representative, GDPR Art 30.2(a)
> > Personal Data         FALSE   The personal data, GDPR Art 13.1(c)
>  The
> > categories of personal data, GDPR Art 14.1(d)         The categories of
> > personal data,GDPR Art 15.1(b)
> >
> > Personal Data Source  FALSE
> >       From which source the personal data originate, GDPR Art 14.2(f).
> > Where the personal data are not collected from the data subject, any
> > available information as to their source, GDPR Art 15.1(g).
> >
> > Personal Data Public or Private Source        FALSE
> >       Whether the personal data originate from publicly accessible
> sources,
> > GDPR Art 14.2(f).
> >
> >
> > Personal Data Provision Legal Basis   FALSE   Whether the provision of
> > personal data is a statutory or contractual requirement, or a
> > requirement necessary to enter into a contract, GDPR Art 13.2(e).
> >
> >
> >
> > Personal Data Provision obligation    FALSE   Whether the data subject
> is
> > obliged to provide the personal data, GDPR Art 13.2(e).
> >
> >
> >
> > Consequence of data provision failure to provide personal data
> FALSE
> > The possible consequences of failure to provide personal data, GDPR
> > Art 13.2(e).
> >
> >
> >
> > Purposes      FALSE   Purposes of the Processing, GDPR Art 13.1(c)
> Data
> > Controller Identity, GDPR Art 14.1(c)         The purposes of the
> processing,
> > GDPR Art 15.1(a)      The purposes of the processing, GDPR Article
> 30.1(b)
> > Processing Categories Classes         FALSE   GDPR Art 4.2
> >
> >
> >       The categories of processing carried out on behalf of each
> > controller, GDPR Art 30.2(b)
> > Processing Categories Classes         FALSE
> >
> >
> >
> >
> > Automated decision-making and profiling       FALSE   The existence of
> > automated decision-making, including profiling, referred to in Article
> > 22(1) and (4), GDPR Art 13.2(f).      The existence of automated
> > decision-making, including profiling, referred to in Article 22(1) and
> > (4), GDPR Art 14.2(g).        The existence of automated
> decision-making,
> > including profiling, referred to in Article 22(1) and (4), GDPR Art
> > 15.1(h).
> >
> > Logic of automated decision-making and profiling      FALSE   Meaningful
> > information about the logic involved in automated decision-making,
> > including profiling, referred to in Article 22(1) and (4), GDPR Art
> > 13.2(f).      Meaningful information about the logic involved in
> automated
> > decision-making, including profiling, referred to in Article 22(1) and
> > (4), GDPR Art 14.2(g).        Meaningful information about the logic
> > involved in automated decision-making, including profiling, referred
> > to in Article 22(1) and (4), GDPR Art 15.1(h).
> >
> > Consequences of automated decision-making and profiling       FALSE
>  The
> > significance and the envisaged consequences of automated
> > decision-making, including profiling, referred to in Article 22(1) and
> > (4) for the data subject, GDPR Art 13.2(f).   The significance and the
> > envisaged consequences of automated decision-making, including
> > profiling, referred to in Article 22(1) and (4) for the data subject,
> > GDPR Art 14.2(g).
> >
> >
> > Data transfer to third country        FALSE   Transfer of personal data
> to a
> > third country or to an international organisation, GDPR Art 13.1(f)
> > Transfer of personal data to a third country or to an international
> > organisation, GDPR Art 14.1(f).       Transfer of personal data to a
> third
> > country or to an international organisation, GDPR Art 15.2.   Transfers
> > of personal data to a third country or an international organisation,
> > GDPR Article 30.1(e).         Transfers of personal data to a third
> country
> > or an international organisation, GDPR Art 30.2(c)
> > Third country name    FALSE
> >
> >
> >       Identification of the third country or international organisation,
> > GDPR Article 30.1(e).         Identification of the third country or
> > international organisation, GDPR Art 30.2(c)
> > Data transfer legal basis     FALSE   Legal Basis for transfer to a
> third
> > country, GDPR Art 13.1(f)     Legal Basis for transfer to a third
> > country, GDPR Art 14.1(f).
> >       Legal Basis for transfer to a third country, GDPR Article 30.1(e)..
> > Legal Basis for transfer to a third country, GDPR Art 30.2(c)
> > Technical and Organisational Measures         FALSE
> >
> >
> >       Where possible, a general description of the technical and
> > organisational security measures referred to in Article 32(1), GDPR
> > Art 30.1(g).  Where possible, a general description of the technical
> > and organisational security measures referred to in Article 32(1),
> > GDPR Art 30.2.
> > Data storage period   FALSE   The period for which the personal data
> > will be stored, GDPR Art 13.2(a).     The period for which the personal
> > data will be stored, GDPR Art 14.2(a).        The envisaged period for
> which
> > the personal data will be stored, GDPR Art 15.1(d).
> >
> > Criteria to determine data storage period     FALSE   The criteria used
> to
> > determine the period for which the personal data will be stored, GDPR
> > Art 13.2(a).  The criteria used to determine the period for which the
> > personal data will be stored, GDPR Art 14.2(a).       The criteria used
> to
> > determine period for which the personal data will be stored, GDPR Art
> > 15.1(d).
> >
> > Time limit for data erasure   FALSE
> >
> >
> >       Where possible, the envisaged time limits for erasure of the
> > different categories of data, GDPR Art 30.1(f).
> > Recipients    FALSE   Recipients of categories of recipients of the
> > personal data (if any), GDPR Art 13.1(e)      The recipients or
> categories
> > of recipients of the personal data, if any, GDPR Art 14.1(e).
>  The
> > recipients or categories of recipient to whom the personal data have
> > been or will be disclosed, in particular recipients in third countries
> > or international organisations, GDPR Art 15.1(c)      The categories of
> > recipients to whom the personal data have been or will be disclosed
> > including recipients in third countries or international
> > organisations, GDPR Article 30.1(d).
> > Legitimate interest of Data Controller        FALSE   Legitimate
> Interest (if
> > the processing is based on GDPR Art 6.1(f)), GDPR Art 13.1(d)
> > Legitimate Interest (if the processing is based on GDPR Art 6.1(f)),
> > GDPR Art 14.2(b)
> >
> >
> > Legitimate interest of Third Party    FALSE   Legitimate Interest (if
> the
> > processing is based on GDPR Art 6.1(f)), GDPR Art 13.1(d)     Legitimate
> > Interest (if the processing is based on GDPR Art 6.1(f)), GDPR Art
> > 14.2(b)
> >
> >
> > Legal Basis   FALSE   Legal Basis for the Processing, GDPR Art 13.1(c)
> > Legal Basis for the Processing, GDPR Art 14.1(c)
> >
> >
> > Right to access       FALSE   The right to access to personal data, GDPR
> Art
> > 13.2(b).      The right to access to personal data, GDPR Art 14.2(c).
>
> >
> >
> > Right to rectification        FALSE   The right to rectification of
> personal
> > data, GDPR Art 13.2(b).       The right to rectification of personal
> data,
> > GDPR Art 14.2(c).     The right to rectification of personal data, GDPR
> > Art 15.1(e).
> >
> > Right to erasure      FALSE   The right to erasure of personal data,
> GDPR
> > Art 13.2(b).  The right to erasure of personal data, GDPR Art 14.2(c).
> >       The right to erasure of personal data, GDPR Art 15.1(e).
> >
> > Right to restriction  FALSE   The right to restriction of processing
> > concerning the data subject, GDPR Art 13.2(b).        The right to
> > restriction of processing concerning the data subject, GDPR Art
> > 14.2(c).      The right to restriction of processing concerning the data
> > subject, GDPR Art 15.1(e).
> >
> > Right to object to processing         FALSE   The right to object to
> > processing, GDPR Art 13.2(b).         The right to object to processing,
> GDPR
> > Art 14.2(c).  The right to object to processing, GDPR Art 15.1(e)..
> >
> > Right to data portability     FALSE   The right to data portability,
> GDPR
> > Art 13.2(b).  The right to data portability, GDPR Art 14.2(c).
> >
> >
> > Right to withdraw consent     FALSE   The right to withdraw consent at
> any
> > time, without affecting the lawfulness of processing based on consent
> > before its withdrawal (where the processing is based on point (a) of
> > Article 6(1) or point (a) of Article 9(2)), GDPR Art 13.2(c).
>  The
> > right to withdraw consent at any time, without affecting the
> > lawfulness of processing based on consent before its withdrawal (where
> > the processing is based on point (a) of Article 6(1) or point (a) of
> > Article 9(2)), GDPR Art 14.2(d).
> >
> >
> > Right to lodge a complaint    FALSE   The right to lodge a complaint
> with
> > a supervisory authority, GDPR Art 13.2(d).    The right to lodge a
> > complaint with a supervisory authority, GDPR Art 14.2(e).     The right
> > to lodge a complaint with a supervisory authority, GDPR Art 15.1(f).
> >
> >
> >
> > Best regards,
> > --
> > Georg Philip Krog
> >
> > signatu <https://signatu.com>
>
> --
> ---
> Harshvardhan Pandit, Ph.D
> Researcher at ADAPT Centre, Trinity College Dublin
> https://harshp.com/research/
>
>
>
>
> --
>
> Georg Philip Krog
>
> signatu <https://signatu.com>
>


-- 
Georg Philip Krog

signatu <https://signatu.com>