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

Re: Definition of claim

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Mon, 13 Jun 2016 12:21:45 +0000
Message-ID: <CAM1Sok13q-G=bOXeziCiJbEcPkY2gf8RanjQCt7XTFc5sNS0fg@mail.gmail.com>
To: David Chadwick <d.w.chadwick@kent.ac.uk>, public-credentials@w3.org
I'd say the issuer and the holder are both legal entities.  However, given
we've been fragmented away from the ID layer; we would surmise that the
Issuer has been able to be ID'd and that an ID will relate somehow to the
Holder, assuming i'm not going to be holding someone else's passport to
'pass off' as my own online.

the simple use-case of saying 'i am over 18' may otherwise be a bit like -
'here's my mums credit card for in-game gems'...  not what we want really
is it...

But beyond the problem of what is out of scope - what is in scope, and the
terms we use for what is in-scope should relate to the legal entity IMHO.

I also suggest it is important to ensure we have notated the use of a group
or chain of linked credentials in-our use-cases.  Only human actors are
really responsible for actions.  whether they do so for a company, bot, or
other 'thing' (understanding companies are legal entities whereas bots,
cars, fauna / flora would likely be considered property) a human is still
involved in making decisions.  they may do so by way of consensus or vote;
but it is still a group of humans involved in making decisions.

therefore; if the medical registration board agrees that subject
128846669247#237afPPdfG = Jane Doe who is issued a credential for
practicing medicine for the specific disciplines of general practice; and
thereby is also issued medical practitioner insurance plan for her
specified services under specified conditions; and through so doing any of
the following happens

1. someone uses her credentials to prescribe drugs that are later found to
have been prescribed fraudulently

2. treats a patient but fails to check for something that later causes a
medical crisis event

3. prescribes drugs that react badly with the patient (whether or not the
patient used the medication as prescribed)

4. is in attendance of a medical emergency outside of the scope of her
insured and approved registration (but may be able to immediately obtain
approval via an online / emergency services interaction);


5. Because we're not doing the ID system - if fraud happens it's not a
problem with the credentialing system, it's the ID system that someone else
made that's been bonded to this thing.

6. The chain of credentials that can develop may interoperate with, within
reason, any form of ID system as to support 'entity credentials' (or
whatever they'll be called) and no-one system needs to be the holder of all
relevant creds for the business system. (therein: use of linked-data)

In summary; I think the benefits of our designs really start to become
highlighted not in the singular document use-cases, but rather when a
plurality of documents are used in an interrelated manner across disparate
yet web-connected systems.

We have an ID/AUTH problem; Creds helps solve some of that by enabling the
3rd parties to make claims about person/s and/or things.  That's important
for solving the broader identity problem - but it is not the traditional,
blunt instrument approach - nor should we consider this work in the
specificity we've been asked to deliver, be considered a golden hammer for

yet; i note it seems there is a distinction between what we can promote to
the IG/WG vs. what we can 'play with' in the CG 'where the wild things

i'll say it again; Web-DHT seems like something that's got real merit for
utility in association with a social-distribution for ID/AUTH support of
humans; and other agents can hang off that capability.  I do think the
WebID group - we should seek to integrate it their, yet, i think we can
still do some 'visionary' incubation of the concepts prior to shipping it
off to a better home.

I think the two fields will interoperate.   Perhaps labelling the work as
'socially encrypted documents' (that in-turn could be used for ID/AUTH)
could mitigate any issues people have about religion and ID.


On Mon, 13 Jun 2016 at 17:59 David Chadwick <d.w.chadwick@kent.ac.uk> wrote:

> On 12/06/2016 22:13, Steven Rowat wrote:
> > On 6/12/16 1:32 PM, David Chadwick wrote:
> >> I believe the latest definition of claim in the architecture document
> >>
> >> http://w3c.github.io/webpayments-ig/VCTF/architecture/
> >>
> >> is fundamentally wrong. It says
> >>
> >> Claim
> >>     A statement made by an entity about a subject. For example: "Jane is
> >> a doctor."
> >>
> >> The example is not one claim, but two claims. It claims that the subject
> >> is a doctor and that the subject is called Jane. We should rewrite this
> >> to say
> >>
> >> Claim
> >>     A statement made by an entity about a holder. For example: "The
> >> holder is a doctor."
> >
> > +1
> > So, "The holder's name is Jane" is separate claim.
> >
> > Then, sorry to partially hijack your thread, but as an interesting
> > extension, I can relate this to my other concern about pseudonyms
> > (aliases), and make a third claim:
> >
> > "The holder has a pseudonym 'George'".
> >
> > This leads specifically to the interesting fact that the simple 'name'
> > of Jane is implied to be the 'legal name' (unless stated otherwise).
> >
> > So perhaps it would be best to always make that explicit. Otherwise it's
> > ambiguous -- what sort of name is it? Who calls Jane Jane?
> >
> > Claim: The holder has legal name 'Jane'.
> > Claim: The holder has pseudonym 'George'.
> This can be addressed in a couple of ways (at least)
> 1. Who is the issuer? If the issuer is a legal entity, this implies the
> name is a legal one, whereas if the issuer is the holder, it implies a
> pseudonym.
> 2. The attribute can be subclassed so that the holder/issuer can decide
> to issue either a generic name claim, or a specialised name claim (such
> as pseudonym, legal name etc.)
> regards
> David
> > Claim: The holder is a doctor.
> >
> > Steven
> >
> >>
> >>
> >> regards
> >>
> >> David
> >>
> >>
> >>
> >>
> >
> >
Received on Monday, 13 June 2016 12:22:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:53 UTC