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

Colin Wallis Kantara colin at kantarainitiative.org
Fri May 31 11:33:03 UTC 2019


Thanks Mark
Let's await comments from the working group participants and any
observations from the WG leadership.
That may help inform the support of, and the timing of, these two streams
of work and potentially others.
Kind regards
Colin


On Fri, May 31, 2019 at 11:59 AM Mark @ OC <mark at openconsent.com> wrote:

> 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> 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> 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>
>> 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
>>> *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> 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
>>>> 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/20190531/58ab0d37/attachment-0001.html>


More information about the WG-InfoSharing mailing list