[WG-InfoSharing] Github Versions Merged
Mark Lizar - OCG
m.lizar at openconsentgroup.com
Mon Mar 14 11:21:09 CDT 2016
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> 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/
> 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
> 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
> 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.
> John Wunderlich
> Call: +1 (647) 669-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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3591 bytes
Desc: not available
More information about the WG-InfoSharing