Difference between revisions of "Consent Receipt"
(→Json output) |
(→Context) |
||
| Line 7: | Line 7: | ||
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. | 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 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 under any regulation, as that would be a privacy exposure of its own. | + | In the context of an IDESG identifier provider best practice 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 a privacy exposure of its own. |
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. | ||
Revision as of 14:44, 3 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 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 a privacy exposure of its own.
It might be useful for the consent receipt to carry an indication of the context (aka receipt type) at its generation.
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.
Implementation on Microsoft ASP.NET Core 2 Web Site
Consent receipts were added to the IDESG best practice web site which is accessible at this site.
Warning that this is a work in process and it works at varying levels of support as changes continue to be added to the site.
Json output
Generated on a partial implementation on 2018-06-01. One thing that might seem a little odd to others is that the Consent receipt for this site never really varies. It is always that same three fields entered at this time.
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 also not clear how to code the jurisdiction for US states. Maybe that is covered elsewhere?
{
"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
}
