Re: Verifiable Claims privacy/technology issues

Tristan Hoy writes:

> The current draft architecture for Verifiable Claims describes a single
> point of privacy failure: the identifier registry.
>
> Here is a set of cascading requirements, assuming the registry is some kind
> of "server":
> 1) The registry MUST be resilient to denial of service attacks
> 2) The registry MUST be able to discriminate between high-volume inspectors
> (e.g. Walmart, government agencies) and DDoS attackers
> 3) Therefore, the registry MUST authenticate inspectors
>
> And this gives the registry access to all of the metadata concerning who an
> identity holder is interacting with. While this is perfect in a government
> or corporate environment where every interaction will be logged regardless,
> it is not good for privacy.
>
> Unless of course, the registry is a blockchain, and each inspector is
> running their own node. There is some very specific jargon that indicates
> that this may be the not-so-opaque intention of the architecture:
> "The registry MUST manage identifiers in a self-sovereign way"
>
> However this is speculation.
>
> What isn't speculation is that this architecture cannot possibly support
> interaction privacy unless the identity registry is a decentralized name
> service or some other flavour of blockchain.
>
> The working group charter states: "The Working Group will
> not...attempt to lead the creation of a specific style of supporting
> infrastructure"
>
> But that's exactly what's happening: the registry is a required component,
> and if you want interaction privacy, the registry has to be a blockchain.

The infrastructure could also be a distributed hash table, right?  For
example, I think you could build something like what the DID spec offers
on top of something like IPFS and IPNS (and I've been trying to
understand how such a thing would work).  It would have some very
significantly different tradeoffs in that without identifiers being
"pinned", they could vanish, but there are some ways to do that.

I'm not saying using a DHT would be the best system to use, I'm just
saying that the DID mechanism seems flexible enough to handle some other
systems that aren't blockchains and still meet the requirements.

Received on Thursday, 27 July 2017 21:27:42 UTC