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

Re: Poll words split Role B

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Sun, 25 Jun 2017 19:06:15 +0100
To: public-credentials@w3.org
Message-ID: <606500bc-91c8-c6ca-2a49-f4dd5ba934a6@kent.ac.uk>

On 25/06/2017 18:33, Steven Rowat wrote:
> On 2017-06-25 2:37 AM, David Chadwick wrote:
>> 6. If the presenter is not the subject then the inspector needs to
>> verify that the presenter is authorised to present the claim. This can
>> be done in a variety of ways e.g. a pre-established trust relationship
>> between the inspector and presenter; a VC delegating authority from the
>> subject to the presenter; a recognised procedure for certain classes of
>> subject and presenter; etc.
> Am I right that:
> a) this is where the 'split' in Role B (in the poll) resides;
> (Presenter/subject or Claimant/Subject, etc.) ?

I think that presenter and claimant are two different roles. The
presenter is not trying to claim anything, but is merely providing
information to the inspector. An example could be a police officer
presenting a parking ticket (issued to some subject) to an inspector,
perhaps for the inspector to subsequently use when the subject contacts it.

I am not sure that we ought to cover the 'presenter' types of use cases
in the VC work, but rather should concentrate on the use cases where the
user is a claimant for a service from the inspector, and may or may not
be the subject of the VC.

Presenter use cases can be dealt with by inspectors in proprietary ways.
I dont think there is any need for standardisation in these cases.

> b) pseudo-anonymity would likely reside in: "a recognised procedure for
> certain classes of subject and presenter" ?
> With reference to a), the split roles in B, it seems that if, for
> example, the poll were to choose "Subject" as the word for Role B, then
> "Presenter" or "Claimant" could be added underneath in the code. But if
> "Claimant" or "Presenter" is chosen for role B, then it seems more
> problematic, or at least quite different.
> All those words are still available in the playground listing today,
> Sunday:
> https://docs.google.com/document/d/1NWdpFxbERXZodvbJP_GgGZhkGI54zWmqTuFz-CR2hps/edit
> Specifically, I mean that people are adding words as options for Role B
> that are actually both sides of the split. Shouldn't we just be choosing
> one side of the split, and know which side that is, in order to get the
> label for that side of the split correct?

I agree. I think the presenter side should be out of scope.


> It appears to me that the way it's set up now might force the technology
> solution to be different dependent on what word is chosen in the poll,
> and I don't think that's the purpose of the poll, though I could be wrong.
> And this could lead extra work later, disentangling and possibly re-naming.
> Steven
>> You seem to think that the VC verification model should stop at step 3.
>> I would argue that these steps are necessary but not sufficient for
>> verifying VCs. The VC verification process should comprise all steps
>> necessary for the inspector to determine whether to keep the VC or
>> discard it as untrustworthy.
>> regards
>> David
>>> Of course, if the subject is uncorrelatable through any means then the
>>> claim can't be tied to a specific entity, then the
>>> inspector/verifier/relying-party will have a hard time applying the
>>> claim.
>>> However, one could generate random pseudonymous unique identifiers and
>>> use those to collect a set of claims from various issuers, presenting
>>> the set of claims as a related set and the RP could correlate across
>>> those claims some relevant fact. For any given claim the subject appears
>>> random and private, but isn't in fact in the context the set of claims.
>>> Each of those claims are valid, even if useless in isolation.
>>> In the case of a truly noncorrelatable subject, i.e., the random unique
>>> number private to the subject, the claimant still doesn't *have* to
>>> prove anything for the claim to be valid. The claim, however, may be
>>> useless. Which is fine. Not all verified claims are going to be useful.
>>> But bearer claims exactly fit this use case. The bearer of this claim
>>> *is* the subject of the claim and due the privileges associated with the
>>> claim.
>>> We don't want to conflate the possibility of authenticating the claimant
>>> as the subject with it being an innate requirement of Verifiable Claims.
>>> Nor do we want to require some proof of rights or relationship between
>>> the claimant and subject. These are outside the scope of the claim
>>> itself. That's why I say that ROLE_B doesn't innately have to prove
>>> anything.
>>> The claim--including its means of verification such as checking for
>>> revocation--stands on its own. If we presume any relationship between
>>> the claimant and the subject we are baking in some serious limitations
>>> to verifiable claims and introducing exogenous verification of the
>>> relationship, which I think would be a mistake.
>>> Claimants present claims. That's simple. Authentication, delegation, and
>>> proving right to use, are external to the claim.
>>> There is one exception that I can see, where an issuer includes a TOS
>>> clause that explicitly affords the right to be a claimant to a specific
>>> entity--which may or may not be the subject. In fact, I think that's a
>>> fairly useful TOS: this claim only applicable when presented by the
>>> subject as authenticated by procedure X.  This is issue
>>> #48 https://github.com/w3c/vc-data-model/issues/48
>>> -j
>>> On Sat, Jun 24, 2017, at 08:57 AM, David Chadwick wrote:
>>>> 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.
>>>> regards
>>>> David
>>>> 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>
>>>>      <mailto:joe@legreq.com>
>>>>                    +1(805)705-8651
>>>>      Do what matters.
>>>>                                  http://legreq.com
>>>>      <http://www.legendaryrequirements.com>
>>> -- 
>>> Joe Andrieu, PMP
>>>                       joe@legreq.com <mailto:joe@legreq.com>
>>>       +1(805)705-8651
>>> Do what matters.
>>>                     http://legreq.com
>>> <http://www.legendaryrequirements.com>
Received on Sunday, 25 June 2017 18:06:50 UTC

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