W3C home > Mailing lists > Public > public-credentials@w3.org > September 2020

Re: Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocols

From: Adam Stallard <adam.stallard@gmail.com>
Date: Mon, 14 Sep 2020 10:11:32 -0700
Message-ID: <CAPKR6aqCUyf-zWmMNVjcVXv69WSJYbb3Dq82neSOMbZ7mU-wMw@mail.gmail.com>
To: daniel.hardman@evernym.com
Cc: email@yancy.lol, Melvin Carvalho <melvincarvalho@gmail.com>, Wayne Chang <wyc@fastmail.fm>, W3C Credentials CG <public-credentials@w3.org>
Daniel.Hardman,

Yes, and have you seen what UBIC is doing with e-passports?
https://github.com/UBIC-repo/Whitepaper#sybil-resistance . The question of
"who watches the watchers" still remains. We can't see what's going on
behind the walls of a centralized ID issuing organization or know whether
they are making sybils themselves.

--Adam

On Mon, Sep 14, 2020 at 10:00 AM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> There is a way to do one person one vote without losing anonymity. It uses
> a Sybil-resistant VC (e.g., a passport or driver's license that gets its
> Sybil resistance from some centralized system), but WITHOUT disclosing any
> strong correlator for the person in question; the verifier knows whether a
> person has already "voted" (or any similar once-per-person action) but need
> not know ANY other attribute of the person. Furthermore, the holder of the
> credential is fully aware that this technique is active, and can thus opt
> in or choose not to cooperate, if they prefer. Balance of powers. It was
> first described in a seminal paper "Clone Wars" paper by Jan Camenisch; for
> the less mathematically inclined, it was described at RWOT9, here
> <https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/zkp-safety.md#technique-2-prevent-link-secret-reuse>
> .
>
> On Thu, Sep 10, 2020 at 1:11 PM Adam Stallard <adam.stallard@gmail.com>
> wrote:
>
>> On Thu, Sep 10, 2020, 1:03 AM email@yancy.lol <email@yancy.lol> wrote:
>>
>>> I agree that a one-person-per-vote system is ideal, however it's hard
>>> map such a system to cyber space directly without a central authority.
>>
>>
>>
>> It's hard, but that's what we're doing. Instead of trusting a central
>> authority, users should trust an anti-sybil algorithm they can verify
>> themselves.
>>
>>
>> Consider how one-vote-per-cpu can allow a way to directly prove the
>>> number of identities (cpus).  For example we know some entity is 10 cpus
>>> because they solve x of the last y blocks.  There is no need to trust any
>>> authority, only the  solution.
>>>
>>> I think Git system might be the closest to one-person-per-vote where you
>>> can know about how many people contribute to the longest known chain of
>>> commits of a git repo (the trunk branch) aka the current consensus.  Of
>>> course this doesn't map directly for a number of reasons (people are not
>>> simple cpus for one).
>>>
>>> -Yancy
>>>
>>> On Wednesday, September 09, 2020 19:09 CEST, Adam Stallard <
>>> adam.stallard@gmail.com> wrote:
>>>
>>>
>>> Verifiable credentials can certainly help. At BrightID, we're working on
>>> way for a decentralized group of computer nodes that analyze an anonymous
>>> social graph and make determinations about uniqueness to collaborate to
>>> sign a credential for a user.
>>>
>>> These credentials also have a notion of "context" to avoid unwanted
>>> linkage between a user as they participate in various apps and networks. A
>>> user of app A should be able to prove they're using only one account there
>>> without linking that account to an account in app B.
>>>
>>> On Wed, Sep 9, 2020, 3:55 AM Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>> I think this was the important insight of the paper here.  And I wonder
>>>> if it can be solved with verifiable credentials?
>>>>
>>>> "If blockchains are to become a significant public infrastructure,
>>>> particularly in the space of civic engagement, then Proof of Work's
>>>> “one-CPU-one-vote” or Proof of Stake's “one-dollar-one-vote” systems will
>>>> not suffice: in order to enable democratic governance, protocols that
>>>> signal unique human identities to enable "one-person-one-vote" systems must
>>>> be created."
>>>>
>>>> On Wed, 9 Sep 2020 at 12:50, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>> PDF is here: https://arxiv.org/pdf/2008..05300.pdf
>>>>>
>>>>> Keywords: decentralized identity, Sybil-protection, crypto-governance
>>>>>
>>>>> Abstract.
>>>>>
>>>>> Most self-sovereign identity systems consist of strictly objective
>>>>> claims, cryptographically signed by trusted third party attestors. Lacking
>>>>> protocols in place to account for subjectivity, these systems do not form
>>>>> new sources of legitimacy that can address the central question concerning
>>>>> identity authentication: "Who verifies the verifier?". Instead, the
>>>>> legitimacy of claims is derived from traditional centralized institutions
>>>>> such as national ID issuers and KYC providers. Thisarchitecture has been
>>>>> employed, in part, to safeguard protocols from a vulnerability previously
>>>>> thought to be impossible to address in peer-to-peer systems: the Sybil
>>>>> attack, which refers to the abuse of an online system by creating many
>>>>> illegitimate virtual personas. Inspired by the progress in cryptocurrencies
>>>>> and blockchain technology, there has recently been a surge in networked
>>>>> protocols that make use of subjective inputs such as voting, vouching,and
>>>>> interpreting, to arrive at a decentralized and sybil-resistant consensus
>>>>> for identity. In this review, we will outline the approaches of these new
>>>>> and natively digital sources of authentication - their attributes,
>>>>> methodologies strengths, and weaknesses - and sketch out possible
>>>>> directions for future developments.
>>>>>
>>>>> On Wed, 9 Sep 2020 at 03:21, Wayne Chang <wyc@fastmail.fm> wrote:
>>>>>
>>>>>> link: https://arxiv.org/abs/2008.05300
>>>>>>
>>>>>> discussion from strangers on the internet:
>>>>>> https://news.ycombinator.com/item?id=24411076
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
Received on Monday, 14 September 2020 17:12:23 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:03 UTC