Consent Management - Revision history

Tom: /* Problems */

2024-12-05T22:26:03Z

‎Problems

Tom: /* Protocols */

2023-07-24T22:31:53Z

‎Protocols

Tom: /* Protocols */

2023-07-24T22:31:29Z

‎Protocols

Tom: /* Protocols */

2023-07-24T22:27:06Z

‎Protocols

Tom: /* Protocols */

2023-07-24T04:34:16Z

‎Protocols

Tom: /* Protocols */

2023-07-24T04:30:55Z

‎Protocols

Tom: /* HealthCare */

2023-07-24T04:24:08Z

‎HealthCare

Tom: /* HealthCare */

2022-02-13T22:34:58Z

‎HealthCare

Tom: /* HealthCare */

2022-02-13T22:30:45Z

‎HealthCare

Tom: /* HealthCare */

2022-02-13T22:30:01Z

‎HealthCare

@@ Line 16: / Line 16: @@
 ==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 [[General_Theory_of_Living_Systems#Cognitive_Overload|Cognitive Overload]] for the [[User]].
 ==Solutions==

@@ Line 24: / Line 24: @@
 [[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]] 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>
+* [[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.

@@ Line 24: / Line 24: @@
 [[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]]
+* [[OpenID Connect]] 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.

@@ Line 23: / Line 23: @@
 ===Protocols===
 [[Consent Management]] seems to have been an after thought of most protocols.
-* [[OAuth 2.0]]
+* [[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]]
 * [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.

@@ Line 22: / Line 22: @@
 *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 seemed to have been an after thought of most protocols.
+[[Consent Management]] seems to have been an after thought of most protocols.
-* [[Oauth 2.0]]
+* [[OAuth 2.0]]
 * [[OpenID Connect]]
 * [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.

@@ Line 21: / 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.
 *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.
 ===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.