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

Re: Revised Verifiable Claims WG Charter (RC-2) (was Re: Problem statement)

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Wed, 10 Aug 2016 12:30:55 +0000
Message-ID: <CAM1Sok31YLvz14QAa96qjGzqVji3=bdOQEB1VnMvMGG-RZfxsA@mail.gmail.com>
To: Shane McCarron <shane@spec-ops.io>
Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Credentials Community Group <public-credentials@w3.org>
So, here's an example[1] generated using JSON-LD playground [2].

can you give me an example of what you are talking about, so i can see we
are on the same page?

Tim.H.

[1] http://tinyurl.com/hdyxcqe
[2] http://json-ld.org/

On Wed, 10 Aug 2016 at 00:46 Shane McCarron <shane@spec-ops.io> wrote:

> Notes inline:
>
> On Tue, Aug 9, 2016 at 7:56 AM, Timothy Holborn <timothy.holborn@gmail.com
> > wrote:
>
>> Perhaps i'm wrong, but if the claims are issued as separate documents
>> with independent signatures for each claim; then the resulting use has
>> quite different qualities to a single document with multiple claims.
>> Therein, the document with the signature needs to be presented and all the
>> claims in that document are combined with the signature.
>>
> Well - I didn't say they were separate documents.  But if there are
> multiple claims in a single credential, then those MUST be decomposable.
> So they must be individually signed by the issuer.  There can ALSO be an
> overall signature on the entire collection that verifies it was issued as a
> block, but that's not that's for you as the holder - not for the processor..
>
>> A credential is in-turn, a document with http-signatures, and embedded
>> linked data.
>>
>
> Sure
>
>> This in-turn could also be used to make other declarations, such as
>> creative-commons, or other means to support restricted use requests.
>>
> I think we have not really explored how restricted use might be
> implemented.  I am not an expert on such things, but (for example) signing
> a claim in a way that if the validity is checked by dereferencing the link
> to the signer that reference is only available until a time certain is one
> way to implement it.
>
>
>> Regardless of what's in the document, once it's been processed by the
>> recipient, the data has been received and can be stored.
>>
>
> Of course.  What we are attempting is to improve the privacy and the
> verifiability.  So a claim can only be VERIFIED by verifying the signature
> and checking the associated URI.  An ephemeral URI is one way to limit that
> verifiability in time.  Limiting it to specific participants is just a
> matter of encrypting with the various participants.
>
> The data itself can't really be protected.  That's why it is so important
> that it be decomposable. That way a holder can only disclose the minimum
> information.
>
>
>> Are we agreeing or did I miss something?
>>
>> Tim.h.
>>
>> On Tue, 9 Aug 2016, 10:19 PM Shane McCarron <shane@spec-ops.io> wrote:
>>
>>> Hmm... actually, I don't think so.  I think that claims should be the
>>> smallest grain possible.  An *identity* credential issued by a government
>>> could have many many claims in it.  The subject is:
>>>
>>>    - A citizen of this country
>>>    - A citizen of this state
>>>    - A citizen of this county
>>>    - Living at an address xxx (or at least receives mail there)
>>>    - Over 18
>>>    - Over 21
>>>    - Has a birthdate of x
>>>    - Is authorized to operate a motor vehicle
>>>    - etc...
>>>
>>> Each of these is a distinct claim.  The privacy enhancement comes from,
>>> in part, the holder being able to readily select which claim(s) are being
>>> shared on an as needed basis, as well as with whom they are shared and for
>>> how long.
>>>
>>> When I am shopping for wine, all they need to know is that I am over
>>> 21.  Not my name nor my address. When I go to pay using my mobile device,
>>> their mobile device reader asks me for proof of age.  My claim curator
>>> service on my mobile device shows *me* a list of claims that I can use.  I
>>> select one and it is shared with the requesting device (the claim
>>> processor) for a very limited period of time.  Green light comes on.  I
>>> take my wine and leave.
>>>
>>> There are obviously many many other use models, but they all boil down
>>> to the holder being in control of sharing the least amount of information
>>> possible, in a verifiable manner, with the least number of processors, for
>>> the least amount of time.  That's privacy-enhancing.
>>>
>>> On Mon, Aug 8, 2016 at 9:02 PM, Timothy Holborn <
>>> timothy.holborn@gmail.com> wrote:
>>>
>>>> I think it's more complex and can relate to the means in which a
>>>> credential is formed.
>>>>
>>>> a credential could, for instance, have an array of counterparts.
>>>>  thereby supporting both a claim relating to a birthdate in addition to
>>>> independently supporting a claim that simply states 'over 18' without
>>>> necessarily declaring the birthdate.
>>>>
>>>> anything with a birth-date would also presumably support some sort of
>>>> 'name' and other identity information.  whether these sorts of datapoints
>>>> are required for various use-cases, ie: access to an adult website - really
>>>> depends on the construction - yet also, is it not important for us to
>>>> figure that out as a counterpart of what we're putting forward?
>>>>
>>>> Tim.H.
>>>>
>>>> On Tue, 9 Aug 2016 at 11:51 Shane McCarron <shane@spec-ops.io> wrote:
>>>>
>>>>> FWIW I interpret privacy-enhancing as the ability for holders and
>>>>> subjects of a claim to limit the verifiable exposure of information from
>>>>> the claim to specific processors and for specific periods of time.  Or
>>>>> something to that effect.
>>>>>
>>>>> On Sun, Aug 7, 2016 at 3:57 PM, David Chadwick <
>>>>> d.w.chadwick@kent.ac.uk> wrote:
>>>>>
>>>>>> Hi Manu
>>>>>>
>>>>>> A couple of comments on the latest version
>>>>>>
>>>>>> i) The first sentence could be formulated more precisely, as
>>>>>> self-sovereign refers to credentials and not to standards. Similar
>>>>>> comment applies tor privacy-enhancing. Therefore the following is more
>>>>>> correct:
>>>>>>
>>>>>> There is currently no standard for expressing and transacting
>>>>>> self-sovereign and privacy-enhancing verifiable claims (aka:
>>>>>> credentials, attestations) via the Web.
>>>>>>
>>>>>> ii) in 3.1 you ought to define what you mean by privacy-enhancing
>>>>>> (regardless of the resolution of i) above). You have already defined
>>>>>> self-sovereign
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06/08/2016 17:47, Manu Sporny wrote:
>>>>>> > On 08/02/2016 12:24 PM, David Chadwick wrote:
>>>>>> >> How about changing the first sentence of the problem statement
>>>>>> >
>>>>>> > Based on Wendy Seltzer and Microsoft's feedback, as well as the
>>>>>> > resulting feedback from the VCTF and CCG, the charter text has been
>>>>>> > changed to reflect the consensus we have built as well as address
>>>>>> the
>>>>>> > concerns raised to date. Remember that we're not looking for the
>>>>>> perfect
>>>>>> > charter, but one that all of us can live with.
>>>>>> >
>>>>>> > The new charter can be found here:
>>>>>> >
>>>>>> > http://w3c.github.io/webpayments-ig/VCTF/charter/rc-2.html
>>>>>> >
>>>>>> > with a diff-marked copy here:
>>>>>> >
>>>>>> > http://w3c.github.io/webpayments-ig/VCTF/charter/rc-2-diff.html
>>>>>> >
>>>>>> > I suggest you look at the latter link if you're only interested in
>>>>>> the
>>>>>> > changes from the previous draft charter.
>>>>>> >
>>>>>> > -- manu
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Shane McCarron
>>>>> Projects Manager, Spec-Ops
>>>>>
>>>>
>>>
>>>
>>> --
>>> Shane McCarron
>>> Projects Manager, Spec-Ops
>>>
>>
>
>
> --
> Shane McCarron
> Projects Manager, Spec-Ops
>
Received on Wednesday, 10 August 2016 12:31:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:42 UTC