2016-06-23 Meeting Notes - CR SPEC EDITING

Owned by Mark Lizar (Unlicensed)
Last updated: Jun 23, 2016 by Former user (Deleted)Version comment
3 min read

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?

  • Reciept ID - is important for receipts portable, machine readable,  alice and bob can reference it in communications
    • Conformance Mode 1
      • MUST be unique for receipt issuer
      • MAY BE UUID
    • Conformance Mode 2
      • MUST be UUID
  • AGREEMENT: The group agrees to use a UUID for Mode 2 for machine readable, and an internally assigned # to a receipt for Mode 1.

 

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

  • Yes this should be MUST
  • But not required to use categories specified
  • Minimum of one category - 1 < N 
  • Guidance Note
    • added in spreadsheet "PI Category MUST be supplied, and should reflect the category that will be shared as understood by the user. Our categories are advisory and the PII Controller may use their own list of categories."
  • AGREEMENT: Yes, keep as MUST, but our suggested list to implementers will appear in Appendix and we will elaborate on use of these in the Supplemental Guidance.

 

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? 

  • security - proportional to method of collection  
  • general guidance 
  • good tip send link to secure web page and pick up, put it in the users profile pages
  • AGREEMENT: The data collection transport method should be reflected in the return of the consent receipt. IE if an https site is used to collect data, the receipt should probably be returned using the same method or use a link for collection. This should probably be in Supplemental Guidance. Group decision.

 

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:

  • consent notice - remove
  • PII confidentiality impact levels - remove
  • PII Processor
  • Processing of PII
  • Purpose
  • Purpose specification - remove
  • Sensitive information categories - remove
  • Sensitive PI categories - remove and place in Supplemental Guidance

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