- From: Shane McCarron <shane@spec-ops.io>
- Date: Wed, 10 Aug 2016 10:02:08 -0500
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAJdbnOD0hUHO4RtOya6AouU1B7YwJ-n5gnQLc7pQDUW1MzNpPQ@mail.gmail.com>
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. 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> 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> 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 >> > -- Shane McCarron Projects Manager, Spec-Ops
Received on Wednesday, 10 August 2016 15:03:05 UTC