W3C home > Mailing lists > Public > public-credentials@w3.org > March 2016

Re: Proposed VC Use Case: Consignment of Claims

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Thu, 03 Mar 2016 14:47:59 +0000
Message-ID: <CAM1Sok2dTRcS0RMExakrqJK5FJ93jjh6xRyUGQ90oZ8-eif4ww@mail.gmail.com>
To: Eric Korb <eric.korb@accreditrust.com>
Cc: Credentials Community Group <public-credentials@w3.org>
On Fri, 4 Mar 2016 at 01:36 Eric Korb <eric.korb@accreditrust.com> wrote:

> I consign my right to life for your exclusive economic benefit.
>
>
> Not the intent.
>
> didn't think it was.


> Think of this this more as tokens - I need to consign this token to you
> for you to act on my behalf.  The trick is not to have to go back to the
> original Issuer of Holder's credential for another credential, but rather
> verify a chain of trust.
>
> their credentials, not tokens. They should be meaningful and design needs
to take that into consideration.

Identity statements are very important.  Design somewhat mandates
verification of a related credential, as to verify 'chain of trust' as far
as i'm aware; yet therein,

from a standards point of view...

HTML is used to create terrible websites alongside very good ones, ones
that people depend upon.  that's not the standard, that's how people use
it.  Yet, perhaps ontology design is an important counterpart.

WebID for instance is fairly specific when it refers to ontologies and even
serialisation formats: https://www.w3.org/wiki/WebID

IMHO amongst the challenges is defining means to support industrial
development of sameAs as is asserted by way of a verifiable document format.


> In the first scenario case the credential claim is a drug prescription,
> which is linked to the pharmacy, doctor and patient.  The patient is
> asserting that only his caretaker can go to a specific pharmacy pick it up
> on his behalf.  The pharmacy should be the only entity which can consume
> this credential for the specific purpose the patient has asserted.
>
> I can see several ways in which this may be done.  Examples include
disability car-permits, where the disabled person doesn't drive the car.
Yet, it is the authority who is able to relate a plurality of assertions.
amongst the questions is how they're asserted on a symmetrical or
a-symmetrical basis.

Another one that's well considered is the 'after death' concept; so,
someone dies, what happens with their data?

I have a contact who's very good within the domain of that specified
field.  It may be a good use-case to examine the types of issues your
considering.  it also has a plurality of end-points which makes it somewhat
better than the prescription use-case, whilst describing the same type of
conditions statements.


> Please feel free to re-write if you have better words.
>
> it's a contribution matrix.  I think we both contribute.  It's always a
humbling experience, but be assured, no matter my flaws, i do, do my best,
in good faith, et.al.  I think their shared values ;)


> Eric
> <https://mail.google.com/>
>
> Tim.H.


> On Thu, Mar 3, 2016 at 9:24 AM, Timothy Holborn <timothy.holborn@gmail.com
> > wrote:
>
>> I consign my right to life for your exclusive economic benefit.
>>
>> What's wrong with that statement and how will the standard protect the
>> shared-values incumbent within the concept of that statement, particularly
>> where it is stated in a less clear manner.
>>
>> Equally; an agent should be able to issue a credential to another entity
>> for specified purpose, yet, this appears to be more of an ontological issue
>> than anything else.
>>
>> If the spec supports modular capabilities then it is the same as if the
>> birth certificate is issued by the relevant entity who in-turn contributes
>> towards the claim that says a person has a drivers license, rather than the
>> drivers license being the authority for both claims.
>>
>> Is that right?
>>
>> Tim.H.
>>
>> On Fri, 4 Mar 2016 at 01:12 Eric Korb <eric.korb@accreditrust.com> wrote:
>>
>>> A.6 Consignment of Claims
>>>
>>> A.6.1 Holder Consigns Their Claim to Another Trusted Entity
>>>
>>> -----------------
>>> Requirement
>>> -----------------
>>> Credential holder will want to consign a claim to a trusted entity so
>>> the trusted entity can act on the holder’s behalf for a specific use.
>>>
>>> --------------
>>> Motivation
>>> --------------
>>> There are times when a credential holder will want or need to consign a
>>> claim to trusted entity.  This will include retrieving the claims about
>>> holder and their relationship with the trusted entity.
>>>
>>> --------------
>>> Importance
>>> --------------
>>> Useful
>>>
>>> -------------
>>> Scenarios
>>> -------------
>>> John is incapacitated, so he asks Sally, his trusted caretaker, to
>>> purchase a drug prescription on his behalf at Downer’s Pharmacy.  John
>>> consigns his issued prescription credential to Sally, which can only be
>>> verified at Downer’s Pharmacy.  When Sally is asked for proof of identity
>>> at the point-of-sale, Sally provides the consigned credential and her own
>>> identification credential referenced in the consigned credential.  Downer’s
>>> pharmacy address credential is also referenced in the consigned credential
>>> to ensure that the can only be verified at that specific pharmacy.
>>>
>>> Mary is applying to Baker University to achieve a master's degree in
>>> Culinary Arts.  Mary must supply an official transcript representing her BA
>>> in Culinary Arts issued by The College of Inspired Cooking.  The College
>>> issues a Degree credential to Mary that authorizes her one-time access to
>>> the College’s student information system to retrieve her official
>>> eTranscript.  Mary consigns the Degree credential to the Baker University
>>> HR system, which can act on behalf of Mary to retrieve the official
>>> transcript.
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *"Trust only credentials that are TrueCred*™ *verified."*
>>> ------------------------------------------------------------------------
>>>
>>> *Eric R. Korb | Chief Executive Officer*
>>>
>>> <https://mail.google.com/>
>>>
>>
>
Received on Thursday, 3 March 2016 14:48:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 March 2016 14:48:38 UTC