Consent Receipt v1.1 Work Backlog
Goals
- To create a backlog of work items to be included in the v1.1 version of the Consent Receipt Specification
Assumptions
- The source for features is the previous 'Parking Lot' pages, the contributions from CR Implementors and Comments received on CR v1.0 drafts
Features
| # | Title | Original Description | Proposed Feature or Thing Description | Importance | Notes | Source |
|---|---|---|---|---|---|---|
| 1 | CR Data Model | Spec Implementer trying to implement and create interoperable data flows between implementations. |
| Must have | A formal data model is needed | WG |
| 2 | Various items | There are missing definitions for key terms in the specification, "Purpose Category" is an example Lack of required elements in the data model to genuinely encoded consent. Missing are: • use cases covered by consent, purpose category is a start but the list and range of types needs to be part of the standard • time element of consent e.g. access for 30 minutes, for one month, one year, 3 months in perpetuity etc.. • frequency of access e.g. once a month, upto five time • recency to prevent over use within specific time frames • limits set on data volumes resulting from a request • coverage of the ability to write data either in form of an update or new entry • Statement of protocol the consent was given over e.g. UMA, OpenID Connect, or any other number of protocols. Individual's need to know consent receipts can work across multiple domains and protocols |
| DA01 | ||
| 3 | Jurisdiction format | What is the required coding of jurisdictions? (IS0 3166-1?) Is this the jurisdiction of the contract or of processing? If the later, then multiple jurisdictions will be needed – array or delimited list? --- For 'jurisdiction' I suggest you define a format for the value of this element, to promote interoperability. This may require an additional document or standard, if nothing exists yet in another domain; but I think that real-world implementations will struggle without it. |
| JL09 AH02 | ||
| 4 | Missing Fields | The following fields are missing: 1) the ability to record multiple (joint) data controllers, 2) a defined retention period (in seconds) for the collected data & 3) a field defining the language of the receipt. |
| JL24 | ||
| 5 | Timestamp timezone | Consent Timestamp': recommend you standardise this to UTC to simplify implementation and interoperability. |
| AH03 | ||
| 6 | Examples for list of Collection Methods | Collection Method': recommend at least a minimal standard list be produced - with the option for extension - again, to help with interoperability and implementation |
| AH04 | ||
| 7 | Make CR ID format explicit | Consent Receipt ID': recommend 'must' be a UUID (rather than leaving implementation details optional) |
| AH05 | ||
| 8 | Phone number format | "PII Controller Phone": recommend that you standardise the format in which this is to be provided to ensure that (a) full details are included (for example, country code); and (b) to help ensure interoperability. ITU T-Rec E.123 (http://www.itu.int/rec/T-REC-E.123/en) might be an option; others probably exist. Side note: it might be worth referring to a similar protocol for email address, to avoid any confusion. |
| AH07 | ||
| 9 | Link format specification | "Privacy Policy": recommend you specify the format for the link (URI per ref. RFC 3986; or whatever is appropriate) |
| AH08 | ||
| 10 | Purpose field length | "Purpose": recommend you define a maximum length for this field to simplify implementation |
| AH09 | ||
| 11 | Registry of Purpose Categories | "Purpose Category": moving towards a standardised registry for this field would be helpful |
| AH10 | ||
| 12 | Examples of Consent Type | "Consent Type": what other consent types are valid? Again, leaving this entirely up to the implementor is going to cause interop issues; and will certainly diminish the usefulness of the spec. | AH11 | |||
| 13 | Establish list of PII Categories | "PII Categories": is there a way we move this towards a standard set of categories? | AH12 | |||
| 14 | Registry of Sensitive PII Categories | "Sensitive PII Category": it would be helpful to move towards a public registry of categories that can be referenced, to simplify implementation and interoperability | AH18 | |||
| 15 | Add Security Considerations section | General concern: no real consideration is given in this document to security requirements. I strongly urge that you consider recommending that receipts are signed - i.e. as a JWS - to mitigate the risk of a forged receipt; or - in the case of someone relying on a receipt in the context of a legal action, the defence that the receipt *might* have been forged or otherwise altered after issuance. I also strongly urge that consent receipts be encrypted, to protect PII; or, at the very least, that you require receipts to be transmitted via a secure channel. | AH20 | |||
| 16 | Inclusion of key and signature | (i) Signature The rationale for including the PII Controller's public key (but not the signature) in the list of receipt contents is not clear, especially as the form of the key and signature are left unspecified beyond the JWT recommendation in section 7.3. The example key in Appendix B.3 doesn't seem to clarify the intended use. Also, should the policy statement be included in the content covered by the digital signature? This would seem reasonable, as most of the protection offered to the PII Principal (if any) is dependent on the policy. | JC04-01 | |||
| 17 | Add URL type to contact option list | (ii) PII Controller contact PII Controller contact options do not seem to include a URL, if the preferred contact mechanism is through (e.g.) a customer service web site. | JC04-2 | |||
| 18 | Clarify use of Third Party Name field | (iii) Third Party Disclosure / Third Party Name: it isn’t clear whether the “Third Party Name” can only be used to enumerate named third parties. There will probably be cases where a PII Controller will want to identify parties by role or function - e.g. “our service delivery partners”, or "anyone" in the case where PII is being published openly. | JC04-3 | |||
| 19 | Improve data type & purpose lists | Iain Henderson has also flagged that the data type and purpose list should be more precise, more aligned with data types in organisational customer-facing systems, and ideally articulated in a matrix/ tabular format. There is a direct connection between types of data gathered, and what these then enable. In turn, some types of data, when shared, have significantly higher impact on the individual than others; that is to say they enable more potentially troublesome purposes. As above, leaving the detailed articulation of data type and purposes to implementers is likely to end up as a barrier to adoption, and lead to a poorer end user experience. | JLINC05 | |||
| 20 | Add detail to purposes list | Jim Fournier also suggests that the purposes should be defined in more granular detail at a linked table and that “marketing” is too vague to serve as a meaningful purpose. | JLINC06 | |||
| 21 | Define PrimaryPurpose field | PrimaryPurpose field: This is an undefined term. It is unclear how this field should be used. (On a legal point: under data minimisation principles, should data be collected for secondary purposes? I suspect that the concept of a hierarchy of purposes would not hold much water.) | JL20 | |||
| 22 | Prioritize displayed field order | Iain Henderson has long flagged in the work group that the field order in the specification could be much improved from the individual perspective. Experience would suggest that people will not read a full receipt, nor indeed much beyond the first 2-3 lines. Thus, the critical attributes could be ordered at the top of the receipt, these most likely to be ‘what data am I sharing, with whom, and what are they going to do with it?’ The other fields largely only become important if concerns are raised in the key lines above. Suggesting that field order be something left to the implementers raises the barrier to adoption, and largely guarantees inconsistent end user experience and ultimately use. | JLINC04 | |||
| 23 | Improve JSON code | We believe the JSON code articulation in the spec could be improved. | JLINC03 | |||
| 24 | Revising the CR towards GDPR regulatory approach and data protection principles | Introductory comments from Jens Kremer - more on attachment provided (a commented v1.0.0 spec): The definition of consent is not in line with the broad understanding of the term in data protection law. Consent is defined as ‘Consent is an individual agreeing to allow an organization to collect, use, and/or disclose their data, and data about them, according to a set of terms and conditions defined by the organization.’ Consent, however, should be ‘…any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;’. This appear to mix consent with contract or agreement. It is important to keep consent and contract separated, because these are entirely different concepts. Surely, one ‘consents’ to signing a contract, but Data Protection law (and especially the GDPR) takes a very different stand. This problem is reflected throughout the paper, and results in a mix up of concepts throughout (see detailed comments). The terminology in the paper uses ISO standards. Particlularily with the recent push of regulation in Europe, and in global data protection law, it may make sense to adjust the terms to be in line with global data protecton standards (OECD, UN, COE, and especially GDPR). The document seems to understand ‘consent’ as a transferable and tradeable commodity rather than an expression of a persons will and interest. This is problematic. Beyond consent, other important concepts such as ‘purpose’ may require clarification if not reformulation. One of the most challenging issues with the specification is that it seems to adopt a very problematic, controller/processor centered approach to consent. Conditions seem to be defined by that entity, and the consent is tracked mainly from that perspective. This is rather problematic as it disregards the role of data subjects. This is certainly not in line with the principles of data protection. Especially not with GDPR. | MD01 | |||
| 25 | Editorial comments on v1.0 | Comments on v1.0 document - submitted 2017-04-20 by Richard Wilsher. Good items for inclusion and consideration in v1.1 | ||||
| 26 | Clarify Spec as a Consent Record to Receipt (CRR). Specification | review the clarity and definitions, review section 4.2 - suggest additonal clarity. edit and outline initial content for WG review. | important | ML02 | ||
| 27 | Provide guidance on the creation of record and the provision of receipt for v.1.1 specification |
Attachments
.gif?api=v2){kind=link}