Re: Proposals

Hi Harsh, all

See my answers inline in blue.

Hi Georg, All.
In addition to Bud's reply
(https://lists.w3.org/Archives/Public/public-dpvcg/2023Dec/0003.html)
which I agree with, below are my thoughts on the proposal.

On 19/12/2023 12:38, Georg Philip Krog wrote:
> I propose the following:
>
> 1..
> Data Subject Vulnerability

We have Vulnerable Data Subject as a category of data subjects - do you
mean to represent specific vulnerabilities, e.g. 'lack of comprehension
ability'? IF yes, is there a list / taxonomy for these that we can adapt?

Yes, I mean to represent specific vulnerabilities, e.g. "low visioned".
Don't know any list.

>
> 2.
> We do not have principles in DPV, not in DPV-GDPR. We should add them if
> they are needed. They are needed for DPIAS like this.

Okay for me. As Bud points out, for GDPR these will be from Art.5 GDPR -
so easy to do specific concepts linked to the clauses. For `Principles`
as the general concept, how to do about it? I think it fits alongside
the Codes of Conduct type concepts, so `Principle` can be an
organisational measure?

Agree.

>
> Assessment of compliance with the fundamental privacy principles:
>
>   * Lawfulness, fairness, and transparency
>   * Purpose limitation
>   * Data minimisation
>   * Accuracy => Is the personal data accurate at the time of collection?
>     Is the personal data kept up to date?
>   * Storage limitation
>   * Integrity and confidentiality
>   * Accountability

Along with these, there are also a lot of "AI" principles that we should
also take a look at since they are applicable to all technology, e.g.
https://oecd.ai/en/ai-principles. The legally defined principles should
go in their respective extensions, as with GDPR above.

Agree.

>
> 3.
> Safeguarding the rights and freedoms of the data subjects is also part
> of a DPIA.

Important points to discuss here:
1) Art.35 does not specifically talk about "safeguarding the rights and
freedoms", but instead refers to risks to rights/freedoms (A.35-7c) and
measures/safegards associated with these risks (A.35-7d)
2) Art.35 does not limit itself to rights/freedoms only of data subjects
but also includes other entities (Art.35-7d "rights and legitimate
interests of data subjects and other persons concerned")
3) In DPV terms, this translates into 'risks' that have the potential to
'impact' rights/freedoms of 'entity', and 'measures' to address these
risks.

Agree.

So the DPIA information concerning safeguarding rights/freedoms is not a
single explicit concept but a grouping of information, which I think we
can already express using the existing concepts.

Agree.

>
> 4.
> Under contract legal basis I propose "Agreement with Data Subject"

As Bud pointed out, 'Agreement' is ambivalent. We can extend the
existing Contract legal basis to be 'Contract with Data Subject' - this
also works out better to free the contract concept to include other
types of contracts e.g. Controller-Processor.

Agree.

>
> 5.
> I propose the following for the personal data category - Information
> about external characteristics that can be observed:
>
> Head Shape:
> pd:HeadHeight - The vertical measurement of the head from the base to
> the top.
> pd:HeadWidth - The horizontal measurement of the head at its widest point..
> pd:HeadLength - The measurement from the front to the back of the head.
> pd:HeadCircumference - The distance around the head, typically measured
> just above the ears.
>
> Hair Color (examples of specific colors):
> pd:HairColorBlack - The individual's hair color is black.
> pd:HairColorBrown - The individual's hair color is brown.
> pd:HairColorBlonde - The individual's hair color is blonde.
> pd:HairColorRed - The individual's hair color is red.
> pd:HairColorGray - The individual's hair color is gray.
> pd:HairColorWhite - The individual's hair color is white.
> pd:HairColorAuburn - The individual's hair color is auburn.
> pd:HairColorOther - The individual's hair color does not fit into the
> standard categories or is a mix of colors.
>
> Skin Tone:
> pd:SkinToneLight - The individual's skin tone is light.
> pd:SkinToneFair - The individual's skin tone is fair..
> pd:SkinToneMedium - The individual's skin tone is medium.
> pd:SkinToneOlive - The individual's skin tone is olive.
> pd:SkinToneTan - The individual's skin tone is tan.
> pd:SkinToneBrown - The individual's skin tone is brown.
> pd:SkinToneDark - The individual's skin tone is dark.
> pd:SkinToneBlack - The individual's skin tone is black.

Is there an authoritative source for these, or an indication of
where/how they are required? Hair Colour and Skin Tone I think can be
argued as being part of some official documents, but a reference would
be good to base it on.

The amount of specific detail is too high - and if we include all such
concepts, the Personal Data extension will be a gigantic list of things
and also open it up to include any and every category of data we can
think of e.g. nail colours. Either we decide where to 'draw the line' so
to speak, or agree that any and all data categories can be added.

Agree.

Regards,
Georg

On Tue, Dec 19, 2023 at 4:39 PM Harshvardhan Pandit <me@harshp.com> wrote:

> Hi Georg, All.
> In addition to Bud's reply
> (https://lists.w3.org/Archives/Public/public-dpvcg/2023Dec/0003.html)
> which I agree with, below are my thoughts on the proposal.
>
> On 19/12/2023 12:38, Georg Philip Krog wrote:
> > I propose the following:
> >
> > 1..
> > Data Subject Vulnerability
>
> We have Vulnerable Data Subject as a category of data subjects - do you
> mean to represent specific vulnerabilities, e.g. 'lack of comprehension
> ability'? IF yes, is there a list / taxonomy for these that we can adapt?
>
> >
> > 2.
> > We do not have principles in DPV, not in DPV-GDPR. We should add them if
> > they are needed. They are needed for DPIAS like this.
>
> Okay for me. As Bud points out, for GDPR these will be from Art.5 GDPR -
> so easy to do specific concepts linked to the clauses. For `Principles`
> as the general concept, how to do about it? I think it fits alongside
> the Codes of Conduct type concepts, so `Principle` can be an
> organisational measure?
>
> >
> > Assessment of compliance with the fundamental privacy principles:
> >
> >   * Lawfulness, fairness, and transparency
> >   * Purpose limitation
> >   * Data minimisation
> >   * Accuracy => Is the personal data accurate at the time of collection?
> >     Is the personal data kept up to date?
> >   * Storage limitation
> >   * Integrity and confidentiality
> >   * Accountability
>
> Along with these, there are also a lot of "AI" principles that we should
> also take a look at since they are applicable to all technology, e.g.
> https://oecd.ai/en/ai-principles. The legally defined principles should
> go in their respective extensions, as with GDPR above.
>
>
> >
> > 3.
> > Safeguarding the rights and freedoms of the data subjects is also part
> > of a DPIA.
>
> Important points to discuss here:
> 1) Art.35 does not specifically talk about "safeguarding the rights and
> freedoms", but instead refers to risks to rights/freedoms (A.35-7c) and
> measures/safegards associated with these risks (A.35-7d)
> 2) Art.35 does not limit itself to rights/freedoms only of data subjects
> but also includes other entities (Art.35-7d "rights and legitimate
> interests of data subjects and other persons concerned")
> 3) In DPV terms, this translates into 'risks' that have the potential to
> 'impact' rights/freedoms of 'entity', and 'measures' to address these
> risks.
>
> So the DPIA information concerning safeguarding rights/freedoms is not a
> single explicit concept but a grouping of information, which I think we
> can already express using the existing concepts.
>
> >
> > 4.
> > Under contract legal basis I propose "Agreement with Data Subject"
>
> As Bud pointed out, 'Agreement' is ambivalent. We can extend the
> existing Contract legal basis to be 'Contract with Data Subject' - this
> also works out better to free the contract concept to include other
> types of contracts e.g. Controller-Processor.
>
> >
> > 5.
> > I propose the following for the personal data category - Information
> > about external characteristics that can be observed:
> >
> > Head Shape:
> > pd:HeadHeight - The vertical measurement of the head from the base to
> > the top.
> > pd:HeadWidth - The horizontal measurement of the head at its widest
> point.
> > pd:HeadLength - The measurement from the front to the back of the head.
> > pd:HeadCircumference - The distance around the head, typically measured
> > just above the ears.
> >
> > Hair Color (examples of specific colors):
> > pd:HairColorBlack - The individual's hair color is black.
> > pd:HairColorBrown - The individual's hair color is brown.
> > pd:HairColorBlonde - The individual's hair color is blonde.
> > pd:HairColorRed - The individual's hair color is red.
> > pd:HairColorGray - The individual's hair color is gray.
> > pd:HairColorWhite - The individual's hair color is white.
> > pd:HairColorAuburn - The individual's hair color is auburn.
> > pd:HairColorOther - The individual's hair color does not fit into the
> > standard categories or is a mix of colors.
> >
> > Skin Tone:
> > pd:SkinToneLight - The individual's skin tone is light.
> > pd:SkinToneFair - The individual's skin tone is fair..
> > pd:SkinToneMedium - The individual's skin tone is medium.
> > pd:SkinToneOlive - The individual's skin tone is olive.
> > pd:SkinToneTan - The individual's skin tone is tan.
> > pd:SkinToneBrown - The individual's skin tone is brown.
> > pd:SkinToneDark - The individual's skin tone is dark.
> > pd:SkinToneBlack - The individual's skin tone is black.
>
> Is there an authoritative source for these, or an indication of
> where/how they are required? Hair Colour and Skin Tone I think can be
> argued as being part of some official documents, but a reference would
> be good to base it on.
>
> The amount of specific detail is too high - and if we include all such
> concepts, the Personal Data extension will be a gigantic list of things
> and also open it up to include any and every category of data we can
> think of e.g. nail colours. Either we decide where to 'draw the line' so
> to speak, or agree that any and all data categories can be added.
>
> Regards,
> --
> ---
> Harshvardhan J. Pandit, Ph.D
> Assistant Professor
> ADAPT Centre, Dublin City University
> https://harshp.com/
>


-- 
Georg Philip Krog

signatu <https://signatu.com>