Add section on "Service Privacy" to Privacy Considerations. #511
Conversation
There was a problem hiding this comment.
I strongly disagree with these changes. Why is "An individual's DID Document expressing endpoints for managing electronic health records (bad idea)." a bad idea?
In this comment I make exactly the opposite argument: #480 (comment) We should be recommending as few service endpoints as possible and protecting them by an authorization server in most cases.
I suggest adding a stronger statement suggesting that service endpoints other than authorization servers or mediators should be avoided.
I suggest we reword the examples section as follows into clear categories based on privacy expectations. Note that I
- replaced the "ordering" statement with clear public and private categories,
- removed the "bad idea" statements,
- changed the managing EHR endpoint example to singular, and
- added two other examples of privacy-expected endpoints:
For example, consider the range of privacy implications for the following service endpoints:
No expectation of privacy:
A governmental DID Document expressing the government's public website.
A celebrity DID Document expressing all of their official social media profiles.
An individual's DID Document expressing their professional profile.
A corporate DID Document expressing contact information for their paying customers.
An individual's DID Document expressing a service endpoint containing their email address.
An individual's DID Document expressing a service endpoint containing their personal phone number and home address.
Some expectation of privacy:
An individual's DID Document expressing an endpoint for managing electronic health records.
A device's DID Document expressing an endpoint for requesting access authorization.
A DID Document expressing an endpoint that mediates requests to provide herd immunity.
| email address (questionable idea). | ||
| </li> | ||
| <li> | ||
| An individual's DID Document expressing a service endpoint containing their | ||
| personal phone number and home address (bad idea). | ||
| </li> | ||
| <li> | ||
| An individual's DID Document expressing endpoints for managing electronic | ||
| health records (bad idea). |
There was a problem hiding this comment.
I don't think we need these parentheticals. This is a considerations section -- we should let the reader consider whether or not these things are a good or bad idea. We should just elevate attention to them so they will receive that consideration.
|
I think it's much worse than we let on in this section. The examples talk
about institutions, public documents, and individuals and don't consider
DIDs for IoT. We can reasonably expect each of us to have a dozens of
connected things in our homes, cars, and pockets. Many of them will connect
directly into the Ether via 5G. Any unprotected service endpoint in the DID
Document of these devices will be indexed and correlated by data brokers
using AI.
For example:
https://venturebeat.com/2020/12/17/bigids-quick-1-billion-plus-valuation-shows-rise-of-data-intelligence-and-privacy/
I suggest we add a paragraph about DIDs for devices and documents that are
associated with individuals, groups, and companies. DID Documents using
service endpoints for indexing convenience will become a standardized
surveillance protocol across everything we do.
…On Mon, Dec 21, 2020 at 11:19 AM Dave Longley ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#511 (comment)>:
> +email address (questionable idea).
+ </li>
+ <li>
+An individual's DID Document expressing a service endpoint containing their
+personal phone number and home address (bad idea).
+ </li>
+ <li>
+An individual's DID Document expressing endpoints for managing electronic
+health records (bad idea).
I don't think we need these parentheticals. This is a considerations
section -- we should let the reader consider whether or not these things
are a good or bad idea. We should just elevate attention to them so they
will receive that consideration.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#511 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YONL3AD2OQ6TBGNZ2TSV5YRPANCNFSM4VDOO22Q>
.
|
There was a problem hiding this comment.
I am okay with this section as written. I agree with Dave's comment that the "(bad idea)" parenthetical is not necessary, but it doesn't bother me either way.
I also agree with Adrian's note that we're failing to talk about IOT as it relates to privacy, so an additional paragraph on that topic would be nice. (Maybe @agropper can suggest one?)
|
@dhh1128 and @msporny - I appreciate the work @msporny did to provide the first example of this section as a PR. I've reviewed the resolutions and propose the following to replace the entire Service Privacy section: The ability for a controller to optionally state at least one service endpoint in the DID Document increases their control and agency. Stating more than one endpoint in the DID Document always adds privacy risk either due to correlation across the endpoint descriptions or because the services are not protected by an authorization mechanism, or both. (Resolution 1) The degree of added privacy risk for using multiple service endpoints in one DID Document can be difficult to estimate. Privacy harms, are typically due to unintended consequences. DIDs can identify documents, things, and schemas as well as services. As such, they will be associated with individual people, households, clubs, and employers and correlation of their service endpoints will become a powerful surveillance and inference tool. (Resolution 3) DID Documents are often public and will be stored and indexed efficiently by their very nature as standards-based. This risk is worse if DID Documents are published to immutable Verifiable Data Registries. Access to a history of the DID Documents referenced by a DID represents a form of traffic analysis made more efficient through our standards process. (Resolution 4) Examples of service endpoints in DID Documents come in three broad categories: (i) intentional public disclosures; (ii) DIDs about natural persons (as might be covered by GDPR and similar privacy regulations); and (iii) about things and documents that are associated with natural persons. For category (i), consider non-DID publication mechanisms with only a single service endpoint as the root. In some cases, the publication mechanism might reference a DID Document with no service endpoints at all. For category (ii), prefer using only one service that points to an authorization server or to a mediator / proxy that can provide a kind of herd immunity, or both. For category (iii), avoid the use of multiple service endpoints for a DID because some of these (e.g. an authorization server) are likely to be reused with other, related DIDs. Place correlatable service endpoints behind a “firewall”, if possible, or introduce a mediator / proxy as a sole service endpoint in order to obscure related devices and documents through herd immunity. (Resolution 2) Help in turning this into a PR would be appreciated. I also hope we can review #506 and #510 and reference it as privacy anti-pattern in this section. |
|
I am quite happy with Adrian's writeup and would be glad to turn it into a PR if Manu feels it covers the same semantic territory as his. @msporny ? |
Yes, please, and thank you @dhh1128. I have some minor nits and a few additions, but would be happy in general with @agropper's wording. I'll leave this PR open until you raise one @dhh1128, then point to that PR as a continuation of this one, and then close this PR. |
|
PR #515 supercede's this PR, closing. |
This PR adds a section on Service Privacy to the Privacy Considerations section and attempts to address issue #382 by implementing the following WG resolutions: #382 (comment)
Preview | Diff