[WG-InfoSharing] Read This One - Privacy is not 'Agreement' & Consent is not 'Permission' - A Call for Identity Industry Privacy Best Practice

Info@SS info at smartspecies.com
Thu Mar 28 17:11:36 UTC 2019


Hi Andrew, 

A big milestone is the contribution of this 5 year project to ISO, if that ends with an appendix instead, then its a good point to pivot the consent receipt work into the next phase.  

I think this is important to be accompanied by a charter update. 

The agreement flow you refer to is a use case of the work, in which we are in a group with each participant having a similar use case to yours.   Yours in particular is on a very old topic of agreements in this work group.  What is hard to work with is dominating the wg activity with your use cases, perhaps a more stratified or structured approach would be more appropriate.  

I am not sure, and I am aware it’s easier to criticise then do, and you have been amazing at learning the WG calls and promoting the work.  The email was in part an attempt to bring the agreement side into focus with consent and privacy, which has been a really big gap in this group. 

That being said, my advocacy of privacy in identity management was what brought this work. Work that was intended for the archived Privacy & Public Policy workgroup originally. 

In terms of titles, machine readable privacy seems to suit the consent receipt work and consent and information sharing  does seem to suit the agreement WG.  But there is no generic agreement flow in consent. So getting these confuses is a big issue and something only a charter can fix IMO.  

 I think when all this started, all of this looked like the same thing.  Which is why the post to the list about Agreements and Privacy looking the same from an identerati perspective. 

 - Mark 



> On 28 Mar 2019, at 16:58, Andrew Hughes <andrewhughes3000 at gmail.com> wrote:
> 
> The Charter is not coming to an end just because we are bringing the receipt spec for consideration for inclusion into an ISO standard (29184).
> And yes, refreshing the WG Charter is long overdue. We are supposed to do a review/refine annually, but it is challenging for the WG chairs to be enthusiastic about it  ;-)
> 
> We have had a long-running set of activities on the WG to identify proposals for specification enhancements. I've tried to begin formalization of a prioritization list (in github) November-ish 2018. It has been slow to get momentum because I've monopolized the call time recently trying to get all the parts together to construct the live demo for presentation at 2019 conferences. But that's reasonably under control now. 
> 
> Here's the product roadmap page for the consent receipt work:
> https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap+for+Kantara+%27User+agreement%27+Receipt+Concept <https://kantarainitiative.org/confluence/display/infosharing/Product+Roadmap+for+Kantara+%27User+agreement%27+Receipt+Concept>
> 
> Re-reading some of the text, I think I see where it is misleading - I've made a few corrections to try to reinforce the idea that the flow chart is a generic flow where a service provider and a user come to some agreement for some exchange of value. That's it - no data involved, no personal data involved, no money involved. The critical bit (I think) is that it shows the person obtaining their own independent record of the agreement in some form. If the generic flow is applied to a use case where the lawful basis for collection and processing of personal data is 'consent', then that independent record of the agreement is probably our 'consent receipt'. That's the interconnection between that generic flow and the 'consent receipt' specification.
> 
> The additions of 'data' into the context will have to be included in additional flow charts based on the generic one. Then the interesting parts about "what 'consent' means" or "what if the person can present their terms as a first party" or "how would a negotiation of terms function" can be elaborated.
> 
> I'm not a participant in the IEEE work, so I cannot speak to that point.
> 
> I do support the idea to create a code of practice as you describe. It will be challenging to define the the constituents subscribing to that code should be, but certainly worthwhile.
> 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, Mar 28, 2019 at 9:35 AM Info at SS <info at smartspecies.com <mailto:info at smartspecies.com>> wrote:
> Ah, Perhaps I am a little thick here? 
> 
> Maybe you are correct in that the agreement flow parts should not be apart of this WG,  and apart of the IEEE WG?  This might actually make sense .    
> 
> But, first thing this WG did was a standard sharing label, and there is a standard sharing agreement, and of course user submitted terms.  Now that the Consent Receipt work and its Charter is coming to an end with you, Collin and David going to the next ISO meeting.  Perhaps its a time to work on an update to the charter? 
> 
> - Mark 
> 
> 
> 
>> On 28 Mar 2019, at 16:20, Info at SS <info at smartspecies.com <mailto:info at smartspecies.com>> wrote:
>> 
>> Hi Andrew, 
>> 
>> This is more an acknowledgement of the gap, I am sure Iain can expound on this gap, which he has repeatedly expressed needs being addressed.  I suppose it represents some long outstanding issues in which companies can generate the privacy infrastructure for information sharing. 
>> 
>> To translate a little better, A Privacy Best Practices for identity management would in my opinion be a consent records and receipt that use standards. Consent receipts are pretty much identity management specific, as Identity and notice are the main required components to create an authoritative record and usable receipt for compliance, evidence and personal data control. 
>> 
>> So, not sure what you mean?   Part of this is directed towards your diagram of the agreement flow, and trying to place this in the flow of work from a cosent receipt perspective.  Again, it might be good to separate consent receipt work and discussion as a subset of the efforts for demo and its application to specific type of use cases as represents in the agreement flow you resented. 
>> 
>> Exploring the use and application of a privacy profile is interesting, because it could even provide the company attributes needed to automate the agreement flows you presented to the group earlier this year. 
>> 
>> Mark,  
>> 
>>> On 28 Mar 2019, at 15:40, Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
>>> 
>>> Hi Mark - I'm confused.
>>> In this work group, I'm pretty sure that we have never equated "Privacy" to "Agreement". And also, we have been gradually working towards acknowledging when "permission" is the thing actually happening instead of "consent". Could this be happening in other groups you participate in?
>>> 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, Mar 28, 2019 at 3:35 AM Info at SS <info at smartspecies.com <mailto:info at smartspecies.com>> wrote:
>>> Hi CISWG, 
>>> 
>>> I am sending this again - with a fix to some auto-correct text fixing issues that has occurred with this email account  Also, I am sending this from a different email account as OpenConsent email address are blocked from sending to the CISWG list at this time 
>>> 
>>> ***
>>> Dear CISWG, 
>>> 
>>> It’s been a bit quite in this work group, I think in part this because a tension has grown between efforts working on contact, and those working on consent.  The topics around this tension are becoming popular as they are being discussed in the IEEE WG and VRM.  
>>> 
>>> Its clear now that there is a big fat gap in identity management when it comes to privacy best practices.  After almost a decade of consent advocacy in the Identity Management industry, it is also clear that the identerati have a hard time distinguishing consent from permission and privacy from agreement.  Which is not a surprise because from IdM centric perspective they look the same. 
>>> 
>>> One effort which has done a great job at distinguishing the two is the FIHR project and the creation of consent directives <http://wiki.hl7.org/index.php?title=FHIR_Consent_Directive_Implementation_Guide> which is a privacy based contract approach. 
>>> 
>>> Ultimately,  Privacy is not Agreement and consent is not permission.   Even though they look a like from an IdM perspective. 
>>> 
>>> A key difference is that privacy is based on rights and these laws are related to (define) the state of governance or the relationship state.  Agreements are contract based items that are used to maintain a state.  
>>> 
>>> This state has often been referred to as the 'social contract' and the 'community bargain’ or new deal on data. 
>>> 
>>> Privacy and agreement can be combined, but, contract doesn’t replace privacy, and contracts that ignore privacy are what we call in VRM as click bait online.  Eg. - click this to agree to privacy.  This is fake privacy, and ultimately this is the work - called Open Notice and the Biggest Lie, that led me to the consent receipt work to this WG. 
>>> 
>>> This is why as of next week, we (OpenConsent) are starting to make privacy profiles for companies and institutions.    If anyone is interested in trying out a privacy profile please get in touch. 
>>> 
>>> Apart of this effort to create privacy profiles, is to support/instigate an effort to generate an Identity Management Industry code of practice, to which privacy can have some default settings.  (Like Blinding Identity) I would like to be apart of such an effort to address the benign evil in IdM. 
>>> 
>>>   Is this something people would be interested in creating in this WG?   Is this something we should start here? 
>>> 
>>> Kind Regards, 
>>> 
>>> Mark Lizar
>>> CEO - OpenConsent.com <https://openconsent.com/>
>>> 
>>> 
>>> _______________________________________________
>>> 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 <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/20190328/f466b338/attachment-0001.html>


More information about the WG-InfoSharing mailing list