Re: [WG-InfoSharing] WG-InfoSharing Digest, Vol 99, Issue 8

[Tom Jones]

I disagree that the CR is designed for people. It is a machine to machine format spec. You need a render engine spec to make it human readible.

thx ..Tom (mobile)

On Feb 21, 2018 7:32 AM, <wg-infoshar...@kantarainitiative.org> wrote:

Send WG-InfoSharing mailing list submissions to
        wg-infosharing@kantarainitiative.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://kantarainitiative.org/mailman/listinfo/wg-infosharing
or, via email, send a message with subject or body 'help' to
        wg-infosharing-request@kantarainitiative.org

You can reach the person managing the list at
        wg-infosharing-owner@kantarainitiative.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of WG-InfoSharing digest..."


Today's Topics:

   1. Re: W3C Workshop - Data Privacy Controls and Vocabularies
      (Mark Lizar)


----------------------------------------------------------------------

Message: 1
Date: Wed, 21 Feb 2018 15:31:34 +0000
From: Mark Lizar <ma...@openconsent.com>
To: Mark Lizar <ma...@openconsent.com>
Cc: "wg-infosharing@kantarainitiative.org"
        <wg-infosharing@kantarainitiative.org>
Subject: Re: [WG-InfoSharing] W3C Workshop - Data Privacy Controls and
        Vocabularies
Message-ID: <03248CBA-D405-4C5B-8F6D-F887FE...@openconsent.com>
Content-Type: text/plain; charset="utf-8"

HI All,

I have progressed this input from the CISWG to this conference (see below for latest version). This input has evolved to make clear that the CR is about people interoperability and that we (CISWG) advocate that specs and tech, use the CR as an output format for people.

In this regard, the final output here is a proposal for CISWG to explore with other community efforts (and specifications) how to support the mapping of these efforts to the Consent Receipt work.

Please Review, comment and support - for call tomorrow.

Best Regards,

Mark

Input From Kantara CISWG:  For Data Privacy Controls & Vocabularies
https://lists.w3.org/Archives/Public/public-new-work/2018Jan/0017.html <https://lists.w3.org/Archives/Public/public-new-work/2018Jan/0017.html>
Consent and Information Sharing WG  (CISWG) at Kantara is  focused on creating an open machine and human readable privacy record  format for people that  maps to international standards and consent based legal notice requirements that vary from jurisdiction to jurisdiction.

In the CISWG work is developed from the perspective that  privacy, is not primarily about companies compliance, but about personal control of data and data processing transparency.   The consent receipt format captures; the identity of the privacy controllers and processors, maps the purpose to personal data categories and to data  types, then uses this specified purpose transparency to map what data is disclosed to 3rd parties.

The Consent  Receipt specification is intended to be usable and extensible by ?Vocabularies to link privacy policies, regulations and involved (business) processes?, to a privacy record format which we have called a consent receipt.    For example the COEL specification at OASIS and work is under way with UMA.

With the GDPR, privacy by default/design is the expectation removing the burden from people to organisations to make privacy the default.   The Consent Receipt specification is being adopted  by people facing technologies and infrastructure to provide a point of interoperability amongst records.

From this context of interoperable privacy  transparency that is usable for people,  the CISWG would also like to explore links and synergies using Linked Data vocabularies in  the context of related efforts such as those listed by W3C.


Consent Receipt Update
Consent Receipt Specification ?has now reached a v1.1 <https://kantarainitiative.org/confluence/download/attachments/76447870/Consent%20Receipt%20Specification%201_1_0%20DRAFT%208%20-%20clean.docx?version=1&modificationDate=1519153788000&api=v2> as this has gone through a 45 day public IPR review and 3 rounds of public comments, so it is getting quite stable.

The receipt is an open specification for the technical output people should receive when providing consent. In terms of interoperability the CISWG proposes that as a common privacy record output that a consent based  privacy vocabulary is of great value for linking data vocabularies to a single format.   For privacy, this means linking laws and legal (privacy and contract) vocabularies to technical lexicons and identity management protocols.

The Consent Receipt specification V1.1 is becoming an internationally applicable specification for consent records;  It is unique because it memorialises an action made by the individual in regard to the policies of an organisations.  This makes the organisation accountable to that policy and enables more than privacy compliance, by enabling semi-automated privacy rights/rights and preferences.






> On 19 Feb 2018, at 16:04, Mark Lizar <ma...@openconsent.com> wrote:
>
> Thanks Julian,
>
> Great comments !!
>
> Mark
>
>> On 18 Feb 2018, at 15:16, Mark Lizar <ma...@openconsent.com <mailto:ma...@openconsent.com>> wrote:
>>
>> HI,
>>
>> Due to some good advice and for ease of editing/commenting and contributing I have pasted the text into an open Google Doc,? <https://docs.google.com/document/d/1cxsFEvwZEUZa8bGF0sN7DpaaKk1qAn1wrCituyrdyGo/edit?usp=sharing>
>>
>> (Full link ?> https://docs.google.com/document/d/1cxsFEvwZEUZa8bGF0sN7DpaaKk1qAn1wrCituyrdyGo/edit?usp=sharing <https://docs.google.com/document/d/1cxsFEvwZEUZa8bGF0sN7DpaaKk1qAn1wrCituyrdyGo/edit?usp=sharing>)
>>
>> Best,
>>
>> Mark
>>
>>
>>> On 18 Feb 2018, at 11:34, Mark Lizar <ma...@openconsent.com <mailto:ma...@openconsent.com>> wrote:
>>>
>>> Input From Kantara CISWG:
>>>
>>> Consent Receipt Specification v1.1 is a significant development for privacy as it is a technical format designed for the purpose of standardising the technical output people receive when engaging with the privacy notice infrastructure of organisations.
>>>
>>> A Consent Receipt is a record of the privacy notices  provided for an explicit consent and is provided/generated at the time of consent to provide a record of privacy to a person.  The consent receipt is comprised of the information required in what is called a Subject Access Request and this is provided to the individual up front to enable people to withdraw consent as easy as they have provided it.
>>>
>>> The consent receipt is being rapidly adopted by people facing technologies and infrastructure and is intended to provide a point of interoperability for people.    As privacy, is not only about companies compliance, its personal and its about transparency over what privacy people do or do not have.  The Consent Receipt assists the individual to self regulate their behaviour and act autonomously.
>>>
>>> Transparency over privacy is a critical requirement to enable people with the tools to be autonomous in the digital age.  The V1.1 specification from the Kantara Consent & Information Sharing WG is the result of 4 years of work from a group of volunteers that are passionate about enabling people with tools to control their own personal information. The specification has been taken up by many other organisations, standards efforts and specifications.
>>>
>>> The V1.1 is an internationally applicable specification for consent records, it has been reviewed extensively as a format for making privacy transparency and personal data control interoperable for people.  It is unique because it memorialises an action made by the individual in regard to the policies of an organisations.  This makes the organisation accountable to that policy and enables more than privacy compliance, by enabling semi-automated privacy infrastructure so that the privacy rights around consent become more usable.
>>>
>>> Already there are a lot of organisations that have picked up the consent receipt for consent management solutions.  The field format in the consent receipt align with international standards like that from the ISO 29100, 29184, and contains the explicit consent notice requirements that are consistent globally.
>>>
>>> The receipt has a specified field format that can be extended for any privacy notice receipt and is intended to go beyond the use of explicit consent as a privacy receipt applies to 'implied consent transparency', no consent transparency, and even  privacy notices about no privacy transparency, as is required for privacy in the EU.
>>>
>>> CISWG would support a cross standards organisation effort to build interoperable privacy notice transparency that maps to efforts in W3C and the web of trust, bridging efforts in this space.
>>
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing@kantarainitiative.org <mailto:WG-InfoSharing@kantarainitiative.org>
>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>
> _______________________________________________
> WG-InfoSharing mailing list
> WG-InfoSharing@kantarainitiative.org
> https://kantarainitiative.org/mailman/listinfo/wg-infosharing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20180221/af72d7a1/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
WG-InfoSharing mailing list
WG-InfoSharing@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-infosharing


------------------------------

End of WG-InfoSharing Digest, Vol 99, Issue 8
*********************************************

[Mark Lizar]

Hi Tom, 

I sympathise with this comment and understand where it is coming from..   Although, In the specification, there is an appendix for the rendering a receipt into something that is human readable - and I would agree not necessarily understandable.  We have had quite a few discussions about this in the past and as a result, the design f the specifications is to have a minimum human readability. 

Of course, this could be explained in guidance for the receipt, and is a very good comment/issue, as it are these comments which will likely be addressed via a guidance first.  That being said, I do need to progress this document and submit this week.    

Does anyone else agree with this comment? 

Mark Lizar | Open Consent | 22 Wenlock Rd, London|  N1 7GU
P +44 (0) 208 123-2476 | E ma...@openconsent.com 
| Twitter @smartopian | Web https://www.openconsent.com |

_______________________________________________
WG-InfoSharing mailing list
WG-Info...@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-infosharing

[Mark Lizar]

Thanks Tom, 

I think you might be referring to the first edit,  along with my sloppy approach to working on a WG submission via the list. 

I have polished up this  third edit and pasted it below for a final review.  It should come across much more polished and, in regard to your earlier comment, I have edited the text to 

"focused on creating an open machine and human usable consent receipt  format “ this is slightly more vague, and emphasis tis purpose more as a utility for consent, rather than something that is read by a human. Let me kno if this ‘weasel word’ works better :-)

Best Regards,

Mark

*** submission_final draft stage *** 

Input From Kantara CISWG:  For Data Privacy Controls & Vocabularies

https://lists.w3.org/Archives/Public/public-new-work/2018Jan/0017.html

Consent and Information Sharing WG  (CISWG) at the Kantara Initiative, is focused on creating an open machine and human usable consent receipt  format for people that all projects can use to map to international standards and consent based legal notice requirements that vary from jurisdiction to jurisdiction and context to context.

In the CISWG work is developed from the perspective that  privacy, is not primarily about companies compliance, but about personal control of data and data processing transparency.   The Consent Receipt v.1.1 format captures; the identity of the privacy controllers and processors, maps the purpose to personal data categories and to data  types, then uses this specified purpose transparency to provide a receipt for the consent.

In terms of legal language and interoperoperabtly,  the consent receipt was built and designed with key documents based on their legal providence,  which are the 1980 OECD FIPS principles and its derivatives. In addition, the lexicon has been taken from the ISO 29100 Privacy Framework, which was determined to be the international standard (between regions).     The ISO29100 framework effort co-ordinated amounts regulators and the Art29WP, as well as taking inputs from long standing contributors in the space.

This  WG approach to developing the specification was used in order to make the consent receipt  backward compatible legally with the core privacy notice requirements across jurisdictional domains for explicit consent.  (which was a core use case)

With the v1.1 almost finished, the next opportunity for CISWG  is to explore how it can best support the use of the receipt specification.

It is hoped that the Consent  Receipt specification is attractive for other work group efforts so that it can be extended for their use cases with “Vocabularies to link privacy policies, regulations and involved (business) processes”  For example the COEL-TC  specification at OASIS and User Managed Access (UMA) WG at the Kantara Initiative. .  

 The Consent Receipt specification is being adopted by people facing technologies who realise the economic benefits of consent interoperability.  This is in no small part due to the GDPR, privacy by default/design expectations that are projected to shifting the burden of privacy from people to organisations.

From this context, of interoperable privacy  transparency,  the CISWG would also like to explore links and synergies using Linked Data vocabularies, in the context of related efforts such as those listed by W3C.

Consent Receipt Status Update

Consent Receipt Specification  has now reached a v1.1 as this has gone through a 45 day public IPR review and 3 rounds of public comments.    The next steps are for a WG ballot then it will go to an all community ballot for a vote from the Kantara Community before it is published.

 

On 22 Feb 2018, at 19:57, Mark Lizar <ma...@openconsent.com> wrote:

Thanks Tom, 

Will update and re-post - does anyone else have any comments before I do? 

- Mark

On 22 Feb 2018, at 19:29, Tom Jones <thomascli...@gmail.com> wrote:

To be clear this problem could be fixed with a few weasel words. The following is particularly bad.

Consent Receipt is a record of the privacy notices  provided for an explicit consent and is provided/generated at the time of consent to provide a record of privacy to a person.  The consent receipt is comprised of the information required in what is called a Subject Access Request and this is provided to the individual up front to enable people to withdraw consent as easy as they have provided it.

thx ..Tom (mobile)

Hi Tom, 

Message-ID: <03248CBA-D405-4C5B-8F6D-F887FE6E...@openconsent.com>

_______________________________________________
WG-InfoSharing mailing list
WG-InfoSharing@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-infosharing

[Tom Jones]

Yes, it passes the smell test.

If i were trying to make the case for the CR i would be more interested in how it fit into a commercial environment rather than a bunch of other obscure standards.

I was trying to that that with the following taxonomy of data privacy types. I had planned to introduce it the the consent management group, but Andrew excluded anything other than historical deployments.

Perhaps some day we can get people together who want to solve realworld problems. 

Personal Information evaluated for use in the Example

Note that the term Individual here means a human being. That should not be considered to prevent the RP from also supporting non human users.

1. Categories of data editing enabled for users of data contained in the user data base (these categories are shown part of the data base schema, but some fields may change categories as the relationship between the user and RP changes over time):
   1. Required by the operation of the site and not editable,
   2. Required by the site owner but editable by the user,
   3. Optional data editable by the user,
   4. Links from external IdPs that are removable by the user,
   5. Data provided by 3rd parties together with a link to those 3rd parties for redress by the user.
   6. Data provided by 3rd parties can be marked as in dispute by the user if they cannot alter it.
2. Personal data evaluated against the above categories is shown in the following model of the user. Where possible names used in the model match those used in the Open ID Connect standard claims. In those cases the lower case underline separate name was converted to a user friendly spelling and the background highlight with blue. Strictly speaking identity claims data is ONLY relevant in the AspNetUserLogins table, so this linkage is only for convenience as a taxonomy of the element names.

from this site: https://wiki.idesg.org/wiki/index.php?title=Best_Practices_and_Example_for_RP_System

Peace ..tom

[Mark Lizar]

Hi Tom, 

Great insight, in the context of this particular submission to the W3C, the case is being made for CR interoperability so privacy can be useable for people.   

This is not intended to make the commercial case as there is a lot of competition at the moment for making commercial cases. 

This is not to say that a WG activity, in which organisations, or individuals like yourself are invited to contribute consent receipt use cases,  isn;t a brilliant idea.  I think you aready have a core use case described in what you have just posted. 

This is something that has been very effectively accomplished in the UMA workgroup.   Here is a link to the use case section of the UMA wiki. 

In this regard, once the WG accepts the CR v1.1, (perhaps next week) the consent receipt spec is sent to the  Kantara Community to vote upon.   After this milestone, we could then work through and discuss these use cases as presented, on a scheduled basis. 

I bet there are a lot of companies and people interested in getting involved in commercial solutions presented by these use cases. 

Thans for this input 

- Mark

[Andrew Hughes]

I probably shouldn't respond to the barb... but...

The Consent Management Solutions WG has a publication project underway to document Best Current Practices of organizations that are already meeting high standards of practice for management of an individual's consent to process personal data, if that is what you refer to as 'historical deployments'. They are solving real-world problems today: they have solutions deployed and are actively expanding uptake. If you'd prefer different language: the publication helps to document existing implementations that have been developed by forward-thinking organizations.

For others in the Consent & Information Sharing WG that want to join the newly-formed Consent Management Solutions WG to contribute their current practices into this industry-leading work, the Group Participation Agreement is here: https://kantarainitiative.org/gpa-signup/?selectedGroup=40 WG meetings are every second week, the next one is March 7, 2018.

The Consent & Information Sharing WG (this list) has lots of important work to do once Consent Receipt v1.1 is published. We will be taking proposals for the next publication (Report or Recommendation) over the next month or two. Documentation of use case sounds like a strong candidate - we can work in the WG to write up the proposal for the WG to deliberate.

andrew.

Chair, Kantara Initiative Consent & Information Sharing WG

Andrew Hughes CISM CISSP 
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road, Victoria, BC V8P 2H8
AndrewHu...@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 

[Mark Lizar]

This evening we had an excellent Consent Receipt comment from an unnamed work group participant.    Which I would like to add to the bottom of the submission. 

IF another org/person would like to contribute a comment about the consent receipt for this submission, I would gladly include it, attributed or anonymous. 

Best, 

Mark 

New Comment for bottom of the CISWG submission to W3C conference. 

**

"The Consent Receipt is designed to future proof any computer application that deals with human identities. It fully comprehends current understanding of the requirements of the GDPR + other regulations  in such a way as to provide evidence of compliance with restrictions that are expected to soon become the law of the EU and apply to any EU citizen or resident no matter where or when data is collected about them. No organization expecting to do any business outside of their home country can ignore the impact of these regulations and should pay careful attention to the solutions proposed in the Consent Receipt.

[Mark Lizar]

Hi Tom, 

I had a chance to look at this and I think I can better understand what you are getting at here. Which is of great value, and I agree that commercial facing focuses should be explored OID Connect which is a commercial use case in and of itself.

This is a great list of permissions below, is it possible to find out how they were created ? 

For example, is this the result of an audit of multiple ISP’s/IDP’s/Laws ?  Or is this recommend best practice for ISP’s based on something else? 

  

Mapping privacy to permissions is also a topic in the UMA Legal Discussion group, with a first report about to come out.    I don't think mapping these permissions to the receipt spec and legal notice requirements would be too difficult. Is there an IDESG schema to look at? 

- Mark

On 24 Feb 2018, at 17:48, Tom Jones <thomascli...@gmail.com> wrote: