[WG-InfoSharing] WG-InfoSharing Digest, Vol 114, Issue 14

Tom Jones thomasclinganjones at gmail.com
Sat May 18 20:59:42 UTC 2019


Something is deeply wrong here.
The consent receipt has no legal connection to consent whatsoever. It is a
legal artifact only in the sense that it's a promise on the part of the
issuer of the receipt.

thx ..Tom (mobile)

On Sat, May 18, 2019, 1:35 PM <wg-infosharing-request at kantarainitiative.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. Re: [WG-Consent-Management] News from EIC Munich - Data
>       receipt demo sessions (Mark @ OC)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 18 May 2019 14:44:44 +0100
> From: "Mark @ OC" <mark at openconsent.com>
> To: Andrew Hughes <andrewhughes3000 at gmail.com>
> Cc: wg-consent-management at kantarainitiative.org, Karyl Fowler
>         <karyl at transmute.industries>, Asya Ivanova <
> asya at sphereidentity.com>,
>         "wg-infosharing at kantarainitiative.org"
>         <wg-infosharing at kantarainitiative.org>
> Subject: Re: [WG-InfoSharing] [WG-Consent-Management] News from EIC
>         Munich - Data receipt demo sessions
> Message-ID: <31190D81-D1E5-4D32-9E54-D2CDB84AFF59 at openconsent.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.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.p7s
> >
>
> ------------------------------
>
> 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 114, Issue 14
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190518/b341db0e/attachment-0001.html>


More information about the WG-InfoSharing mailing list