Difference between revisions of "Consent Management"
(→Solutions) |
(→Protocols) |
||
| (20 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
In order to ensure that consent is freely given, consent should not provide a valid legal ground for the processing of personal data in a specific case where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation. Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. | In order to ensure that consent is freely given, consent should not provide a valid legal ground for the processing of personal data in a specific case where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation. Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. | ||
</blockquote> | </blockquote> | ||
| + | |||
| + | The Office of the Privacy Commissioner of Canada has published Guidelines for obtaining meaningful consent<ref>Privacy Commissioner of Canada, ''Guidelines for obtaining meaningful consent.'' https://www.priv.gc.ca/en/privacy-topics/collecting-personal-information/consent/gl_omc_201805/</ref> which "sets out practical and actionable guidance regarding what organizations should do to ensure that they obtain meaningful consent." | ||
==Problems== | ==Problems== | ||
| Line 19: | Line 21: | ||
*Make sure that there is a list of the data types that can be displayed to the user when asking for consent. Too many details will not be helpful, so the categories need to be broad, yet not confusing, for example, don't ask the user for consent to have their street, then their city, then their state, etc., just ask for consent for the mailing address. | *Make sure that there is a list of the data types that can be displayed to the user when asking for consent. Too many details will not be helpful, so the categories need to be broad, yet not confusing, for example, don't ask the user for consent to have their street, then their city, then their state, etc., just ask for consent for the mailing address. | ||
*The [[User Consent]] page should have check boxes for each data type that may be pre-filled by the [[Web Site]], but under control of the user. Some legislation requires the [[Web Site]] to tell the user which types are mandatory, but in any case the site should be able to continue to function for the user if some types are unchecked. Clearly a mailing address will be required if the user wants to have a package mailed to them, but not if they are getting online delivery. Asking for a billing address if a credit card is used is not required, but some sites will not work if it is not provided. That behavior is now illegal in some jurisdictions. | *The [[User Consent]] page should have check boxes for each data type that may be pre-filled by the [[Web Site]], but under control of the user. Some legislation requires the [[Web Site]] to tell the user which types are mandatory, but in any case the site should be able to continue to function for the user if some types are unchecked. Clearly a mailing address will be required if the user wants to have a package mailed to them, but not if they are getting online delivery. Asking for a billing address if a credit card is used is not required, but some sites will not work if it is not provided. That behavior is now illegal in some jurisdictions. | ||
| + | ===Protocols=== | ||
| + | [[Consent Management]] seems to have been an after thought of most protocols. | ||
| + | * [[OAuth 2.0]] provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user’s credentials. When you use OAuth 2.0 for authorization, Google displays a consent screen to the user including a summary of your project, its policies, and the requested authorization scopes of access.<ref>Auth0, ''What is OAuth 2.0?'' https://auth0.com/intro-to-iam/what-is-oauth-2</ref> | ||
| + | * [[OpenID Connect]] has consent built-in. This is important as OIDC is often used in consumer-facing services (e.g., a Relying Party), where the sharing of personal data requires the user’s explicit consent. However, it is possible to configure OIDC without explicit consent.<ref>Okta ''Request user consent'' https://developer.okta.com/docs/guides/request-user-consent/main/</ref> | ||
| + | * [https://github.com/consumer-reports-innovation-lab/data-rights-protocol Data Rights Protocol] defines a web protocol encoding a set of standardized request/response data flows such that Users can exercise Personal Data Rights provided under regulations like the California Consumer Privacy Act, General Data Protection Regulation, and other regulatory or voluntary bases, and receive affirmative responses in standardized formats. | ||
| + | |||
| + | ===HealthCare=== | ||
| + | There are two types of consent involved, consent to access user information and consent to preform a medical procedure. This sections is entirely about the former. | ||
| + | * [[FHIR]] provides a [http://www.hl7.org/fhir/consent.html resource consent] which create a "record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." It appears that this was designed solely to enable access to a FHIR CRUD API by a medical practitioner, or payor, that is part of the FHIR HIPPA entities. It is likely that this resource consent is derived from written consent provided by the patient to the [[EHR]]. | ||
| + | * While the FHIR resource consent is already derived, it [https://www.linkedin.com/pulse/applied-fhir-consent-jaime-olivares/ has been proposed] that Applied FHIR Consent could be offered as a twice-derived service. (2022-02-13) | ||
| + | * To be part of the patient's actual interchanges atom sort of [[Smartphone]].[[Native App]] would likely be required to be able to create a consent request ia some common format. | ||
==References== | ==References== | ||
| Line 24: | Line 37: | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category:Privacy]] | ||
| + | [[Category: User Experience]] | ||
| + | [[Category: Consent]] | ||
Latest revision as of 15:31, 24 July 2023
Contents
Full Title or Meme
The process of acquiring, refreshing, managing and deleting User Consent to access User Private Information and other resources.
Context
The primary consideration is the collection of consent from the user, but the need for Recovery, Redress and simple maintenance by the user must be addressed as well.
The EU has already addressed the collection of consent in some guidance.[1] That guidance was based on the following paragraphs 42 and 43 of the GDPR.
Where processing is based on the data subject's consent, the controller should be able to demonstrate that the data subject has given consent to the processing operation. In particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. In accordance with Council Directive 93/13/EEC1 a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.
In order to ensure that consent is freely given, consent should not provide a valid legal ground for the processing of personal data in a specific case where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation. Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.
The Office of the Privacy Commissioner of Canada has published Guidelines for obtaining meaningful consent[2] which "sets out practical and actionable guidance regarding what organizations should do to ensure that they obtain meaningful consent."
Problems
It's easy to say that the user should have control of their own data, it's hard to create a User Experience which enables such control in a manner that does not result in Cognitive Overload for the User.
Solutions
Just a list of some of the factors to address:
- Make sure that there is a list of the data types that can be displayed to the user when asking for consent. Too many details will not be helpful, so the categories need to be broad, yet not confusing, for example, don't ask the user for consent to have their street, then their city, then their state, etc., just ask for consent for the mailing address.
- The User Consent page should have check boxes for each data type that may be pre-filled by the Web Site, but under control of the user. Some legislation requires the Web Site to tell the user which types are mandatory, but in any case the site should be able to continue to function for the user if some types are unchecked. Clearly a mailing address will be required if the user wants to have a package mailed to them, but not if they are getting online delivery. Asking for a billing address if a credit card is used is not required, but some sites will not work if it is not provided. That behavior is now illegal in some jurisdictions.
Protocols
Consent Management seems to have been an after thought of most protocols.
- OAuth 2.0 provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user’s credentials. When you use OAuth 2.0 for authorization, Google displays a consent screen to the user including a summary of your project, its policies, and the requested authorization scopes of access.[3]
- OpenID Connect has consent built-in. This is important as OIDC is often used in consumer-facing services (e.g., a Relying Party), where the sharing of personal data requires the user’s explicit consent. However, it is possible to configure OIDC without explicit consent.[4]
- Data Rights Protocol defines a web protocol encoding a set of standardized request/response data flows such that Users can exercise Personal Data Rights provided under regulations like the California Consumer Privacy Act, General Data Protection Regulation, and other regulatory or voluntary bases, and receive affirmative responses in standardized formats.
HealthCare
There are two types of consent involved, consent to access user information and consent to preform a medical procedure. This sections is entirely about the former.
- FHIR provides a resource consent which create a "record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." It appears that this was designed solely to enable access to a FHIR CRUD API by a medical practitioner, or payor, that is part of the FHIR HIPPA entities. It is likely that this resource consent is derived from written consent provided by the patient to the EHR.
- While the FHIR resource consent is already derived, it has been proposed that Applied FHIR Consent could be offered as a twice-derived service. (2022-02-13)
- To be part of the patient's actual interchanges atom sort of Smartphone.Native App would likely be required to be able to create a consent request ia some common format.
References
- ↑ EU Commission, How should my consent be requested? https://ec.europa.eu/info/law/law-topic/data-protection/reform/rights-citizens/how-my-personal-data-protected/how-should-my-consent-be-requested_en
- ↑ Privacy Commissioner of Canada, Guidelines for obtaining meaningful consent. https://www.priv.gc.ca/en/privacy-topics/collecting-personal-information/consent/gl_omc_201805/
- ↑ Auth0, What is OAuth 2.0? https://auth0.com/intro-to-iam/what-is-oauth-2
- ↑ Okta Request user consent https://developer.okta.com/docs/guides/request-user-consent/main/
