Difference between revisions of "Consent Receipt"

Revision as of 14:35, 19 July 2018

Full Title or Meme

A structured receipt generated by a Web Site to show the detail of what information the user has agreed to share.

Context

The current design of a Consent receipt is based building a JSON object and user display of the current transaction that describes categories of user data.

A Consent Receipt is defined as a "record of a consent interaction (or consent record summary linked to the record of consent)" ... "in accordance with an agreed set of terms."

A Privacy Policy is a "statement/policy and applicable terms of use in effect when the consent was obtained, and the receipt was issued".

In the context of an Best Practice and Example Identifier Provider it was based on a state at the IdP of a user immediately after a user initiated profile update. Note that user here means whatever sort of entity has the identifier shown as "user name". It cannot be inferred that the identified user has any rights, or indeed any legal standing, under any regulation, as that would be an unwarranted privacy exposure of its own.

Current draft of the Spec

Draft on which this implementation was based is listed below. In theory, practice is the same as theory, in practice it is not.

Current draft of Kantara Initiative Technical Specification Recommendation, Consent Receipt Specification Version:1.1.0 DRAFT 8 Date:2018-02-20

Warning: this document is based the 1980 OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [OECD] focusing on consent using the ISO 29100 [ISO 29100:2011] lexicon, which means that the terms are stilted and do not reflect current usages. That is also the reason for some of the odd tags in the JSON object.

The Consent Receipt uses obsolete technical terms like "Personally Identifiable Information (PII)" rather than the more generic term from the GDPR of Personal Information or the more descriptive of what we should control Private Personal Information, although with the Right to be Forgotten there may no distinction between those two terms in the EU.

Problems (both solved and remaining)

• The GDPR has the follows requirements which are addressed herewith:
  • TK
• It might be useful for the consent receipt to carry an indication of the context (aka receipt type) at its generation.
• One thing that becomes a little weird in the near future of this site is that the user will have the option of adding more information in the future in support of authentication at other sites. It seems that neither the GDPR nor the Consent Receipt considers that fact that users can enter data of their own free will for reasons that are not known to the IdP but will be used later at a relying party. In this case the IdP is just a trusted third party, a problem which will recur frequently in the health industry.

• It is not clear from the spec how to code the jurisdiction for US states. Maybe that is covered elsewhere?

Solutions

• this site shows the rendered consent receipt
• this is the stylesheet that did the rending
• The source code is available here.
• Consent receipts were added to the IDESG best practice web site which is accessible at this site.
  • You will first need to register. Google federated signin works quickest.
  • You will need to manage your profile - click on you name in the upper right of the headers (or the drop down if using a cell phone).
  • Select the check box "Get Receipt and click "Save". You will see the Consent Receipt and be able to print it or save it a stringified JSON.

The user is giving reasons why the data is required and what will be done with before the data is even entered.