[WG-InfoSharing] Call for A Critical Assessment of the Capacity of CISWG to produce a V2 of the Consent Receipt

Mark @ OC mark at openconsent.com
Fri May 31 10:58:02 UTC 2019


HI Colin, 

Thanks for this well thought out and explained response, it really helps in terms of trying to get to the nitty gritty here 

Some responses inline. 



> On 31 May 2019, at 11:23, Colin Wallis Kantara <colin at kantarainitiative.org> wrote:
> 
> Thanks Mark
> 
> I wasn't on yesterday's call, so my comments and completely personal views below are my personal interpretation of the current motivations and the landscape as I holistically understand it, rather than specifically wrt yesterday's call. 
> 
> And I am a non voting participant really on calls to inform the group of other context that might help. The group decides its work and direction. Not me, not the Board, just the group.
> 
> First point to note, it will be wrong. There is no way I will be 100% accurate in interpreting other people's and organisations positions. But here goes.. 
> 
> Let's track the development in ISO. ISO, like many SDOs, approaches new domains by developing framework standards. That's why it has 24760, a Framework for Identity Management and 29100, Privacy Framework. It does this, so that the concepts (one or a combination of several) in scope of the framework, can be further developed to fulfill a particular need (I visualize a tree or pyramid or..). A good example of that has been 29184 Online privacy notices and consent (an example of the CR is now to be in Annex B). 29184 is strongly informed by 29100 and other ISO standards but goes deeper into a particular concept or set of concepts. ISO then launches a study period to consider a potential future standard for consent receipts and records. It depends on how you interpret the motivation, but I think it is also strongly informed by 29100 (and branch off that main trunk) and partially by 29184, rather than an extension and refinement of 29184 itself.
> 
> Now let's track the development of Kantara. As an industry organisation it is often filling in the blank canvas where ISO et al have not already drawn, 'because industry needs something now', while all the while, checking back with ISO et al to best know how to orchestrate its contributions and informing its future work, after considering what standards have been developed since the last check. In Kantara, the forerunner to this group, then called the ISWG some 7 years ago, created an info sharing specification. ISO had nothing like that, but some of the principles were derived from the then very new 29100. Then around 2015 you and a small band of folks in the group saw GDPR et al on the horizon, saw that industry would have no standardized tools and determined to create the Consent Receipt to fill gap.  
> 
> So here we are in mid 2019 at something of a crossroads.
> 
> Mindful of what ISO is planning wrt a potential Consent Receipts and Records standard, that even in its name suggests a potential standard that is broader in scope than the Consent Receipt, my sense of the Chair's proposal is to reflect that new ISO motivation by broadening the scope of CISWG's next window of work - not forever - just this next phase of work.


> Just as ISO seems to be 'calling home' to the 29100 trunk, the equivalent in Kantara is to 'call home' to the Information Sharing Agreement (ISA) trunk and build out a broader scoped branch that in turn would retrofit the existing CR as one sub-branch and in a future piece of work at a future time, continue to develop it. The CR was a ground breaking, world leading great idea, no-one is arguing that, least of all the Chair. But my sense of it is that he is concerned that it was a remedial fix to an industry problem and at some stage Kantara has to circle back to rationalize its development from the original concepts in the ISA and build those out incrementally.

Am not convinced its Kantara’s role to reconcile a rationalisation, and, the consent receipt work is very specific (specified) so as to solve a critical problem - and it is being developed in a very specific environment suitable to address this problem and grow this work.  

The opportunity is for Kantara Community to review a full consent receipt specification where all the entities in the consent interaction are identified for extending identity assurance to privacy assurance.  This means identification and delegation, which is what the expertise this group and work is calling upon to complete. 

> 
> Looking at it that way, there would have been be this specification with a broader scope (currently missing due to the priority quite understandably devoted to CR ) sitting between the ISA and the CR, from which the CR would have been developed if there had been time.  

This work or rationalisation is in effect the notice receipt work, which we originally thought was needed to solve the problems around transparency and data control, when this turned out to be a naive assumption consent was brought to Kantara because consent is not only comprise of notice, but identity.   If this work group looses sight of these essential points then the effort becomes moot. 

> 
> Fast forward to today. ISO is indicating a broader scoped standard is needed, and with the Study Period on Consent Receipts and Records already underway, the decision whether to proceed or not, will be based on the findings of the Study Period. A well known technique to help that decision is to provide a wireframe draft of the standard, to give the ISO national bodies a glimpse of what it might look like, so as to gain their support to proceed. The findings of the Study Period are in front of ISO in October, the work having to be completed in August. That is 3 months from now. 
> 
> We face some stark choices for this next 3 month window. 
> 
> Option 1) We can continue with refining CR as a V2. I don't really know what you propose that to be but it seems like adding requirements arising out of regulations, so in a practical sense giving implementers more fields to choose from.

I proposed in yesterday’s call that I present updates on all of these efforts to help inform the group to make decisions.  At that time on yesterday’s call, Andrew informed me I would have to present this to the chairs first. 


> Nothing wrong in that but that means we cannot do the wireframe to inform the ISO Study Period and the direction it goes, and we still have our 'spec gap' between ISA and CR. Under Kantara's usual approach it will take as long as it takes until there's consensus, vote and publication.

AM not sure I understand this logic.  Mis understanding the problem we are solving by trying to broaden the scope and in effect preventing the problem from being solved in fact invalidates the need to actually make a standard in ISO.   
> 
> Option 2) Pivot to focus on the ISO wireframe as a 'CR V2' appreciating that it is wider in scope to satisfy ISO's motivations and filling in a gap in the specs for Kantara.

As I have mentioned - the ISTPA work was pushed into ISO to create 29100 - the motivations an requirements of this work, like the consent receipt were developed over years to fill a specific set of gaps. 

> But we can't use Kantara's usual approach if we are to deliver something by the end of August. There is simply not enough time. So my sense of it was to have an expert draft the wireframe informed by Kantara's published work that has found broad agreement in the past, and to create something that won't have the time for the Kantara process in the usual one step at a time order, but will be done later as a second pass when the time is not so constrained.

I see, and understand the motivation.  I have attempted as you know to propose a path forward for this work, but the WG Chair is preventing this, and the proposal doesn’t meet the requirements necessary to progress the CR work in this way.  Specifically, the standards that have adopted the CR format into their standards need to be informed of any change in scope and I would suggest approve this. 

> After the ISO decision in October which we hope is to proceed with a standard and offering up the wireframe as a 1st Working Draft, we have the time to contribute comments to correct the wireframe, and in so doing actually helping develop our own missing spec. It is both a short term opportunistic play, but with a longer term strategic return, if you think of the broader range of profiles that might arise from it, attracting new folks to this group.

There is some great opportunity here, but if this WG leadership and Kantara leadership is un clear on the purpose of this work, why it is in Kantara and how it extends existing identity assurance, then I think we should call the CR v1.1 a success as it has met its initial objectives, and the work should not be continued under a new specification as to not destroy the purpose of the work, and its use in infrastructure. 

We spent years lobbying and promoting this work and the impact of this effort is that it is being used to help create regulations and combined in standards.   And most importantly, to not understand this is very specifified legal technology, and to think that this legal technology can be expanded by making up new receipt names is absolutely mis understanding this work. 
> 
> Please note that most times I have seen V2 it is in 'speech marks' because it could (maybe should) be called something more descriptive to what it actually is. I take it that 'CR V2' is actually a working title until we have a real one. 

The v1 was the Minimum Viable Consent Receipt, it was developed so that all the regulators could see how they could write consent laws against massive lobbies like Google and Facebook . And so that we could also play with the receipt as a receipt for any  privacy context. 

The V.2 Needs to be a format that can be used for explicit high privacy and identity assurance consent receipts, so that consent could functionally be used a legal technical tool by people independently of companies and ad-tech etc, etc,  

This level of assurance, arguably could be extend in scope, once achieved.  But to think that the receipt would provide this high assurance function by not using the legal requirements it would be required to meet as requirements defeats the purpose of creating this standard. 

> 
> There's no perfect answer - just two main choices - both of which carry compromises.


The real issue here Colin, is that the work group chairs and leadership are attempting to nascar the work group with a non- transparency - un-identified expert to produce a V2 not based on the requirement for the V.1 for some non-transparent aim - this defeats the purpose of Kantara and I would strongly suggest reining in this activity or risk the integrity of the Kantara Community. 


> 
> Kind regards
> Colin
> PS: I can't get your references to the identity industry. I don't know if that's misunderstanding the make-up of Kantara's members and non member participants which are about 50/50 identity/personal data platforms but heavily overlapping, or if it refers to your belief that only identity organizations are likely to deploy our work, or a confusion with the other ISO Study Period (IDPV) that has a Kantara DG focused on that which has nothing to do with the discussion on Study Periods here..I dunno..     

The existing customers for this work are ISO, W3C DPV, OASIS COEL, HL7, and all the other tech specs that refers to the consent receipt format and standards - like perhaps Common Accord, UMA Legal etc. 

For example : to  change the scope of the CR specification to which the COEL Standard has used to build its standard would adversely affect that standard and require OASIS to create the V2 to support the COEL standard.  Or W3C to create the V2 in vocabulary themselves..  Again , removing the need for this work to be done. 

Perhaps, this is the way forward for this work, and we should stop now while this work is a success and let the group or the paying members go create their own - non - legal tech versions of this work.  This isn’t the worst option on the table. 

Kind Regards, 

Mark 

> 
> On Thu, May 30, 2019 at 8:29 PM Mark @ OC <mark at openconsent.com <mailto:mark at openconsent.com>> wrote:
> HI Colin, 
> 
> Perahaps you are right. 
> 
> 
>  This might originates with a few mis-communications, and these  are really important for a working effort to address  and the role of the chair to facilitate. 
> 
>  In this proposal there seems to be a key mis-understanding in the scope.   
> 
> From my understanding, the consent receipt specification customer  (or core audience)  are  regulators and standards organisations, and the identity industry/implementors are the consumers  or users of the work.   This is because this standard made in this way is legally authoritative, if it is combined with other legally authoritative standards, laws  and artefacts. (Like perhaps a consent certificate) 
> 
> It has been used as input into the GDPR and other regulators changes, and these have been fundamental to the development of the iteration on requirements which produced this specification .  It is actually now a going concern, because this approach, this lobby, this combination of people and community, have won in it’s combined work. 
> 
> The market wants, and people need a standard that is capable of automating compliance and evidence requirements in the ‘market’.     As Iain and Tom are saying, consent should be in the background and not a burden on people. 
> 
> This is why,  Kantara is the ideal place for such works, due to its bottom up approach, its key roles in assurance in the identity industry, and all of the people who participate and genuinely care about this stuff.  Care enough to battle and lobby for consent and notice to actually be a piece of infrastructure that identity systems can add as tools to the systems they make possible. 
> 
> Hopefully, this helps with providing some insight into the very focused and hardened consent receipt works that we now have the opportunity to complete.  Expanding the scope to more types of processing besides consent is not actually required to fulfil the objective of this work.  But creating a specification capable of compliance automation that people can control and use  - is. 
> 
> The people with the expertise to evaluate how to expand the scope for legal compliance use, to something like a processing receipt for many legal justifications, are largely not in this work group.  
> 
> I would have no objecting to a separate piece of work called the personal data receipt or whatever the group chose.  And if there was an expansion of scope - my major sticking point, is that the  expansion of the scope would need to be crystal clear (ideally to the existing customer ) before expanding it.  
>  
> Mark
> 
> 
> 
> 
> 
> 
>> On 30 May 2019, at 19:57, Colin Wallis Kantara <colin at kantarainitiative.org <mailto:colin at kantarainitiative.org>> wrote:
>> 
>> OK, thanks.
>> Yes, sounds like some crossed wires, but also, it is a different approach than is typical in Kantara, and there's always a level of discomfort when something new is tried, .
>> How it is expressed of course is an individual thing..;-).
>> 
>> 
>> On Thu, May 30, 2019 at 6:03 PM Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
>> Mark. There are factual errors in your email. More to come.
>> 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 30, 2019 at 9:46 AM Mark @ OC <mark at openconsent.com <mailto:mark at openconsent.com>> wrote:
>> 
>> Dear CISWG, 
>> 
>> After the last call, I have some critical concerns about the ability of the  V.2 work to be progressed in the current proposal.  There definitely should not be this much friction in process and admin. 
>> 
>> The proposal for the V2, is not a transparent approach, agreed by consensus, and what is extremely alarming is the proposition of  a  re-start to requirement gathering from the identity industry, to produce a specification in 3 months.  
>> 
>> The existing consent receipt specification was developed with 5 years of requirement gathering (over 10 versions of separate requirements for each version and use cases ) in consultation with standards bodies, industry trade associations and regulators.  This took a heck of a lot of work and has resulted in a legal tech specification for using consent with notice transparency that has been adopted by global standards efforts and entire industries. (US Health) To the point in which ISO has offered to initiate a study period which would be driven by this work group. 
>> 
>> For leadership, to not be aware or understand this scope, while also proposing to lead the work group product, is a massive red flag .  
>> 
>> A WG chair, to not know of the history of this extraordinary effort called the consent receipt, and to want to reframe this entire work from a identity implementation perspective is not only alarming but would not work. As this would be a different specification and not be CR V2 
>> 
>> In addition, I personally have a complaint that the behaviour continuously exhibited in calls by the convening chairs is not acceptable.  In particularly, not letting other people speak, not being transparent, and effectively (or continuously man-splaining) is not acceptable from a WG chair in any organisations - especially for work of such  import.
>> 
>> It is very clear that this proposal to V2 doesn’t consider the legal scope of work, which makes this a real legal framework (regulation usable) in consent standard for legal compliance.  
>> 
>> I would like to respectfully ask Kantara Leadership  Colin and Jim (of course) to review this behaviour, as well as all of you in this work group, and perhaps in the mean time, respectfully request that  Jim  (the Chair) take over the reigns of leadership in CISWG. .
>> 
>> With respect to CISWG,  I invite everyone to provide an opinion on this matter, who has an investment in the V2 work. 
>> 
>> Kind Regards,
>> 
>> Mark
>> 
>> _______________________________________________
>> 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>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20190531/fac5b2f9/attachment-0001.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/20190531/fac5b2f9/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list