[WG-InfoSharing] Kantara MVCR Implementation & Spec Objectives

Mark Lizar - OCG m.lizar at openconsentgroup.com
Thu Mar 10 07:22:35 CST 2016

My Feed Back on the Kantara MVCR Implementation

1. there is no copy of the data input by the user in the form, on the rendered receipt. 
2. there is no copy of the options of selected by user in the form in rendered receipt
3. there is no option to get a receipt (download/email/ save to profile etc) Consent Receipt must be provided at point of consent, when consent is submitted.  
4.  (there is the email address entered by the user, should this be removed from MVCR with provision that copy of data should be in the receipt?)  (
- brings up good question about wether or not 
5. Policy link (should be privacy policy) not a link to the policy for the WG IPR

(note: it would be best to have a review of the kantara implementation in the next call, with a draft of objectives on the list this week, then, we can comment on the fields and have these reviewed prior to updating the Kantara implementation. ) 


> On 10 Mar 2016, at 11:11, Mark Lizar - OCG <m.lizar at openconsentgroup.com> wrote:
> Hi CISWG, 
> We are at the point where we are working on the next version of the Kantara implementation of the consent receipt. (found here https://kantarainitiative.org/beta-signup/ <https://kantarainitiative.org/beta-signup/>)   This means all comments for this need to be submitted to Oliver. 
> I am creating a list of comments in the spec review workbook <https://docs.google.com/spreadsheets/d/1KmHxYJRNxtDZsy5hSDTHcQTZbsxI-cMQ7HE7hd47DUU/edit?usp=sharing> (Kantara Implementation Tab).  Some feed back from Oliver has included that we need to provide some guidance as to wether or not the consent receipt is implemented correctly.  
> This combined with comments from others, about what would a compliant implementation would look like, underlines the need for us to make clear the objectives for the MVCR and how implementations will be evaluated. 
> This speaks to a long standing debate as to whether or not minimum viable (in MVCR) should refer to legal requirements or should refer to the simple provision of the receipt.    After tons of thought and discussion on this issue, I agree that just the provision of the receipt with correct links, format and valid data controller contact information should be a key objective for evaluating a v1 MVCR implementation.  But, I also agree that it should be clear that the MVCR can scale to be compliant with minimum consent based legal requirements. (but maybe not out of the box with v.1) 
>  This coincides with the view that consent compliance will be a long journey not a quick fix, especially in view that most of the market is unaware about what is consent compliance is or why it is.     
> That being said it would be good to have either a balance between the consent hardliners and consent soft liner in the objectives.  Or, have multiple levels of consent objectives for different levels of consent.  i.e. sensitive data consents would have a different objectives for a compliant implementation. 
> Please take the time to review the implementation, and share thoughts about objectives for MVCR.  (i will follow up with some suggested objectives) 
> Best,
> Mark Lizar
> Executive Director
> Open Consent Group
> Email: m.lizar at openconsentgroup.com <mailto:m.lizar at openconsentgroup.com>
> Mobile: +447738382658
> Twitter: @smartopian
> _______________________________________________
> WG-InfoSharing mailing list
> WG-InfoSharing at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-infosharing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20160310/0c61b857/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/20160310/0c61b857/attachment-0001.p7s>

More information about the WG-InfoSharing mailing list