W3C home > Mailing lists > Public > public-credentials@w3.org > June 2017

Re: Negative VCs

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Wed, 28 Jun 2017 11:02:19 +0100
To: public-credentials@w3.org
Message-ID: <86d1c790-faf5-361a-ecb2-aedabcadb7c4@kent.ac.uk>

On 27/06/2017 16:30, Adam Lake wrote:
> On 6/26/2017 7:59 PM, Melvin Carvalho wrote:
>> On 24 June 2017 at 00:38, David Chadwick <D.W.Chadwick@kent.ac.uk
>> <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>>     I think that most of us have been assuming that VCs are always
>>     positive
>>     and confer some benefit on the subject. Common examples used by us
>>     have
>>     been passport, credit card, club membership etc.
>>     But what about negative VCs, such as a criminal record, 'points'
>>     on your
>>     driving licence, or failure to pay a bill on time etc. Subjects are
>>     going to be reluctant to present these to verifiers, especially if
>>     this
>>     would remove any benefit that they were hoping to obtain from the
>>     verifier's online service. In this case the VCs might be presented by
>>     someone other than the subject of the VC, and by someone not
>>     wishing to
>>     represent the subject of the VC.
>>     For this reason I would support the following alternative wording
>>     in the
>>     Terminology Playground
>>     ROLE_B is typically the Subject of Claims. In some circumstances,
>>     where
>>     the ROLE_B is not the Subject of the Claim, then ROLE_B must be
>>     able to
>>     prove that they are 'authorised to provide the claim'. This is a
>>     preferrable alternative to 'has the authority to represent the Subject
>>     of the Claims', as it covers the latter case as well as a third party
>>     providing negative VCs to a verifier.
>> I think you've hit upon an incredibly interesting use case.
>> One issue with centralized claims is that claims of a negative nature
>> can be a point of failure when, say, the domain owner comes into
>> conflict with the person who the claims about. 
>> For this reason businesses normally do not allow negative claims to be
>> made to reduce that point of failure.
>> However, there's another mode of the web where the claim can be
>> independent of any central website or URL, just as, when the contents
>> of a file is independent of that file itself. 
>> I think it's a really important use case and I have in our community
>> heard many calls for such a system to emerge, but yet, we have not to
>> date been able to solve such a use case effectively, at least in web
>> 1.0 and web 2.0 type offerings.
>> I'm optimistic that web technologies can deliver claims of any kind
>> which become the ownership of the author, rather than, the publisher. 
>> I honestly think the web is screaming out for this as one of the most
>> important use cases yet to be addressed. 
>> In our reputation community we have explored this quite a bit, and the
>> issue becomes one of sock puppets flooding the eco system with
>> negative claims ... the question remains as to how to analyses a web
>> of claims and get the signal from the noise.  From experience, what
>> seems to be the case is that most actors are genuine, but a few try to
>> game the system.  It seems something of an arms race.  I really look
>> forward to innovation in this space, and one someone gets the ball
>> rolling I think decentralized claims of this kind could be popular in
>> a very viral way ...
> It seems to me that claims are verifiable free speech. We all have the
> freedom to say anything about anyone else, short of defamation. How we
> get the signal from the noise is each person defining their own web of
> trusted issuers through which level of trust per claim can be derived.

this is a fundamental component of the model.

> Can't a flood of negative claims be disregarded as noise?

It is totally up to the relying party to decide, based on his trust rules


> Adam
>>     regards
>>     David
> -- 
> Adam Lake
> Business Development Lead
> Digital Bazaar
Received on Wednesday, 28 June 2017 10:02:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:39 UTC