The DID service endpoint privacy challenge

I’m hoping to speed the privacy discussion across DID, auth, and SDS by
introducing a challenge:


DiDs are a public and persistent identifier that will be indexed,
correlated, analyzed and catalogued to create new opportunities for privacy
and security mischief including inferences leading to discrimination, spam,
and denial of service attacks. The mitigation of these attacks is rooted in
the demarcation between the public DID Document and the private user agent
that controls the DID, often secured by a biometric.


This demarcation is the service endpoint. If DIDs were normatively
restricted to a single service endpoint privacy analysis would be greatly
simplified. Allowing multiple service endpoints of the same type and of
different types (authorization, storage, notification) makes privacy
analysis of DIDs more difficult and unintended consequences more likely.


If there were only one service endpoint, what would it be and could it
accommodate authentication, authorization, storage, and notification uses
without undue limitation?


- Adrian

Received on Monday, 29 June 2020 09:14:44 UTC