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

Mark Lizar mark at openconsent.com
Mon Aug 13 16:21:37 UTC 2018


Hi Tom,

You are bringing in a number of separate elements  that should be addressed separately. Legal requirements are requirements for the specification development,  specific context based notices and UX are different issues. 

in reference to the link you provided 
Consent is used to allow an end user to grant a client access to resources (identity or API).

So there is a gap here - in that - access to a resource indicates technical permissions that are interpreted that have been interpreted already from the legal consent requirements.    The gap is in translating the purpose to resource access controls. 

 If there is not a code of conduct that has a privacy profile that defines this interpretation, or this legal to technical permission scope is not defined and published somewhere, then I am not sure if  is possible to standardise the acess control scopes and the  notices and policies that go with them.  

This also aptly reveals a gap in privacy regulation, in that a purpose can be interpreted in so many different ways,  can be broadly scoped, can be policy and not practice, purposes are not often held to conformance of a code of practice, not typically registered, and to create privacy integrity so as to provide privacy assurance then proof of notice and consent is a good solution to this issue. 

This is more of what I would consider a ‘real' problem that the spec is focused on so that there is a framework that scales and is interoperable 

As for understandable by the ordinary user, this is again another issue, personally, I dont think human readable is good enough, in fact. Something human readable reinforces issues we are trying to address. Human  understandable, and this is why I agree with you, as I have advocated the point of view that readable and understandable requires a consistent view and understanding that is meaningful and operationally useful to people.  

In your references it seems you are looking for the notice requirements and how these should be included in the consent receipt, and it seems you are also looking to see how to convert these in to auth scopes. For your IdM approach. But I cant tell for sure as you seem more comfortable point the finger at our work focus. 

Either way,  a quick way to get what you want, might be to start with a privacy risk assessment on the service, specify the  purpose, to get a list of  notice requirements for the legal context,  then create the auth scopes that  are required and present in a layered notice. This is a static approach to generating notice and not a dynamic one, but might be useful for case studies UX testing and one off notice generating contexts . 

Hope this helps, 

- Mark 


> On 8 Aug 2018, at 04:15, Tom Jones <thomasclinganjones at gmail.com> wrote:
> 
> 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 <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 kantarainitiative.org <mailto:wg-infosharing-request at kantarainitiative.org>> wrote:
>>> Send WG-InfoSharing mailing list submissions to
>>>         wg-infosharing at kantarainitiative.org <mailto:wg-infosharing at kantarainitiative.org>
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>         https://kantarainitiative.org/mailman/listinfo/wg-infosharing <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 <mailto:wg-infosharing-request at kantarainitiative.org>
>>> 
>>> You can reach the person managing the list at
>>>         wg-infosharing-owner at kantarainitiative.org <mailto: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 <mailto:mark at openconsent.com>>
>>> To: "wg-infosharing at kantarainitiative.org <mailto:wg-infosharing at kantarainitiative.org>"
>>>         <wg-infosharing at kantarainitiative.org <mailto: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 <mailto: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.net/index.php?title=Personal_Information&action=edit&redlink=1 <http://tcwiki.azurewebsites.net/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_Private_Information&action=edit&redlink=1 <http://tcwiki.azurewebsites.net/index.php?title=Personal_Private_Information&action=edit&redlink=1>>, although with the Right to be Forgotten <http://tcwiki.azurewebsites.net/index.php?title=Right_to_be_Forgotten&action=edit&redlink=1 <http://tcwiki.azurewebsites.net/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 <mailto:mark at openconsent.com> 
>>> | Twitter @smartopian | Web https://www.openconsent.com <https://www.openconsent.com/> |
>>> 
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20180803/de395488/attachment-0001.html <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20180803/de395488/attachment-0001.html>>
>>> 
>>> ------------------------------
>>> 
>>> Subject: Digest Footer
>>> 
>>> _______________________________________________
>>> WG-InfoSharing mailing list
>>> WG-InfoSharing at kantarainitiative.org <mailto:WG-InfoSharing at kantarainitiative.org>
>>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing <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 <mailto:WG-InfoSharing at kantarainitiative.org>
>>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing <https://kantarainitiative.org/mailman/listinfo/wg-infosharing>
>> 
>> 
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org <mailto:WG-InfoSharing at kantarainitiative.org>
>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing <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/20180813/617e1a2d/attachment-0001.html>


More information about the WG-InfoSharing mailing list