Child pages
  • Consent Receipt v1.1 Work Backlog

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#TitleOriginal DescriptionProposed Feature or Thing DescriptionImportanceNotesSource
1CR Data ModelSpec Implementer trying to implement and create interoperable data flows between implementations.
  • A formal data model
  • A JSON representation of the data model
Must have

A formal data model is needed

WG
2Various 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

  • SPLIT UP
  • Some inputs into data model item
  • (break out) PURPOSE CATEGORY: each one could have recommended practices developed (suggestion: collect purpose categories submissions via form or email list)
  • Recommendations for practices to satisfy particular use cases
  • More clear definition of PURPOSE CATEGORY meaning
  DA01
3Jurisdiction 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.

  • MORE ANALYSIS NEEDED
  • Comment: jurisdiction is not uniformly at a country level
  • Action: clear context of 'jurisdiction' - is this country level? Regulation level? Province/State level?
  • Is this the country that the regulator exists in?
  • Based on Action - will determine what data format. In today's practice, what are orgs specifying in the notices they already issue?
  

JL09

AH02

4Missing 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.

  • SPLIT
  • 1) Add the ability to have multiple/joint (is this about 3rd party, chained, joint, flow-down, etc?)
  • 2) Add the field and specify it
  • 3) Add this and Use the ISO standard to specify what written language is in use
  JL24
5Timestamp timezoneConsent Timestamp': recommend you standardise this to UTC to simplify implementation and interoperability.
  • Issue 1: the data storage format shall be specified in UTC time zone
  • Issue 2: usability and display formats shall be considered when displaying information to people
  • Issue 3: should there be 2 fields - one for the UTC time and another for the 'localized' time which includes the timezone?
  AH03
6Examples for list of Collection MethodsCollection Method': recommend at least a minimal standard list be produced - with the option for extension - again, to help with interoperability and implementation
  • Lower priority
  • Review the meaning of 'collection method' field
  AH04
7Make CR ID format explicitConsent Receipt ID': recommend 'must' be a UUID (rather than leaving implementation details optional)
  • Specify that the CR ID shall be a UUID-4 (including relevant references to define that)
  AH05
8Phone 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.
  • Check to see if the JSON includes data types - and bring those back into the field definition text.
  AH07
9Link format specification"Privacy Policy": recommend you specify the format for the link (URI per ref. RFC 3986; or whatever is appropriate)
  • v1.1: state that wherever URIs are specified that RFC whatever is in effect.
  • The field is currently a free-form text field and not intended to include any particular text format.
  • Decision needed: if a URI is specified where the target is mutable, it defeats the purpose.
  • Implication: are we requiring that data controllers keep copies of every policy that ever existed.
  AH08
10Purpose field length"Purpose": recommend you define a maximum length for this field to simplify implementation
  • Not really feasible to specify a maximum field length in the core spec
  • Guidance - suggest that field lengths should go in a profile of the specification
  AH09
11Registry of Purpose Categories"Purpose Category": moving towards a standardised registry for this field would be helpful
  • This is out of scope for the specification itself, but probably a good idea.
  • Is this a request to have registration authorities or independent registries that contain this information.
  AH10
12Examples 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
13Establish list of PII Categories"PII Categories": is there a way we move this towards a standard set of categories?   AH12
14Registry 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
15Add Security Considerations sectionGeneral 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
16Inclusion 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
17Add 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
18Clarify 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
19Improve data type & purpose listsIain 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
20Add detail to purposes listJim 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
21Define PrimaryPurpose fieldPrimaryPurpose 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
22Prioritize displayed field orderIain 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
23Improve JSON codeWe believe the JSON code articulation in the spec could be improved.   JLINC03
24Revising 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
25Editorial comments on v1.0Comments on v1.0 document - submitted 2017-04-20 by Richard Wilsher. Good items for inclusion and consideration in v1.1    
26Clarify Spec as a Consent Record to Receipt (CRR). Specificationreview 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

Attachments

User interaction and design

...