Difference between revisions of "Consent Receipt"
From MgmtWiki
(→Context) |
(→Current draft of the Spec) |
||
Line 10: | Line 10: | ||
===Current draft of the Spec=== | ===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 | + | Draft on which this implementation was based is listed below. In theory practice is the same as theory, in practice it is not. |
[https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification?preview=/76447870/101810304/Consent%20Receipt%20Specification%201_1_0%20DRAFT%208.docx Current draft of spec ] Version:1.1.0 DRAFT 83 Date:2018-02-20 | [https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification?preview=/76447870/101810304/Consent%20Receipt%20Specification%201_1_0%20DRAFT%208.docx Current draft of spec ] Version:1.1.0 DRAFT 83 Date:2018-02-20 |
Revision as of 09:26, 2 June 2018
Contents
Full Title or Meme
Consent Receipt generated by an IDESG compliant Identifier Provider
Context
The current design of a Consent receipt is based on the theory of a transaction between a pii data controller and a pii data principle.
In the context of an IDESG identifier provider best practice it was based on a state at the IdP of a user.
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 spec Version:1.1.0 DRAFT 83 Date:2018-02-20
Implementation on Microsoft ASP.NET Core 2 Web Site
Json output
{ "version": "KI-CR-v1.1.0", "jurisdiction": "WA", "consentTimestamp": "", "collectionMethod": "user input", "consentReceiptID": "f4de5671-bd2c-4e54-b855-76f84f5b407e", "publicKey": null, "language": "en", "piiPrincipalId": null, "piiControllers": "IDESGidp", "policyUrl": "http://tomjones.us/CRpolicy", "services": null, "sensitive": "false", "spiCat": null }