Privacy Considerations - Specifically call out GDPR

[msporny]

@talltree wrote:

As much as I'd love to have a magic wand to avoid privacy or GDPR issues with ... DID documents...I personally believe it can't be done. It doesn't matter if we constrain the value of a serviceEndpoint property to a URL. You can stuff almost any kind of relatively short personal data in a URL if you want to.

This is an excellent point, we should have a section in the DID Document specifically about GDPR and the challenges posed by ledger-based systems and GDPR. This includes at least: PII, URLs that contain potential PII, identifiers that could be used to track in the DID Document (even when the DID itself is potentially a one-off / pairwise thing), and other things that would trigger GDPR wrt. the entity operating the ledger or writing the ledger software or using the ledger.

[peacekeeper]

There is already quite a bit of content related to GDPR and tracking, maybe it can be improved/expanded somehow?

When talking about GDPR, the term "personal data" should be used instead of "PII".

[rhiaro]

Markus' proposed change ("PII" -> "personal data") has been made in #232

[talltree]

On the 2020-05-26 WG call, we discussed that this is still an issue that must be addressed in the updated Privacy Considerations Section. I still own this issue, and will address it as soon as the updates to the Terminology section are done.

[rhiaro]

If you can give me a ballpark idea of what we need to say about GDPR, I can write some more text for it.

[talltree]

On the 2020-06-16 WG call, we confirmed the status is still the same. I am still willing to draft text on this issue when I reach it in the priority queue, but I welcome others who would like to submit a PR.

[talltree]

If you can give me a ballpark idea of what we need to say about GDPR, I can write some more text for it.

@rhiaro , it's a pretty deep issue, but I can point you at the work we did at the Sovrin Foundation on this issue. If you're willing to read the 35-page white paper, it should give you the background you need.

If it would be helpful to have a call with me to discuss, happy to, just drop me an email.

[agropper]

Privacy has a big problem with GDPR, CCPA, HIPAA and other regulations that allow for an unlimited number of aggregated copies of our personal information. Our aggregated information is seen as an asset to be monetized with or without consent, such aggregates to be used by an unlimited number of actors to create inferences that can then be applied to ourselves and others.

Some of these unlimited aggregates are created without consent through de-identification. Here's a recent real-world concern in the context of CCPA but it would apply equally to GDPR. https://us10.campaign-archive.com/?e=3c414bccd2&u=612aa5bbee2712df75cf92250&id=b78c807951

If we're going to weigh in on regulatory issues like GDPR, our community would do well to link the rubrics of decentralization to the impact of unlimited aggregation, data and inference brokerage.

[agropper]

https://us10.campaign-archive.com/?e=3c414bccd2&u=612aa5bbee2712df75cf92250&id=b78c807951

[rhiaro]

I'm not sure what to add that we don't already have which is basically "don't put private/identifying info on an immutable ledger"

[talltree]

The relationship of DIDs (and associated public keys) on immutable public ledgers is a topic that is coming up with increasing frequency in my conversations with customers adopting DID technology in the market. So I believe this concern must be addressed in our Privacy Considerations section. However, as I and others like @agropper have pointed out earlier in this thread, this is a very deep subject with a lot of information published about it. So I believe that our entry in the Privacy Considerations section on this topic should be a summary of the core issue and our current understanding about DIDs and public keys as "personal data" under GDPR together with links to public documents to refer to on the topic. I suggest we write that entry as we prepare the spec for CR as it would be good to have the very latest information (the regulatory discussion of this issue is ongoing).

[selfissued]

We should remove references to specific laws, including the GDPR reference in the Privacy Considerations section. At most, we should say that implementers and deployers should be aware of locally applicable regulations and comply with them.

Also, Wikipedia links are not authoritative references. I found two of them when investigating this issue. We should remove all of them and/or replace them with authoritative references to the intended topics.

[iherman]

We should remove references to specific laws, including the GDPR reference in the Privacy Considerations section. At most, we should say that implementers and deployers should be aware of locally applicable regulations and comply with them.

Also, Wikipedia links are not authoritative references. I found two of them when investigating this issue. We should remove all of them and/or replace them with authoritative references to the intended topics.

@selfissued, the PC section is non-normative, meaning that I do not think a wikipedia link is necessarily a problem. Similarly, a reference to GDPR as an example should be o.k. (although it is probably better to make it clear that this is just an example for a well-known regulation).

[rhiaro]

the PC section is non-normative, meaning that I do not think a wikipedia link is necessarily a problem.

it might be a good idea to see if we can link to a specific snapshot of the page history though, as it can be edited out from under us to say something completely different any time

[talltree]

This is excellent discussion. I have the action item to draft proposed text for this as soon as I am done with normative sections of DID Core.

[peacekeeper]

I think @selfissued and @iherman make good points here. Perhaps GDPR should be mentioned as an example without going into details, and there should be language that there are also other privacy laws out there.

[msporny]

This issue hasn't moved forward in a month and we're approaching CR. This issue will be closed before we enter CR if a pull request isn't raised to add it into the specification.

[TallTed]

It would be better if there were reference to at least one example law/regulation other than GDPR, in addition to GDPR. I don't think there's a strong parallel in the USA. Does anyone know of such a thing, in any other nation/region/alliance?

[talltree]

@TallTed Yes, there are several strong parallels to GDPR around the world. Two that I frequently cite are the the Canadian Personal Information Protection and Electronic Documents Act (PIPEDA), and the California Consumer Privacy Act (CCPA). California also just passed the California Privacy Rights Act (CPRA).

I agree that citing several examples of these privacy regulations would be best.

[msporny]

This issue will be closed once PR #460 is merged.

[talltree]

@msporny I just did a complete read-through of the current text in the Privacy Considerations section and I was gratified to see that every point I planned to make about GDPR and other privacy and data protection regulations had already been made.

At this point I don't see that we need to add anything else—IMHO we can close this issue unless another WG member believes something is still missing.

[peacekeeper]

I agree this issue has been addressed and can probably be closed.

I think the spec should use the term "personal data" consistently everywhere, and I created a new issue for this: #590.

[msporny]

PR #460 has been merged and @talltree has performed a review of privacy considerations that address the remaining GDPR concerns. @peacekeeper is tracking some minor editorial clean ups in #590. This issue is done, closing.