Date

Jun 23, 2016

Attendees

 

Here are questions the group should address tomorrow, in our meeting on the Consent Receipt Standard Candidate, in no particular order:

1. Should we have a unique number for each consent receipt as a requirement?

What is the benefit of this? And the potential harms?

 

2. PII Categories? Should this be a MUST in the Field table?

 

3. Should PII Category descriptions and informational examples be moved to "supplemental guidance" if not a MUST?

AGREEMENT: Supplemental Guidance will elaborate, but this remains a MUST field in both the Mode 1 and Mode 2 Receipts.


4. If Sensitive Data = No and data is not confidential can a consent receipt be sent via email? 

 

5. Consent Notices? Are these receipts? Can we back out of "notices" as a descriptor for a receipt?

AGREEMENT: all receipts are receipts, but Mode 1 and Mode 2 can also be referred interchangeably with "Human Readable" for Mode 1 and "Machine Readable" for Mode 2. Also if we get to a Mode 3 we can refer possibly to those as "Interoperable" -- but that 3rd version is TBD.


6. Disclosure Y/N  and 3rd Party Disclosure Y/N: see suggested descriptions here:

https://docs.google.com/spreadsheets/d/1KmHxYJRNxtDZsy5hSDTHcQTZbsxI-cMQ7HE7hd47DUU/edit#gid=1136261486

In law, and the use for policy Disclosure is referenced : pre-trial phase where parties to the case obtain evidence, where parties are compelled to share personal information about their customers. etc

This is IMO the dominant definition of disclosure for implementors. 

https://en.wikipedia.org/wiki/Disclosure

AGREEMENT: we agreed that for Guidance under the Field Table, language would be as follows:
For the end-user: we will use "Sharing" to describe, in a Field name, when the end-user shares with the PII Controller. However, for information we direct in the spec to the implementer (PII Controller) we will use terms that are more precise such as "disclosure" and "use" and "collection".
Therefore guidance for the Implementer for Field name: SHARING Y/N should read, "Disclosure of PII data MUST be able to be turned on and off with a Yes or No choice. This a yes / no flag provided as a notice to the end-user (PII subject) that some data, which may be sensitive, is being collected by the PII Controller, and can be disclosed to other parties, so that the PI Subject may take steps to safeguard their data. It indicates that there are policies out of band of the receipt which should be present."

And for Field Name: 3RD PARTY DISCLOSURE Y/N should read, "Disclosure of PII data with 3rd parties SHOULD be able to be turned on and off with a Yes or No choice. This a yes / no flag provided as a notice to the user that some data, which may be sensitive, is being collected, so that the PI Subject may take steps to safeguard their data. It indicates that there are policies out of band of the receipt which should be present."

All remaining items tabled for next working meeting:

7. Suggested glossary definitions and suggested changes:

8. Sensitive PII Category list and guidance in Field table -- how will this work?

 

Here is the proposed Standard for Consent Receipt:

https://docs.google.com/document/d/19Ot2g_NacXQs2nf6KnEVoZkrBJV6pPg5LF_UgRaXoNg/edit# 

 

Supplemental Guidance (A very basic list at this point of things we will need to work up while the Standard is with the spec editor):

https://docs.google.com/document/d/1I7e9KVu0UuZYOGAP7HJ0s5T8Fl1oycPOTxByvZJfw6k/edit# 

 

Field tables and other tabs for the Modes of compliance, glossary, and other items:

https://docs.google.com/spreadsheets/d/1KmHxYJRNxtDZsy5hSDTHcQTZbsxI-cMQ7HE7hd47DUU/edit#gid=1136261486