<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I wholeheartedly disagree, I think machine readability is a must have at all stages.<div class=""><br class=""></div><div class="">&nbsp;— Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 3:51 PM, Iain Henderson &lt;<a href="mailto:iainhenderson@mac.com" class="">iainhenderson@mac.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">I agree, I think machine readability is very much a nice to have at MVCR stage than a must have.</div><div class=""><br class=""></div><div class="">Iain</div><div class=""><br class="">On 14 Mar 2016, at 19:41, John Wunderlich &lt;<a href="mailto:john@wunderlich.ca" class="">john@wunderlich.ca</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(7,55,99)"><div class="">Kind of in the order that they are raised</div><ol class=""><li class="">Valid consent is not always explicit consent. And it’s more complicated than a binary explicit/not-explicit.&nbsp;<br class=""></li><li class="">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.</li><li class="">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).</li><li class="">Any project changes over time and that includes original scope and deliverables statements.</li><li class="">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.</li><ol class=""><li class="">CR-SelfAsserted =&gt; a Consent Receipt that sets out the information that the organization attests to meeting the Kantara established minimum requirements (to be determined, but&nbsp;I’m thinking maybe ISO 29100?)</li><li class="">CR-TrustMark =&gt; a Consent Receipt that sets out the information for a third party attestation that the organization is meeting some [to be determined] standard</li><li class="">CR-GDPR =&gt; a Consent Receipt that sets out the information necessary to demonstrate compliance with the GDPR</li><li class="">CR-PrivacyShield =&gt; a Consent Receipt that sets out the information necessary to demonstrate compliance with the PrivacyShield</li></ol></ol></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(7,55,99)"><br class=""></div><div class="gmail_extra"><div class="gmail_default" style="font-family:verdana,sans-serif;color:rgb(7,55,99)">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.&nbsp;</div><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><font face="verdana,sans-serif" class="">Sincerely,<br class="">John Wunderlich<br class="">@PrivacyCDN<br class=""></font><span class=""><br class=""></span><font face="verdana,sans-serif" class="">Call: +1 (647) 669-4749<br class="">eMail: <a href="mailto:john@wunderlich.ca" target="_blank" class="">john@wunderlich.ca</a></font><font face="verdana,sans-serif" class=""><br class=""></font></div></div></div></div></div></div></div></div>
<br class=""><div class="gmail_quote">On 14 March 2016 at 14:48, Mark Lizar - OCG <span dir="ltr" class="">&lt;<a href="mailto:m.lizar@openconsentgroup.com" target="_blank" class="">m.lizar@openconsentgroup.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">This is my point as well,&nbsp;<div class="">&nbsp;&nbsp;</div><div class="">If the scope changes from explicit consent to any type of consent &nbsp;then the specification will loose its value.&nbsp; Same thing if the back end of the receipt is not specified with data field name and format.&nbsp; 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.&nbsp; Which IMO make the whole exercise of making a specification redundant.&nbsp;</div><div class=""><br class=""></div><div class="">Too much variability and interpretation will make the specification meaningless. &nbsp; 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. &nbsp;(except for maybe one or two) &nbsp;</div><div class=""><br class=""></div><div class="">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.&nbsp; I think this is then a very valuable specification. &nbsp; &nbsp; Just sending a signal from bob to alice, that is not &nbsp;matching readable is much easier and doesn’t need all of the fields that are in there. &nbsp; In fact, it doesn’t need a specification at all.&nbsp;</div><div class=""><br class=""></div><div class="">Does anyone else have an opinion? &nbsp;?&nbsp;</div><div class=""><br class=""></div><div class="">Should the scope be explicit consent and machine readable? &nbsp; &nbsp;</div><div class=""><br class=""></div><div class="">Should it be to just send a signal from bob to alice that consent of some sort has been provided? &nbsp;</div><div class=""><br class=""></div><div class="">Should we it be something else ? &nbsp;</div><div class=""><br class=""></div><div class="">I propose &nbsp;two compromises&nbsp;</div><div class=""><br class=""></div><div class="">1. that we change consent type to explicit consent Y/N &nbsp;- 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.&nbsp;</div><div class="">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.&nbsp;</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Mark&nbsp;</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Mar 2016, at 17:43, Iain Henderson &lt;<a href="mailto:iainhenderson@mac.com" target="_blank" class="">iainhenderson@mac.com</a>&gt; wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class=""></div><div class="">Yes, run MVCR with pick last options I'd suggest.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class="">On 14 Mar 2016, at 17:29, Mark Lizar - OCG &lt;<a href="mailto:m.lizar@openconsentgroup.com" target="_blank" class="">m.lizar@openconsentgroup.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Answer in line</div><div class=""><br class=""></div><div class=""><br class=""></div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Mar 2016, at 16:59, John Wunderlich &lt;<a href="mailto:john@wunderlich.ca" target="_blank" class="">john@wunderlich.ca</a>&gt; wrote:</div><br class=""><div class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class=""><div dir="ltr" class=""><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(7,55,99)" class="">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.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(7,55,99)" class=""><br class=""></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div></span><div class="">John, as the specification has always been for explicit consent I see that as out of scope. &nbsp; Personally &nbsp; I think this field is redundant.&nbsp; Also, I think there are many different definitions for what implied consent means. &nbsp; &nbsp; &nbsp; &nbsp;How would the receipt be judged as to what type of consent it is? &nbsp; Is this something the implentor would do or the reader?&nbsp; Even if this was in scope, this adds a lot of &nbsp; unnecessary complexity to the receipt, there are many different definitions and variations of what is implied, &nbsp;&nbsp;</div><div class=""><br class=""></div><div class="">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.&nbsp;</div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">In way of compromise and the spirit of collaboration I &nbsp;think the Y/N explicit consent flag is very useful. &nbsp; &nbsp;I am hoping you can meet me half way her.&nbsp;</div></div></blockquote><div class=""><br class=""></div><div class=""><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(7,55,99)" class="">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.&nbsp;</div></div></div></div></div></div></div></blockquote></div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">If we leave the definition of what consent is to Bob, then how is Alice going to understand what type of consent it is?&nbsp; 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 ?&nbsp;</div></div><div class=""><br class=""></div><div class="">Mark&nbsp;</div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">WG-InfoSharing mailing list</span><br class=""><span class=""><a href="mailto:WG-InfoSharing@kantarainitiative.org" target="_blank" class="">WG-InfoSharing@kantarainitiative.org</a></span><br class=""><span class=""><a href="http://kantarainitiative.org/mailman/listinfo/wg-infosharing" target="_blank" class="">http://kantarainitiative.org/mailman/listinfo/wg-infosharing</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div>

<br class="">
<div style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em" class=""><br class=""></div><div class=""><font face="Arial, Helvetica, sans-serif" size="1" class="">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.</font></div></div></blockquote></div>_______________________________________________<br class="">WG-InfoSharing mailing list<br class=""><a href="mailto:WG-InfoSharing@kantarainitiative.org" class="">WG-InfoSharing@kantarainitiative.org</a><br class="">http://kantarainitiative.org/mailman/listinfo/wg-infosharing<br class=""></div></blockquote></div><br class=""></div></body></html>