[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 18:25:49 UTC 2019


OK - so we should ensure that the WG resumes coverage of topics beyond the
consent receipt specification, right? Let's do it!

(except for the limitation to identity management specific elements - the
consent receipts have never, as far I know, been about only the identity
management domain)

*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 11:18 AM Info at SS <info at smartspecies.com> wrote:

> My suggestion is for this WG to focus on the identity management specific
> elements in consent, and to enable other efforts to run with this work and
> create more things.
>
>  Like FIHR and the many other efforts that use this work but are not
> listed as implementors.  At the moment, this looks like the code of
> practice and an harmonised concept of what the privacy defaults are.  Or
> more specifically, privacy expectations and the capture of a mutual state
> of privacy, and the identities involved.
>
> I think this group needs to have a open and frank discussion of scope and
> capabilities so that the activities is reflected in the charter.  This will
> help other efforts.  My most recent proposal in this regard was support and
> development of extensions, like the one for the GDPR, and the proposed one
> for FIHR.
>
>  Mark
>
> On 28 Mar 2019, at 17:22, Andrew Hughes <andrewhughes3000 at gmail.com>
> wrote:
>
> I'm not sure I understand what you are proposing.
> The generic flow was created to form the basis for future work on the
> receipt concept.
> Are you talking about the 'receipt' work or something other than the
> receipt work?
> A proposal to reactivate Inactive groups would be ok - maybe the the
> conditions that caused it to go dormant back then have changed?
>
> On Thu, Mar 28, 2019 at 10:12 AM Info at SS <info at smartspecies.com> wrote:
>
>> 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
>>
>> 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,
>> <https://maps.google.com/?q=1249+Palmer+Road,+Victoria,+BC+V8P+2H8&entry=gmail&source=g>
>>  Victoria, BC V8P 2H8
>> <https://maps.google.com/?q=1249+Palmer+Road,+Victoria,+BC+V8P+2H8&entry=gmail&source=g>
>> 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,
>>> <https://maps.google.com/?q=1249+Palmer+Road,+Victoria,+BC+V8P+2H8&entry=gmail&source=g>
>>>  Victoria, BC V8P 2H8
>>> <https://maps.google.com/?q=1249+Palmer+Road,+Victoria,+BC+V8P+2H8&entry=gmail&source=g>
>>> 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
>>>
>>>
>>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org
>> https://kantarainitiative.org/mailman/listinfo/wg-infosharing
>>
>>
>> --
> 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
> 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/20190328/578dbb24/attachment-0001.html>


More information about the WG-InfoSharing mailing list