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

Andrew Hughes andrewhughes3000 at gmail.com
Thu Mar 28 16:58:31 UTC 2019


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

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
*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> 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> 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>
> 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
> *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> 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
>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org
>> 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/7829d558/attachment-0001.html>


More information about the WG-InfoSharing mailing list