[WG-InfoSharing] Standard Information Sharing Agreements
Iain Henderson
iain.henderson at mydex.org
Wed Dec 15 05:25:59 EST 2010
Hi Richard, in this model it's not the users that need to 'come back', its the organisation that needs to come back for permissioned refresh from the personal data store. Obviously they can also choose to not do so and work with their ageing, base level data that they get through being a service provider.
I agree that T & C's are largely for the provider to set. I guess my assumption is that privacy and respect for personal data will become an area where providers will compete, the proverbial race to the top so to speak'.
Make sense?
Cheers
Iain
On 14 Dec 2010, at 10:05, Richard Baker-Donnelly wrote:
> Iain,
>
> I thought the whole idea was that users did not have to "come back" to
> maintain data. The issue of T&Cs is more driven by the provider of a
> service and how that change is experienced bythe consumer of the service.
>
> I am not sure what Sherrie is getting at with the differentiation around
> large and small purchases, my objective is as a consumer of services that I
> minimise the number of parties I need to inform of changes in core
> information. Other information around changes in preferences should not
> presumed to be part of an agreement unless it is relevent and core to part
> of a specific service they provide me. (Basic Data Protection - EU at
> least).
>
> Richard
>
> -----Original Message-----
> From: wg-infosharing-bounces at kantarainitiative.org
> [mailto:wg-infosharing-bounces at kantarainitiative.org] On Behalf Of Iain
> Henderson
> Sent: 13 December 2010 16:57
> To: Sherrie Noble
> Cc: wg-infosharing at kantarainitiative.org
> Subject: Re: [WG-InfoSharing] Standard Information Sharing Agreements
>
> Good point Sherrie,
>
> I should have flagged that another concept in this space we need to look at
> is for data attributes to have 'expiry dates', after which recipients need
> to come back for a refresh of data and T & C's.
>
> Iain
>
> On 13 Dec 2010, at 16:27, Sherrie Noble wrote:
>
>> Iain,
>>
>> I like it. One question--where there is a commitment to maintain data over
> time by individuals will there be timing somewhere in the background tied to
> that feature and linked to the nature of the customer behavior?
>>
>> Eg--large purchases are less likely to occur within months so data
> maintenance may not need to be verified every 3-6 months but smaller
> purchases might need more routine baseline data support. Length of residence
> in a specific location could also be a trigger for more routine data
> confirmation. Keeping it user centric is a great perspective but all
> users/buyers are not equal so there isn't any reason to keep the standards
> identical.
>>
>> Thanks for the summary.
>>
>> Sherrie Noble
>>
>> -----Original Message-----
>> From: wg-infosharing-bounces at kantarainitiative.org
>> [mailto:wg-infosharing-bounces at kantarainitiative.org] On Behalf Of
>> Iain Henderson
>> Sent: Monday, December 13, 2010 8:12 AM
>> To: Joe Andrieu; wg-infosharing at kantarainitiative.org
>> Subject: Re: [WG-InfoSharing] Standard Information Sharing Agreements
>>
>> Hi Joe/ all,
>>
>> To get things moving along for list discussion, i'd propose that we focus
> on what could well be the first standard information sharing agreement,
> namely the one that kicks in at stage 6 in the customer-supplier
> relationship framework, i.e. product delivery/ service configuration.
>>
>> I believe that there is one specific agreement that would work well in
> that space, in which the individual (buyer) commits to provide the minimum
> data-set required to enable a product delivery or service configuration, do
> so in an accurate, timely manner, with verification where necessary AND
> commits to maintaining that data over time (thus eliminating a huge cost for
> organisations).
>>
>> That particular agreement design cuts to the heart of many of the current
> issues around information sharing, and specifically plays to the
> well-established privacy principle of 'minimised data gathering' (i.e. an
> organisation will gather the minimum data required to fulfil its purposes,
> which is a component of OECD, EU and many other privacy legal frameworks).
> When I say 'well established', of course I do not mean 'well adhered to',
> indeed this principle is often largely ignored, and is the driver of privacy
> policies/ terms of use that are designed to ensure they are not read.
>>
>> To put that another way, the individuals purpose in the above scenario is,
> at its core, to have a product delivery or service set up. The
> organisational purpose in this scenario is most typically to deliver a
> product/ configure a service AND to then secure data for use in other
> contexts (e.g. for direct marketing, onward re-sale, or fraud management).
>>
>> Asking organisations to give that up is clearly a big stick, but offering
> the carrot of user-provisioned and maintained data, operating within a trust
> framework, and above the bar of global privacy regulation is a pretty big
> potential payback.
>>
>> Any thoughts/ feedback on this proposal?
>>
>> Cheers
>>
>> Iain
>>
>>
>>
>>
>> On 6 Dec 2010, at 18:15, Joe Andrieu wrote:
>>
>>> Ok, folks.
>>>
>>> We've gotten started on the next major phase of our work and I'd like to
> get some discussion going on the list.
>>>
>>> In our 11/22 meeting, we outlined the deliverables for the Standard
> Information Sharing Agreement work:
>>>
>>> 1. Several standard contract types covering different situations/use
> cases
>>> a. Data type & data use
>>>
>>> 2. Mechanics of agreement
>>> a. How vendors public, discover & agree
>>> b. How individuals publish, discover & agree
>>> c. Compliance
>>> i. Technology
>>> ii. Policy
>>> d. Iconography & Labels
>>> i. Lawyer, human, machine readable
>>>
>>> We agreed that our initial focus would be the car buying pRFP scenario.
>>>
>>> http://kantarainitiative.org/confluence/display/infosharing/Personal+
>>> RFP+Engagement+Model
>>>
>>> SO, with that framework, what data types & uses should we start out with?
>>>
>>>
>>> In our meeting today, we discussed the 11-stage Customer-Supplier
> Engagement Framework and how each stage in that framework provides guidance
> for data types & uses.
>>>
>>> I'd like to propose that what might end up working is a distinct set of
> types & uses for on each step, rather than a monolithic information sharing
> agreement that is supposed to manage the ENTIRE relationship. We might be
> able to consolidate some of these once we map them out, but I think breaking
> it into the 11 steps could work nicely.
>>>
>>> This does mean we'll end up with more than 3-5 patterns, but the benefit
> of an incremental approach to permissions seems compelling.
>>>
>>> 1. Disclosure and permissions and develop as the relationship develops,
> allowing trust to grow incrementally, minimizing risks upfront and covering
> required uses and data as required.
>>>
>>> 2. Context for each stage is clearer for both buyer & seller, and
> therefore the permissions and scope should be much easier to understand.
>>>
>>> 3. The stages provide interface guidance for embedding the permissioning
> directly in the workflow, rather than as a great big chart of checkboxes.
> See Alan Karp's work at IIW
> http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=alan+karp+IIW and
> http://iiw.idcommons.net/Making_Security_Decisions_Disappear in particular.
>>>
>>>
>>> In short, I think the first question in the permissions agreement
> architecture is "What stage of the relationship are we?" Everything else
> flows from there.
>>>
>>> Thoughts?
>>>
>>> -j
>>> --
>>> Joe Andrieu
>>>
>>> joe at andrieu.net
>>>
>>> +1 (805) 705-8651
>>>
>>> _______________________________________________
>>> WG-InfoSharing mailing list
>>> WG-InfoSharing at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>
>
> 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.
>
>
>
>
> _______________________________________________
> WG-InfoSharing mailing list
> WG-InfoSharing at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-infosharing
>
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.
More information about the WG-InfoSharing
mailing list