Difference between revisions of "Consent Receipt"

From MgmtWiki
Jump to: navigation, search
(→‎Current draft of the Spec)
(→‎References)
 
(35 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
  
−
Consent Receipt generated by an IDESG compliant Identifier Provider
+
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==
  
−
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.
+
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 '''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".
 
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===
 
===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.
+
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]].
  
 
[https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification?preview=/76447870/101810304/Consent%20Receipt%20Specification%201_1_0%20DRAFT%208.docx Current draft of Kantara Initiative Technical Specification Recommendation, Consent Receipt Specification  ] Version:1.1.0 DRAFT 8  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 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.
+
===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]].
  
−
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.
+
*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)==
 
==Problems (both solved and remaining)==
  
−
* The [[GDPR]] has the follows requirements which are address herewith:
+
* 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.
 
* 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 32: Line 33:
 
* It is not clear from the spec how to code the jurisdiction for US states. Maybe that is covered elsewhere?
 
* It is not clear from the spec how to code the jurisdiction for US states. Maybe that is covered elsewhere?
  
−
==Implementation on Microsoft ASP.NET Core 2 Web Site==
+
==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.
  
−
===Links to the Solution===
 
 
* [https://idesg-idp.azurewebsites.net/consentreceipt.xml this site shows the rendered consent receipt]
 
* [https://idesg-idp.azurewebsites.net/consentreceipt.xml this site shows the rendered consent receipt]
 
* [https://idesg-idp.azurewebsites.net/consentreceipt-min.xsl this is the stylesheet that did the rending]
 
* [https://idesg-idp.azurewebsites.net/consentreceipt-min.xsl this is the stylesheet that did the rending]
 
* The source code is available [https://github.com/TomCJones/idesg-idp here].
 
* The source code is available [https://github.com/TomCJones/idesg-idp here].
−
* Consent receipts were added to the IDESG best practice web site which is accessible at this [https://idesg-idp.azurewebsites.net/ site].
+
* Consent receipts for the user data input in the IDEF best practice web site is accessible at this [https://idesg-idp.azurewebsites.net/ site].
 
** You will first need to register. Google federated signin works quickest.
 
** 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).
 
** 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.
+
** 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.
−
 
 
−
This site described is an IdP. Several points were noted for discussion:
 
−
# The Consent Receipt spec is not specific to IdPs. Some assumptions were necessary about how it might work for an IdP that were not necessarily optimal.
 
−
# One interesting example is the "third party" as that is not known for a federated identifier at the time the the consent receipt is issued. One use case might require that consent receipts were reissued at every new site logon? The right answer may not be known until the lawyers complete some very expensive lawsuits. One can only hope that answers to question like these do not have different answers in different jurisdictions.
 
−
# Some mandatory requirements, like service address and phone number might be fine for large organizations, but if applied to small ones there will be some that just avoid the issue and hope no one notices. I specifically noted that this site was not in compliance with those requirements, and never intends to be compliant.
 
−
# Termination was unclear especially as to what might actually be possible. It was decided to just use a link to where the user can get information about that AND privacy policy - they should be tightly related, if not identical.
 
−
# Experience leads to the conclusion that fields like purpose vary among the different elements of user private information stored. If fact it seems like the GDPR requires this as the point is made (at least in the CA initiative) that some data may be part of a core function and other data voluntary. Since the consent receipt is designed so that it can be issued prior to (and independent of) any data collection, there was no provision made for user data beyond the very broad piiCategory. The question remains about how to accommodate users' desires for determination of the exact extent of exposure and redress to unwanted data disclosures. Specifically can the Kantara Consent Receipt serve as a base requirement to which other elements are added, or is a completely different standard required to meet user expectations?
 
−
# The assumption seems to be that piiPrinciple is a sentient carbon-based life form. This is not necessarily true. In the case of a pseudonyn it is PII to even know if the principle (subject) is a carbon-based life form. In case you wondered about this odd formulation it should be noted that [https://www.washingtonpost.com/news/innovations/wp/2017/10/29/saudi-arabia-which-denies-women-equal-rights-makes-a-robot-a-citizen/ Saudi Arabia, which denies women equal rights, makes a robot a citizen]
 
−
 
 
−
Warning that this is a description of a work in process and changes continue to be added to the best practice site.
 
−
 
 
−
===Json classes===
 
−
 
 
−
  // ConsentReceipt helper clases (c) 2018 tom jones
 
−
  {
 
−
    public class ConsentReceipt
 
−
    {
 
−
        [JsonObject]
 
−
        public class ProfileResponse
 
−
        {
 
−
            [JsonProperty]
 
−
            public string version { get; set; }
 
−
            [JsonProperty]
 
−
            public string jurisdiction { get; set; }
 
−
            [JsonProperty]
 
−
            public string consentTimestamp { get; set; }
 
−
            [JsonProperty]
 
−
            public string collectionMethod { get; set; }
 
−
            [JsonProperty]
 
−
            public string consentReceiptID { get; set; }
 
−
            [JsonProperty(NullValueHandling=NullValueHandling.Ignore)]
 
−
            public string publicKey { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string language { get; set; }
 
−
            [JsonProperty]
 
−
            public string piiPrincipalId { get; set; }
 
−
            [JsonProperty]
 
−
            public Array piiControllers { get; set; }
 
−
            [JsonProperty]
 
−
            public string policyUrl { get; set; }
 
−
            [JsonProperty]
 
−
            public Array services { get; set; }
 
−
            [JsonProperty]
 
−
            public string sensitive { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string spiCat { get; set; }
 
−
        }
 
−
 
 
−
        [JsonObject]
 
−
        public class jsonController
 
−
        {
 
−
            public static jsonController Create(string json)
 
−
            {
 
−
                return new jsonController(json);
 
−
            }
 
−
            public static string Write(jsonController options)
 
−
            {
 
−
                return JsonConvert.SerializeObject(options);
 
−
            }
 
−
            public jsonController()
 
−
            { }
 
−
            public jsonController(string json)
 
−
            {
 
−
                try
 
−
                {
 
−
                    JsonConvert.PopulateObject(json, this);
 
−
                }
 
−
                catch (Exception ex)
 
−
                {
 
−
                    throw new Exception(string.Format("Error deserializing json:'{0}', into '{1}.", json, GetType()), ex);
 
−
                }
 
−
            }
 
−
            [JsonProperty]
 
−
            public string piiController { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string onBehalf { get; set; }
 
−
            [JsonProperty]
 
−
            public string contact { get; set; }
 
−
            [JsonProperty]
 
−
            public string address { get; set; }
 
−
            [JsonProperty]
 
−
            public string email { get; set; }
 
−
            [JsonProperty]
 
−
            public string phone { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string fax { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string piiControllerURL { get; set; }
 
−
        }
 
−
 
 
−
        [JsonObject]
 
−
        public class jsonService
 
−
        {
 
−
            [JsonProperty]
 
−
            public string service { get; set; }
 
−
            [JsonProperty]
 
−
            public Array purposes { get; set; }
 
−
        }
 
−
 
 
−
        [JsonObject]
 
−
        public class jsonPurpose
 
−
        {
 
−
            [JsonProperty]
 
−
            public string purpose { get; set; }
 
−
            [JsonProperty]
 
−
            public string[] purposeCategory { get; set; }
 
−
            [JsonProperty]
 
−
            public string consentType { get; set; }
 
−
            [JsonProperty]
 
−
            public string[] piiCategory { get; set; }
 
−
            [JsonProperty]
 
−
            public bool primaryPurpose { get; set; }
 
−
            [JsonProperty]
 
−
            public string termination { get; set; }
 
−
            [JsonProperty]
 
−
            public bool thirdPartyDisclosure { get; set; }
 
−
            [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
 
−
            public string thirdPartyName { get; set; }
 
−
        }
 
−
    }
 
−
  }
 
−
 
 
−
===Json Constructer===
 
−
            ProfileResponse profileResp = new ProfileResponse
 
−
            {
 
−
                version = "KI-CR-v1.1.0",
 
−
                jurisdiction = "WA",
 
−
                consentTimestamp = DateTime.UtcNow.ToString("o"),
 
−
                collectionMethod = "user input",
 
−
                consentReceiptID = Guid.NewGuid().ToString(),
 
−
                language = "en",
 
−
                piiPrincipalId = user.UserName,
 
−
                piiControllers = new jsonController[]
 
−
                {
 
−
                    new jsonController { piiController = "IDESGidp",
 
−
                    contact = "jerry",
 
−
                        email="jerry@ca0.net",
 
−
                        address="too restrictive for small sites",
 
−
                        phone="too restrictive for small sites"}
 
−
                    },
 
−
                policyUrl = "http:idesg-idp.azurewebsites.net/Home/About",
 
−
                services = new jsonService[]
 
−
                {
 
−
                    new jsonService {
 
−
                        service = "IdP",
 
−
                        purposes = new jsonPurpose[]
 
−
                        {
 
−
                            new jsonPurpose {
 
−
                            purpose = "Authenticate User",
 
−
                            purposeCategory= new string[] {"1 - Core Function" },
 
−
                            consentType="EXPLICIT",
 
−
                            piiCategory = new string[] {"2 - Contact" },
 
−
                            primaryPurpose= true,
 
−
                            termination="http:idesg-idp.azurewebsites.net/Home/About",
 
−
                            thirdPartyDisclosure = false
 
−
                            },
 
−
                            new jsonPurpose
 
−
                            {
 
−
                                purpose="Federated Logon",
 
−
                                purposeCategory= new string[] {"2 - not clear to me" },
 
−
                                consentType="IMPLICIT",
 
−
                                piiCategory=new string[] {"2 - Contact", "3 - More stuff"},
 
−
                                primaryPurpose=false,
 
−
                                termination="same as primary purpose",
 
−
                                thirdPartyDisclosure = true,
 
−
                                thirdPartyName="this will be the site you visit"
 
−
                            }
 
−
                        }
 
−
                    }
 
−
                },
 
−
                sensitive = "false"
 
−
            };
 
−
 
 
−
            string jsonResp = JsonConvert.SerializeObject(profileResp);
 
−
 
 
−
===Json output===
 
−
 
 
−
Generated on a partial implementation on 2018-06-06. 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.
 
  
−
The next challenge is, given a Consent Receipt on the web site, what should be done with it?
+
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]].
−
  "version": "KI-CR-v1.1.0",
 
−
  "jurisdiction": "WA",
 
−
  "consentTimestamp": "2018-06-08T17:43:20.7681968Z",
 
−
  "collectionMethod": "user input",
 
−
  "consentReceiptID": "ce56a128-abd2-4edc-94f3-3d1b2efcb57d",
 
−
  "language": "en",
 
−
  "piiPrincipalId": "tomcjones",
 
−
  "piiControllers": [
 
−
    {
 
−
      "piiController": "IDESGidp",
 
−
      "contact": "jerry",
 
−
      "address": "too restrictive for small sites",
 
−
      "email": "jerry@ca0.net",
 
−
      "phone": "too restrictive for small sites"
 
−
    }
 
−
  ],
 
−
  "policyUrl": "http:idesg-idp.azurewebsites.net/Home/About",
 
−
  "services": [
 
−
    {
 
−
      "service": "IdP",
 
−
      "purposes": [
 
−
        {
 
−
          "purpose": "Authenticate User",
 
−
          "purposeCategory": [ "1 - Core Function" ],
 
−
          "consentType": "EXPLICIT",
 
−
          "piiCategory": [ "2 - Contact" ],
 
−
          "primaryPurpose": true,
 
−
          "termination": "http:idesg-idp.azurewebsites.net/Home/About",
 
−
          "thirdPartyDisclosure": false
 
−
        },
 
−
        {
 
−
          "purpose": "Federated Logon",
 
−
          "purposeCategory": [ "2 - not clear to me" ],
 
−
          "consentType": "IMPLICIT",
 
−
          "piiCategory": [ "2 - Contact", "3 - More stuff" ],
 
−
          "primaryPurpose": false,
 
−
          "termination": "same as primary purpose",
 
−
          "thirdPartyDisclosure": true,
 
−
          "thirdPartyName": "this will be the site you visit"
 
−
        }
 
−
      ]
 
−
    }
 
−
  ],
 
−
  "sensitive": "false"
 
−
}
 
  
−
===XML output===
+
===Standards===
 +
*[https://www.w3.org/community/dpvcg/ W3C DATA PRIVACY VOCABULARIES AND CONTROLS COMMUNITY GROUP]
  
−
This is a conversion of the same [JSONOBJECT] that was converted to JSON above.
+
==References==
  
−
<?xml version="1.0"?>
+
[[Category:Glossary]]
−
<?xml-stylesheet type="text/xsl" href="ConsentReceipt-min.xsl" ?>
+
[[Category:Authentication]]
−
<ConsentReceipt>
+
[[Category:Privacy]]
−
  <version>KI-CR-v1.1.0</version>
+
[[Category:Consent]]
−
  <jurisdiction>WA</jurisdiction>
+
[[Category: Notice]]
−
  <consentTimestamp>2018-06-07T05:18:39.7205685Z</consentTimestamp>
 
−
  <collectionMethod>user input</collectionMethod>
 
−
  <consentReceiptID>57678f2e-0ea7-4da9-b01b-0446902ffced</consentReceiptID>
 
−
  <language>en</language>
 
−
  <piiPrincipalId>tomcjones</piiPrincipalId>
 
−
  <piiControllers json:Array="true" xmlns:json="http://james.newtonking.com/projects/json">
 
−
    <piiController>IDESGidp</piiController>
 
−
    <contact>jerry</contact>
 
−
    <address>too restrictive for small sites</address>
 
−
    <email>jerry@ca0.net</email>
 
−
    <phone>too restrictive for small sites</phone>
 
−
  </piiControllers>
 
−
  <policyUrl>http:idesg-idp.azurewebsites.net/Home/About</policyUrl>
 
−
  <services json:Array="true" xmlns:json="http://james.newtonking.com/projects/json">
 
−
    <service>IdP</service>
 
−
    <purposes>
 
−
      <purpose>Authenticate User</purpose>
 
−
      <purposeCategory json:Array="true">1 - Core Function</purposeCategory>
 
−
      <consentType>EXPLICIT</consentType>
 
−
      <piiCategory json:Array="true">2 - Contact</piiCategory>
 
−
      <primaryPurpose>true</primaryPurpose>
 
−
      <termination>http:idesg-idp.azurewebsites.net/Home/About</termination>
 
−
      <thirdPartyDisclosure>false</thirdPartyDisclosure>
 
−
    </purposes>
 
−
    <purposes>
 
−
      <purpose>Federated Logon</purpose>
 
−
      <purposeCategory json:Array="true">2 - not clear to me</purposeCategory>
 
−
      <consentType>IMPLICIT</consentType>
 
−
      <piiCategory>2 - Contact</piiCategory>
 
−
      <piiCategory>3 - More stuff</piiCategory>
 
−
      <primaryPurpose>false</primaryPurpose>
 
−
      <termination>same as primary purpose</termination>
 
−
      <thirdPartyDisclosure>true</thirdPartyDisclosure>
 
−
      <thirdPartyName>this will be the site you visit</thirdPartyName>
 
−
    </purposes>
 
−
  </services>
 
−
  <sensitive>false</sensitive>
 
−
</ConsentReceipt>
 

Latest revision as of 18:44, 5 March 2022

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.

Standards

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Consent_Receipt&oldid=14031"