- From: David Chadwick <d.w.chadwick@kent.ac.uk>
- Date: Wed, 10 Aug 2016 16:45:01 +0100
- To: Shane McCarron <shane@spec-ops.io>, Timothy Holborn <timothy.holborn@gmail.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
On 10/08/2016 16:02, Shane McCarron wrote: > I will try. I wanted to expand on something I said earlier though: If > you are concerned about the keeping sensitive information private, > Verifiable Claims is not for you. Any information, once shared, is > revealed. You can express your intent with regard to the use of the > information. You can express your desires on how long the data should be > around or with whom it can be shared, but you cannot enforce it. The > value proposition for Verifiable Claims is the "V" part. That an > inspector can be 100% confident in something you claim (assuming the > issuer is in the inspector's trust chain somewhere). > > What we started debating here was about what privacy-enhancing means. > What I should have said earlier was that the Working Group will define > exactly what that means. Excellent. This is one of the things that I was originally requesting. So returning to this thread and your original proposition for a definition: > privacy-enhancing is 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. Three comments on this: i) Specific processors will presumably be controlled by the user sending the VC to the chosen inspector, so this is quite straightforward ii) We currently do not say anything about specific periods of time as far as I am aware, so there is a mismatch here between your definition and the model iii) I would like to add to the end of your proposal 'and ensure that the credentials do not contain correlating identifiers' (notice that I specifically said credential rather than claim in this respect) regards David > Part of the job of a formal activity like this > is to balance the needs of users with technological capabilities. We > should not presuppose any solution. That was my bad. > > So, getting back to the core discussion... Our use cases [1] imply a > lot of core functionality. Decomposability is NOT actually implied in > there. I just re-read the document. Composability IS implied. And all > that means is that, given a collection of claims (at whatever level of > granularity) I as a holder MUST be able to group together some of these, > express my intent about how they should be used, and sign the group. > Let's call this a "credential". > > Once that credential exists, I can pass that to an inspector. The > inspector then presumably knows whatever they needed to know, and they > can verify the individual claims that make up the credential I sent to > them. > > Ideally, when I am issued a digital claim, it is a collection of VERY > FINELY GRAINED claims, each of which was signed by the issuer. Then I > have the ability to create my credential in exactly the way I want. > > I suppose it is possible that there will be issuers who will not do > this. They will issue a big claim to me. The US State Department could > issue a digital passport that contained ALL of the relevant information > (including an embedded PNG of my face and a link to some magic > blockchain thing onto which all of my passport transactions would be > written). In that case, I would probably only choose to share that with > governments. I wouldn't use it at the liquor store. > > But I digress. I will go play in the playground and see if can do what > you have asked. I will try to start from examples in our data model > document [2] and go from there. > > [1] http://w3c.github.io/webpayments-ig/VCTF/use-cases/ > [2] http://www.opencreds.org/specs/source/claims-data-model/ > > > > On Wed, Aug 10, 2016 at 7:30 AM, Timothy Holborn > <timothy.holborn@gmail.com <mailto:timothy.holborn@gmail.com>> wrote: > > 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 > <mailto:shane@spec-ops.io>> wrote: > > Notes inline: > > On Tue, Aug 9, 2016 at 7:56 AM, Timothy Holborn > <timothy.holborn@gmail.com <mailto: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 <mailto: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 > <mailto: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 <mailto: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 > <mailto: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 > <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 > <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 > > > > > -- > Shane McCarron > Projects Manager, Spec-Ops
Received on Wednesday, 10 August 2016 15:45:49 UTC