From brett at projectliberty.org Fri Jan 2 13:46:25 2009 From: brett at projectliberty.org (Brett McDowell) Date: Fri, 2 Jan 2009 16:46:25 -0500 Subject: [Sig-vpi] new set of use cases... a volunteer guinea pig In-Reply-To: <41D5C910-982F-4A83-8E7E-8B0E1A9836DD@mydex.org> References: <652C0FB0-AA6D-4C49-828B-FC132ADDD145@projectliberty.org> <41D5C910-982F-4A83-8E7E-8B0E1A9836DD@mydex.org> Message-ID: Okay, I'll write something up. --- Sent from my mobile phone On Dec 28, 2008, at 4:42 PM, Iain Henderson wrote: > Thanks Brett, that would be great - there is nothing like a real > live documented experience for illustration potential improvements. > > You might want to have a look at this UK site/ service as a > reference point; it is reasonably good although still seller-centric > and funds itself by selling your data to advertisers. > > In the next call we should discuss our use case documentation > formats to a conclusion then keep building out the examples - I > think my start point can be build out with elements of your MRD > document. I'm going to do another one for our recent 'having a > child' experience, that is if I still have any energy left from the > mayhem that has ensued. That use case will be good for getting into > the government and health sector side of things - registering the > birth, child tax credits, NHS records etc. > > Cheers > > Iain > > > > > > > On 28 Dec 2008, at 16:13, Brett McDowell wrote: > >> Over the holidays I have *finally* "sold" my house and "purchased" >> a new one (the quotes are to indicate nothing is final until the >> two closings take place on Feb 6). I'm telling the SIG this >> because I remember Iain being interested in this "change of >> address" VPI use case in previous discussions. I am about to go >> through all the hundreds of steps that it takes to move and I'm >> happy to share this with the SIG if that will be useful for >> building out the "change of address" VPI use case. In return, I >> would hope to get some good advice ;-) >> >> Cheers, >> >> -- Brett >> >> _______________________________________________ >> 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. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Mon Jan 5 10:01:58 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Mon, 5 Jan 2009 18:01:58 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts Message-ID: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Hi Folks, Happy new year - hope you all had a good break. I've had an opportunity emerge for some very high end lawyers who specialise in tech/ open source to contribute thinking on VPI and the options for taking things forward. They are of the view that this is a area of sufficient interest to them that they are putting in a sizable chunk of time 'pro bono'. I'm meeting them on Thursday for an initial deep dive into the subject area and intend to focus on nature and deployment options for the contracts and terms and conditions that individual through which an individual would make their volunteered information available. This will be before our next call so I thought we might iterate by e- mail in advance on this first meeting. My going in thoughts are that: - a range of standard contracts will be required, as per Creative Commons - they will have to be able to operate at a very granular level (individual data element in a specific use scenario at a particular point in time) if they are to be meaningful (this is where most privacy legislation falls down in my view) - they should be machine discoverable and readable in order to automate the process of find and engage - they will have to be realistic in terms of the supply side being able to comply, although that bar may be raised over time - they will have to be couched in language readily understandable by individuals, probably involving the use of icons to represent contract choices/ sub-choices Anyone have any comments/ further thoughts prior to the lawyer meeting? 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 joe at switchbook.com Mon Jan 5 11:49:04 2009 From: joe at switchbook.com (Joe Andrieu) Date: Mon, 5 Jan 2009 11:49:04 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Message-ID: <010d01c96f6e$ab6e7b80$024b7280$@com> I would add that we would like to allow appropriate variants based on "aggregated" and/or "anonymized" data. That is, denying rights to specific data sets for a certain use, while allowing it in an aggregate or anonymized form for the same use. This will require some definitions around what it means to aggregate and anonymize, but the business value for this is clear, and may be necessary for adoption. This parallels what a industry associations often do with survey data. The individual companies' data are confidential, but the aggregated sum of activity in that industrial sector is non-confidential. (Which allows each contributor to measure their market share against accurate industry data without divulging their revenue publicly.) I think defining "aggregate" and "anonymous" will be tricky, but worth the effort. -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: Monday, January 05, 2009 10:02 AM > To: VPI SIG > Subject: [Sig-vpi] Input from Lawyers on VPI Contracts > > Hi Folks, > > Happy new year - hope you all had a good break. > > I've had an opportunity emerge for some very high end lawyers who > specialise in tech/ open source to contribute thinking on VPI and the > options for taking things forward. They are of the view that this is a > area of sufficient interest to them that they are putting in a sizable > chunk of time 'pro bono'. > > I'm meeting them on Thursday for an initial deep dive into the subject > area and intend to focus on nature and deployment options for the > contracts and terms and conditions that individual through which an > individual would make their volunteered information available. > > This will be before our next call so I thought we might iterate by e- > mail in advance on this first meeting. > > My going in thoughts are that: > > - a range of standard contracts will be required, as per Creative > Commons > > - they will have to be able to operate at a very granular level > (individual data element in a specific use scenario at a particular > point in time) if they are to be meaningful (this is where most > privacy legislation falls down in my view) > > - they should be machine discoverable and readable in order to > automate the process of find and engage > > - they will have to be realistic in terms of the supply side being > able to comply, although that bar may be raised over time > > - they will have to be couched in language readily understandable by > individuals, probably involving the use of icons to represent contract > choices/ sub-choices > > Anyone have any comments/ further thoughts prior to the lawyer meeting? > > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig- > vpi_lists.projectliberty.org From brett at projectliberty.org Mon Jan 5 11:52:18 2009 From: brett at projectliberty.org (Brett McDowell) Date: Mon, 5 Jan 2009 14:52:18 -0500 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Message-ID: Good news Iain. I'm be interested to know who the firm is once they agree. As for comments on next steps: - Has anyone reached out to Mary Rundle recently? That came up as an action item in the Boston VRM session (way back before is started snowing) but I don't recall who took the action... it might have been Drummond Reed if memory serves. But since she is responsible for leading the icon work in this space so far I think she should (at least given the explicit invitation to) be involved. - I'm working with the Cyberspace Committee of the American Bar Association on some other model contracts, not for individuals who disclose their information but for organizations who allow individuals to share valuable information across boundaries based on Federation agreements. Do you think there is enough similarity between that work and what you envision for VPI to invite them to this discussion? On Mon, Jan 5, 2009 at 1:01 PM, Iain Henderson wrote: > Hi Folks, > > Happy new year - hope you all had a good break. > > I've had an opportunity emerge for some very high end lawyers who > specialise in tech/ open source to contribute thinking on VPI and the > options for taking things forward. They are of the view that this is a area > of sufficient interest to them that they are putting in a sizable chunk of > time 'pro bono'. > > I'm meeting them on Thursday for an initial deep dive into the subject area > and intend to focus on nature and deployment options for the contracts and > terms and conditions that individual through which an individual would make > their volunteered information available. > > This will be before our next call so I thought we might iterate by e-mail > in advance on this first meeting. > > My going in thoughts are that: > > - a range of standard contracts will be required, as per Creative Commons > > - they will have to be able to operate at a very granular level (individual > data element in a specific use scenario at a particular point in time) if > they are to be meaningful (this is where most privacy legislation falls down > in my view) > > - they should be machine discoverable and readable in order to automate the > process of find and engage > > - they will have to be realistic in terms of the supply side being able to > comply, although that bar may be raised over time > > - they will have to be couched in language readily understandable by > individuals, probably involving the use of icons to represent contract > choices/ sub-choices > > Anyone have any comments/ further thoughts prior to the lawyer meeting? > > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > -- Brett McDowell || phone = +1 (413) 652-1248 || blog = http://blog.brettmcdowell.com | twitter = http://twitter.com/brettmcdowell || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com || LinkedIn = http://tinyurl.com/brettonli | Facebook = http://tinyurl.com/brettonfb || my free/busy calendar = http://tinyurl.com/myfreebusy -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Mon Jan 5 14:00:38 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Mon, 5 Jan 2009 22:00:38 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <010d01c96f6e$ab6e7b80$024b7280$@com> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <010d01c96f6e$ab6e7b80$024b7280$@com> Message-ID: <4D599788-5213-4A06-B293-187C30E8855A@mydex.org> Thanks Joe, i'll include those issues in the 'data use' section of the discussion. Cheers Iain On 5 Jan 2009, at 19:49, Joe Andrieu wrote: > I would add that we would like to allow appropriate variants based on > "aggregated" and/or "anonymized" data. That is, denying rights to > specific > data sets for a certain use, while allowing it in an aggregate or > anonymized > form for the same use. This will require some definitions around > what it > means to aggregate and anonymize, but the business value for this is > clear, > and may be necessary for adoption. > > This parallels what a industry associations often do with survey > data. The > individual companies' data are confidential, but the aggregated sum of > activity in that industrial sector is non-confidential. (Which > allows each > contributor to measure their market share against accurate industry > data > without divulging their revenue publicly.) > > I think defining "aggregate" and "anonymous" will be tricky, but > worth the > effort. > > -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: Monday, January 05, 2009 10:02 AM >> To: VPI SIG >> Subject: [Sig-vpi] Input from Lawyers on VPI Contracts >> >> Hi Folks, >> >> Happy new year - hope you all had a good break. >> >> I've had an opportunity emerge for some very high end lawyers who >> specialise in tech/ open source to contribute thinking on VPI and the >> options for taking things forward. They are of the view that this >> is a >> area of sufficient interest to them that they are putting in a >> sizable >> chunk of time 'pro bono'. >> >> I'm meeting them on Thursday for an initial deep dive into the >> subject >> area and intend to focus on nature and deployment options for the >> contracts and terms and conditions that individual through which an >> individual would make their volunteered information available. >> >> This will be before our next call so I thought we might iterate by e- >> mail in advance on this first meeting. >> >> My going in thoughts are that: >> >> - a range of standard contracts will be required, as per Creative >> Commons >> >> - they will have to be able to operate at a very granular level >> (individual data element in a specific use scenario at a particular >> point in time) if they are to be meaningful (this is where most >> privacy legislation falls down in my view) >> >> - they should be machine discoverable and readable in order to >> automate the process of find and engage >> >> - they will have to be realistic in terms of the supply side being >> able to comply, although that bar may be raised over time >> >> - they will have to be couched in language readily understandable by >> individuals, probably involving the use of icons to represent >> contract >> choices/ sub-choices >> >> Anyone have any comments/ further thoughts prior to the lawyer >> meeting? >> >> 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. >> >> >> >> >> >> _______________________________________________ >> 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 iain.henderson at mydex.org Tue Jan 6 00:04:36 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Tue, 6 Jan 2009 08:04:36 +0000 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: <000b01c965fa$a953f190$fbfbd4b0$@org> References: <000b01c965fa$a953f190$fbfbd4b0$@org> Message-ID: <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> Thanks for this Kurt. Could I just sense check with the group whether the current call schedule of every second Thursday at 5 UK time, 12 Eastern, 9am Pacific works for people and there are not clashes that exist with other calls? Please feed back on your preferences and i'll set up the schedule for this year on the wiki. Cheers Iain On 24 Dec 2008, at 19:06, Kurt Kolok wrote: > All, > > Minutes from our last call may be found on the VPI SIG wiki at the > following link: > > http://wiki.projectliberty.org/index.php/HIMSIG20081218 > > Regards, > > Kurt > > Kurt Kolok > Program Coordinator > Liberty Alliance Project > _______________________________________________ > 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 Eve.Maler at Sun.COM Tue Jan 6 08:08:15 2009 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 06 Jan 2009 08:08:15 -0800 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> Message-ID: <617D1810-E441-44DF-A714-6ED74A5FCBD8@sun.com> That time slot generally works for me. Happy new year, all. Eve On Jan 6, 2009, at 12:04 AM, Iain Henderson wrote: > Thanks for this Kurt. > > Could I just sense check with the group whether the current call > schedule of every second Thursday at 5 UK time, 12 Eastern, 9am > Pacific works for people and there are not clashes that exist with > other calls? > > Please feed back on your preferences and i'll set up the schedule > for this year on the wiki. > > Cheers > > Iain > > On 24 Dec 2008, at 19:06, Kurt Kolok wrote: > >> All, >> >> Minutes from our last call may be found on the VPI SIG wiki at the >> following link: >> >> http://wiki.projectliberty.org/index.php/HIMSIG20081218 >> >> Regards, >> >> Kurt >> >> Kurt Kolok >> Program Coordinator >> Liberty Alliance Project >> _______________________________________________ >> 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From joe at switchbook.com Tue Jan 6 08:22:07 2009 From: joe at switchbook.com (Joe Andrieu) Date: Tue, 6 Jan 2009 08:22:07 -0800 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> Message-ID: <027701c9701a$ed018450$c7048cf0$@com> That works for me. Just one question: is that every other Thursday? Or every second Thursday of the month? -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: Tuesday, January 06, 2009 12:05 AM > To: Kurt Kolok; VPI SIG > Subject: Re: [Sig-vpi] 2008-12-18 VPI SIG Minutes > > Thanks for this Kurt. > > Could I just sense check with the group whether the current call > schedule of every second Thursday at 5 UK time, 12 Eastern, 9am > Pacific works for people and there are not clashes that exist with > other calls? > > Please feed back on your preferences and i'll set up the schedule for > this year on the wiki. > > Cheers > > Iain > > On 24 Dec 2008, at 19:06, Kurt Kolok wrote: > > > All, > > > > Minutes from our last call may be found on the VPI SIG wiki at the > > following link: > > > > http://wiki.projectliberty.org/index.php/HIMSIG20081218 > > > > Regards, > > > > Kurt > > > > Kurt Kolok > > Program Coordinator > > Liberty Alliance Project > > _______________________________________________ > > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig- > vpi_lists.projectliberty.org From iain.henderson at mydex.org Tue Jan 6 10:18:14 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Tue, 6 Jan 2009 18:18:14 +0000 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: <027701c9701a$ed018450$c7048cf0$@com> References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> <027701c9701a$ed018450$c7048cf0$@com> Message-ID: <3202041C-2646-4A75-A368-42137B78E48B@mydex.org> I'm suggesting every second Thursday starting this week. Cheers Iain On 6 Jan 2009, at 16:22, Joe Andrieu wrote: > That works for me. Just one question: is that every other Thursday? > Or every > second Thursday of the month? > > -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: Tuesday, January 06, 2009 12:05 AM >> To: Kurt Kolok; VPI SIG >> Subject: Re: [Sig-vpi] 2008-12-18 VPI SIG Minutes >> >> Thanks for this Kurt. >> >> Could I just sense check with the group whether the current call >> schedule of every second Thursday at 5 UK time, 12 Eastern, 9am >> Pacific works for people and there are not clashes that exist with >> other calls? >> >> Please feed back on your preferences and i'll set up the schedule for >> this year on the wiki. >> >> Cheers >> >> Iain >> >> On 24 Dec 2008, at 19:06, Kurt Kolok wrote: >> >>> All, >>> >>> Minutes from our last call may be found on the VPI SIG wiki at the >>> following link: >>> >>> http://wiki.projectliberty.org/index.php/HIMSIG20081218 >>> >>> Regards, >>> >>> Kurt >>> >>> Kurt Kolok >>> Program Coordinator >>> Liberty Alliance Project >>> _______________________________________________ >>> 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. >> >> >> >> >> >> _______________________________________________ >> 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 brett at projectliberty.org Tue Jan 6 10:55:37 2009 From: brett at projectliberty.org (Brett McDowell) Date: Tue, 6 Jan 2009 13:55:37 -0500 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: <3202041C-2646-4A75-A368-42137B78E48B@mydex.org> References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> <027701c9701a$ed018450$c7048cf0$@com> <3202041C-2646-4A75-A368-42137B78E48B@mydex.org> Message-ID: So, to be clear, I think Iain is saying the next meeting will be Jan 8th followed by: - Jan 22 - Feb 5 etc. Is that correct? Some of us might call that "every other Thursday" but it's just as accurate to call it "every 2nd Thursday". On Tue, Jan 6, 2009 at 1:18 PM, Iain Henderson wrote: > I'm suggesting every second Thursday starting this week. > > Cheers > > Iain > > > On 6 Jan 2009, at 16:22, Joe Andrieu wrote: > > That works for me. Just one question: is that every other Thursday? Or >> every >> second Thursday of the month? >> >> -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: Tuesday, January 06, 2009 12:05 AM >>> To: Kurt Kolok; VPI SIG >>> Subject: Re: [Sig-vpi] 2008-12-18 VPI SIG Minutes >>> >>> Thanks for this Kurt. >>> >>> Could I just sense check with the group whether the current call >>> schedule of every second Thursday at 5 UK time, 12 Eastern, 9am >>> Pacific works for people and there are not clashes that exist with >>> other calls? >>> >>> Please feed back on your preferences and i'll set up the schedule for >>> this year on the wiki. >>> >>> Cheers >>> >>> Iain >>> >>> On 24 Dec 2008, at 19:06, Kurt Kolok wrote: >>> >>> All, >>>> >>>> Minutes from our last call may be found on the VPI SIG wiki at the >>>> following link: >>>> >>>> http://wiki.projectliberty.org/index.php/HIMSIG20081218 >>>> >>>> Regards, >>>> >>>> Kurt >>>> >>>> Kurt Kolok >>>> Program Coordinator >>>> Liberty Alliance Project >>>> _______________________________________________ >>>> 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. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > -- Brett McDowell || phone = +1 (413) 652-1248 || blog = http://blog.brettmcdowell.com | twitter = http://twitter.com/brettmcdowell || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com || LinkedIn = http://tinyurl.com/brettonli | Facebook = http://tinyurl.com/brettonfb || my free/busy calendar = http://tinyurl.com/myfreebusy -------------- next part -------------- An HTML attachment was scrubbed... URL: From joni at ieee-isto.org Tue Jan 6 11:08:19 2009 From: joni at ieee-isto.org (Joni Brennan) Date: Tue, 6 Jan 2009 11:08:19 -0800 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> <027701c9701a$ed018450$c7048cf0$@com> <3202041C-2646-4A75-A368-42137B78E48B@mydex.org> Message-ID: <947ea3330901061108k73709a09q12016a769340d040@mail.gmail.com> Hello, I've been following this thread and have taken a moment to add the calls for January (2nd and 4th Thursdays) to the VPI SIG wiki for your convenience: http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG Cheers, Joni On Tue, Jan 6, 2009 at 10:55 AM, Brett McDowell wrote: > So, to be clear, I think Iain is saying the next meeting will be Jan 8th > followed by: > - Jan 22 > - Feb 5 > etc. > > Is that correct? Some of us might call that "every other Thursday" but > it's just as accurate to call it "every 2nd Thursday". > > > On Tue, Jan 6, 2009 at 1:18 PM, Iain Henderson wrote: > >> I'm suggesting every second Thursday starting this week. >> >> Cheers >> >> Iain >> >> >> On 6 Jan 2009, at 16:22, Joe Andrieu wrote: >> >> That works for me. Just one question: is that every other Thursday? Or >>> every >>> second Thursday of the month? >>> >>> -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: Tuesday, January 06, 2009 12:05 AM >>>> To: Kurt Kolok; VPI SIG >>>> Subject: Re: [Sig-vpi] 2008-12-18 VPI SIG Minutes >>>> >>>> Thanks for this Kurt. >>>> >>>> Could I just sense check with the group whether the current call >>>> schedule of every second Thursday at 5 UK time, 12 Eastern, 9am >>>> Pacific works for people and there are not clashes that exist with >>>> other calls? >>>> >>>> Please feed back on your preferences and i'll set up the schedule for >>>> this year on the wiki. >>>> >>>> Cheers >>>> >>>> Iain >>>> >>>> On 24 Dec 2008, at 19:06, Kurt Kolok wrote: >>>> >>>> All, >>>>> >>>>> Minutes from our last call may be found on the VPI SIG wiki at the >>>>> following link: >>>>> >>>>> http://wiki.projectliberty.org/index.php/HIMSIG20081218 >>>>> >>>>> Regards, >>>>> >>>>> Kurt >>>>> >>>>> Kurt Kolok >>>>> Program Coordinator >>>>> Liberty Alliance Project >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >> >> >> >> >> >> _______________________________________________ >> Sig-vpi mailing list >> Sig-vpi at lists.projectliberty.org >> >> http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org >> > > > > -- > Brett McDowell > || phone = +1 (413) 652-1248 > || blog = http://blog.brettmcdowell.com | twitter = > http://twitter.com/brettmcdowell > || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com > || LinkedIn = http://tinyurl.com/brettonli | Facebook = > http://tinyurl.com/brettonfb > || my free/busy calendar = http://tinyurl.com/myfreebusy > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > > -- Joni Brennan IEEE-ISTO Liberty Alliance Project Operations Manager voice:+1 732-226-4223 email: joni @ projectliberty.org email: joni @ ieee-isto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eve.Maler at Sun.COM Tue Jan 6 12:26:15 2009 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 06 Jan 2009 12:26:15 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Message-ID: Ian, this is great news, and I'm very interested to follow the wrok (and maybe even suggest additional lawyerly/public policy resources who are interested to help). Mary and I are supposed to get together sometime soon -- we planned a meeting for last month but got beaten by the Seattle snow! This is a good reminder for me to ping her again. Other comments: One of the goals of CC is to have the terms be readable by ordinary people, legal specialists, and machines -- and with the various requirements listed below, I think you've also hit all of these. I seem to recall that someone (Doc? don't recall) reached out to Larry Lessig some months ago to discuss working together. Would that be a possibility here? I strongly recommend that we have a goal of simplicity, and that will mean the range of options can't be too large, and there are basic usability principles to keep in mind. I agree about ultimately targeting finer-grained terms for sharing/ using individual pieces of information, but would be happy with baby steps that apply a set of terms to a *set* of data. For an internal project I've got going, our analysis on this ended up interpreting a set of data-sharing contract terms as *the* thing that defines a data- sharing "relationship" (in reductionist fashion), such that if you decide you want to share other information with the same vendor under different terms, it's like setting up a different/parallel relationship between the same parties. (This isn't so strange, if you think about it; for example, NDAs generally are better if they're not very broad, and so various business partners and I operate under a multiplicity of NDAs and we have to pick the applicable one before every conversation. And the same parties can have a variety of purchase contracts at the same time.) Talk to y'all on the 8th! Eve On Jan 5, 2009, at 11:52 AM, Brett McDowell wrote: > Good news Iain. I'm be interested to know who the firm is once they > agree. > > As for comments on next steps: > > - Has anyone reached out to Mary Rundle recently? That came up as > an action item in the Boston VRM session (way back before is started > snowing) but I don't recall who took the action... it might have > been Drummond Reed if memory serves. But since she is responsible > for leading the icon work in this space so far I think she should > (at least given the explicit invitation to) be involved. > > - I'm working with the Cyberspace Committee of the American Bar > Association on some other model contracts, not for individuals who > disclose their information but for organizations who allow > individuals to share valuable information across boundaries based on > Federation agreements. Do you think there is enough similarity > between that work and what you envision for VPI to invite them to > this discussion? > > > On Mon, Jan 5, 2009 at 1:01 PM, Iain Henderson > wrote: > Hi Folks, > > Happy new year - hope you all had a good break. > > I've had an opportunity emerge for some very high end lawyers who > specialise in tech/ open source to contribute thinking on VPI and > the options for taking things forward. They are of the view that > this is a area of sufficient interest to them that they are putting > in a sizable chunk of time 'pro bono'. > > I'm meeting them on Thursday for an initial deep dive into the > subject area and intend to focus on nature and deployment options > for the contracts and terms and conditions that individual through > which an individual would make their volunteered information > available. > > This will be before our next call so I thought we might iterate by e- > mail in advance on this first meeting. > > My going in thoughts are that: > > - a range of standard contracts will be required, as per Creative > Commons > > - they will have to be able to operate at a very granular level > (individual data element in a specific use scenario at a particular > point in time) if they are to be meaningful (this is where most > privacy legislation falls down in my view) > > - they should be machine discoverable and readable in order to > automate the process of find and engage > > - they will have to be realistic in terms of the supply side being > able to comply, although that bar may be raised over time > > - they will have to be couched in language readily understandable by > individuals, probably involving the use of icons to represent > contract choices/ sub-choices > > Anyone have any comments/ further thoughts prior to the lawyer > meeting? > > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > > > > -- > Brett McDowell > || phone = +1 (413) 652-1248 > || blog = http://blog.brettmcdowell.com | twitter = http://twitter.com/brettmcdowell > || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com > || LinkedIn = http://tinyurl.com/brettonli | Facebook = http://tinyurl.com/brettonfb > || my free/busy calendar = http://tinyurl.com/myfreebusy > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Tue Jan 6 13:10:53 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Tue, 6 Jan 2009 21:10:53 +0000 Subject: [Sig-vpi] 2008-12-18 VPI SIG Minutes In-Reply-To: References: <000b01c965fa$a953f190$fbfbd4b0$@org> <70E711EA-5DF0-4E3E-8E2E-F8AEE96AFB81@mydex.org> <027701c9701a$ed018450$c7048cf0$@com> <3202041C-2646-4A75-A368-42137B78E48B@mydex.org> Message-ID: Yes, that's what I had in mind thanks. So, this Thursday it is as per the link to the wiki. http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG Cheers Iain On 6 Jan 2009, at 18:55, Brett McDowell wrote: > So, to be clear, I think Iain is saying the next meeting will be Jan > 8th followed by: > - Jan 22 > - Feb 5 > etc. > > Is that correct? Some of us might call that "every other Thursday" > but it's just as accurate to call it "every 2nd Thursday". > > On Tue, Jan 6, 2009 at 1:18 PM, Iain Henderson > wrote: > I'm suggesting every second Thursday starting this week. > > Cheers > > Iain > > > On 6 Jan 2009, at 16:22, Joe Andrieu wrote: > > That works for me. Just one question: is that every other Thursday? > Or every > second Thursday of the month? > > -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: Tuesday, January 06, 2009 12:05 AM > To: Kurt Kolok; VPI SIG > Subject: Re: [Sig-vpi] 2008-12-18 VPI SIG Minutes > > Thanks for this Kurt. > > Could I just sense check with the group whether the current call > schedule of every second Thursday at 5 UK time, 12 Eastern, 9am > Pacific works for people and there are not clashes that exist with > other calls? > > Please feed back on your preferences and i'll set up the schedule for > this year on the wiki. > > Cheers > > Iain > > On 24 Dec 2008, at 19:06, Kurt Kolok wrote: > > All, > > Minutes from our last call may be found on the VPI SIG wiki at the > following link: > > http://wiki.projectliberty.org/index.php/HIMSIG20081218 > > Regards, > > Kurt > > Kurt Kolok > Program Coordinator > Liberty Alliance Project > _______________________________________________ > 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. > > > > > > _______________________________________________ > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > > > > -- > Brett McDowell > || phone = +1 (413) 652-1248 > || blog = http://blog.brettmcdowell.com | twitter = http://twitter.com/brettmcdowell > || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com > || LinkedIn = http://tinyurl.com/brettonli | Facebook = http://tinyurl.com/brettonfb > || my free/busy calendar = http://tinyurl.com/myfreebusy 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 bill at oidf.org Tue Jan 6 23:55:29 2009 From: bill at oidf.org (Bill Washburn) Date: Tue, 6 Jan 2009 23:55:29 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Message-ID: <891348600901062355k6cf12d95w8e842a5200d2acf8@mail.gmail.com> Hi Iain, Happy 2009 to you as a new father. Congratulations. A few thoughts: I could be way wrong, but since you're talking to attorneys the following thought could be worth bit of discussion / examination. To my mind, what consumers would greatly benefit from in the VRM arena is what I would call a "contract services" or "legal services" third party (Mydex might play this role in part, for instance as part of their offerings) that is operated with sufficient legal expertise and where the individual citizen/consumer/user would have a trusted primary relationship with the contract services/legal services provider. The legal services provider would manage and monitor and otherwise maintain (via software efficiencies, obviously) any and all granular iterations and permutations that a user may wish to exercise regarding revealing information and preferences - perhaps the dashboard metaphor interface would be a useful way to visualize control. To me this is valuable to consider because we all know well that reading/checking legal terms and conditions on the 'net is ignored more or less universally. Also a few competing legal services provider companies would help create the critical mass of users and thereby help promote and build the VRM market. As a a result, having a legal services provider component as part of the VRM discussions feels valuable and compelling from my perspective. cheers, -bill On Mon, Jan 5, 2009 at 10:01 AM, Iain Henderson wrote: > Hi Folks, > > Happy new year - hope you all had a good break. > > I've had an opportunity emerge for some very high end lawyers who > specialise in tech/ open source to contribute thinking on VPI and the > options for taking things forward. They are of the view that this is a area > of sufficient interest to them that they are putting in a sizable chunk of > time 'pro bono'. > > I'm meeting them on Thursday for an initial deep dive into the subject area > and intend to focus on nature and deployment options for the contracts and > terms and conditions that individual through which an individual would make > their volunteered information available. > > This will be before our next call so I thought we might iterate by e-mail > in advance on this first meeting. > > My going in thoughts are that: > > - a range of standard contracts will be required, as per Creative Commons > > - they will have to be able to operate at a very granular level (individual > data element in a specific use scenario at a particular point in time) if > they are to be meaningful (this is where most privacy legislation falls down > in my view) > > - they should be machine discoverable and readable in order to automate the > process of find and engage > > - they will have to be realistic in terms of the supply side being able to > comply, although that bar may be raised over time > > - they will have to be couched in language readily understandable by > individuals, probably involving the use of icons to represent contract > choices/ sub-choices > > Anyone have any comments/ further thoughts prior to the lawyer meeting? > > 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. > > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Wed Jan 7 03:01:48 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Wed, 7 Jan 2009 11:01:48 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> Message-ID: <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> Thanks Eve, yes by all means bring in additional policy specialists to help out. Let's make this issue of VPI sharing contracts the subject of tomorrows call then and i'll feedback on what the lawyers have to say. I agree with your point on simplicity although that needs to be balanced with having enough depth to make a meaningful difference. My thoughts, such as they are so far, on contract design are that: 1) All variants of a VPI sharing contract should include a base level set of expectations of organisational behaviour that set the bar quite high (higher than any existing deployed privacy legislation). This base set of behaviours is akin to the 12 components of good organisational practice I shared at the start of the workgroup discussion - which in turn were derived from reviewing global privacy laws and sprinkling some VRM principles on top. 2) The contract variants are likely to be architected around the different stages in a CRM/ VRM relationship, as written up in the table in our use case documentation. So that might mean: a) Checking You Out/ Contract 1, 'i'm just searching, exploring, checking you out from afar to see whether we need to talk'. b) 'Dating'/ Contract 2, we're having some entry level interactions and transactions. c) Relationship start up/ Contract 3, we need to get the basic relationship enabling information in place. d) Relationship maintenance/ Contract 4, dealing with amends and updates to base level relationship information over time and any tactical problems that emerge. e) 'We get on well, let's develop this relationship'/ Contract 5, dealing with the added value information required to broaden, deepen and strengthen customer-supplier relationships. So - I think we need 5 contract types for VPI sharing; but that's very much up for debate and research. I still need to think about how 'mandatory relationships' are handled in the above contract set; they may be able to be weaved in with sub contracts, or need a 6th one. An illustration of what I mean by mandatory contracts is at this link, courtesy of our wonderful Identity and Passport Service in UK; i'm looking forward to telling them they can now subscribe to my feed by signing my contract. 3) All variants of a VPI sharing contract would include a 'what happens if we need to split up' scenario. The advantage in the above approach would be that it plumbs directly into existing buying and selling processes and information flows/ uses, and thus vendor side budgets and mind-sets. It also works at the level of the ways in which data is being used rather than at the data type level and thus can be much more easily spelt out in a contract. All of the above will have to be set in context of a wider VPI sharing framework/ story - which will need to include articulation of the business case for both parties, discovery processes, machine readable icons, trust marks, audit, compliance mechanisms and no doubt some technologies as well. Talk to you tomorrow. Cheers Iain On 6 Jan 2009, at 20:26, Eve Maler wrote: > Ian, this is great news, and I'm very interested to follow the wrok > (and maybe even suggest additional lawyerly/public policy resources > who are interested to help). > > Mary and I are supposed to get together sometime soon -- we planned > a meeting for last month but got beaten by the Seattle snow! This > is a good reminder for me to ping her again. > > Other comments: > > One of the goals of CC is to have the terms be readable by ordinary > people, legal specialists, and machines -- and with the various > requirements listed below, I think you've also hit all of these. > > I seem to recall that someone (Doc? don't recall) reached out to > Larry Lessig some months ago to discuss working together. Would > that be a possibility here? > > I strongly recommend that we have a goal of simplicity, and that > will mean the range of options can't be too large, and there are > basic usability principles to keep in mind. > > I agree about ultimately targeting finer-grained terms for sharing/ > using individual pieces of information, but would be happy with baby > steps that apply a set of terms to a *set* of data. For an internal > project I've got going, our analysis on this ended up interpreting a > set of data-sharing contract terms as *the* thing that defines a > data-sharing "relationship" (in reductionist fashion), such that if > you decide you want to share other information with the same vendor > under different terms, it's like setting up a different/parallel > relationship between the same parties. (This isn't so strange, if > you think about it; for example, NDAs generally are better if > they're not very broad, and so various business partners and I > operate under a multiplicity of NDAs and we have to pick the > applicable one before every conversation. And the same parties can > have a variety of purchase contracts at the same time.) > > Talk to y'all on the 8th! > > Eve > > On Jan 5, 2009, at 11:52 AM, Brett McDowell wrote: > >> Good news Iain. I'm be interested to know who the firm is once >> they agree. >> >> As for comments on next steps: >> >> - Has anyone reached out to Mary Rundle recently? That came up as >> an action item in the Boston VRM session (way back before is >> started snowing) but I don't recall who took the action... it might >> have been Drummond Reed if memory serves. But since she is >> responsible for leading the icon work in this space so far I think >> she should (at least given the explicit invitation to) be involved. >> >> - I'm working with the Cyberspace Committee of the American Bar >> Association on some other model contracts, not for individuals who >> disclose their information but for organizations who allow >> individuals to share valuable information across boundaries based >> on Federation agreements. Do you think there is enough similarity >> between that work and what you envision for VPI to invite them to >> this discussion? >> >> >> On Mon, Jan 5, 2009 at 1:01 PM, Iain Henderson > > wrote: >> Hi Folks, >> >> Happy new year - hope you all had a good break. >> >> I've had an opportunity emerge for some very high end lawyers who >> specialise in tech/ open source to contribute thinking on VPI and >> the options for taking things forward. They are of the view that >> this is a area of sufficient interest to them that they are putting >> in a sizable chunk of time 'pro bono'. >> >> I'm meeting them on Thursday for an initial deep dive into the >> subject area and intend to focus on nature and deployment options >> for the contracts and terms and conditions that individual through >> which an individual would make their volunteered information >> available. >> >> This will be before our next call so I thought we might iterate by >> e-mail in advance on this first meeting. >> >> My going in thoughts are that: >> >> - a range of standard contracts will be required, as per Creative >> Commons >> >> - they will have to be able to operate at a very granular level >> (individual data element in a specific use scenario at a particular >> point in time) if they are to be meaningful (this is where most >> privacy legislation falls down in my view) >> >> - they should be machine discoverable and readable in order to >> automate the process of find and engage >> >> - they will have to be realistic in terms of the supply side being >> able to comply, although that bar may be raised over time >> >> - they will have to be couched in language readily understandable >> by individuals, probably involving the use of icons to represent >> contract choices/ sub-choices >> >> Anyone have any comments/ further thoughts prior to the lawyer >> meeting? >> >> 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. >> >> >> >> >> >> _______________________________________________ >> Sig-vpi mailing list >> Sig-vpi at lists.projectliberty.org >> http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org >> >> >> >> -- >> Brett McDowell >> || phone = +1 (413) 652-1248 >> || blog = http://blog.brettmcdowell.com | twitter = http://twitter.com/brettmcdowell >> || Skype = myidym | AIM = myidiym | Gtalk = email at brettmcdowell.com >> || LinkedIn = http://tinyurl.com/brettonli | Facebook = http://tinyurl.com/brettonfb >> || my free/busy calendar = http://tinyurl.com/myfreebusy >> _______________________________________________ >> Sig-vpi mailing list >> Sig-vpi at lists.projectliberty.org >> http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Wed Jan 7 07:40:23 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Wed, 7 Jan 2009 15:40:23 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <891348600901062355k6cf12d95w8e842a5200d2acf8@mail.gmail.com> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <891348600901062355k6cf12d95w8e842a5200d2acf8@mail.gmail.com> Message-ID: <5B0323A9-1398-4F07-9E02-3EA3968F2BFD@mydex.org> Thanks Bill, yes I just about have enough energy left for pushing VPI forward!!! Yes, Mydex is likely to play in that space you mention, subject to our research/ focus groups telling us that would be of use. We have just about finished building our proof of concept and will take that to research later in Jan - will keep you informed. Cheers Iain On 7 Jan 2009, at 07:55, Bill Washburn wrote: > Hi Iain, > > Happy 2009 to you as a new father. Congratulations. > > A few thoughts: > > I could be way wrong, but since you're talking to attorneys the > following thought could be worth bit of discussion / examination. > To my mind, what consumers would greatly benefit from in the VRM > arena is what I would call a "contract services" or "legal services" > third party (Mydex might play this role in part, for instance as > part of their offerings) that is operated with sufficient legal > expertise and where the individual citizen/consumer/user would have > a trusted primary relationship with the contract services/legal > services provider. > > The legal services provider would manage and monitor and otherwise > maintain (via software efficiencies, obviously) any and all granular > iterations and permutations that a user may wish to exercise > regarding revealing information and preferences - perhaps the > dashboard metaphor interface would be a useful way to visualize > control. > > To me this is valuable to consider because we all know well that > reading/checking legal terms and conditions on the 'net is ignored > more or less universally. Also a few competing legal services > provider companies would help create the critical mass of users and > thereby help promote and build the VRM market. As a a result, > having a legal services provider component as part of the VRM > discussions feels valuable and compelling from my perspective. > > cheers, > -bill > > On Mon, Jan 5, 2009 at 10:01 AM, Iain Henderson > wrote: > Hi Folks, > > Happy new year - hope you all had a good break. > > I've had an opportunity emerge for some very high end lawyers who > specialise in tech/ open source to contribute thinking on VPI and > the options for taking things forward. They are of the view that > this is a area of sufficient interest to them that they are putting > in a sizable chunk of time 'pro bono'. > > I'm meeting them on Thursday for an initial deep dive into the > subject area and intend to focus on nature and deployment options > for the contracts and terms and conditions that individual through > which an individual would make their volunteered information > available. > > This will be before our next call so I thought we might iterate by e- > mail in advance on this first meeting. > > My going in thoughts are that: > > - a range of standard contracts will be required, as per Creative > Commons > > - they will have to be able to operate at a very granular level > (individual data element in a specific use scenario at a particular > point in time) if they are to be meaningful (this is where most > privacy legislation falls down in my view) > > - they should be machine discoverable and readable in order to > automate the process of find and engage > > - they will have to be realistic in terms of the supply side being > able to comply, although that bar may be raised over time > > - they will have to be couched in language readily understandable by > individuals, probably involving the use of icons to represent > contract choices/ sub-choices > > Anyone have any comments/ further thoughts prior to the lawyer > meeting? > > 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. > > > > > > _______________________________________________ > 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 Wed Jan 7 11:58:33 2009 From: joe at switchbook.com (Joe Andrieu) Date: Wed, 7 Jan 2009 11:58:33 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> Message-ID: <04ae01c97102$53981980$fac84c80$@com> Iain and I talked a bit about VPI in today's VRM Standards Committee call and I wanted to share some insights about his 5-stage relationship model, and subsequent 5-part approach to contracts. First, that every company goes through the same five steps with their customers. Second that these five steps are focal points for budgeting, projects, and operations. In other words, this structure is how CRM-savvy companies are already viewing and managing the customer relationship. We talked through some examples of what each stage means for someone who might be new to an online vendor: a) Checking You Out/ Contract 1, 'i'm just searching, exploring, checking you out from afar to see whether we need to talk'. Visiting the website, searching within that site, navigation b) 'Dating'/ Contract 2, we're having some entry level interactions and transactions. Filling out some forms. Downloading a free copy of something. Accepted a sales promotion. c) Relationship start up/ Contract 3, we need to get the basic relationship enabling information in place. Now divulged Identity information. The organization needs to know "who I am". Perhaps the user purchased a product and needs to submit billing and shipping information. d) Relationship maintenance/ Contract 4, dealing with amends and updates to base level relationship information over time and any tactical problems that emerge. Got married, got divorced, moved. e) 'We get on well, let's develop this relationship'/ Contract 5, dealing with the added value information required to broaden, deepen and strengthen customer-supplier relationships. Buying more of the same, buying a wider range. Some way a higher share of customer. Also new forms of engagement with the customer, such as focus groups or an affiliate program. SwitchBook's model doesn't parallel these five stages, simply because our scope is a specific multi-site, multi-day search rather than the relationship. However, these five stages seem to cover the field reasonably, even if the boundaries between each stage are a bit gray. Notably, participating in a promotion or downloading a free copy of a white paper (Stage 2) typically requires divulging identity information, which is Stage 3. Not for all companies, but for a lot. I guess that is the same as saying that companies like to use Stage 2 to convince people to move to Stage 3. Or, in the scope of search, entering information in a search form is, to me, moving to Stage 2 (that's revealing information about what they are looking for, leading to advanced "conversation" as they access new resources), while in Iain's thinking, search is still a part of navigation (Stage 1). What I like about the distinction that brings to the contracts conversation is we can now consider the data rights requirements for search and argue whether it falls under navigation-minimal requirements on usage-or whether or not it entails more sophisticated disclosure of personal information that should be more appropriately protected. [For instance, I'm completely uncomfortable with the level of rights management afforded my search history at Google.] -j -- Joe Andrieu SwitchBook http://www.switchbook.com joe at switchbook.com +1 (805) 705-8651 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Wed Jan 7 13:17:06 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Wed, 7 Jan 2009 21:17:06 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <04ae01c97102$53981980$fac84c80$@com> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <04ae01c97102$53981980$fac84c80$@com> Message-ID: Thanks Joe, yes that's a good build on my earlier notes - we can go further on the VPI call tomorrow. I don't doubt there will be difficulties with the 5 relationship stage contract approach, as there would be with any new approach - but my gut feel is that it will be a good place to start. Talk to you tomorrow. Cheers Iain On 7 Jan 2009, at 19:58, Joe Andrieu wrote: > Iain and I talked a bit about VPI in today's VRM Standards Committee > call and I wanted to share some insights about his 5-stage > relationship model, and subsequent 5-part approach to contracts. > > First, that every company goes through the same five steps with > their customers. Second that these five steps are focal points for > budgeting, projects, and operations. In other words, this structure > is how CRM-savvy companies are already viewing and managing the > customer relationship. > > We talked through some examples of what each stage means for someone > who might be new to an online vendor: > > a) Checking You Out/ Contract 1, 'i'm just searching, exploring, > checking you out from afar to see whether we need to talk'. > > Visiting the website, searching within that site, navigation > > b) 'Dating'/ Contract 2, we're having some entry level interactions > and transactions. > > Filling out some forms. Downloading a free copy of something. > Accepted a sales promotion. > > c) Relationship start up/ Contract 3, we need to get the basic > relationship enabling information in place. > > Now divulged Identity information. The organization needs to know > "who I am". Perhaps the user purchased a product and needs to submit > billing and shipping information. > > d) Relationship maintenance/ Contract 4, dealing with amends and > updates to base level relationship information over time and any > tactical problems that emerge. > > Got married, got divorced, moved. > > e) 'We get on well, let's develop this relationship'/ Contract 5, > dealing with the added value information required to broaden, deepen > and strengthen customer-supplier relationships. > > Buying more of the same, buying a wider range. Some way a higher > share of customer. Also new forms of engagement with the customer, > such as focus groups or an affiliate program. > > SwitchBook's model doesn't parallel these five stages, simply > because our scope is a specific multi-site, multi-day search rather > than the relationship. However, these five stages seem to cover the > field reasonably, even if the boundaries between each stage are a > bit gray. Notably, participating in a promotion or downloading a > free copy of a white paper (Stage 2) typically requires divulging > identity information, which is Stage 3. Not for all companies, but > for a lot. I guess that is the same as saying that companies like to > use Stage 2 to convince people to move to Stage 3. Or, in the scope > of search, entering information in a search form is, to me, moving > to Stage 2 (that's revealing information about what they are looking > for, leading to advanced "conversation" as they access new > resources), while in Iain's thinking, search is still a part of > navigation (Stage 1). > > What I like about the distinction that brings to the contracts > conversation is we can now consider the data rights requirements for > search and argue whether it falls under navigation?minimal > requirements on usage?or whether or not it entails more > sophisticated disclosure of personal information that should be more > appropriately protected. [For instance, I'm completely > uncomfortable with the level of rights management afforded my search > history at Google.] > > -j > > -- > Joe Andrieu > SwitchBook > http://www.switchbook.com > joe at switchbook.com > +1 (805) 705-8651 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 Eve.Maler at Sun.COM Fri Jan 9 11:09:08 2009 From: Eve.Maler at Sun.COM (Eve Maler) Date: Fri, 09 Jan 2009 11:09:08 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> Message-ID: <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> I may have missed an obvious place to mention this in the call yesterday, but my intuition is that 5 types/cycles of contracting is too many. C, D, and E seem to be iterations that could expand *or* reduce the scope of the relationship, depending on a variety of circumstances. So I'm guessing that all three will end up being normal variations of each other that can be tweaked at will, whether on initial relationship establishment or later. They might get hardened into simple checkboxes eventually, but I'm pretty sure we don't know all the scenarios yet, and for all we know they may vary widely per vertical (as new business models grow) or per type of customer (as we learn more about, and affect, online behavior). Eve On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: > Thanks Eve, yes by all means bring in additional policy specialists > to help out. > > Let's make this issue of VPI sharing contracts the subject of > tomorrows call then and i'll feedback on what the lawyers have to say. > > I agree with your point on simplicity although that needs to be > balanced with having enough depth to make a meaningful difference. > My thoughts, such as they are so far, on contract design are that: > > 1) All variants of a VPI sharing contract should include a base > level set of expectations of organisational behaviour that set the > bar quite high (higher than any existing deployed privacy > legislation). This base set of behaviours is akin to the 12 > components of good organisational practice I shared at the start of > the workgroup discussion - which in turn were derived from reviewing > global privacy laws and sprinkling some VRM principles on top. > > 2) The contract variants are likely to be architected around the > different stages in a CRM/ VRM relationship, as written up in the > table in our use case documentation. So that might mean: > > a) Checking You Out/ Contract 1, 'i'm just searching, exploring, > checking you out from afar to see whether we need to talk'. > > b) 'Dating'/ Contract 2, we're having some entry level interactions > and transactions. > > c) Relationship start up/ Contract 3, we need to get the basic > relationship enabling information in place. > > d) Relationship maintenance/ Contract 4, dealing with amends and > updates to base level relationship information over time and any > tactical problems that emerge. > > e) 'We get on well, let's develop this relationship'/ Contract 5, > dealing with the added value information required to broaden, deepen > and strengthen customer-supplier relationships. > > So - I think we need 5 contract types for VPI sharing; but that's > very much up for debate and research. I still need to think about > how 'mandatory relationships' are handled in the above contract set; > they may be able to be weaved in with sub contracts, or need a 6th > one. An illustration of what I mean by mandatory contracts is at > this link, courtesy of our wonderful Identity and Passport Service > in UK; i'm looking forward to telling them they can now subscribe to > my feed by signing my contract. > > 3) All variants of a VPI sharing contract would include a 'what > happens if we need to split up' scenario. > > The advantage in the above approach would be that it plumbs directly > into existing buying and selling processes and information flows/ > uses, and thus vendor side budgets and mind-sets. It also works at > the level of the ways in which data is being used rather than at the > data type level and thus can be much more easily spelt out in a > contract. > > All of the above will have to be set in context of a wider VPI > sharing framework/ story - which will need to include articulation > of the business case for both parties, discovery processes, machine > readable icons, trust marks, audit, compliance mechanisms and no > doubt some technologies as well. > > Talk to you tomorrow. > > Cheers > > Iain > Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at oidf.org Fri Jan 9 12:19:04 2009 From: bill at oidf.org (Bill Washburn) Date: Fri, 9 Jan 2009 12:19:04 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> Message-ID: <891348600901091219w2e978f1dg1824755bf32d2fec@mail.gmail.com> +1 Perhaps it might make sense to think in terms of one contractual base document on top of which there might be a few types of commercial relationships: (i) One time transaction - with no or absolute minimum sharing of data (Perhaps this is a brokered transaction completed through a 3rd party service provider) (ii) Anticipated on-going relationship with multiple transactions per year/cycle - mutually acceptable modest data sharing with machine2machine established contractual terms and conditions (iii) Loyalty program relationship - with benefits and agreements that are contractually entailed (iv) Occasionally there might be a potential relationship to explore that is so important that there ought to be an introductory vetting phase (mutual exploring of interest and compatibility). This might have to do high value relationships concerning, say, medicine, legal, employment, bank, insurance, retirement planning, other financial services. I apologize if this is off point. cheers, -bill On Fri, Jan 9, 2009 at 11:09 AM, Eve Maler wrote: > I may have missed an obvious place to mention this in the call yesterday, > but my intuition is that 5 types/cycles of contracting is too many. C, D, > and E seem to be iterations that could expand *or* reduce the scope of the > relationship, depending on a variety of circumstances. So I'm guessing that > all three will end up being normal variations of each other that can be > tweaked at will, whether on initial relationship establishment or later. > They might get hardened into simple checkboxes eventually, but I'm pretty > sure we don't know all the scenarios yet, and for all we know they may vary > widely per vertical (as new business models grow) or per type of customer > (as we learn more about, and affect, online behavior). > > Eve > > On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: > > Thanks Eve, yes by all means bring in additional policy specialists to help > out. > Let's make this issue of VPI sharing contracts the subject of tomorrows > call then and i'll feedback on what the lawyers have to say. > > I agree with your point on simplicity although that needs to be balanced > with having enough depth to make a meaningful difference. My thoughts, such > as they are so far, on contract design are that: > > 1) All variants of a VPI sharing contract should include a base level set > of expectations of organisational behaviour that set the bar quite high > (higher than any existing deployed privacy legislation). This base set of > behaviours is akin to the 12 components of good organisational practice I > shared at the start of the workgroup discussion - which in turn were derived > from reviewing global privacy laws and sprinkling some VRM principles on > top. > > 2) The contract variants are likely to be architected around the different > stages in a CRM/ VRM relationship, as written up in the table in our use > case documentation. So that might mean: > > a) Checking You Out/ Contract 1, 'i'm just searching, exploring, checking > you out from afar to see whether we need to talk'. > > b) 'Dating'/ Contract 2, we're having some entry level interactions and > transactions. > > c) Relationship start up/ Contract 3, we need to get the basic relationship > enabling information in place. > > d) Relationship maintenance/ Contract 4, dealing with amends and updates to > base level relationship information over time and any tactical problems that > emerge. > > e) 'We get on well, let's develop this relationship'/ Contract 5, dealing > with the added value information required to broaden, deepen and strengthen > customer-supplier relationships. > > So - I think we need 5 contract types for VPI sharing; but that's very much > up for debate and research. I still need to think about how 'mandatory > relationships' are handled in the above contract set; they may be able to be > weaved in with sub contracts, or need a 6th one. An illustration of what I > mean by mandatory contracts is at this link, > courtesy of our wonderful Identity and Passport Service in UK; i'm looking > forward to telling them they can now subscribe to my feed by signing my > contract. > > 3) All variants of a VPI sharing contract would include a 'what happens if > we need to split up' scenario. > > The advantage in the above approach would be that it plumbs directly into > existing buying and selling processes and information flows/ uses, and thus > vendor side budgets and mind-sets. It also works at the level of the ways in > which data is being used rather than at the data type level and thus can be > much more easily spelt out in a contract. > > All of the above will have to be set in context of a wider VPI sharing > framework/ story - which will need to include articulation of the business > case for both parties, discovery processes, machine readable icons, trust > marks, audit, compliance mechanisms and no doubt some technologies as well. > > Talk to you tomorrow. > > Cheers > > Iain > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain.henderson at mydex.org Fri Jan 9 14:31:59 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Fri, 9 Jan 2009 22:31:59 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> Message-ID: <11D10B05-5ADA-49FF-9475-5176F407145A@mydex.org> Thanks Eve, as you say - 5 may be too many in one respect and even not enough in others. We don't know yet and even when we develop our thinking further and test with use cases then i'd still want to find a way to fund some heavy duty research with end users and organisations. The perspective i'm coming from is that the CRM practices VPI and VRM must interface with are vastly more complex than we have dared to discuss. In my day job in customer management consultancy I run assessments of how well organisations are doing in that area. That involves testing for 260 best practices, presence and quality of 55 types of customer and related data and 75 ways of using data. I'm reluctant to believe that we can interface with that level of complexity in a couple of contracts - but i'd love to be proved wrong. Anyway, I suggest I write up my thinking in a bit more detail and circulate in advance of the next call and then give it a good going over/ decide how best to develop further. As an aside, the lawyers I spoke to would like to see the issue addressed in one single contract with sub-clauses. Cheers Iain On 9 Jan 2009, at 19:09, Eve Maler wrote: > I may have missed an obvious place to mention this in the call > yesterday, but my intuition is that 5 types/cycles of contracting is > too many. C, D, and E seem to be iterations that could expand *or* > reduce the scope of the relationship, depending on a variety of > circumstances. So I'm guessing that all three will end up being > normal variations of each other that can be tweaked at will, whether > on initial relationship establishment or later. They might get > hardened into simple checkboxes eventually, but I'm pretty sure we > don't know all the scenarios yet, and for all we know they may vary > widely per vertical (as new business models grow) or per type of > customer (as we learn more about, and affect, online behavior). > > Eve > > On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: > >> Thanks Eve, yes by all means bring in additional policy specialists >> to help out. >> >> Let's make this issue of VPI sharing contracts the subject of >> tomorrows call then and i'll feedback on what the lawyers have to >> say. >> >> I agree with your point on simplicity although that needs to be >> balanced with having enough depth to make a meaningful difference. >> My thoughts, such as they are so far, on contract design are that: >> >> 1) All variants of a VPI sharing contract should include a base >> level set of expectations of organisational behaviour that set the >> bar quite high (higher than any existing deployed privacy >> legislation). This base set of behaviours is akin to the 12 >> components of good organisational practice I shared at the start of >> the workgroup discussion - which in turn were derived from >> reviewing global privacy laws and sprinkling some VRM principles on >> top. >> >> 2) The contract variants are likely to be architected around the >> different stages in a CRM/ VRM relationship, as written up in the >> table in our use case documentation. So that might mean: >> >> a) Checking You Out/ Contract 1, 'i'm just searching, exploring, >> checking you out from afar to see whether we need to talk'. >> >> b) 'Dating'/ Contract 2, we're having some entry level interactions >> and transactions. >> >> c) Relationship start up/ Contract 3, we need to get the basic >> relationship enabling information in place. >> >> d) Relationship maintenance/ Contract 4, dealing with amends and >> updates to base level relationship information over time and any >> tactical problems that emerge. >> >> e) 'We get on well, let's develop this relationship'/ Contract 5, >> dealing with the added value information required to broaden, >> deepen and strengthen customer-supplier relationships. >> >> So - I think we need 5 contract types for VPI sharing; but that's >> very much up for debate and research. I still need to think about >> how 'mandatory relationships' are handled in the above contract >> set; they may be able to be weaved in with sub contracts, or need a >> 6th one. An illustration of what I mean by mandatory contracts is >> at this link, courtesy of our wonderful Identity and Passport >> Service in UK; i'm looking forward to telling them they can now >> subscribe to my feed by signing my contract. >> >> 3) All variants of a VPI sharing contract would include a 'what >> happens if we need to split up' scenario. >> >> The advantage in the above approach would be that it plumbs >> directly into existing buying and selling processes and information >> flows/ uses, and thus vendor side budgets and mind-sets. It also >> works at the level of the ways in which data is being used rather >> than at the data type level and thus can be much more easily spelt >> out in a contract. >> >> All of the above will have to be set in context of a wider VPI >> sharing framework/ story - which will need to include articulation >> of the business case for both parties, discovery processes, machine >> readable icons, trust marks, audit, compliance mechanisms and no >> doubt some technologies as well. >> >> Talk to you tomorrow. >> >> Cheers >> >> Iain >> > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > 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 Fri Jan 9 14:38:41 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Fri, 9 Jan 2009 22:38:41 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <891348600901091219w2e978f1dg1824755bf32d2fec@mail.gmail.com> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> <891348600901091219w2e978f1dg1824755bf32d2fec@mail.gmail.com> Message-ID: <1FE60A20-F0A2-4703-AD65-AC971FAFC456@mydex.org> Thanks Bill, no not off point at all. As per my note to Eve, the lawyerly preference/ suggestion was for one base document. I'll write up the logic of how I get to the current 5 before the next meet and include reference to the points you make. Cheers Iain On 9 Jan 2009, at 20:19, Bill Washburn wrote: > +1 > > Perhaps it might make sense to think in terms of one contractual > base document on top of which there might be a few types of > commercial relationships: > > (i) One time transaction - with no or absolute minimum sharing of > data > (Perhaps this is a brokered transaction completed through a 3rd > party service provider) > > (ii) Anticipated on-going relationship with multiple transactions > per year/cycle - mutually acceptable modest data sharing with > machine2machine established contractual terms and conditions > > (iii) Loyalty program relationship - with benefits and agreements > that are contractually entailed > > (iv) Occasionally there might be a potential relationship to explore > that is so important that there ought to be an introductory vetting > phase (mutual exploring of interest and compatibility). This might > have to do high value relationships concerning, say, medicine, > legal, employment, bank, insurance, retirement planning, other > financial services. > > I apologize if this is off point. > > cheers, > -bill > > On Fri, Jan 9, 2009 at 11:09 AM, Eve Maler wrote: > I may have missed an obvious place to mention this in the call > yesterday, but my intuition is that 5 types/cycles of contracting is > too many. C, D, and E seem to be iterations that could expand *or* > reduce the scope of the relationship, depending on a variety of > circumstances. So I'm guessing that all three will end up being > normal variations of each other that can be tweaked at will, whether > on initial relationship establishment or later. They might get > hardened into simple checkboxes eventually, but I'm pretty sure we > don't know all the scenarios yet, and for all we know they may vary > widely per vertical (as new business models grow) or per type of > customer (as we learn more about, and affect, online behavior). > > Eve > > On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: > >> Thanks Eve, yes by all means bring in additional policy specialists >> to help out. >> >> Let's make this issue of VPI sharing contracts the subject of >> tomorrows call then and i'll feedback on what the lawyers have to >> say. >> >> I agree with your point on simplicity although that needs to be >> balanced with having enough depth to make a meaningful difference. >> My thoughts, such as they are so far, on contract design are that: >> >> 1) All variants of a VPI sharing contract should include a base >> level set of expectations of organisational behaviour that set the >> bar quite high (higher than any existing deployed privacy >> legislation). This base set of behaviours is akin to the 12 >> components of good organisational practice I shared at the start of >> the workgroup discussion - which in turn were derived from >> reviewing global privacy laws and sprinkling some VRM principles on >> top. >> >> 2) The contract variants are likely to be architected around the >> different stages in a CRM/ VRM relationship, as written up in the >> table in our use case documentation. So that might mean: >> >> a) Checking You Out/ Contract 1, 'i'm just searching, exploring, >> checking you out from afar to see whether we need to talk'. >> >> b) 'Dating'/ Contract 2, we're having some entry level interactions >> and transactions. >> >> c) Relationship start up/ Contract 3, we need to get the basic >> relationship enabling information in place. >> >> d) Relationship maintenance/ Contract 4, dealing with amends and >> updates to base level relationship information over time and any >> tactical problems that emerge. >> >> e) 'We get on well, let's develop this relationship'/ Contract 5, >> dealing with the added value information required to broaden, >> deepen and strengthen customer-supplier relationships. >> >> So - I think we need 5 contract types for VPI sharing; but that's >> very much up for debate and research. I still need to think about >> how 'mandatory relationships' are handled in the above contract >> set; they may be able to be weaved in with sub contracts, or need a >> 6th one. An illustration of what I mean by mandatory contracts is >> at this link, courtesy of our wonderful Identity and Passport >> Service in UK; i'm looking forward to telling them they can now >> subscribe to my feed by signing my contract. >> >> 3) All variants of a VPI sharing contract would include a 'what >> happens if we need to split up' scenario. >> >> The advantage in the above approach would be that it plumbs >> directly into existing buying and selling processes and information >> flows/ uses, and thus vendor side budgets and mind-sets. It also >> works at the level of the ways in which data is being used rather >> than at the data type level and thus can be much more easily spelt >> out in a contract. >> >> All of the above will have to be set in context of a wider VPI >> sharing framework/ story - which will need to include articulation >> of the business case for both parties, discovery processes, machine >> readable icons, trust marks, audit, compliance mechanisms and no >> doubt some technologies as well. >> >> Talk to you tomorrow. >> >> Cheers >> >> Iain >> > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > > > _______________________________________________ > 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 Eve.Maler at Sun.COM Fri Jan 9 17:36:35 2009 From: Eve.Maler at Sun.COM (Eve Maler) Date: Fri, 09 Jan 2009 17:36:35 -0800 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <1FE60A20-F0A2-4703-AD65-AC971FAFC456@mydex.org> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> <891348600901091219w2e978f1dg1824755bf32d2fec@mail.gmail.com> <1FE60A20-F0A2-4703-AD65-AC971FAFC456@mydex.org> Message-ID: <1A17116E-9693-4A62-8A3F-2FC7E9DE66B2@Sun.COM> If we're going to ask individuals to create and tweak these, then we'll probably max out at a handful of main types, with variations on each. CC has six main licenses, each with options (http://creativecommons.org/about/licenses/ ); I have no idea if we can succeed in hitting such a target, but they had reasons for keeping the main list small, and we'll probably have the same reasons. It would be very nice to get the process down to a radio button press! (CC example from Flickr) -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.png Type: image/png Size: 20190 bytes Desc: not available URL: -------------- next part -------------- Eve On Jan 9, 2009, at 2:38 PM, Iain Henderson wrote: > Thanks Bill, no not off point at all. As per my note to Eve, the > lawyerly preference/ suggestion was for one base document. > > I'll write up the logic of how I get to the current 5 before the > next meet and include reference to the points you make. > > Cheers > > Iain > > On 9 Jan 2009, at 20:19, Bill Washburn wrote: > >> +1 >> >> Perhaps it might make sense to think in terms of one contractual >> base document on top of which there might be a few types of >> commercial relationships: >> >> (i) One time transaction - with no or absolute minimum sharing of >> data >> (Perhaps this is a brokered transaction completed through a 3rd >> party service provider) >> >> (ii) Anticipated on-going relationship with multiple transactions >> per year/cycle - mutually acceptable modest data sharing with >> machine2machine established contractual terms and conditions >> >> (iii) Loyalty program relationship - with benefits and agreements >> that are contractually entailed >> >> (iv) Occasionally there might be a potential relationship to >> explore that is so important that there ought to be an introductory >> vetting phase (mutual exploring of interest and compatibility). >> This might have to do high value relationships concerning, say, >> medicine, legal, employment, bank, insurance, retirement planning, >> other financial services. >> >> I apologize if this is off point. >> >> cheers, >> -bill >> >> On Fri, Jan 9, 2009 at 11:09 AM, Eve Maler wrote: >> I may have missed an obvious place to mention this in the call >> yesterday, but my intuition is that 5 types/cycles of contracting >> is too many. C, D, and E seem to be iterations that could expand >> *or* reduce the scope of the relationship, depending on a variety >> of circumstances. So I'm guessing that all three will end up being >> normal variations of each other that can be tweaked at will, >> whether on initial relationship establishment or later. They might >> get hardened into simple checkboxes eventually, but I'm pretty sure >> we don't know all the scenarios yet, and for all we know they may >> vary widely per vertical (as new business models grow) or per type >> of customer (as we learn more about, and affect, online behavior). >> >> Eve >> >> On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: >> >>> Thanks Eve, yes by all means bring in additional policy >>> specialists to help out. >>> >>> Let's make this issue of VPI sharing contracts the subject of >>> tomorrows call then and i'll feedback on what the lawyers have to >>> say. >>> >>> I agree with your point on simplicity although that needs to be >>> balanced with having enough depth to make a meaningful difference. >>> My thoughts, such as they are so far, on contract design are that: >>> >>> 1) All variants of a VPI sharing contract should include a base >>> level set of expectations of organisational behaviour that set the >>> bar quite high (higher than any existing deployed privacy >>> legislation). This base set of behaviours is akin to the 12 >>> components of good organisational practice I shared at the start >>> of the workgroup discussion - which in turn were derived from >>> reviewing global privacy laws and sprinkling some VRM principles >>> on top. >>> >>> 2) The contract variants are likely to be architected around the >>> different stages in a CRM/ VRM relationship, as written up in the >>> table in our use case documentation. So that might mean: >>> >>> a) Checking You Out/ Contract 1, 'i'm just searching, exploring, >>> checking you out from afar to see whether we need to talk'. >>> >>> b) 'Dating'/ Contract 2, we're having some entry level >>> interactions and transactions. >>> >>> c) Relationship start up/ Contract 3, we need to get the basic >>> relationship enabling information in place. >>> >>> d) Relationship maintenance/ Contract 4, dealing with amends and >>> updates to base level relationship information over time and any >>> tactical problems that emerge. >>> >>> e) 'We get on well, let's develop this relationship'/ Contract 5, >>> dealing with the added value information required to broaden, >>> deepen and strengthen customer-supplier relationships. >>> >>> So - I think we need 5 contract types for VPI sharing; but that's >>> very much up for debate and research. I still need to think about >>> how 'mandatory relationships' are handled in the above contract >>> set; they may be able to be weaved in with sub contracts, or need >>> a 6th one. An illustration of what I mean by mandatory contracts >>> is at this link, courtesy of our wonderful Identity and Passport >>> Service in UK; i'm looking forward to telling them they can now >>> subscribe to my feed by signing my contract. >>> >>> 3) All variants of a VPI sharing contract would include a 'what >>> happens if we need to split up' scenario. >>> >>> The advantage in the above approach would be that it plumbs >>> directly into existing buying and selling processes and >>> information flows/ uses, and thus vendor side budgets and mind- >>> sets. It also works at the level of the ways in which data is >>> being used rather than at the data type level and thus can be much >>> more easily spelt out in a contract. >>> >>> All of the above will have to be set in context of a wider VPI >>> sharing framework/ story - which will need to include articulation >>> of the business case for both parties, discovery processes, >>> machine readable icons, trust marks, audit, compliance mechanisms >>> and no doubt some technologies as well. >>> >>> Talk to you tomorrow. >>> >>> Cheers >>> >>> Iain >>> Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc. From iain.henderson at mydex.org Sat Jan 10 01:02:24 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Sat, 10 Jan 2009 09:02:24 +0000 Subject: [Sig-vpi] Input from Lawyers on VPI Contracts In-Reply-To: <1A17116E-9693-4A62-8A3F-2FC7E9DE66B2@Sun.COM> References: <3A46DA4D-92FE-459E-A1F3-C511749C2E90@mydex.org> <9EB1D6FC-D344-4D5C-B5A6-2E94C2D65D27@mydex.org> <599D4417-648D-48DC-9D90-8A34F618B6A3@Sun.COM> <891348600901091219w2e978f1dg1824755bf32d2fec@mail.gmail.com> <1FE60A20-F0A2-4703-AD65-AC971FAFC456@mydex.org> <1A17116E-9693-4A62-8A3F-2FC7E9DE66B2@Sun.COM> Message-ID: Yes, CC is certainly one of the models to consider and likely to be a good one. I spoke to Renee Lloyd about this i at the last VRM event at Berkman and she advised that the CC folks learnt a lot during deployment - and that actual use in practice is by no means exactly as intentioned. We were due to discuss this in more detail before x'mas but it got lost in the festivities - i'll re-arrange and feedback to the group. Thanks Iain On 10 Jan 2009, at 01:36, Eve Maler wrote: > If we're going to ask individuals to create and tweak these, then > we'll probably max out at a handful of main types, with variations > on each. CC has six main licenses, each with options (http://creativecommons.org/about/licenses/ > ); I have no idea if we can succeed in hitting such a target, but > they had reasons for keeping the main list small, and we'll probably > have the same reasons. It would be very nice to get the process > down to a radio button press! (CC example from Flickr) > > > > > > Eve > > On Jan 9, 2009, at 2:38 PM, Iain Henderson wrote: > >> Thanks Bill, no not off point at all. As per my note to Eve, the >> lawyerly preference/ suggestion was for one base document. >> >> I'll write up the logic of how I get to the current 5 before the >> next meet and include reference to the points you make. >> >> Cheers >> >> Iain >> >> On 9 Jan 2009, at 20:19, Bill Washburn wrote: >> >>> +1 >>> >>> Perhaps it might make sense to think in terms of one contractual >>> base document on top of which there might be a few types of >>> commercial relationships: >>> >>> (i) One time transaction - with no or absolute minimum sharing of >>> data >>> (Perhaps this is a brokered transaction completed through a 3rd >>> party service provider) >>> >>> (ii) Anticipated on-going relationship with multiple transactions >>> per year/cycle - mutually acceptable modest data sharing with >>> machine2machine established contractual terms and conditions >>> >>> (iii) Loyalty program relationship - with benefits and agreements >>> that are contractually entailed >>> >>> (iv) Occasionally there might be a potential relationship to >>> explore that is so important that there ought to be an >>> introductory vetting phase (mutual exploring of interest and >>> compatibility). This might have to do high value relationships >>> concerning, say, medicine, legal, employment, bank, insurance, >>> retirement planning, other financial services. >>> >>> I apologize if this is off point. >>> >>> cheers, >>> -bill >>> >>> On Fri, Jan 9, 2009 at 11:09 AM, Eve Maler >>> wrote: >>> I may have missed an obvious place to mention this in the call >>> yesterday, but my intuition is that 5 types/cycles of contracting >>> is too many. C, D, and E seem to be iterations that could expand >>> *or* reduce the scope of the relationship, depending on a variety >>> of circumstances. So I'm guessing that all three will end up >>> being normal variations of each other that can be tweaked at will, >>> whether on initial relationship establishment or later. They >>> might get hardened into simple checkboxes eventually, but I'm >>> pretty sure we don't know all the scenarios yet, and for all we >>> know they may vary widely per vertical (as new business models >>> grow) or per type of customer (as we learn more about, and affect, >>> online behavior). >>> >>> Eve >>> >>> On Jan 7, 2009, at 3:01 AM, Iain Henderson wrote: >>> >>>> Thanks Eve, yes by all means bring in additional policy >>>> specialists to help out. >>>> >>>> Let's make this issue of VPI sharing contracts the subject of >>>> tomorrows call then and i'll feedback on what the lawyers have to >>>> say. >>>> >>>> I agree with your point on simplicity although that needs to be >>>> balanced with having enough depth to make a meaningful >>>> difference. My thoughts, such as they are so far, on contract >>>> design are that: >>>> >>>> 1) All variants of a VPI sharing contract should include a base >>>> level set of expectations of organisational behaviour that set >>>> the bar quite high (higher than any existing deployed privacy >>>> legislation). This base set of behaviours is akin to the 12 >>>> components of good organisational practice I shared at the start >>>> of the workgroup discussion - which in turn were derived from >>>> reviewing global privacy laws and sprinkling some VRM principles >>>> on top. >>>> >>>> 2) The contract variants are likely to be architected around the >>>> different stages in a CRM/ VRM relationship, as written up in the >>>> table in our use case documentation. So that might mean: >>>> >>>> a) Checking You Out/ Contract 1, 'i'm just searching, exploring, >>>> checking you out from afar to see whether we need to talk'. >>>> >>>> b) 'Dating'/ Contract 2, we're having some entry level >>>> interactions and transactions. >>>> >>>> c) Relationship start up/ Contract 3, we need to get the basic >>>> relationship enabling information in place. >>>> >>>> d) Relationship maintenance/ Contract 4, dealing with amends and >>>> updates to base level relationship information over time and any >>>> tactical problems that emerge. >>>> >>>> e) 'We get on well, let's develop this relationship'/ Contract 5, >>>> dealing with the added value information required to broaden, >>>> deepen and strengthen customer-supplier relationships. >>>> >>>> So - I think we need 5 contract types for VPI sharing; but that's >>>> very much up for debate and research. I still need to think about >>>> how 'mandatory relationships' are handled in the above contract >>>> set; they may be able to be weaved in with sub contracts, or need >>>> a 6th one. An illustration of what I mean by mandatory contracts >>>> is at this link, courtesy of our wonderful Identity and Passport >>>> Service in UK; i'm looking forward to telling them they can now >>>> subscribe to my feed by signing my contract. >>>> >>>> 3) All variants of a VPI sharing contract would include a 'what >>>> happens if we need to split up' scenario. >>>> >>>> The advantage in the above approach would be that it plumbs >>>> directly into existing buying and selling processes and >>>> information flows/ uses, and thus vendor side budgets and mind- >>>> sets. It also works at the level of the ways in which data is >>>> being used rather than at the data type level and thus can be >>>> much more easily spelt out in a contract. >>>> >>>> All of the above will have to be set in context of a wider VPI >>>> sharing framework/ story - which will need to include >>>> articulation of the business case for both parties, discovery >>>> processes, machine readable icons, trust marks, audit, compliance >>>> mechanisms and no doubt some technologies as well. >>>> >>>> Talk to you tomorrow. >>>> >>>> Cheers >>>> >>>> Iain >>>> > > Eve Maler +1 425 947 4522 > Principal Engineer eve.maler @ sun.com > Business Alliances group Sun Microsystems, Inc. > 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 Tue Jan 20 05:46:34 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Tue, 20 Jan 2009 13:46:34 +0000 Subject: [Sig-vpi] Subject: REMINDER: VPI SIG Call Agenda - Jan 22, 2009 / Minutes posted - Jan 8, 2009 References: <947ea3330901192221l6131af2erf01cfbadda7620df@mail.gmail.com> Message-ID: <5891DD9D-23D9-4F2F-9F11-0A2294DBF854@mydex.org> > Hello VPI SIG, > > The next VPI SIG call will be: > > Date: Thursday - January 22, 2009 > Time: 09:00 - 10:00 PT / 12:00 - 13:00 ET / 15:00 - 16:00 GMT / > 16:00 - 17:00 CET > Dial In: > US toll-free number: 866-469-3239 > US toll number: 650-429-3300 > SIG Meeting Number or Access Code: 78701111# > Corresponding International Dial In Numbers > > Draft Agenda > > 1. Review Minutes > > - Last Call: January 8th, 2009: http://wiki.projectliberty.org/index.php/VPISIG20090108 > > 2. Discuss/ Agree Group Deliverables and Programme Plan > > - I'd like to discuss the 7 building blocks (see minutes) that > I believe are required to deliver VPI as a distinct and new class of > data and decide if we are up for turning this into a programme of > work with associated timetable and sub-group activity as necessary. > 3. Any Other Business > > Cheers Iain > > > Iain Henderson > Liberty Alliance - VPI SIG Chair 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: From iain.henderson at mydex.org Thu Jan 22 03:31:05 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Thu, 22 Jan 2009 11:31:05 +0000 Subject: [Sig-vpi] Todays Discussion Message-ID: <30FD7AA2-FFAE-49FA-B5ED-5B49D41D78F7@mydex.org> Folks, I said on the last call that i'd write up how I see the programme of work. I've not had time to do the full thing i'm afraid, but I have done the section on which technology standards and platforms are relevant to the various aspects of sharing volunteered personal information. I suggest we discuss this on the call today (see attached document); i'd like to get to the point where we have a decent view of which technologies we need to engage with and who we should speak to about them to assess the actual fit and identify gaps that need to be plugged. Talk to you later. Thursday, January 22, 2009 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# Corresponding International Dial In Numbers Iain -------------- next part -------------- A non-text attachment was scrubbed... Name: VPI Programme Plan Tech Standards 0.1 22nd Jan 09 Type: application/octet-stream Size: 42496 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 brett at projectliberty.org Thu Jan 22 06:15:15 2009 From: brett at projectliberty.org (Brett McDowell) Date: Thu, 22 Jan 2009 09:15:15 -0500 Subject: [Sig-vpi] Todays Discussion In-Reply-To: <30FD7AA2-FFAE-49FA-B5ED-5B49D41D78F7@mydex.org> References: <30FD7AA2-FFAE-49FA-B5ED-5B49D41D78F7@mydex.org> Message-ID: <923EA6DF-1971-43E4-A476-3558D4D6EC51@projectliberty.org> I may not be on the call today due to other conflicts. But I encourage the group to focus on the 3rd column of Iain's document "point of contact". So far the VPI SIG has operated mostly as an isolated group, separate from the other groups in Liberty Alliance. I think VPI will need to connect and "liaise" with TEG, BMEG, IAEG and PPEG going forward. Perhaps the group can identify some members who are active in the SIG to serve as liaisons/coordinators with the other groups? I will be happy to play this role to the extent I have the bandwidth but I think VPI will enjoy more rapid uptake if we can divide and conquer on this issue in particular. This will be key for the standards block and the certification program block. Cheers, On Jan 22, 2009, at 6:31 AM, Iain Henderson wrote: > Folks, > > I said on the last call that i'd write up how I see the programme of > work. > > I've not had time to do the full thing i'm afraid, but I have done > the section on which technology standards and platforms are relevant > to the various aspects of sharing volunteered personal information. > > I suggest we discuss this on the call today (see attached document); > i'd like to get to the point where we have a decent view of which > technologies we need to engage with and who we should speak to about > them to assess the actual fit and identify gaps that need to be > plugged. > > Talk to you later. > > Thursday, January 22, 2009 > 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# > Corresponding International Dial In Numbers > > 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. > > > > > _______________________________________________ > Sig-vpi mailing list > Sig-vpi at lists.projectliberty.org > http://lists.projectliberty.org/mailman/listinfo/sig-vpi_lists.projectliberty.org From iain.henderson at mydex.org Thu Jan 22 06:53:23 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Thu, 22 Jan 2009 14:53:23 +0000 Subject: [Sig-vpi] Todays Discussion In-Reply-To: <923EA6DF-1971-43E4-A476-3558D4D6EC51@projectliberty.org> References: <30FD7AA2-FFAE-49FA-B5ED-5B49D41D78F7@mydex.org> <923EA6DF-1971-43E4-A476-3558D4D6EC51@projectliberty.org> Message-ID: <3C9B3735-99A0-4FE9-A556-75D2E75A0D72@mydex.org> Thanks Brett, yes - the 3rd column is key, although obviously we'll need to populate the 2nd to get there. I agree we now need to reach out to other contacts; the group needed a bit of time to form and broadly agree a direction but I think we now have enough substance in place to reach out both within and outside of Liberty as necessary. Cheers Iain On 22 Jan 2009, at 14:15, Brett McDowell wrote: > I may not be on the call today due to other conflicts. But I > encourage the group to focus on the 3rd column of Iain's document > "point of contact". So far the VPI SIG has operated mostly as an > isolated group, separate from the other groups in Liberty Alliance. > I think VPI will need to connect and "liaise" with TEG, BMEG, IAEG > and PPEG going forward. Perhaps the group can identify some members > who are active in the SIG to serve as liaisons/coordinators with the > other groups? I will be happy to play this role to the extent I > have the bandwidth but I think VPI will enjoy more rapid uptake if > we can divide and conquer on this issue in particular. This will be > key for the standards block and the certification program block. > > Cheers, > > On Jan 22, 2009, at 6:31 AM, Iain Henderson wrote: > >> Folks, >> >> I said on the last call that i'd write up how I see the programme >> of work. >> >> I've not had time to do the full thing i'm afraid, but I have done >> the section on which technology standards and platforms are >> relevant to the various aspects of sharing volunteered personal >> information. >> >> I suggest we discuss this on the call today (see attached >> document); i'd like to get to the point where we have a decent view >> of which technologies we need to engage with and who we should >> speak to about them to assess the actual fit and identify gaps that >> need to be plugged. >> >> Talk to you later. >> >> Thursday, January 22, 2009 >> 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# >> Corresponding International Dial In Numbers >> >> 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. >> >> >> >> >> _______________________________________________ >> 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 iain.henderson at mydex.org Thu Jan 22 09:05:07 2009 From: iain.henderson at mydex.org (Iain Henderson) Date: Thu, 22 Jan 2009 17:05:07 +0000 Subject: [Sig-vpi] Document from earlier today re-sent as a PDF as some people had format issues Message-ID: A non-text attachment was scrubbed... Name: VPI Programme Plan Tech Standards 0.1 22nd Jan 09.pdf Type: application/pdf Size: 53430 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 Eve.Maler at Sun.COM Tue Jan 27 09:56:17 2009 From: Eve.Maler at Sun.COM (Eve Maler) Date: Tue, 27 Jan 2009 09:56:17 -0800 Subject: [Sig-vpi] SAML-related action items Message-ID: <2ABA76E2-6160-4BD6-86DE-D237F18366C0@sun.com> I took two AIs in the last call; here's an attempt to fulfill them: * SAML standardization of identifiers: In Section 8.3 of SAML2's "core" spec, a number of formats are defined for SAML's "NameID" field: http://www.oasis-open.org/committees/download.php/22385/sstc-saml-core-errata-2.0-wd-04-diff.pdf (see page 87) - Unspecified (default value) - Email address (note that it's in the format of an email address, but it doesn't have to function as a communications endpoint) - X.509 subject name - Windows domain qualified name - Kerberos principal name - Entity identifier (used for SAML authorities such as IdPs - format recommended to be a URI) * Existence proofs of sites that serve as "walk-up" SAML IdPs to the general public, allowing anyone to register for an identifier to be used with SAML protocols: - http://ssocircle.com/ - http://www.protectnetwork.org/ Eve Eve Maler +1 425 947 4522 Principal Engineer eve.maler @ sun.com Business Alliances group Sun Microsystems, Inc.