From iain.henderson at mydex.org Wed Feb 4 03:40:29 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Wed, 4 Feb 2009 11:40:29 +0000 Subject: [Sig-vpi] Notes from Last Call/ Update to Materials Message-ID: <331BF846-E03E-46CB-90E1-014C284CBC20@mydex.org> Folks, After last week's call on technologies relevant to VPI, and after a few one to one calls with some of you, i've updated the table and converted it into a spreadsheet (attached) for ease of use. On this weeks call (Thursday 5th), i'd like to carry on discussing and building out this table, adding any further technologies we think may be relevant, and refining our understanding of the requirements. Feel free to comment back by e-mail if you can't make the call - after this week I plan to start talking to the experts in each technology to understand precisely how each would meet our requirements, what is available right now/ planned, and what gaps remain. Call details are below. Also, see the link below for an initial blog post I did about VPI on the blog of Olswangs (www.olswang.com), the law firm giving us some of their time to sense check and build out the legal/ policy side of VPI. http://datonomy.blogspot.com/2009/02/promise-of-volunteered-personal.html Teleconference Schedule: Every second Thursday (next call Thursday 5th Feb 09) 09:00am-10:00am PST, 12:00 -13:00 EST, 17.00-18.00 UK, 18.00-19.00 CET; Dial In: US toll-free number: 866-469-3239 US toll number: 650-429-3300 SIG Meeting Number or Access Code: 78701111# Talk to you tomorrow. Iain Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VPI Technology Options Draft 0.2.xls Type: application/vnd.ms-excel Size: 26624 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Mon Feb 16 06:04:59 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Mon, 16 Feb 2009 14:04:59 +0000 Subject: [Sig-vpi] Notes from Last Call/ Agenda and Items for this Week's Call Message-ID: Folks, I've been trying to figure out how to load up a spreadsheet to the wiki with no luck, so i'll e-mail it out for now. This sheet is the summary of what we have discussed on the last two calls - i.e. the technologies that might play a role in supporting the different stages of the VPI sharing scenario and who we might talk to in order to validate this view. I don't think this is yet the finished article, but it will do for now and i'll now start to contact the various technology leads we have identified to validate/ challenge/ build out our understanding of the role of each technology in enabling VPI sharing. I'll write a short white paper introducing the subject before sending along with the sheet to the tech experts. The main addition from last weeks call was from Joe in flagging that the Search Maps he has been working on are a good instance/ illustration of VPI. The group agreed to move on to discuss the design of the VPI sharing contracts, Iain will circulate a draft, base level contract for discussion on the call this week. We also agreed to reach out to Scott Blackmer, Daniel Perry, Mary Rundle and other legal experts on the various VRM/ identity lists to seek to engage their interest in this project. We have a call due for this Thursday, details below and at http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG#Meetings Teleconference Schedule: Every second Thursday (next call Thursday 19th Feb 09) 09:00am-10:00am PST, 12:00 -13:00 EST, 17.00-18.00 UK, 18.00-19.00 CET; Dial In: US toll-free number: 866-469-3239 US toll number: 650-429-3300 SIG Meeting Number or Access Code: 78701111# In this call, we'll kick off with a discussion led by Joni Brennan on the migration path towards 'New Org', the planned development of Liberty Alliance from April this year. One other point of note, it looks like we'll have a VRM face to face event on West Coast on 15th & 16th May, just prior to IIW which begins on 18th. I'd like to have a VPI face to face working session for at least half a day sometime over that period, could those of you likely to be able to attend e-mail me and let me know your availability - i'll probably be over that way from 14th till 21st May. Cheers Iain Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VPI Technology Options Draft 0.2.xls Type: application/vnd.ms-excel Size: 27136 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Wed Feb 18 12:07:07 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Wed, 18 Feb 2009 20:07:07 +0000 Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 Message-ID: Folks, As discussed, here is a draft of one potential shape of a VPI sharing agreement; this is as much to kick off the discussion as it is a specific view on how things will end up - not least because they will be web deployed rather than a Word document. The principles I have deployed in this design are: 1) The main break from business as usual is that in this scenario, the organisation is signing the individuals terms and conditions prior to VPI being shared. 2) It is underpinned by 8 standard privacy/ data protection principles as deployed is EU, Canada, Australasia and others; it thus has a grounding in existing legislation - meaning that organisations are being asked to contract to things they should be doing anyway. 3) It is enhanced by 4 VRM principles which raise the bar over straight legislation - as befits the higher value and sensitivity around Volunteered Personal Information. 4) Some of the contractual issues relate only to VPI, others are more general and relate to all personal data shared with an organisation. 5) The agreement has three levels: - top level, 'this organisation is VPI enabled' - mid level, 'this organisation confirms contractually that they are operating at or above the minimum level set in the 12 compliance statements' - detailed level, 'this organisation contracts with this individual to this specific combination of data attributes shared and these uses to which they will be put (this detailed level has still to be designed but is do-able, albeit with considerable effort) 6) The agreement and its component parts have associated icons that will be as per Creative Commons, machine readable, lawyer readable and person readable, each having the same underlying effect. 7) The design enables audit and compliance capabilities to sit behind it, and a VPI trust mark to be deployed. Lots of discussion to be had around this obviously - see you on the call tomorrow. For those who can't make the call, by all means feed back to the group via e-mail. Cheers Iain -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft VPI Sharing Agreement 0.1.doc Type: application/msword Size: 156672 bytes Desc: not available URL: -------------- next part -------------- Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. From paulmadsen at rogers.com Thu Feb 19 07:35:24 2009 From: paulmadsen at rogers.com (Paul Madsen) Date: Thu, 19 Feb 2009 10:35:24 -0500 Subject: [Sig-vpi] Comments on spreadsheet of possible VPI technologies Message-ID: <499D7C3C.20101@rogers.com> Hi Iain et al, some comments on the latest spreadsheet listing VPI requirements against possibly relevant technologies 1) For the 'minimal disclosure' requirement, ID WSF allows a requestor to pose queries against the attributes, rather than directly ask for the raw data. For instance, "is the user within 2 km of my store?" rather than "where is the user?" Separately, this requirement seems a bit too broad, i.e. is it a privacy thing or something more general? 2) The 'enforcement and audit' requirement lists cards, Higgins, XDI, and ID-WSF as relevant. ID-WSF has a (somewhat inactive) spec for event reporting that could be used to support audit. Have the other technologies been verified to have something similar? 3) I'd argue that all current identity technologies support personas, albeit to varying degrees and through different manifestations. (i.e. where persona selection occurs) 4) There are a number (the same as for audit) of technologies listed against the 'termination' requirement. To me this implies that these protocols/technologies would support 'active' mechanisms for terminating the VPI contract. I. I'd expect XDI to do this, but there is nothing in ID-WSF to support (nor, AFAIK, in cards). 5) I cant think how ID- WSF would support the 'raise a flag' requirement ... I'd suggest that XRD (as an example of a passive metadata format) would be relevant here 6) Whether OpenID is listed as relevant against a requirement or not seems a bit random. AFAIK, OpenID has the same level of (active) support for audit as cards ... 7) OAuth? regards paul -- Paul Madsen e:paulmadsen @ ntt-at.com p:613-482-0432 m:613-282-8647 web:connectid.blogspot.com ConnectID -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gMwy.1.gif Type: image/gif Size: 10313 bytes Desc: not available URL: From iain.henderson at mydex.org Thu Feb 19 08:36:13 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Thu, 19 Feb 2009 16:36:13 +0000 Subject: [Sig-vpi] Comments on spreadsheet of possible VPI technologies In-Reply-To: <499D7C3C.20101@rogers.com> References: <499D7C3C.20101@rogers.com> Message-ID: <8059B677-34FB-49FD-B19D-190F42D8ACF1@mydex.org> Thanks Paul, good to hear from you - as you'll have noticed we had put your name down as someone we should look to speak to confirm/ build out our understanding of how ID WSF and related protocols might support our requirements. I've taken a quick stab at answering your queries inline, but would it be possible to arrange some time to talk through the requirements in more detail by phone? I'll also tell you about the airline that is interested in deploying your old British Airways magazine scenario from 18 months back!!!! Cheers Iain On 19 Feb 2009, at 15:35, Paul Madsen wrote: > Hi Iain et al, some comments on the latest spreadsheet listing VPI > requirements against possibly relevant technologies > > 1) For the 'minimal disclosure' requirement, ID WSF allows a > requestor to pose queries against the attributes, rather than > directly ask for the raw data. For instance, "is the user within 2 > km of my store?" rather than "where is the user?" That's good and helpful thanks. As an aside, in the Mydex social enterprise we have recently built a VRM proof of concept with a spec similar to the VPI requirements. In that build we included a ID WSF component, built by Asa Hardcastle (as well as some XRI and managed Information Cards). In short, we were impressed by the ID WSF capability, but as mainly non-techies, find the specification of what it does/ does not do pretty much impossible to track down at a level where we could decide to build out that capability. I've looked in lots of places for a clear spec, but have not yet found one at the level we need - could you point us towards what you regard as the best overview of the functional specification? > > > Separately, this requirement seems a bit too broad, i.e. is it a > privacy thing or something more general? Yes, it is quite broad at this stage - it is a privacy thing in the sense that we look to enable the individual to share only what they have to and no more. > > > 2) The 'enforcement and audit' requirement lists cards, Higgins, > XDI, and ID-WSF as relevant. ID-WSF has a (somewhat inactive) spec > for event reporting that could be used to support audit. Have the > other technologies been verified to have something similar? At this stage, we've not got as far as verifying what a technology does/ does not do. But we need to and intend to over time. As noted above, I want to get to the stage where I know what it would cost to build to that spec (at lower levels of detail), who would build it and how long would it take. > > > 3) I'd argue that all current identity technologies support > personas, albeit to varying degrees and through different > manifestations. (i.e. where persona selection occurs) Yes, I suspect you are right; maybe I need to re-frame the requirement to say which technologies make it easy to deal with complex persona scenario's (or lose the requirement and assume they all do). Where we wish to get to is to readily enable the individual to switch between the various persona in their life (husband, father, Director, anonymous etc) without the process being to painful and without any loss in functionality. > > > 4) There are a number (the same as for audit) of technologies listed > against the 'termination' requirement. To me this implies that > these protocols/technologies would support 'active' mechanisms for > terminating the VPI contract. I. I'd expect XDI to do this, but > there is nothing in ID-WSF to support (nor, AFAIK, in cards). Noted thanks. > > > 5) I cant think how ID- WSF would support the 'raise a flag' > requirement ... I'd suggest that XRD (as an example of a passive > metadata format) would be relevant here Noted thanks, yes I think we will inevitably end up with combinations of technologies that work in harmony (hopefully without too much pain/ overhead involved). > > > 6) Whether OpenID is listed as relevant against a requirement or not > seems a bit random. AFAIK, OpenID has the same level of (active) > support for audit as cards ... Yes, we need more detailed involvement/ review of Open ID. > > > 7) OAuth? Yes, we need to dig into OAuth and add to the list. > > > regards > > paul > -- > Paul Madsen > e:paulmadsen @ ntt-at.com > p:613-482-0432 > m:613-282-8647 > web:connectid.blogspot.com > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. From joe at switchbook.com Thu Feb 19 08:50:51 2009 From: joe at switchbook.com (Joe Andrieu) Date: Thu, 19 Feb 2009 08:50:51 -0800 Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 In-Reply-To: References: Message-ID: <001b01c992b2$3b25b250$b17116f0$@com> Iain, This is a great starting point. It lays out several potential requirements for data management and suggests an initial verbal framework. Which is enough to dive in and start thinking about the problem. So, with a constructive intent, let me dive into the details. First, it didn't seem that the structure matched the goals very clearly. You mention two types of data transactions: ongoing or one-off. But I didn't see any specifics as to the contractual obligations that differ between those two. For example, a one-off situation should have specifics around the duration of the authorized use of that data. It seems that a standard contract should outline how those two would be handled, then also specify which of those two applies for the data to be shared. Also, the "three levels" you discuss in your email aren't apparent in the structure of the agreement. If I understand the three levels, in my own terms: 1. The company has agreed to standard terms regarding VP data (generation, use, deletion) 2. The company asserts they've been compliant for 12 months 3. For this particular data, the company agrees to these specific terms But I don't see that structure in the agreement. Turning to content, I might suggest some different approaches. First, I don't think that requiring the last 12 months is reasonable. It presents a serious bootstrapping problem, where no company can use this agreement until 12 months into being fully VPI compliant. I'm guessing that the 12 month bit is chasing after a different, specific goal. Let's identify that and find a way that avoids this bootstrapping issue. Second, I feel strongly that simply allowing companies to state their policy is insufficient. Disclosure of bad behavior doesn't make it good behavior. I think part of our work is going to be figuring out what is "good" behavior, what is "allowed" behavior, and what is "bad" behavior. That is, we need to outline policy requirements, not just require that policies are clearly articulated. Then, within those requirements, we need to be flexible for different use cases and different business needs, in the same way Creative Commons attempts to boil down the handful of typical use profiles so that authors can pick and choose what is appropriate. Similarly, users and vendors should be able to pick and choose a handful of "approved" usage patterns that make sense. For example, a quid-pro-quo around retention of search history (for search quality improvement efforts) in exchange for improved search results. The retention profile in that case is different than in "one night stand" one-off transactions with unrelated vendors. In particular the section on onward consent is far too weak. "active consent is sought prior to sharing". Sought? That just means they made some effort to ask you. It has no requirement that they actually /listen/ to your consent. For personal data I'm putting into the cloud, I require much greater control and specific limits on what will actually be done with it, not just disclosure of what is happening. -j -- Joe Andrieu SwitchBook http://www.switchbook.com joe at switchbook.com +1 (805) 705-8651 > -----Original Message----- > From: sig-vpi-bounces at lists.projectliberty.org [mailto:sig-vpi- > bounces at lists.projectliberty.org] On Behalf Of Iain Henderson > Sent: Wednesday, February 18, 2009 12:07 PM > To: VPI SIG > Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 > > Folks, > > As discussed, here is a draft of one potential shape of a VPI sharing > agreement; this is as much to kick off the discussion as it is a > specific view on how things will end up - not least because they will > be web deployed rather than a Word document. > > The principles I have deployed in this design are: > > 1) The main break from business as usual is that in this scenario, the > organisation is signing the individuals terms and conditions prior to > VPI being shared. > > 2) It is underpinned by 8 standard privacy/ data protection principles > as deployed is EU, Canada, Australasia and others; it thus has a > grounding in existing legislation - meaning that organisations are > being asked to contract to things they should be doing anyway. > > 3) It is enhanced by 4 VRM principles which raise the bar over > straight legislation - as befits the higher value and sensitivity > around Volunteered Personal Information. > > 4) Some of the contractual issues relate only to VPI, others are more > general and relate to all personal data shared with an organisation. > > 5) The agreement has three levels: > > - top level, 'this organisation is VPI enabled' > - mid level, 'this organisation confirms contractually that they are > operating at or above the minimum level set in the 12 compliance > statements' > - detailed level, 'this organisation contracts with this individual to > this specific combination of data attributes shared and these uses to > which they will be put (this detailed level has still to be designed > but is do-able, albeit with considerable effort) > > 6) The agreement and its component parts have associated icons that > will be as per Creative Commons, machine readable, lawyer readable and > person readable, each having the same underlying effect. > > 7) The design enables audit and compliance capabilities to sit behind > it, and a VPI trust mark to be deployed. > > Lots of discussion to be had around this obviously - see you on the > call tomorrow. For those who can't make the call, by all means feed > back to the group via e-mail. > > Cheers > > Iain > > From iain.henderson at mydex.org Thu Feb 19 11:10:49 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Thu, 19 Feb 2009 19:10:49 +0000 Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 In-Reply-To: <001b01c992b2$3b25b250$b17116f0$@com> References: <001b01c992b2$3b25b250$b17116f0$@com> Message-ID: <635E3B11-8C73-4890-8C12-9D18DE268D08@mydex.org> Thanks Joe, yes my intention was to start the debate around the contract - very much draft 0.1. I have answers to some of your points and completely accept others - will respond in detail tomorrow. Cheers Iain On 19 Feb 2009, at 16:50, Joe Andrieu wrote: > Iain, > > This is a great starting point. It lays out several potential > requirements > for data management and suggests an initial verbal framework. Which is > enough to dive in and start thinking about the problem. > > So, with a constructive intent, let me dive into the details. > > First, it didn't seem that the structure matched the goals very > clearly. > > You mention two types of data transactions: ongoing or one-off. But > I didn't > see any specifics as to the contractual obligations that differ > between > those two. For example, a one-off situation should have specifics > around > the duration of the authorized use of that data. It seems that a > standard > contract should outline how those two would be handled, then also > specify > which of those two applies for the data to be shared. > > Also, the "three levels" you discuss in your email aren't apparent > in the > structure of the agreement. If I understand the three levels, in my > own > terms: > > 1. The company has agreed to standard terms regarding VP data > (generation, > use, deletion) > 2. The company asserts they've been compliant for 12 months > 3. For this particular data, the company agrees to these specific > terms > > But I don't see that structure in the agreement. > > Turning to content, I might suggest some different approaches. > > First, I don't think that requiring the last 12 months is > reasonable. It > presents a serious bootstrapping problem, where no company can use > this > agreement until 12 months into being fully VPI compliant. I'm > guessing that > the 12 month bit is chasing after a different, specific goal. Let's > identify > that and find a way that avoids this bootstrapping issue. > > Second, I feel strongly that simply allowing companies to state > their policy > is insufficient. Disclosure of bad behavior doesn't make it good > behavior. I > think part of our work is going to be figuring out what is "good" > behavior, > what is "allowed" behavior, and what is "bad" behavior. That is, we > need to > outline policy requirements, not just require that policies are > clearly > articulated. Then, within those requirements, we need to be flexible > for > different use cases and different business needs, in the same way > Creative > Commons attempts to boil down the handful of typical use profiles so > that > authors can pick and choose what is appropriate. Similarly, users and > vendors should be able to pick and choose a handful of "approved" > usage > patterns that make sense. For example, a quid-pro-quo around > retention of > search history (for search quality improvement efforts) in exchange > for > improved search results. The retention profile in that case is > different > than in "one night stand" one-off transactions with unrelated vendors. > > In particular the section on onward consent is far too weak. "active > consent > is sought prior to sharing". Sought? That just means they made some > effort > to ask you. It has no requirement that they actually /listen/ to your > consent. > > For personal data I'm putting into the cloud, I require much greater > control > and specific limits on what will actually be done with it, not just > disclosure of what is happening. > > -j > > -- > Joe Andrieu > SwitchBook > http://www.switchbook.com > joe at switchbook.com > +1 (805) 705-8651 > >> -----Original Message----- >> From: sig-vpi-bounces at lists.projectliberty.org [mailto:sig-vpi- >> bounces at lists.projectliberty.org] On Behalf Of Iain Henderson >> Sent: Wednesday, February 18, 2009 12:07 PM >> To: VPI SIG >> Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 >> >> Folks, >> >> As discussed, here is a draft of one potential shape of a VPI sharing >> agreement; this is as much to kick off the discussion as it is a >> specific view on how things will end up - not least because they will >> be web deployed rather than a Word document. >> >> The principles I have deployed in this design are: >> >> 1) The main break from business as usual is that in this scenario, >> the >> organisation is signing the individuals terms and conditions prior to >> VPI being shared. >> >> 2) It is underpinned by 8 standard privacy/ data protection >> principles >> as deployed is EU, Canada, Australasia and others; it thus has a >> grounding in existing legislation - meaning that organisations are >> being asked to contract to things they should be doing anyway. >> >> 3) It is enhanced by 4 VRM principles which raise the bar over >> straight legislation - as befits the higher value and sensitivity >> around Volunteered Personal Information. >> >> 4) Some of the contractual issues relate only to VPI, others are more >> general and relate to all personal data shared with an organisation. >> >> 5) The agreement has three levels: >> >> - top level, 'this organisation is VPI enabled' >> - mid level, 'this organisation confirms contractually that they are >> operating at or above the minimum level set in the 12 compliance >> statements' >> - detailed level, 'this organisation contracts with this individual >> to >> this specific combination of data attributes shared and these uses to >> which they will be put (this detailed level has still to be designed >> but is do-able, albeit with considerable effort) >> >> 6) The agreement and its component parts have associated icons that >> will be as per Creative Commons, machine readable, lawyer readable >> and >> person readable, each having the same underlying effect. >> >> 7) The design enables audit and compliance capabilities to sit behind >> it, and a VPI trust mark to be deployed. >> >> Lots of discussion to be had around this obviously - see you on the >> call tomorrow. For those who can't make the call, by all means feed >> back to the group via e-mail. >> >> Cheers >> >> Iain >> >> > > Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it. From iain.henderson at mydex.org Mon Feb 23 01:03:37 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Mon, 23 Feb 2009 09:03:37 +0000 Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 In-Reply-To: <001b01c992b2$3b25b250$b17116f0$@com> References: <001b01c992b2$3b25b250$b17116f0$@com> Message-ID: <5565D373-6C29-4F65-9AC4-8F1F292E8D3E@mydex.org> Thanks Joe, see comments inline; and also version 0.2 of the draft agreement with the first stab at the detailed level (what is being shared and what done with it) in place. And also some relevant links i've dug out as background. http://en.wikipedia.org/wiki/Database_right http://cybermatron.blogspot.com/2009/02/is-time-running-out-for-privacy-notices.html http://www.ico.gov.uk/about_us/news_and_views/current_topics/personal_info_promise.aspx Cheers Iain On 19 Feb 2009, at 16:50, Joe Andrieu wrote: > Iain, > > This is a great starting point. It lays out several potential > requirements > for data management and suggests an initial verbal framework. Which is > enough to dive in and start thinking about the problem. Yes, start point was the intention - and as discussed on the call I have a meet with the lawyers who are giving pro bono input next Friday (27th) so any further iterations we can do this week would be helpful if getting us in good shape to make maximum use of that resource. > > > So, with a constructive intent, let me dive into the details. > > First, it didn't seem that the structure matched the goals very > clearly. Quite possibly - we are dealing with a necessarily complex beast; remember that we propose not only the contractual framework but also the associated audit and compliance mechanism that sits behind/ enforces it and shines a light on good practice as well as bad. The audit and compliance thinking comes from that work on 'the trust index' I had shared previously and attached again as a reminder - note that the 12 dimensions in the contract mirror the 12 assessed components (which run on a 5 point scale). It will take a bit of iteration to get a smooth journey through that mix but I believe the core components of the solution are in place (subject to the additional points below). > > > You mention two types of data transactions: ongoing or one-off. But > I didn't > see any specifics as to the contractual obligations that differ > between > those two. For example, a one-off situation should have specifics > around > the duration of the authorized use of that data. It seems that a > standard > contract should outline how those two would be handled, then also > specify > which of those two applies for the data to be shared. I'm proposing one contract to cover two types of sharing and yes we need to work on the 'duration' issue. In the next version (draft 0.2) attached i've hopefully clarified things a little by showing the next level of detail down which gets to the type of data being shared and the type of use allowed - this will also require significant iteration as there are a number of different approaches that could be taken in this area. Going back to your point about 2 types of sharing being enabled; there is a complexity in that all data types could be shared via either route - again we'll need more iteration on this. > > > Also, the "three levels" you discuss in your email aren't apparent > in the > structure of the agreement. If I understand the three levels, in my > own > terms: > > 1. The company has agreed to standard terms regarding VP data > (generation, > use, deletion) > 2. The company asserts they've been compliant for 12 months > 3. For this particular data, the company agrees to these specific > terms. > > > But I don't see that structure in the agreement. No, the structure I meant to explain/ propose for debate is: top level - we are VPI enabled (i.e. we have had our organisational lawyers crawl over the contract and our business folks/ techies commit to delivering on it); this top level just acts as a trust mark/ discovery tool when people are looking for VPI compliant organisations. mid-level (which can potentially be crunched together with the top level in that it says the same but in a more granular manner) - We (organisation) contractually agree to what we should be doing anyway through legislation and good practice. low level (the most important one) - where we go below the level of existing privacy legislation and insist on the organisation spelling out how they address facets of the 12 capabilities IN DETAIL, i.e. below the level currently set as the norm in privacy legislation. The early focus of this will probably be' what data do you want, and what are you going to do with it'; but over time this drill down may extend into the other 10 areas (i.e. tell me more about how you secure my data) > > > Turning to content, I might suggest some different approaches. > > First, I don't think that requiring the last 12 months is > reasonable. It > presents a serious bootstrapping problem, where no company can use > this > agreement until 12 months into being fully VPI compliant. I'm > guessing that > the 12 month bit is chasing after a different, specific goal. Let's > identify > that and find a way that avoids this bootstrapping issue. Agreed, i've deleted the reference to 'time/ duration', there will be better ways to handle that - the lawyers will advise. > > > Second, I feel strongly that simply allowing companies to state > their policy > is insufficient. Disclosure of bad behavior doesn't make it good > behavior. I > think part of our work is going to be figuring out what is "good" > behavior, > what is "allowed" behavior, and what is "bad" behavior. That is, we > need to > outline policy requirements, not just require that policies are > clearly > articulated. Then, within those requirements, we need to be flexible > for > different use cases and different business needs, in the same way > Creative > Commons attempts to boil down the handful of typical use profiles so > that > authors can pick and choose what is appropriate. Similarly, users and > vendors should be able to pick and choose a handful of "approved" > usage > patterns that make sense. For example, a quid-pro-quo around > retention of > search history (for search quality improvement efforts) in exchange > for > improved search results. The retention profile in that case is > different > than in "one night stand" one-off transactions with unrelated vendors. > > In particular the section on onward consent is far too weak. "active > consent > is sought prior to sharing". Sought? That just means they made some > effort > to ask you. It has no requirement that they actually /listen/ to your > consent. > > For personal data I'm putting into the cloud, I require much greater > control > and specific limits on what will actually be done with it, not just > disclosure of what is happening. I think you are mis-interpreting what I meant, perhaps because I had yet to include that more detail; or how it is currently being expressed. The intent with VPI is to operate WELL ABOVE current practices, in a different level of atmosphere altogether. And remember, the contract is not stand alone, there are multiple other of the VPI building blocks that raise the bar yet further - an automatic log of all sharing activity via the VPI technology, audit and compliance processes etc. Here's my next iteration. All - feel free to comment back to the group before Friday this week; at which point i'll take the draft contract to the lawyers for their initial input - then back to the group for discussion on the next call. One other thing i'll try to do before the next call is run through the contract scenario with our car buying and vacation buying scenario to see what light that sheds. -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft VPI Sharing Agreement 0.2.doc Type: application/msword Size: 435200 bytes Desc: not available URL: -------------- next part -------------- > > > -j > -------------- next part -------------- A non-text attachment was scrubbed... Name: ti-output-for-wordpress.gif Type: image/gif Size: 55750 bytes Desc: not available URL: -------------- next part -------------- > -- > Joe Andrieu > SwitchBook > http://www.switchbook.com > joe at switchbook.com > +1 (805) 705-8651 > >> -----Original Message----- >> From: sig-vpi-bounces at lists.projectliberty.org [mailto:sig-vpi- >> bounces at lists.projectliberty.org] On Behalf Of Iain Henderson >> Sent: Wednesday, February 18, 2009 12:07 PM >> To: VPI SIG >> Subject: [Sig-vpi] Draft VPI Sharing Agreement version 0.1 >> >> Folks, >> >> As discussed, here is a draft of one potential shape of a VPI sharing >> agreement; this is as much to kick off the discussion as it is a >> specific view on how things will end up - not least because they will >> be web deployed rather than a Word document. >> >> The principles I have deployed in this design are: >> >> 1) The main break from business as usual is that in this scenario, >> the >> organisation is signing the individuals terms and conditions prior to >> VPI being shared. >> >> 2) It is underpinned by 8 standard privacy/ data protection >> principles >> as deployed is EU, Canada, Australasia and others; it thus has a >> grounding in existing legislation - meaning that organisations are >> being asked to contract to things they should be doing anyway. >> >> 3) It is enhanced by 4 VRM principles which raise the bar over >> straight legislation - as befits the higher value and sensitivity >> around Volunteered Personal Information. >> >> 4) Some of the contractual issues relate only to VPI, others are more >> general and relate to all personal data shared with an organisation. >> >> 5) The agreement has three levels: >> >> - top level, 'this organisation is VPI enabled' >> - mid level, 'this organisation confirms contractually that they are >> operating at or above the minimum level set in the 12 compliance >> statements' >> - detailed level, 'this organisation contracts with this individual >> to >> this specific combination of data attributes shared and these uses to >> which they will be put (this detailed level has still to be designed >> but is do-able, albeit with considerable effort) >> >> 6) The agreement and its component parts have associated icons that >> will be as per Creative Commons, machine readable, lawyer readable >> and >> person readable, each having the same underlying effect. >> >> 7) The design enables audit and compliance capabilities to sit behind >> it, and a VPI trust mark to be deployed. >> >> Lots of discussion to be had around this obviously - see you on the >> call tomorrow. For those who can't make the call, by all means feed >> back to the group via e-mail. >> >> Cheers >> >> Iain >> >> > > Iain Henderson iain.henderson at mydex.org This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e- mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it.