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

Andrew Hughes andrewhughes3000 at gmail.com
Thu May 16 15:05:44 UTC 2019


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
*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>
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>
> 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
> *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>
> 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>
>> 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
>>
>> 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 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 receipt file loader web page (built by Pas, Tarik
>> and the team) and the 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
>> *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
>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190516/5ea04cf6/attachment-0001.html>


More information about the WG-InfoSharing mailing list