[WG-InfoSharing] Github Versions Merged
john at wunderlich.ca
Mon Mar 14 11:59:23 CDT 2016
In line below
Call: +1 (647) 669-4749
eMail: john at wunderlich.ca
On 14 March 2016 at 12:21, Mark Lizar - OCG <m.lizar at openconsentgroup.com>
> 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> 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
> John Wunderlich
> Call: +1 (647) 669-4749
> eMail: john at wunderlich.ca
> On 14 March 2016 at 07:41, Mark Lizar - OCG <m.lizar at openconsentgroup.com>
>> 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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-InfoSharing