Add language about correlation risk to individuals

[msporny]

No description provided.

[rhiaro]

Thanks! This more or less address #6 I think.

[rhiaro]

What is "DID method registry" in this context? Does that mean the server which hosts the DID doc? I'd change the language to avoid confusion with this DID method registry. We could say "Verifiable Data Registry" to be consistent with the DID Core spec?

In this case I also wouldn't use the word "ledger" here.

(I haven't reviewed the rest of the spec to make sure language aligns with the latest in DID Core, so I'll do that too.)

[OR13]

+1 to using the term VDR.

[rhiaro]

Suggested change

	enables the DID Method registry to know when and where every did:web DID on the
	ledger is used, which is useful when tracking behaviour of the DID subject.
	enables the DID Method registry to know when and where every did:web DID on the
	ledger is used, which enables anyone with access to the sever to track behaviour of the DID subject.

[dmitrizagidulin]

Minor typo with 'sever'

[rhiaro]

Suggested change

	is used for DIDs where the DID subject requires privacy. Examples of
	is used for DIDs where the DID subject requires privacy and the Verifiable Data Registry infrastructure (e.g. the domain name and Web server) is not under direct and exclusive control of the DID subject. Examples of

[rhiaro]

Suggested change

To put a finer point on the privacy concerns of this particular DID Method.

(this doesn't stand on its own as a sentence)

[rhiaro]

Suggested change

	It is strongly advised that governments and corporations strongly advise
	individuals pick a DID Method that is more auditable and privacy-preserving
	than this DID Method.
	It is strongly advised that individuals do not use this DID method unless they have absolute confidence in their control over the underlying infrastructure of the implementation; that is, that the individual controls and has access to the domain name and Web server being used. It is strongly advised that individuals do not agree to or make use of a did:web DID that is issued on their behalf by a centralized authority which can control the underlying infrastructure without notice or auditability.
	It is strongly advised that where governments and corporations need to issue DIDs for individuals (as opposed to companies, departments or assets for example) they use a DID method that is more auditable and privacy-preserving than did:web.
	individuals pick a DID Method that is more auditable and privacy-preserving
	than this DID Method.

[dmitrizagidulin]

@msporny +1 to this PR overall (we've been meaning to add this section for a while).

We should get more specific with the warnings, though.

For example, verification of a Verifiable Presentation might result in resolving a did:web DID by the verifier. This enables the DID Method registry Verifiable Data Registry to know when and where every did:web DID on the
ledger is used, which is useful when tracking behaviour of the DID subject.

The "when and where every did:web DID ... is used" is not quite right. We should say something more like:

"For example, the verification of a Verifiable Presentation might result in a verifier resolving a did:web DID. As with any HTTP request, this resolution enables the Verifiable Data Registry (the server where the DID is hosted) to track a number of things, both about the verifier and the DID itself. (Incidentally, these concerns apply to any DID methods accessed through an http-based Universal Resolver of any sort hosted on a public website.)

DID:

• the server can track the frequency with which a DID is requested (which allows for various statistics gathering regarding relative popularity of DIDs).
• the exact time the verification was requested (which, combined with the next section, can help pinpoint the identity of the verifier).

Verifier:

• the server can track the requesting IP address of the verifier, which frequently enables geolocation-by-IP or even the exact identity of a well-known institution by their IP.
• the server can track any URL query parameters that are added to the DID by the requester (for example, some search engines, when directing a user to a website, pass along the search terms that were used to find it).
• if the verification request was performed using a typical web browser, the server can track even more about the verifier:
  • The User-Agent (as well as any other HTTP headers), which often enables browser fingerprinting attacks.
  • Any cookies the browser sends along with the request, which are frequently used for tracking.
    "

[OR13]

unclear what changes need to be accepted to see this merged.

[dmitrizagidulin]

@OR13 - I'd like the warnings to be more specific. (discussing this with @msporny)

[OR13]

PR is stale and should be closed.

[msporny]

Yes, it's stale. If we close this, the text should be preserved and integrated into the new spec.

[OR13]

#29

This PR should be closed if the requested changes cannot be implemented in a timely manner.

@dmitrizagidulin @awoie I recommend adding a "pending-close" / 1 week tag.

[OR13]

@msporny this PR has conflicts and changes requested, if they are not addressed in 1 week it will be closed, if you wish for these concerns to be addressed, please open issues to track them.

[OR13]

Closing the PR, feel free to open another one at any time.