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

Salvatore DAgostino sal at idmachines.com
Mon May 20 15:29:02 UTC 2019


Thanks Jim.

 

From: WG-InfoSharing <wg-infosharing-bounces at kantarainitiative.org> On Behalf Of Jim Pasquale
Sent: Monday, May 20, 2019 9:04 AM
To: Mark <mark at openconsent.com>; Tom Jones <thomasclinganjones at gmail.com>
Cc: wg-infosharing at kantarainitiative.org
Subject: Re: [WG-InfoSharing] WG-InfoSharing Digest, Vol 114, Issue 14

 

Tom & Mark, 

 

Here’s a short presentation our CTO did as an example and reference point to have a discussion around. It is NOT a cookie consent like the one we’ve all had to deal with for the past year.

 

 





On May 19, 2019, at 5:25 PM, Mark <mark at openconsent.com <mailto:mark at openconsent.com> > wrote:

 

Hi Tom,  

 

There were and are comments that hopefully the Consent Receipt V2 will clear up, that the receipt captures an interaction (not a transaction like a money receipt) and the primary purpose of the standards is high privacy assurance transparency, that can be automated for personal use of data rights and asserting personal terms.  For this to actually work, more ecosystem component standards have been required.   A common format  (the Consent Receipt provides) is for an output of a privacy receipt that paves the path for this transparency  convergence. This is apart of the interoperability we discussed this week at the Kantara Plenary, and it easy to see how  a single output format like receipt can be used to automate, aka operationalise transparency and use of rights across many orgs - not a one by one level of transparency that is impossible for people. 

 

This is what the great work on the demo has been promoting.   In terms of ecosystem or cross domain interop, there are a couple more standards and projects that are working on the same problem set that work with the CR, ISO 29100, COEL from OASIS, the W3C Data Privacy Vocabulary for Controls. (Note: These are not the only standards that are using this work.)

 

>From EIC we learned that there is a huge interest in the potential of interoperability that simplifies privacy enough for people to be see privacy so consent can be meaningful and people can control personal data with the provision of  terms on use.  For example, Agent technologies are a big topic that need a common format and standards to scale. 

 

The work in IEEE Machine Readable privacy group is looking at this, and their is alot of DID based work that will also work to make transparency and consent a much more powerful application for people and society. 

 

ITs really starting to pick up.

 

- Mark





On 19 May 2019, at 18:51, Tom Jones <thomasclinganjones at gmail.com <mailto:thomasclinganjones at gmail.com> > wrote:

 

can you describe in anyway how the act of user consent is captured by a consent receipt? 

It just captures the relying party's understanding of their intent to violate the user's privacy.

There isn't even an automated procedure for the user to say "NO! that is not what i meant."

A lot of ink has been spilled about how the consent receipt matches a payment receipt; but there at least i have given money in exchange.

There is no exchange of any sort required in the consent receipt process.


Peace ..tom

 

 

On Sat, May 18, 2019 at 2:18 PM Mark @ OC <mark at openconsent.com <mailto:mark at openconsent.com> > wrote:

Hows that Tom? 

 

On 18 May 2019, at 21:59, Tom Jones <thomasclinganjones at gmail.com <mailto:thomasclinganjones at gmail.com> > wrote:

 

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 <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
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. 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 <mailto:mark at openconsent.com> >
To: Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com> >
Cc: wg-consent-management at kantarainitiative.org <mailto:wg-consent-management at kantarainitiative.org> , Karyl Fowler
        <karyl at transmute.industries <mailto:karyl at transmute.industries> >, Asya Ivanova <asya at sphereidentity.com <mailto:asya at sphereidentity.com> >,
        "wg-infosharing at kantarainitiative.org <mailto:wg-infosharing at kantarainitiative.org> "
        <wg-infosharing at kantarainitiative.org <mailto: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 <mailto: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>  <mailto: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>  <mailto: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>  <mailto: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>  <mailto: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>  <mailto: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>  <mailto: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>  <mailto: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/>  <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/>  <http://digi.me/> receipt file loader web page (built by Pas, Tarik and the team) and the digi.me <http://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>  <mailto: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>  <mailto: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>  <mailto: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 <mailto:WG-InfoSharing at kantarainitiative.org> 
https://kantarainitiative.org/mailman/listinfo/wg-infosharing


------------------------------

End of WG-InfoSharing Digest, Vol 114, Issue 14
***********************************************

_______________________________________________
WG-InfoSharing mailing list
WG-InfoSharing at kantarainitiative.org <mailto:WG-InfoSharing at kantarainitiative.org> 
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

 

_______________________________________________
WG-InfoSharing mailing list
 <mailto:WG-InfoSharing at kantarainitiative.org> WG-InfoSharing at kantarainitiative.org
 <https://kantarainitiative.org/mailman/listinfo/wg-infosharing> https://kantarainitiative.org/mailman/listinfo/wg-infosharing

 

 

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorised to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. If you have received this email in error, please delete it and advise the sender.

.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190520/ff72ef7e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6645 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190520/ff72ef7e/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list