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

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