diff --git a/index.html b/index.html index 8e3e1a9..89e1f54 100644 --- a/index.html +++ b/index.html @@ -2502,63 +2502,43 @@

Level of Assurance

Privacy Considerations

-Since controller documents are designed to be administered -directly by the controller, it is critically important to apply -the principles of Privacy by Design [[PRIVACY-BY-DESIGN]] to all aspects of the -decentralized identifier architecture. All seven of these principles -have been applied throughout the development of this specification. The design -used in this specification does not assume that there is a registrar, hosting -company, nor other intermediate service provider to recommend or apply -additional privacy safeguards. Privacy in this specification is preventive, -not remedial, and is an embedded default. The following sections cover privacy -considerations that implementers might find useful when building systems that -utilize controller documents. +Since controller documents are designed to be administered directly by +the controller, it is critically important to apply the principles of +Privacy by Design [[PRIVACY-BY-DESIGN]] to all aspects of the +controller document. All seven of these principles have been applied +throughout the development of this specification. The design used in this +specification does not assume that there is a registrar, hosting company, nor +other intermediate service provider to recommend or apply additional privacy +safeguards. Privacy in this specification is preventive, not remedial, and is an +embedded default. The following sections cover privacy considerations that +implementers might find useful when building systems that utilize controller +documents.

Keep Personal Data Private

-If a DID method specification is written for a public-facing -verifiable data registry where corresponding DIDs and DID -documents might be made publicly available, it is critical that -those controller documents contain no personal data. Personal data can instead -be transmitted through other means such as 1) Verifiable Credentials -[[?VC-DATA-MODEL]], or 2) service endpoints under control of the DID -subject or DID controller. -

- -

-Due diligence is expected to be taken around the use of URLs in service -endpoints to prevent leakage of personal data or correlation within a URL of -a service endpoint. For example, a URL that contains a username is -dangerous to include in a controller document because the username is likely to -be human-meaningful in a way that can reveal information that the DID -subject did not consent to sharing. With the privacy architecture suggested -by this specification, personal data can be exchanged on a private, peer-to-peer -basis using communication channels identified and secured by verification -methods in controller documents. This also enables DID subjects and -requesting parties to implement the GDPR -right to be -forgotten, because no personal data is written to an immutable -distributed ledger. +If a controller document is about a specific individual and is +public-facing, it is critical that the controller documents +contain no personal data. Personal data can instead be transmitted through other +means such as 1) [=verifiable credentials=] [[?VC-DATA-MODEL-2.0]], or 2) +other private communication channels.

-

DID Correlation Risks

+

Identifier Correlation Risks

-Like any type of globally unambiguous identifier, DIDs might be used for -correlation. DID controllers can mitigate this privacy risk by using -pairwise DIDs that are unique to each relationship; in effect, each -identifier acts as a pseudonym. A pairwise identifier need only be shared with -more than one party when correlation is explicitly desired. If pairwise -DIDs are the default, then the only need to publish an identifier openly, -or to share it with multiple parties, is when the DID controller(s) and/or DID subject -explicitly desires public identification and correlation. +Globally unambiguous identifiers can be used for the purpose of correlation. +Controllers can mitigate this privacy risk by using pairwise identifiers +that are unique to each relationship; in effect, each identifier acts as a +pseudonym. A pairwise identifier need only be shared with more than one party +when correlation is explicitly desired. If pairwise identifiers are the default, +then the only need to publish an identifier openly, or to share it with multiple +parties, is when the controllers and/or subjects explicitly +desire public identification and correlation.