Add section on service privacy #515
Conversation
Signed-off-by: Daniel Hardman <[email protected]>
|
It's ok with me. I'm curious about the reasoning. I assume there are cases
where people see the need for an array or list of endpoints. If so, it may
be useful to change the paragraph with the three examples.
…On Tue, Dec 22, 2020 at 2:31 PM Daniel Hardman ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#515 (comment)>:
> +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.
I'm fine with this change, but this PR was intended to embody @agropper
<https://github.com/agropper> 's verbiage, so I don't feel like I can
unilaterally update it. Adrian?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YOSAFWZUQD32G7THOLSWDX2VANCNFSM4VFK2SRA>
.
|
index.html
Outdated
| service endpoint as the root. In some cases, the publication mechanism might | ||
| reference a DID Document with no service endpoints at all. For category 2, | ||
| 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 |
There was a problem hiding this comment.
| mediator / proxy that can provide a kind of herd immunity, or both. For | |
| mediator/proxy that can provide a kind of herd immunity, or both. For |
index.html
Outdated
| category 3, 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 |
There was a problem hiding this comment.
| possible, or introduce a mediator / proxy as a sole service endpoint in | |
| possible, or introduce a mediator/proxy as a sole service endpoint in |
|
This PR is waiting on @dhh1128 to respond to review comments and either accept changes, or reject them with reasoning. |
|
I'm just noting that I'm aware of these suggestions/points of feedback, and working through them is on my to-do list. I don't have strong opinions about most of this stuff; I submitted the the content in this PR but attributed @agropper as author. So, while I can easily merge updates to polish the PR, I think Adrian should express an opinion about how much of the feedback aligns with the thinking he wanted to propose. |
|
I see all but one of the proposed changes as editorial.
The one suggestion that changes the intent of the joint PR is:
Suggested change
…-unintended consequences. DIDs can identify documents, things, and schemas as
-well as services. As such, they will be associated with individual people,
+unintended consequences. DIDs can identify documents, services, schemas, and
+other things. As such, they will be associated with individual people,
My point was to call out things as services that are often associated
with people.
Thank you @dhh1128 for your help and care.
Adrian
On Mon, Jan 4, 2021 at 11:32 AM Daniel Hardman ***@***.***> wrote:
I'm just noting that I'm aware of these suggestions/points of feedback,
and working through them is on my to-do list.
I don't have strong opinions about most of this stuff; I submitted the the
content in this PR but attributed @agropper <https://github.com/agropper>
as author. So, while I can easily merge updates to polish the PR, I think
Adrian should express an opinion about how much of the feedback aligns with
the thinking he wanted to propose.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YNGP7TDBMVERAHEYHDSYHURBANCNFSM4VFK2SRA>
.
|
|
Fair enough. Would you agree to saying: "as well as service endpoints."?
…On Mon, Jan 4, 2021 at 4:15 PM Ted Thibodeau Jr ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#515 (comment)>:
> +unintended consequences. DIDs can identify documents, things, and schemas as
+well as services. As such, they will be associated with individual people,
@agropper <https://github.com/agropper> -- I've edited the above
suggested change. Perhaps it now communicates what you intended? (My
concern is that your phrasing suggests that DIDs are [or will be] used
primarily to identify services, which I think inaccurate.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YNRSQQTVMNMAURDKJTSYIVWTANCNFSM4VFK2SRA>
.
|
|
instead of services.
On Mon, Jan 4, 2021 at 4:19 PM Adrian Gropper <[email protected]>
wrote:
… Fair enough. Would you agree to saying: "as well as service endpoints."?
On Mon, Jan 4, 2021 at 4:15 PM Ted Thibodeau Jr ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In index.html
> <#515 (comment)>:
>
> > +unintended consequences. DIDs can identify documents, things, and schemas as
> +well as services. As such, they will be associated with individual people,
>
> @agropper <https://github.com/agropper> -- I've edited the above
> suggested change. Perhaps it now communicates what you intended? (My
> concern is that your phrasing suggests that DIDs are [or will be] used
> primarily to identify services, which I think inaccurate.)
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#515 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABB4YNRSQQTVMNMAURDKJTSYIVWTANCNFSM4VFK2SRA>
> .
>
|
Co-authored-by: Dave Longley <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Manu Sporny <[email protected]>
Co-authored-by: Manu Sporny <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
@agropper -- I think my revision was not communicated clearly by github's email gateway. This was the revised suggestion (which @dhh1128 merged, anticipating your OK) -- I don't feel strongly about "services" vs "service endpoints" here. I think that the "... as well as ..." phrasing implies that the thing that follows "as well as" is implicit (and so could have been left unstated), while the things that precede "as well as" had to be explicit -- i.e., that the "as well as" phrasing implies that DIDs are mostly about identifying "services" (or "service endpoints") and "documents, things, and schemas" are surprising bonus things to be identified by DIDs. (I am now a bit concerned that this text now implies that DIDs cannot identify people because people are not listed as being identified by DIDs, only as being inversely associated with things that are identified by DIDs...) |
|
I'm confused. My intent and my proposal focuses on DIDs as Identifiers. A
service or service endpoint is "meta" from this privacy perspective and may
be the source of our confusion.
I propose that we stick to: "DIDs can identify documents, things, and
schemas that may be associated or correlated with individual people and
with groups."
Can we go with that?
Adrian
…On Mon, Jan 4, 2021 at 6:31 PM Ted Thibodeau Jr ***@***.***> wrote:
@agropper <https://github.com/agropper> --
I think my revision was not communicated clearly by github's email
gateway. This was the revised suggestion (which @dhh1128
<https://github.com/dhh1128> merged, anticipating your OK) --
unintended consequences. DIDs can identify documents, services, schemas, and
other things that may be associated with individual people,
I don't feel strongly about "services" vs "service endpoints" here.
I think that the "... as well as ..." phrasing implies that the thing that
follows "as well as" is implicit (and so could have been left unstated),
while the things that precede "as well as" had to be explicit -- i.e., that
the "as well as" phrasing implies that DIDs are *mostly* about
identifying "services" (or "service endpoints") and "documents, things, and
schemas" are surprising bonus things to be identified by DIDs.
(I am now a bit concerned that this text now implies that DIDs *cannot*
identify *people* because people are not listed as being identified by
DIDs, only as being inversely associated with things that are identified by
DIDs...)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YOUKK7JAOORKDFI7LDSYJFU5ANCNFSM4VFK2SRA>
.
|
|
DIDs are indeed Identifiers, which take the form of URIs/URLs/IRIs in the Note 0 — My list of classes of entities of which DIDs may Identify individuals is longer than your original, in an effort to increase clarity -- i.e., DIDs may Identify anything (though there will be many classes which just don't need DIDs, and the world will be perfectly fine continuing to Identify them with CIDs such as HTTPS-based Github or Twitter or Facebook or example.com URIs). Note 1 -- I put "any other thing" at the end of that list of classes, because every other class (every other "thing") in the list is a sub-type of "thing". "Things" don't belong in the middle, because there's nothing else -- no super-class "xyz" -- that fits as an "any other xyz" phrase to end the list. Note 2 -- A "person" was the first "thing" conceived of as needing a DID to identify him/her/it-self, i.e., to be the Controller of their own Decentralized Identifier a/k/a DID. Leaving "people" out of the list of "things" which a DID may identify is problematic, even if another longer list is found elsewhere in the sam document. It would inevitably cause confusion as readers encounter that truncated list and say, "Clearly people can't be identified by DIDs — people aren't in this list of things that DIDs can Identify!" I think the privacy focus calls even louder for inclusion of "people". |
|
This is a section on privacy. Bridges and the Federal Register could have
DIDs but they would not have much of a privacy impact. Aside from bridges
and public proclamations, most documents, things, and many schemas are
associated with people or groups of people and therefore have potential
privacy concerns through correlation, traffic analysis, and AI/ML
techniques that enable inferences to be made about people.
Adrian
…On Tue, Jan 5, 2021 at 12:08 AM Ted Thibodeau Jr ***@***.***> wrote:
DIDs are indeed Identifiers, which take the form of URIs/URLs/IRIs in the
did: scheme, which we are defining, and otherwise conform to RFC 3986
<https://tools.ietf.org/html/rfc3986>. Just like any other URI/URL/IRI,
they can be used to identify (a/k/a name, a/k/a denote) people, places,
services, concepts, schemas, documents, and any other thing, material or
imaginary, any of which might be associated or correlated with individual
persons or groups thereof.
------------------------------
Note 0 — My list of classes of entities of which DIDs may Identify
individuals is longer than your original, in an effort to increase clarity
-- i.e., DIDs may Identify *anything* (though there will be many classes
which just don't need DIDs, and the world will be perfectly fine continuing
to Identify them with CIDs such as HTTPS-based Github or Twitter or
Facebook or example.com URIs).
Note 1 -- I put "any other thing" at the end of that list of classes,
because every other class (every other "thing") in the list is a sub-type
of "thing". "Things" don't belong in the middle, because there's nothing
else -- no super-class "xyz" -- that fits as an "any other xyz" phrase to
end the list.
Note 2 -- A "person" was the first "thing" conceived of as needing a DID
to identify him/her/it-self, i.e., to be the Controller of their own
Decentralized Identifier a/k/a DID. Leaving "people" out of the list of
"things" which a DID may identify is problematic, even if another longer
list is found elsewhere in the sam document. It would inevitably cause
confusion as readers encounter that truncated list and say, "Clearly people
can't be identified by DIDs — people aren't in this list of things that
DIDs can Identify!" I think the *privacy* focus calls even louder for
inclusion of "people".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YK2D5W5JP6V2T5D7ADSYKNF5ANCNFSM4VFK2SRA>
.
|
|
The phrase "...most documents, things, and many schemas are..." seems to suggest that "schemas" are not "things", and that does not work for me. That short phrase could be changed to "...many documents, schemas, and other things are..." and I'd be satisfied with your latest paragraph -- but I don't think that paragraph flows with the rest of this section of the document. I think this is getting harder to work on without larger context. Below, there are 3 versions of the paragraph of immediate focus. The original from the PR; my previously suggested revision (adjusted a bit after feedback); and my currently suggested revision. I stand by the second version below. I would also accept the third. Original: My almost-original suggested change: My current suggestion, trying to incorporate what you've responded with: |
|
The third version adds: "DIDs can directly identify specific
individuals..." I really don't think we want to go there. This has been
discussed by @jandrieu in other threads. I see no reason to bring it up
here. The third version also introduces "unintentionally" which feels
wrong.
A thing is not a service. In the context of a privacy issues section it is
simple and clear. This section is not about defining what DIDs are or are
intended to be.
Please stay with the first version or get other people involved.
Adrian
…On Wed, Jan 6, 2021 at 9:36 PM Ted Thibodeau Jr ***@***.***> wrote:
@agropper <https://github.com/agropper>
The phrase "...most documents, things, and many schemas are..." seems to
suggest that "schemas" are not "things", and that does not work for me.
That short phrase could be changed to "...many documents, schemas, and
other things are..." and I'd be satisfied with your latest paragraph -- but
I don't think that paragraph flows with the rest of this section of the
document.
------------------------------
I think this is getting harder to work on without larger context. Below,
there are 3 versions of the paragraph of immediate focus. The original from
the PR; my previously suggested revision (adjusted a bit after feedback);
and my currently suggested revision.
I stand by the second version below. I would also accept the third.
Original:
The degree of additional privacy risk caused by using multiple service
endpoints in one DID document can be difficult to estimate. Privacy
harms are typically 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 could become a powerful
surveillance and inference tool.
My almost-original suggested change:
The degree of additional privacy risk caused by using multiple service
endpoints in one DID document can be difficult to estimate. Privacy
harms are typically unintended consequences. DIDs can identify documents,
services, schemas, and other things that may be associated
with individual people, households, clubs, and employers — and
correlation of their service endpoints could become a powerful
surveillance and inference tool.
My current suggestion, trying to incorporate what you've responded with:
The degree of additional privacy risk caused by using multiple service
endpoints in one DID document can be difficult to estimate. Privacy
harms are typically unintended consequences. DIDs can directly identify
specific individuals or groups of people. DIDs can also indirectly and
unintentionally identify individual people, households, clubs, employers,
and other groups of people by directly identifying documents, schemas, and
other things that may be associated with those individuals or groups
through correlation, traffic analysis, AI/ML techniques, etc."
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#515 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YJJQ4PPZIPSVF7BMPTSYUM2PANCNFSM4VFK2SRA>
.
|
I don't know why you don't want to go there, in a privacy section, where the fact that DIDs can directly identify individuals is the most obvious top-level privacy risk, and the fact that DIDs which identify non-human-things (including services, documents, schems, etc.) can be used (with various technologies) to indirectly identify individuals, being a less-obvious second- or third- or lower-level privacy risk. I believe both should be noted in a privacy section!
I don't understand your objection to "unintentionally", which is essentially equivalent to "unintended consequences" (your words).
Yes, this section is not about defining (nor redefining, which seems to me one unintended side-effect of leaving out the "direct identification of individual people") DIDs, but it is about discussing how what DIDs are can lead to privacy issues. "Services" is a subclass of "things" (a/k/a "entities", a/k/a "concepts"). All instances of class "services" are also instances of class "things". On the other hand, many instances of class "things" are not instances of class "services". My couch not a service; my refrigerator is not a service; my house is not a service -- but all three of these are things, and they may be identified by DIDs. Correlating the facts that :alice sits on my couch, and eats from my refrigerator, and sleeps in my house, one might infer that
I'm happy to have other people involved. I don't believe anyone else who saw my initial suggested edit took issue with it. Indeed, @dhh1128 merged it, anticipating that you would agree with it. I wonder if @msporny, @dlongley, maybe @burnburn have some thoughts to contribute? |
|
I have been quiet for a while, but just wanted to say that all of the versions of the paragraph in question feel okay to me -- Adrian's, or any of Ted's revisions. The key point is that the ideal from a privacy perspective is to disclose nothing beyond control keys in a DID document. If a DID identifies a person and its document is publicly viewable, then the more we step away from that ideal, the more we incur a privacy risk; leaked metadata is exploitable. The language differs in its precision and the finer points of how it explains this concern, but the principle is right in all versions of the text. |
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This is an alternative embodiment of the "Service Privacy" guidance as proposed by Adrian Gropper in this comment. If accepted, it would supersede #511 and address issue #382.
Signed-off-by: Daniel Hardman [email protected]
Preview | Diff