[WG-InfoSharing] [WG-Consent-Management] News from EIC Munich - Data receipt demo sessions

Mark @ OC mark at openconsent.com
Sat May 18 13:44:44 UTC 2019


HI Andrew, 

As the consent receipt is intended to be a legally usable artefact for automating the control of personal data, I would suggest we keep the legal referencing. 

For example, the minimum viable consent receipt, could become the more general minimum processing receipt. 

Profiles for the minimum receipt could be, the explicit consent for the GDPR, like the one submitted already. 

- Mark

> On 16 May 2019, at 16:05, Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
> 
> Close, I think. 
> 
> When I think about this, I think about it more like this:
> - the core Kantara Personal Data Receipt specification (v2) sets out the mandatory data fields and syntax and structure that must appear in every "Kantara" receipt. It also includes Recommended data fields and maybe some Optional fields. The core v2 spec should not be directly implementable without at least a minimal profile (see next line)
> -  there must be 'profiles' or specializations of the core specification that constrains the allowable values and specifies the additional mandatory fields and structures 
> 
> - My view is that we should not specify what any receipt issuer stores inside their system - we should not design the 'record' directly - receipt issuers have many requirements for their internal record structures. We should specify the 'receipt' - the implementer just has to write a receipt outputter based on whatever information they have in their system. If implementers choose to output a receipt that is nearly identical to their internal record, they can do that - if we design the profile approach well, the 'extra' data in those rich receipts should be ignorable by other receipt handlers.
> 
> - We should probably keep the target 'personal data' or 'personally identifiable information' rather than 'data' in general. We should discuss this part (my brain hurts trying to frame up how to think about a general data receipt)
> 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
> AndrewHughes3000 at gmail.com <mailto:AndrewHughes3000 at gmail.com> 
> https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>
> Digital Identity | International Standards | Information Security 
> 
> 
> 
> On Thu, May 16, 2019 at 3:49 PM Iain Henderson <iainhenderson at mac.com <mailto:iainhenderson at mac.com>> wrote:
> Good thanks, so let me test what you are saying in my own way of thinking about the issue.
> 
> So:
> 
> Any party, sharing any data with any other party for any purpose will have the option to generate a standardised, machine readable digital record of that data transaction.
> 
> … and that digital record of the data transaction can be used to memorialise a standardised, machine readable data receipt.
> 
> The above being the core of the Kantara Data Receipt standard, further specialist versions can be built to meet the additional needs of specific use cases.
> 
> Does that framing still align with yours?
> 
> Cheers
> 
> Iain
> 
>> On 16 May 2019, at 08:25, Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
>> 
>> Thanks everyone
>> 
>> Iain: Yes. No. Maybe.  ;-)
>> 
>> What I'm proposing right now is that the current and evolved Consent Receipt is actually a specialization of a more generalized data receipt. The generalized data receipt does not exist and I believe that's where we need to move towards for v2. Conceptually, anyone should be able to pick up that general data receipt specification and 'specialize' or 'profile' it to meet the requirements of their situation. Two of the key specializations are "GDPR-Consent" and maybe something like "CCPA-Consumer Protection" - same core fields, similar data dictionary, specialized fields and values based on specific regulation. 
>> 
>> I'd like v2 to retain requirements traceability properties - that's critical if we want the specification to have smooth intake to international standards bodies. This will look like a 'use case gathering' phase; a requirements derivation phase; a 'features' prioritization phase; and a specification writing phase.
>> 
>> We have been encouraging people to think about and contribute use cases into the pool so that we have a good set or sources to feed into the overall process.
>> 
>> One possible process way to retain the 'consent' receipt and also build the 'general' receipt spec is to categorize the requested 'features' into 'functional requirements' requests and 'non-functional requirements' requests. That way we can incorporate improvements into the v1.1 spec and also use the new requirements to flesh out the general data receipt.
>> 
>> I makes sense to me - but I'm pretty badly jetlagged at the moment :-)
>> 
>> andrew.
>> 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
>> AndrewHughes3000 at gmail.com <mailto:AndrewHughes3000 at gmail.com> 
>> https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>
>> Digital Identity | International Standards | Information Security 
>> 
>> 
>> 
>> On Thu, May 16, 2019 at 8:36 AM Iain Henderson <iainhenderson at mac.com <mailto:iainhenderson at mac.com>> wrote:
>> Thanks Andrew, that all looks very positive.
>> 
>> So can I assume that for v 2 that we are making the leap to a more generalised data receipt as the deliverable rather than one that focuses on where consent is the basis for processing?
>> 
>> Iain
>> 
>>> On 15 May 2019, at 17:13, Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
>>> 
>>> The slide deck that we presented around the demo is now on Slideshare:
>>> https://www.slideshare.net/AndrewHughes6/kantara-privacy-control-panel-demonstration-2019-0515 <https://www.slideshare.net/AndrewHughes6/kantara-privacy-control-panel-demonstration-2019-0515>
>>> 
>>> Very strong positive reaction to the demo and core data receipt concept! The audiences were engaged and we got them thinking about how the concept could be applied in their situations. We expect several new WG participants over the next few weeks.
>>> 
>>> The main goal for the demo was to inspire and inform the audience about the idea of personal receipts for data-related interactions. We were successful.
>>> 
>>> We showed a few variations of the Privacy Control Panel and receipts to make the point that implementations can be case-specific and designed to suit.
>>> 
>>> Consentua's Richard Gomer built a Chrome extension that captured any 'consent' action performed on any consentua.com <http://consentua.com/> page; and posts the Kantara receipt to the API that Keith Uber of Ubisecure; and updates a counter on the browser icon. I wrote some scripts to query and fetch from the API to show the audience some of the inner workings.
>>> 
>>> Asya Ivanova and Katherine Noall of Sphere Identity showed the consent receipt functionality of their system's mobile app.
>>> 
>>> We showed Transmute Industry's video showing how consent receipts work in their app (thanks Margo Johnson for making that).
>>> 
>>> We showed the digi.me <http://digi.me/> receipt file loader web page (built by Pas, Tarik and the team) and the digi.me <http://digi.me/>consent access certificate dashboard screens to show another display and management mode.
>>> 
>>> Mark Lizar talked about some of the future possibilities that might come out of this work.
>>> 
>>> 'Kantara Consent/Data Receipts' were mentioned unprompted by a bunch of keynote speakers - which was very satisfying.
>>> 
>>> On next week's call we'll run through some of the demo material.
>>> 
>>> Thank you everyone for encouraging your product teams to make the changes needed to make this demo possible. (We need a bit more effort to prep for the Identiverse demo in a few weeks)
>>> 
>>> andrew.
>>> 
>>> 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
>>> AndrewHughes3000 at gmail.com <mailto:AndrewHughes3000 at gmail.com> 
>>> https://www.linkedin.com/in/andrew-hughes-682058a <https://www.linkedin.com/in/andrew-hughes-682058a>
>>> Digital Identity | International Standards | Information Security 
>>> 
>>> _______________________________________________
>>> 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-Consent-Management mailing list
> WG-Consent-Management at kantarainitiative.org <mailto:WG-Consent-Management at kantarainitiative.org>
> https://kantarainitiative.org/mailman/listinfo/wg-consent-management <https://kantarainitiative.org/mailman/listinfo/wg-consent-management>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190518/5d2ac700/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3862 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190518/5d2ac700/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list