...
| # | Title | Original Description | Feature 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 | ||||
| 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 | |||||
| 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 | |||||
| 17 | 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 | ||||
| 18 | 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 | ||||
| 19 | 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 | ||||
| 20 | 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 | ||||
| 21 | Improve JSON code | We believe the JSON code articulation in the spec could be improved. | JLINC03 | ||||
| 22 |
User interaction and design
...