Child pages
  • Charter Final Draft for Review
Skip to end of metadata
Go to start of metadata

Charter 2019 Final draft

(1) WG NAME (and any acronym or abbreviation of the name): The WG name, acronym and abbreviation must not include trademarks not owned by the Organization, or content that is infringing, harmful, or inappropriate.

Information Sharing Work Group (ISWG)

(2) PURPOSE: Please provide a clear statement of purpose and justification why the proposed WG is necessary.

The volume and frequency of sharing of information about, by, and from individuals have outpaced the ability to manage it; and surveillance capitalism is now the norm. The current system of regulations and solutions, e.g. GDPR, privacy policies and terms of use, is insufficient for the control of personal data and its use, despite that often being the stated goal. In this context, this workgroup is developing open specifications enabling interoperable infrastructure for the control of personal data and its use.

The individual is the optimal point of origination and integration of data that is about them. The role of this WG is to shepherd open specifications for new technologies by which personal information can flow and be processed under the control of the individual, improving the relationship between demand and supply with personal data control. This will include solutions built specifically for individuals, and also those that fostering mutually beneficial information sharing between individuals and organizations.

Note that this WG relies on the CMS WG [with revised charter] to provide the necessary legal and business requirements to develop technical standards.

(3) SCOPE: Explain the scope and definition of the planned work.
Become and/or initiate an active public discussion forum for the collection, development, and analysis of use cases, scenarios, and specifications improving information sharing as seen from the individual’s perspective.
Foster awareness of and participation in open information-sharing infrastructure(s) from the broadest stakeholder cross-section possible, both the near-term use case phase which has taken place in this working group, the mid-term specification and practical framework build phase (where we are now), and the long-term adoption of the specifications by SSO (Standards Setting Organizations).
Create recommendations, technical specifications and reference implementations covering information sharing usability, security, privacy, interoperability et al that enable persons to exert control over information sharing.
Develop guidance and supporting materials in order to advocate the adoption of specific standard practices, policies, and terms to increase the quality of information sharing practices. Become an umbrella location for new and relevant information sharing technology initiatives should they wish to join our community.
Create and maintain a registry of known implementations that plan to or have adopted the WG recommendations and technical specifications.
Promote and advocate for the implementations of workgroup participants.
Engage and draw upon work in other organizations to coordinate e
fforts.

(4) DRAFT TECHNICAL SPECIFICATIONS: List Working Titles of draft Technical Specifications to be produced (if any), projected completion dates, and the Standards Setting Organization(s) to which they will be submitted upon approval by the Membership.
Consent Receipt Specification – Building on existing version, accommodating existing and new requirements; timing and resources to be discussed

Kantara Data Receipt Framework Specification – each of the Receipt specs are profiles of the Framework Specification
Create Personal Data Receipt Profile Specification - timing and resources to be discussed Specification covering Data Usage Statement – for the user to reconcile their receipts against the institution’s transactional records.

Information Sharing Control Panel/ Agent Reference Implementation
Sample Legal Information Sharing Agreement Contracts that illustrate how the reference model can be used to allow the individual to share data whilst retaining control.
It is the intention of the Information Sharing WG to ultimately submit the specifications listed above to an appropriate Standards Settings Organization for full life-cycle maintenance. The receiving organizations will be determined on a per-specification basis.

(5) OTHER DRAFT RECOMMENDATIONS: Other Draft Recommendations and projected completion dates for submission for All Member Ballot.

The ISWG is open for supporting and collaborating with organizations that have specification work or standards in this space.

(6) LEADERSHIP: Proposed WG Chair and Editor(s) (if any) subject to confirmation by a vote of the WG Participants.

TBC
(7) AUDIENCE: Anticipated audience or users of the work.

Developers, entrepreneurs, privacy and data protection advocates, policymakers, developers, and deployers, both internal and external, to large organizations that manage services for individual customers.

(8) DURATION: Objective criteria for determining when the work of the WG has been completed (or a statement that the WG is intended to be a standing WG to address work that is expected to be ongoing).

The Kantara Leadership Council charters the Information Sharing Work Group for five years. It may be amended from time to time, with changes approved by the Leadership Council. This charter will expire in August 2021.

(9) IPR POLICY: The Organization approved Intellectual Property Rights Policy under which the WG will operate.

Kantara IPR Policy - Option Patent and Copyright Reciprocal Royalty Free with Opt-Out to (RAND) <can we replace with new IPR policy?>

(10) RELATED WORK AND LIAISONS: Related work being done in other WGs or other organizations and any proposed liaison with those other WGs or organizations. Conference Content Committees - to secure speaking spots at conferences.
ISO Liaison - to synchronize timelines for specification development and to propose new international standards.

UMA - to collaborate on specifications and identification of requirements. Project VRM - solicit requirements and feedback.
Customer Commons - solicit requirements and feedback.
MyData Global -solicit requirements and feedback.

Me2B Alliance- exchange status updates and collaborate as appropriate.

(11) CONTRIBUTIONS (optional): A list of contributions that the proposers anticipate will be made to the WG.

TBC

(12) PROPOSERS: Names, email addresses, and any constituent affiliations of at least the minimum set of proposers required to support forming the WG.
Iain Henderson
John Wunderlich

Andrew Hughes Jim Pasquale James Aschberger Lisa LeVasseur History

July 23, 2013
First complete draft for consideration by the work group
July 1, 2013
Initial partial draft
Feb 2, 2016 Update of the new charter approved - need an iterative update on SDO - As Kantara may be new SDO for the WG
July 2019 Update

  • No labels

6 Comments

  1. Comments -

    It might be easier if its made clear that this is a Charter Update : Not a new Charter, and the proposal to change the name should be separate point of discussion or consensus  from the Charter Update.  This should include what happens to consent management works and specifications if its going to say or go - where the work will happen, and perhaps a charter update for the CMSWG. 


    Section 4 - (4) DRAFT TECHNICAL SPECIFICATIONS: List Working Titles of draft Technical Specifications to be produced (if any),

    Section 5 - Other Draft Recommendations

    • This should be areas that the WG is interested in with a contact point, so people can get involved in future works 
    • This should have a link to info about how to get involved or start a new project - 


  2. Hello all

    my first participation and very green to Kantara so please be understanding (smile) Congratulations also for the excellent work being done.

    I'd be interested in another aspect of Consent which is on demonstrating Consent. This is basically a problem of non-repudiation and I have an introductory paper here on it. There will be a follow-up soon. This is also a problem that Nancy Kim raised, in a presentation for the group a few weeks ago, coming from the legal side. This could lead to a technical specification.

    Would this be of interest to this charter? And is this the best moment to raise it?

    (hope this all makes sense and I look forward to joining the calls from next week)


    --Vitor Jesus, UK, http://www.vitorjesus.com

    1. Jim

      Vitor,


      Excellent observation around the ideas of a common set of practices works being done in the consent management solutions WG. ANd would be of interest to the work there and part of the CMS Charter here: Updated Charter Final Draft. And I believe it would be the right place and time to raise it in this group, which just as it happens will meet next Wednesday, as the group meets every other week. Here: WG - Consent Management Solutions Home

      Nevertheless, there are several companies doing consent pre-and-post data collection.  I was also not able to open your link otherwise would have been happy to drill into your paper. 

  3. Dear Jim,

    Thanks for the comments. I'll join the call next week. Would be very good to hear the group's thoughts.

    Sorry for the broken link to the paper. Here's a new one.

    1. Jim

      Vitor:

      Passing along these observations from Tom Joens, who must be having login issues, as you must be login in order to reply. He also copied Mark Lizar, not sure why we all see this post, but nevertheless, these are from Tom:

      I tried to respond on the wiki - but that does not seem to be working.
      As jim suggested, several of us have been working on consent itself.
      I have been trying to capture user intent cryptographically for nearly 20 years. See  US 20110154505 A1 for one example.
      I have raised the idea of cryptographic intents in this group several times but have had no interest from the attendees.
      Mark's charter seems to be open enuf to include them if we could get sufficient interest.
      I strong disagree with your paper on using channel binding for identification purposes. eg TLS That has been tried many times to no avail.
      btw jim - try this url   http://www.open-access.bcu.ac.uk/7619/2/consent%20-%20camera.pdf   might work better.

      I introduced the following consent proposal into a different Kantara work group on US healthcare. It is based on user self-issued ids.
      here is my proposal https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding
      Let me know if the group would ever get the time to discuss this.
      Peace ..tom

      Back to Jim: So, between Tom's, suggested link and your refreshed link I will try, over the next few days, to take a look at it Vitor.


      THX..


      1. Thank you, Jim and Tom.

        I hoep to have the opportunity to discuss Tom's thoughts but I'll advance the following: I agree with Tom about channel bindings (smile)

        There's lots of work to be done in this area and most is very unclear – again, thanks for Kantara for being so visionary.

        --v