2015-01-29 Meeting Notes

New MVCR Edit - Comment

• create use case document: underway

MVCR Scope & Framework Discussion

- cleanup spec: Mark has made significant progress on this; group should review revised text; see new appendix on compliance metrics and new format fields for the receipt

Question: Is this supposed to be about the user experience, that a consent receipt should include the following information but the actual coding is up to the implementer? Or is this supposed to be a specification at the level of implementation?

- This still seems to be under debate

- There doesn't need to be any reference to any third parties; the only reference would be back to the data subject and the data processor and their privacy policy. This would then provide the scope of work for the details for the actual specification in terms of a JSON spec.

- The MVCR should only describe the kind of data collected, the purpose, and intended use; this is a UX thing. This is a receipt received after the data is collected; the consent has been assumed or given.

- Need to be aware of the concerns around possible privacy exposure with the receipt itself. This may be mitigated by saying what fields we collected, but not sharing the data itself.

- Hoping that the receipt will include a link to the profile, the subject accessibility, or a link to the contact information to ask what data has been collected. Note some disagreement about the use of links; links may go beyond minimum information and a self-contained receipt, and may open up the user to phishing attacks.

* Need to take this to the list: links, yes or no? This may be an operational issue more than a spec issue.

Proposal: This version (0.6) will be about the information that the user will receive. 0.7 will the detail required by the programmer.

* John to remove the "extension" language from the spec; extensions don't belong in a document describing the "minimum".

P3WG references (research) for the MVCR & References and Lexicon Review

* https://kantarainitiative.org/confluence/display/archive/Reference+Library?src=contextnavchildmode

* https://kantarainitiative.org/confluence/download/attachments/45059055/p3wg_privacy_framework_DRAFT-1.doc?api=v2

Note that the P3WG work was created under a different IPR regime. LC will discuss what needs to be done for the CISWG to use that work as input.

- Suggest that this is going to be a rat hole to try and figure out what terms we do or don't want to use. If the words aren't used in the MVCR spec, then we don't need to discuss them.

- Suggest that if we do need to refer to something, it should be ISO first and ISPA second.

- Note that whatever terms used may be used across jurisdiction; ISO is a more likely to be stable and neutral use.

Compliant by Default

- Looking in the draft spec in github, this was added under Fair and Reasonable Consent conditions.

- Suggest leaving compliance language out of it, and leaving specific language up to the data controller.

- Companies are required to be compliant; this is supposed to give them a mechanism to demonstrate their compliance. The default is therefore compliance. However, there are exemptions in every jurisdiction, and that needs to be taken into account.

still under discussion at the KI Board level