[WG-InfoSharing] WG-InfoSharing Digest, Vol 105, Issue 3

Tom Jones thomasclinganjones at gmail.com
Wed Aug 8 03:15:14 UTC 2018


I had started on a comparison of the smart phone privacy settings, so i
completed it and sent in this link.
The challenge is that privacy and user consent consists of more than data
sharing, which is all that i believe Kantara seeks to address.
My scope is broader and so i suspect my list of data categories will be
broader than your interests.

http://tcwiki.azurewebsites.net/index.php?title=Native_App_Privacy

I must point out that Mark's note encompasses the real problem here. It
seems that Kantara is focused on *legal requirements* of the whole GDPR,
while i am only focused on the part where the result needs to be
*understandable
by the ordinary user*.  I do not believe it is even remotely possible to do
both in one UX.


Peace ..tom

On Tue, Aug 7, 2018 at 8:30 AM, Mark Lizar <mark at openconsent.com> wrote:

> Tom,
>
> I agree, totally, but  this is a separate issue than how to create
> standard,  which can be interoperable both technically and legally, with
> terms that mean the same thing across domains.
>
> Explicit consent for marketing is different than explicit consent for
>  HIPPA, which is different than explicit consent for Healthcare in the  UK
>
> There can be a global set of terms that cover all explicit, non-explicit,
> consent - but these terms would differ depending on the legal requirements,
> the languages being used, the audience, the context and might require
> various modalities of notice and different explanation or use of  terms ..
>
> But to understand you better, can you clarify what you mean by, this works
> for apps on smart phones ?
>
> - Mark
>
>
> On 6 Aug 2018, at 18:46, Tom Jones <thomasclinganjones at gmail.com> wrote:
>
> If you want the user to understand the consent receipt, you will need a
> set of terms that the user can understand. This works for apps on smart
> phones. It must work for the consent receipt if you care about getting
> informed user consent. I think neither the auto repair shop nor the lawyer
> care if you understand the invoice. I suspect they would prefer that you
> not understand.
>
> Peace ..tom
>
> On Mon, Aug 6, 2018 at 10:41 AM, David Turner <
> david.turner at voltagegate.com> wrote:
>
>> I believe Mark's description is a useful way to position CRs, and a means
>> to address the common concerns now being raised by multiple jurisdictions.
>>
>> When we started working on the specification we called it the  Minimum
>>> Viable Consent Receipt MVCR, which was mapped to ISO terms and definitions
>>> required to make a consent record.   With the idea that we can then map any
>>> set of laws to the CR.  The theory being that this is how to make a
>>> specification for an internationally interoperable specification.
>>
>>
>> This issue is very similar to the debate many years ago about
>> standardizing the structure of invoices. Most invoices have a standard set
>> of elements (customer data, invoice total, payment terms, etc.) even while
>> there will endless debates about what goes IN the payment terms field (can
>> you say "consent termination"). The fact that two data structures can both
>> be identified as invoices has value in itself. However, the body of the
>> invoice from a lawyer will NEVER be the same as one from an auto parts
>> supplier. So the need for domain-specific invoice structures is now well
>> understood and accepted. Our situation is probably more similar to the
>> differences between an invoice from an accountant and a lawyer.
>>
>>
>>
>>
>> On Sat, Aug 4, 2018 at 12:28 PM, Mark Lizar <mark at openconsent.com> wrote:
>>
>>> Hi Tom,,
>>>
>>> This is a great comment - am actually thinking about the same topic.
>>>
>>> When we started working on the specification we called it the  Minimum
>>> Viable Consent Receipt MVCR, which was mapped to ISO terms and definitions
>>> required to make a consent record.   With the idea that we can then map any
>>> set of laws to the CR.  The theory being that this is how to make a
>>> specification for an internationally interoperable specification.
>>>
>>> After that version of the specification stumbled a bit, CISWG (the royal
>>> we here) decided to simplify and change from the MVCR, to Consent Receipt.
>>>      Since then, the GDPR was announced and now CCPA.
>>>
>>> The MVCR would then be the use of the receipt to create an extension for
>>> CCPA and GDPR and then these two jurisdictions would have the ability to
>>> provide  interoperable consent receipts.
>>>
>>> - Mark
>>>
>>>
>>> On 4 Aug 2018, at 19:55, Tom Jones <thomasclinganjones at gmail.com> wrote:
>>>
>>> While I support Mark's request for alignment with GDPR, I would also
>>> support alignment with the California regulation, in part because I am
>>> interested in improving that regulation as it roles out in other
>>> jurisdictions. As important as the EU might be, I suspect their efforts to
>>> export those to other parts of the world will fail.
>>>
>>> N.b. the problem with pii as a term is that it is not descriptive of the
>>> problem as understood today. In fact there are NO personal attributes that
>>> are not pii, so it's misleading at best. What I really need to understand
>>> is what user information needs user consent to share. I suspect there will
>>> never be agreements with the European countries on that.
>>>
>>> thx ..Tom (mobile)
>>>
>>> On Sat, Aug 4, 2018, 5:00 AM <wg-infosharing-request at kantar
>>> ainitiative.org> wrote:
>>>
>>>> Send WG-InfoSharing mailing list submissions to
>>>>         wg-infosharing at 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 at kantarainitiative.org
>>>>
>>>> You can reach the person managing the list at
>>>>         wg-infosharing-owner at 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. Critical CR and CISWG Issue and Solution (Mark Lizar)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Fri, 3 Aug 2018 14:10:24 +0100
>>>> From: Mark Lizar <mark at openconsent.com>
>>>> To: "wg-infosharing at kantarainitiative.org"
>>>>         <wg-infosharing at kantarainitiative.org>
>>>> Subject: [WG-InfoSharing] Critical CR and CISWG Issue and Solution
>>>> Message-ID: <60173568-227D-4FF4-9B9E-AF3FE829C9B2 at openconsent.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> HI CISWG,
>>>>
>>>>
>>>> It has increasingly come to my attention, that the Consent Receipt work
>>>> is coming under attack.    People in  and out of our community have been
>>>> talking about how operationally unsuitable the consetn receipt
>>>> specification is, and as we have not produce a lot documentation about why
>>>> it was built this way.  This is understandable.
>>>>
>>>> In addition, we have not provided the GDPR update, for the CR. Which I
>>>> believe would go a long way towards explaining the CR for us.
>>>>
>>>>  For example statements like this:
>>>>
>>>> "The Consent Receipt uses obsolete technical terms like "Personally
>>>> Identifiable Information (PII)" rather than the more generic term from the
>>>> GDPR of Personal Information <http://tcwiki.azurewebsites.n
>>>> et/index.php?title=Personal_Information&action=edit&redlink=1> or the
>>>> more descriptive of what we should control Personal Private Information <
>>>> http://tcwiki.azurewebsites.net/index.php?title=Personal_Pr
>>>> ivate_Information&action=edit&redlink=1>, although with the Right to
>>>> be Forgotten <http://tcwiki.azurewebsites.n
>>>> et/index.php?title=Right_to_be_Forgotten&action=edit&redlink=1> there
>>>> may no distinction between those two terms in the EU.?
>>>>
>>>>
>>>> Statements like these are understandable but mis-informed,because;
>>>>
>>>> 1. The consent receipt uses international lexicon not a jurisdictional
>>>> lexicon that is only relevant in a jurisdiction, this is for
>>>> A) international use. - all the systems in the world dont use GDPR, and
>>>> GDPR with all its greatness has many flaws - for example it is focus on
>>>> Data Protection not so much Privacy.  Something this WG is very aware of.
>>>>
>>>> B) It references on OECD and FIPS  and terms like PII - so that the
>>>> receipt spec will be backwards compatible - with the existing global
>>>> infratructure, not one that is emerging over the next 5 years and only
>>>> enforced in 28 countries.
>>>>
>>>> Ether way, I think its really important to get a GDPR Extension for our
>>>> CR together and into the WG, and out for the community of CR adopters that
>>>> support this work, before My Data.
>>>>
>>>> To this end,
>>>>
>>>> 1. would there be any objections for a CISWG funding application to the
>>>> Kantara Board of Directors for an Editor and funds to cover the costs the
>>>> initial authoring the a CR v1.1 GDPR spec extension and its contribution to
>>>> this WG?
>>>>
>>>> 2. Are there any supporters for this action to happen asap?
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>> Mark Lizar | Open Consent | 22 Wenlock Rd, London|  N1 7GU
>>>> <https://maps.google.com/?q=22+Wenlock+Rd,+London%7C%C2%A0+N1+7GU&entry=gmail&source=g>
>>>> P +44 (0) 208 123-2476 | E mark at openconsent.com
>>>> | Twitter @smartopian | Web https://www.openconsent.com |
>>>>
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attac
>>>> hments/20180803/de395488/attachment-0001.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> WG-InfoSharing mailing list
>>>> WG-InfoSharing at kantarainitiative.org
>>>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of WG-InfoSharing Digest, Vol 105, Issue 3
>>>> **********************************************
>>>>
>>> _______________________________________________
>>> WG-InfoSharing mailing list
>>> WG-InfoSharing at kantarainitiative.org
>>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>>
>>>
>>>
>>> _______________________________________________
>>> WG-InfoSharing mailing list
>>> WG-InfoSharing at kantarainitiative.org
>>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20180807/67b7d45e/attachment-0001.html>


More information about the WG-InfoSharing mailing list