Difference between revisions of "Consent Receipt"
From MgmtWiki
(→Problems (both solved and remaining)) |
(→References) |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A structured receipt generated by a [[Web Site]] to show the detail of what | + | A structured receipt generated by a [[Web Site]] to show the detail of what [[User Information]] the [[User]] has agreed to share and for what purposes. |
==Context== | ==Context== | ||
| Line 24: | Line 24: | ||
==Problems (both solved and remaining)== | ==Problems (both solved and remaining)== | ||
| − | * While the spec appears to allow any format for the interchange of the [[Consent Receipt]], the use of a JSON Schema to define the receipt | + | * While the spec appears to allow any format for the interchange of the [[Consent Receipt]], the use of a JSON Schema to define the receipt includes anonymous lists of nodes, which is incompatible with (for example) XML and has been confusing for some developers. |
| + | * The terminology of the [[Data Controller]] in the GDPR is confusing, for example there is no distinction made between the source and sink of the [[User Information]] which is also seen in the [[Consent Receipt]]. | ||
* The [[GDPR]] has the follows requirements which are addressed herewith: | * The [[GDPR]] has the follows requirements which are addressed herewith: | ||
| − | ** TK | + | ** TK - under development by Mark Lizar |
* It might be useful for the consent receipt to carry an indication of the context (aka receipt type) at its generation. | * 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. | * 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. | ||
| Line 46: | Line 47: | ||
Content of the [[Consent Receipt]] is displayed on the page [[Consent Receipt Construction]]. | Content of the [[Consent Receipt]] is displayed on the page [[Consent Receipt Construction]]. | ||
| + | |||
| + | ===Standards=== | ||
| + | *[https://www.w3.org/community/dpvcg/ W3C DATA PRIVACY VOCABULARIES AND CONTROLS COMMUNITY GROUP] | ||
| + | |||
| + | ==References== | ||
| + | |||
| + | [[Category:Glossary]] | ||
| + | [[Category:Authentication]] | ||
| + | [[Category:Privacy]] | ||
| + | [[Category:Consent]] | ||
| + | [[Category: Notice]] | ||
Latest revision as of 18:44, 5 March 2022
Contents
Full Title or Meme
A structured receipt generated by a Web Site to show the detail of what User Information the User has agreed to share and for what purposes.
Context
While the spec is silent of the actual structure format to be shared, the current design of a Consent Receipt is based on the construction of a JSON object based on a schema in the spec 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".
Current draft of the Spec
Kantara has published an implementers' draft of the spec which is focused exclusively on the legal requirements of Information Sharing. The issues about other Privacy concerns are described in Native App Privacy.
Current draft of Kantara Initiative Technical Specification Recommendation, Consent Receipt Specification Version:1.1.0 DRAFT 8 Date:2018-02-20
Current States of Implementations
- Kantara has been collecting examples of consent reciepts in preparation for an interop demo. At present there is not an agreement on the best format to use for the Consent Receipt, for example is it to be plain JSON or a JWT.
- A detailed description of the open source implementation is at this page Consent Receipt Construction.
- 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.
Problems (both solved and remaining)
- While the spec appears to allow any format for the interchange of the Consent Receipt, the use of a JSON Schema to define the receipt includes anonymous lists of nodes, which is incompatible with (for example) XML and has been confusing for some developers.
- The terminology of the Data Controller in the GDPR is confusing, for example there is no distinction made between the source and sink of the User Information which is also seen in the Consent Receipt.
- The GDPR has the follows requirements which are addressed herewith:
- TK - under development by Mark Lizar
- 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
As a part of the IDEF compatible Best Practice and Example Identifier Provider the following output is now available from the current work in progress.
- this site shows the rendered consent receipt
- this is the stylesheet that did the rending
- The source code is available here.
- Consent receipts for the user data input in the IDEF best practice web site 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 as a stringified JSON.
The user is giving reasons why the data is required and what will be done with the data before it is even entered as a part of the User Consent process.
Content of the Consent Receipt is displayed on the page Consent Receipt Construction.
