"Is 'acceptably non-dystopian' self-sovereign identity even possible?"

An essay about self-sovereign identity, decentralized identity, verifiable credentials, soulbound tokens, and all those other terms that have been flying around lately.

blog.mollywhite.net/is-accepta

@molly0xfff

How can centralization help implement privacy-preserving Sybil resistance? (Not rhetorical, I'm sometimes out of the loop with protocols such as escrow.)

If there's privacy, it's hard to know who people are even if you're centralized; Wikipedia for example (where the problem is called "sock puppets").

Sybil resistance sounds good to me, I'm getting sick of waking up in strange rooms in weird clothes trying to find my wallet and not recognizing the name on any of the ID cards.

@Sandra @molly0xfff I've been toying with the idea of verifiable credentials myself, for a good decade and a half, actually, and I genuinely think there is potential there. There are a couple of things the blockchain world gets very wrong, though, the first of which is that it needs to involve any kind of blockchain/record.

But the far more worrying thing is that they all seem to want to enforce things computationally about people. That's the dystopian bit.

@Sandra @molly0xfff Privacy and centralization is really more of a question of which data you reveal to whom. Let's say you do want to receive money to your bank account. As Swiss numbered bank accounts show, you really just need to provide an opaque identifier of sorts to achieve that.

You want to verify that it's at a particular bank? Have that bank sign it. You want to verify that it's owned by some person? Have the bank sign a hash over the person's id...

@Sandra @molly0xfff ... and the opaque identifier. You don't need the bank to provide the person ID, because the person will do so.

The problem I see in most approaches is that they're inflexible; they try to prove some global truth, and in order to capture enough use cases, they include and leak more data than is necessary for each individual use case.

Implementors should focus a lot more on how the offline world already operates.

As another example, in...

@jens

"You don't need the bank to provide the person ID, because the person will do so."

And that's not a solution, it's kicking the can down the road🤷🏻‍♀️

@Sandra Yes, actually, because it's about minimizing data. What else is privacy but that?

@jens

The problem was proving identity. "The bank has seen a proof of identity" isn't a solution to creating such proofs of identity in the first place.

@Sandra Of course it is. That's the whole point.

You don't need to prove identity in the vast majority of use cases, you just need to prove that such proof exists. You need to be able to trust that proof-of-proof, which means you need to trust someone else to issue trustworthy proof-of-proofs.

In the banking case, the obvious issuer is the bank; they have a vested interest in it after all. In other use cases, less centralisation may be better.

@Sandra The bank may wish to be a root of proof, or request a proof from the state. In either case, since the whole thing eventually ties back to the real world, it'll involve some real world ritual. Once per root. And only that root needs to know anything at all about you, the person.

This isn't even centralization in a lot of senses, because proofs can be issued such that the root doesn't have to be consulted, or any intermediary. It centralizes identity proving, yes.

Follow

@Sandra But equally, it's perfectly fine to have non-overlapping proof roots. It's the use case that needs to determine which root or roots are acceptable.

Voting may need a state operated root. You show your ID at the voting booth, after all.

Shopping does not, as a rule. I don't tend to show my ID at the checkout.

The big issue I see with most proposals is that they treat all identification issues as the same, and as the initial root proof.

Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.