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

Re: Negative VCs

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sat, 24 Jun 2017 13:57:41 +0100
To: public-credentials@w3.org
Message-ID: <a2209f62-fe15-3ded-1d96-03ddaeef7645@kent.ac.uk>
Joe you are making a very big assumption in your message below that is
not always true, and this is that the inspector can know from viewing
the VC who the subject is (viz: "I might publicly post academic
credentials to my linkedin profile"). This might be true if the subject
has a globally unambiguous identifier that is publicly known to the
world (as in your LinkedIn case), but if the identifier in the VC is
some random number that is private to the subject, then what you say is
not true. You need to cater for this (more difficult) case as well. Once
you do, you will find that your (easier) case is covered by that
solution as well.



On 24/06/2017 00:42, Joe Andrieu wrote:
> I don't follow the need for ROLE_B to prove anything. Nothing in the
> data model provides any proofing for the holder/presenter/claimant. In
> many use cases the relationship of the claimant to the subject is
> immaterial or at least exogeneous to the claim.
> Consider that I might publicly post academic credentials to my linkedin
> profile and that a recruiter or potential boss includes those
> credentials in recommending to HR that I come in for an interview.  The
> credentials themselves hold the entirety of the verification required
> for the relying party/verifier/inspector, aka HR, to decide whether the
> credentials are valid.
> At no time does it matter whether or not the particular
> holder/claimant/presenter is authorized to provide the claim. 
> In the case of negative claims, I think this is even more true. If a
> background check on me finds verifiable claims that, e.g., I failed
> physics three times or had a crappy GPA, etc., the claim infrastructure
> doesn't care if the claimant is an authorized representative.
> Seems to me the important thing about the claimant isn't whatever rights
> they have or what they've been authorized to do, it is simply what they
> do: present a claim.  Whether or not presenting that claim is
> appropriate in the context in which it is presented is a completely
> different problem.
> -j
> On Fri, Jun 23, 2017, at 06:38 PM, David Chadwick 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.
>> regards
>> David
> --
> Joe Andrieu, PMP                                                        
>                      joe@legreq.com <mailto:joe@legreq.com>
> LEGENDARY REQUIREMENTS                                                  
>      +1(805)705-8651
> Do what matters.                                                        
>                    http://legreq.com <http://www.legendaryrequirements.com>
Received on Saturday, 24 June 2017 12:58:14 UTC

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