[WG-InfoSharing] Github Versions Merged

Iain Henderson iainhenderson at mac.com
Mon Mar 14 14:51:15 CDT 2016


I agree, I think machine readability is very much a nice to have at MVCR stage than a must have.

Iain

> On 14 Mar 2016, at 19:41, John Wunderlich <john at wunderlich.ca> wrote:
> 
> Kind of in the order that they are raised
> Valid consent is not always explicit consent. And it’s more complicated than a binary explicit/not-explicit. 
> From my perspective the initial core value of the consent receipt for Alice is to enable Bob to tell her what kind of consent he used at or just after the actual collection. It’s not up to us (at the MVCR level anyway) to try and predetermine what Bob will assert as valid. That can be determined by a) Alice, and b) the competent regulator to whom she might refer the consent.
> The real world is variable and subject to interpretation. If the MVCR doesn’t allow that variability for Bob to apply his interpretation,then it risks becoming an activist aspiration rather than a practical tool. (See Iain’s comments from his SalesForce developers).
> Any project changes over time and that includes original scope and deliverables statements.
> Setting out the information that Bob has to provide Alice is what constitutes the standard, whether or not it’s machine readable. In that sense I see the MVCR as more like an ISO standard than an IETF specification. We’ll get to that kind of specification next (assuming we can put the MVCR to bed quickly) with the CR spec which should include a semantic element to enable assertion of compliance with different regulatory frameworks, like the following notional list.
> CR-SelfAsserted => a Consent Receipt that sets out the information that the organization attests to meeting the Kantara established minimum requirements (to be determined, but I’m thinking maybe ISO 29100?)
> CR-TrustMark => a Consent Receipt that sets out the information for a third party attestation that the organization is meeting some [to be determined] standard
> CR-GDPR => a Consent Receipt that sets out the information necessary to demonstrate compliance with the GDPR
> CR-PrivacyShield => a Consent Receipt that sets out the information necessary to demonstrate compliance with the PrivacyShield
> 
> From my perspective, the MVCR is the first and necessary step along the way to the above suggested machine readable, interoperable and systemically usable consents. The MVCR is the version that I can see being understandable and ’sellable’ to otherwise technology solution resistant lawyers, marketers or regulators. That was the reason I suggested starting with a minimum version of the receipt - one that didn’t need any technology overhead, but that could be used for socializing the consent and empowering even the least technical of users to create receipts for their users if they wanted. We’ve never disagreed about the end state, but what the intermediate minimum version should be. 
> 
> Sincerely,
> John Wunderlich
> @PrivacyCDN
> 
> Call: +1 (647) 669-4749
> eMail: john at wunderlich.ca
> 
>> On 14 March 2016 at 14:48, Mark Lizar - OCG <m.lizar at openconsentgroup.com> wrote:
>> This is my point as well, 
>>   
>> If the scope changes from explicit consent to any type of consent  then the specification will loose its value.  Same thing if the back end of the receipt is not specified with data field name and format.  Without the data part of the specification or explict scope it will be implemented with many different names and will have little to no meaning to Alice.  Which IMO make the whole exercise of making a specification redundant. 
>> 
>> Too much variability and interpretation will make the specification meaningless.   This is why explicit consent and systematically usable are the scopes and in this scope each field in there makes sense and comprises the Minimum viable fields.  (except for maybe one or two)  
>> 
>> This is why the compromise of explicit consent y/n is useful, then it can be used for any type of consent. but it still has meaning to indicate that this is complaint with the MVCR for explicit consent.  I think this is then a very valuable specification.     Just sending a signal from bob to alice, that is not  matching readable is much easier and doesn’t need all of the fields that are in there.   In fact, it doesn’t need a specification at all. 
>> 
>> Does anyone else have an opinion?  ? 
>> 
>> Should the scope be explicit consent and machine readable?    
>> 
>> Should it be to just send a signal from bob to alice that consent of some sort has been provided?  
>> 
>> Should we it be something else ?  
>> 
>> I propose  two compromises 
>> 
>> 1. that we change consent type to explicit consent Y/N  - this way it can still be systematically usable and it can also be used for any type of consent and still conform to being for explicit consent. 
>> 2. that we have different packages of conformance to asses the MVCR against this makes it easier for different flavours of the MVCR to be developed and it can be flexible in that it scales or devolves to a wider set of use cases. 
>> 
>> 
>> Mark 
>> 
>> 
>>> On 14 Mar 2016, at 17:43, Iain Henderson <iainhenderson at mac.com> wrote:
>>> 
>>> Yes, run MVCR with pick last options I'd suggest.
>>> 
>>> That was a significant bit of the feedback when I asked our Salesforce team to deploy. Their point was 'if you don't define it, we'll only have to join the queue to speak to the lawyers, who will bring in their external lawyers, and we'll end up with a watered down version of what you could have put in your pick list I the first place.
>>> 
>>>> On 14 Mar 2016, at 17:29, Mark Lizar - OCG <m.lizar at openconsentgroup.com> wrote:
>>>> 
>>>> 
>>>> Answer in line
>>>> 
>>>> 
>>>> 
>>>>> On 14 Mar 2016, at 16:59, John Wunderlich <john at wunderlich.ca> wrote:
>>>>> 
>>>>>>> 4. Suggest leaving Consent Type (like Purposes) up to the entity producing it, but provide a base list of choices such as Implied/Implicit,Opt-out, Opt-in, Expressed/Explicit or Not Applicable. So long as the field is not blank, the user is being informed and can make a judgement as to veracity and applicability based on their understanding.
>>>>>> 
>>>>>> John, as the specification has always been for explicit consent I see that as out of scope.   Personally   I think this field is redundant.  Also, I think there are many different definitions for what implied consent means.        How would the receipt be judged as to what type of consent it is?   Is this something the implentor would do or the reader?  Even if this was in scope, this adds a lot of   unnecessary complexity to the receipt, there are many different definitions and variations of what is implied,   
>>>>>> 
>>>>>> for an implied consent we could get rid of a lot more fields for it to conform to what you have written to be minimum viable. 
>>>>>> 
>>>>>> 
>>>>>> In way of compromise and the spirit of collaboration I  think the Y/N explicit consent flag is very useful.    I am hoping you can meet me half way her. 
>>>>> 
>>>>> What I’m suggesting is that we leave the definition of consent type up to Bob, recognizing that there are many definitions of valid consent in many jurisdictions. The minimum requirement is to set out that Bob must specify a consent type for the transaction. It’s up to Bob to determine if one of the options provided is appropriate or to put in something specific for his context and language. 
>>>> 
>>>> 
>>>> 
>>>> If we leave the definition of what consent is to Bob, then how is Alice going to understand what type of consent it is?  Do we need to make a and define a list of all the types of consent and then Bob and Alice have to conform to these ? 
>>>> 
>>>> Mark 
>>>> _______________________________________________
>>>> WG-InfoSharing mailing list
>>>> WG-InfoSharing at kantarainitiative.org
>>>> http://kantarainitiative.org/mailman/listinfo/wg-infosharing
> 
> 
> 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20160314/beac429a/attachment-0001.html>


More information about the WG-InfoSharing mailing list