[WG-InfoSharing] Github Versions Merged

Mark Lizar - OCG m.lizar at openconsentgroup.com
Mon Mar 14 12:16:56 CDT 2016


Respectfully, 

To both respond to John and answer your question Iain, the question is meant to focus the discussion. 

Its seems that the scope of the MVCR has now changed and is no longer clear, what is a minimum set of requirements is very clear for explicit consent and for machine readable or systemically usably consent.  These objectives were very clear when this project came from Open Notice into CISWG and can be found in the 2012 paper published by W3C.  —> https://www.w3.org/2012/dnt-ws/papers.html ‘Opening Up the Online Notice Infrastructure” - 

But, in this last iteration the scope has changes to include more types of consent and not be machine readable.   In this regard I am curious as to how you define a minimum set of requirements with these changes in scope as I don’t understand this.  

Not only has a lot of work gone into figuring out how to achieve this scope, which is pretty much accomplished now and ready to be ratified in group, but, this changes what fields are needed.  As the minimum set of requirements for policy does not include jurisdiction, or subject id or many other fields.   Arguably all that is needed is a privacy policy link, purpose and contact information to meet minimum requirements for a receipt.  

As I mentioned, we are very close now and I think all of these objectives can be achieved 0  I propose that we take the layered conformance approach, so that this discussion becomes moot.    Rather than changing the specification scope and objectives so late into the work.   

Not understanding why all the changes and resistance.  

- Mark 


> On 14 Mar 2016, at 16:59, John Wunderlich <john at wunderlich.ca> wrote:
> 
> In line below
> 
> Sincerely,
> John Wunderlich
> @PrivacyCDN
> 
> Call: +1 (647) 669-4749
> eMail: john at wunderlich.ca <mailto:john at wunderlich.ca>
> 
> On 14 March 2016 at 12:21, Mark Lizar - OCG <m.lizar at openconsentgroup.com <mailto:m.lizar at openconsentgroup.com>> wrote:
> Hi John, 
> 
> Interesting, so can you clarify what you mean by "minimum set of requirements that will support informed consent on the part of the user."
> 
> 
>> On 14 Mar 2016, at 16:02, John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>> wrote:
>> 
>> Thanks for the pull. I know I’m still climbing Mount Newbie with respect to GitHub as well.
>> 
>> re: comments:
>> 
>> 1. I don’t think that the MVCR is limited to websites. The Alice/Bob web site registration is just the simplest example. Any entity that collects PI should be able to provide an MVCR.
> 
> Ok lets remove this from scope/ 
> 
> ​Agree to make clear that the MVCR is for any Internet based PII transaction (to be in scope of Kantara)👍
>>> 2. The MVCR scope should be as generic as possible - i.e. any entity that collects personal information from an individual on the web
> 
> lets remove from the web 
> ​Same as 1. 👍​
>  
> 
>> 3. Point of disagreement. The MVCR doesn’t have to be machine readable any more than a receipt you get from any purchase transaction. Some are machine readable. Some are not. All are valid.
> 
> I disagree, the point has always been to create a receipt format that can be aggregated  
> 
> ​Agree that the endpoint of a fully realized consent receipt infrastructure is to enable aggregation (on both sides). Disagree that this makes it a requirement for the MVCR. Aggregation is not necessary for a consent receipt to convey the information it needs to the Alice from Bob.​
> 
>> 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. 
>  
> 
> - Mark
> 
> 
>> 
>> 
>> Sincerely,
>> John Wunderlich
>> @PrivacyCDN
>> 
>> Call: +1 (647) 669-4749 <tel:%2B1%20%28647%29%20669-4749>
>> eMail: john at wunderlich.ca <mailto:john at wunderlich.ca>
>> 
>> On 14 March 2016 at 07:41, Mark Lizar - OCG <m.lizar at openconsentgroup.com <mailto:m.lizar at openconsentgroup.com>> wrote:
>> FYI: 
>> 
>> As requested: 
>> 
>> I have merged John’s version (I think) its first time I have tried to merge via github interface.  
>> 
>> Initial comments I have for this version are: 
>> To not limit MVCR scope to websites, 
>> to improve scope by making it more specific,
>> We need to get the MVCR much closer to machine readable consent receipts.  (we can try and remove the json to appendix) but this seems to make the machine readable stuff a lot harder
>> Consent type should be changed to - explicit consent (y/n) -  which I think everyone will be happy with. 
>> - Mark
>> 
>> 
>> 
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org <mailto:WG-InfoSharing at kantarainitiative.org>
>> http://kantarainitiative.org/mailman/listinfo/wg-infosharing <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.
> 
> 
> 
> 
> 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/29c6ae20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3591 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20160314/29c6ae20/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list