- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Wed, 10 Aug 2016 12:30:55 +0000
- To: Shane McCarron <shane@spec-ops.io>
- Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAM1Sok31YLvz14QAa96qjGzqVji3=bdOQEB1VnMvMGG-RZfxsA@mail.gmail.com>
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