Difference between revisions of "User Consent"
From MgmtWiki
(→Consent Page) |
|||
| (32 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | User | + | [[User Consent]] is the informed [[Grant]] by the user to information or resources owned or controlled by the [[User]]. |
==Context== | ==Context== | ||
| − | *During an authorization request by a Relying Party, the [[Identifier or Attribute Provider]] requires user consent redirecting the user to the consent page. | + | *This page is about the use case of a [[User]] on a [[User Agent]] authenticated by an [[Identifier or Attribute Provider]] (IAP) that requests [[User Consent]] to [[Authorization|Authorize]] release of [[User Private Information]] and other [[Resource]]s to a [[Relying Party]] (RP). |
| + | *This page does not consider [[User Public Information]] or the [[Right to be Forgotten]]. | ||
| + | *During an authorization request by a [[Relying Party]], the [[Identifier or Attribute Provider]] requires user consent redirecting the user to the consent page. | ||
*Consent is used to allow an end user to grant a client access to resources (identity or API). | *Consent is used to allow an end user to grant a client access to resources (identity or API). | ||
| Line 10: | Line 12: | ||
==Solution== | ==Solution== | ||
| − | In this wiki it is assumed that there can exist only one active [[User Consent]] among three parties on the internet, the [[Subject]] (aka [[User]]) the [[Identifier or Attribute Provider]] and the [[Relying Party]]. It is unclear if [[User Consent]] has any specific meaning between the [[Subject]] and the [[Identifier or Attribute Provider]]; that is left for further developments. | + | In this wiki it is assumed that there can exist only one active [[User Consent]] among three parties on the internet, the [[Subject]] (aka [[User]]) the [[Identifier or Attribute Provider]] and the [[Relying Party]]. It is unclear if [[User Consent]] has any specific meaning between the [[Subject]] and the [[Identifier or Attribute Provider]]; that is left for further developments. In other words, if the user updates consent - all prior consents are unavailable for new actions. |
===Consent Page=== | ===Consent Page=== | ||
| Line 16: | Line 18: | ||
*A consent page normally renders the display name of the current user, the display name of the [[Relying Party]] (aka client) requesting access, the logo of the client, a link for more information about the client, and the list of resources the client is requesting access to. It’s also common to allow the user to indicate that their consent should be “remembered” so they are not prompted again in the future for the same client. | *A consent page normally renders the display name of the current user, the display name of the [[Relying Party]] (aka client) requesting access, the logo of the client, a link for more information about the client, and the list of resources the client is requesting access to. It’s also common to allow the user to indicate that their consent should be “remembered” so they are not prompted again in the future for the same client. | ||
*Once the user has provided consent, the consent page must inform [[Identifier or Attribute Provider]] of the consent, and then the browser must be redirected back to allow the user to continue where they left off. | *Once the user has provided consent, the consent page must inform [[Identifier or Attribute Provider]] of the consent, and then the browser must be redirected back to allow the user to continue where they left off. | ||
| + | *The user's choice may be stored for later use by the same [[Web Site]] if the user opts into that option. If the user does not opt in, the choice as to scopes, date and destination MUST not be saved. | ||
| + | |||
| + | ===Back at the Relying Party=== | ||
| + | The [[User Consent]] provided might not align exactly with what the RP requested. In that case the RP may accept the consent granted, or it may need to go back to the user for additional [[Attribute]]s or some [[Validated|Validation]] of the [[Attribute]]s. It is important at this point to know if the session with the IAP is still valid, or if a new session would be initiated. The [[User Experience]] should be maximized whichever path is chosen. | ||
| + | |||
| + | ===Consent Taxonomy=== | ||
| + | The user must be shown a list of categories of [[User Private Information]] we start with a [https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims list] of [[OpenID Connect]] [[Scope]]s and move on from there. Note that if [[Recovery]] or [[Notification]] is required, then either phone or email must be included; (theoretically address would work, but practically it is not included.) | ||
| + | {|border="1" padding="2" width="799px" | ||
| + | | Name || OIDC || Priv Risk|| Notes | ||
| + | |- | ||
| + | |openid ||yes||0 || requests access to the user_id (sub) [[Claim]] which is here assumed to be pair-wise unique for the privacy score. | ||
| + | |- | ||
| + | |profile ||yes ||4 || requests that access to the End-User’s profile Claims excluding the address and email Claims. | ||
| + | |||
| + | |- | ||
| + | |email|| yes|| 4|| requests that access to the email and verified Claims | ||
| + | |- | ||
| + | |Email validated || -||0 ||more significant for AuthN - needed if noticed desired | ||
| + | |- | ||
| + | |address|| yes|| 4||requests access to address Claim | ||
| + | |- | ||
| + | |addr validated||-||0|| for example by AAMVA | ||
| + | |- | ||
| + | |phone|| -|| 4||requests that access to the phone_number Claim (assumed SMS capable) | ||
| + | |- | ||
| + | |phone validated||-||0 || more significant for AuthN - needed if noticed desired | ||
| + | |- | ||
| + | |user device location||-||4||request for location of device used for this interaction (note that IP addresses leak a fairly good approximation of this) | ||
| + | |} | ||
| + | |||
| + | ==References== | ||
| + | <references /> | ||
| + | ===Other Sources=== | ||
| + | *See the [http://hl7.org/fhir/secpriv-module.html FHIR section on security and privacy] for the HL7 take on privacy consent. | ||
| + | *[https://www.priv.gc.ca/en/privacy-topics/collecting-personal-information/consent/gl_omc_201805/ Guidelines for obtaining meaningful consent] from Office of the Privacy Commissioner of Canada which began to apply these guidelines on January 1, 2019. | ||
| + | *[http://www.meaningfulconsent.org/ Meaningful Consent in the Digital Economy] (MCDE) is an EPSRC-funded research project that is examining issues related to giving and obtaining user consent online. | ||
| + | *The wiki page [[Financial User Consent]] extends this use case for where items of value are exchanged. | ||
| + | |||
| + | [[Category:Glossary]] | ||
| + | [[Category:Privacy]] | ||
| + | [[Category:Consent]] | ||
| + | [[Category:Use Case]] | ||
Revision as of 14:47, 14 April 2019
Contents
Full Title or Meme
User Consent is the informed Grant by the user to information or resources owned or controlled by the User.
Context
- This page is about the use case of a User on a User Agent authenticated by an Identifier or Attribute Provider (IAP) that requests User Consent to Authorize release of User Private Information and other Resources to a Relying Party (RP).
- This page does not consider User Public Information or the Right to be Forgotten.
- During an authorization request by a Relying Party, the Identifier or Attribute Provider requires user consent redirecting the user to the consent page.
- Consent is used to allow an end user to grant a client access to resources (identity or API).
Problem
User consent is discussed in the GDPR for transfers of User Information between two Data Controllers on the internet. It is not clear if the GDPR or other regulations apply to a site that collects user data for its own purposes and does not further process or share that User Information. Nor is any temporal relationship between User Consent acts described. So it is not clear if a new User Consent arrives, what action should be taken vis a vis any prior consents. If older consents are not invalidated, it is unclear how to evaluate conflict between the different consents.
Solution
In this wiki it is assumed that there can exist only one active User Consent among three parties on the internet, the Subject (aka User) the Identifier or Attribute Provider and the Relying Party. It is unclear if User Consent has any specific meaning between the Subject and the Identifier or Attribute Provider; that is left for further developments. In other words, if the user updates consent - all prior consents are unavailable for new actions.
Consent Page
In order for the user to grant consent, a consent page must be provided by the Identifier or Attribute Provider.
- A consent page normally renders the display name of the current user, the display name of the Relying Party (aka client) requesting access, the logo of the client, a link for more information about the client, and the list of resources the client is requesting access to. It’s also common to allow the user to indicate that their consent should be “remembered” so they are not prompted again in the future for the same client.
- Once the user has provided consent, the consent page must inform Identifier or Attribute Provider of the consent, and then the browser must be redirected back to allow the user to continue where they left off.
- The user's choice may be stored for later use by the same Web Site if the user opts into that option. If the user does not opt in, the choice as to scopes, date and destination MUST not be saved.
Back at the Relying Party
The User Consent provided might not align exactly with what the RP requested. In that case the RP may accept the consent granted, or it may need to go back to the user for additional Attributes or some Validation of the Attributes. It is important at this point to know if the session with the IAP is still valid, or if a new session would be initiated. The User Experience should be maximized whichever path is chosen.
Consent Taxonomy
The user must be shown a list of categories of User Private Information we start with a list of OpenID Connect Scopes and move on from there. Note that if Recovery or Notification is required, then either phone or email must be included; (theoretically address would work, but practically it is not included.)
| Name | OIDC | Priv Risk | Notes |
| openid | yes | 0 | requests access to the user_id (sub) Claim which is here assumed to be pair-wise unique for the privacy score. |
| profile | yes | 4 | requests that access to the End-User’s profile Claims excluding the address and email Claims. |
| yes | 4 | requests that access to the email and verified Claims | |
| Email validated | - | 0 | more significant for AuthN - needed if noticed desired |
| address | yes | 4 | requests access to address Claim |
| addr validated | - | 0 | for example by AAMVA |
| phone | - | 4 | requests that access to the phone_number Claim (assumed SMS capable) |
| phone validated | - | 0 | more significant for AuthN - needed if noticed desired |
| user device location | - | 4 | request for location of device used for this interaction (note that IP addresses leak a fairly good approximation of this) |
References
Other Sources
- See the FHIR section on security and privacy for the HL7 take on privacy consent.
- Guidelines for obtaining meaningful consent from Office of the Privacy Commissioner of Canada which began to apply these guidelines on January 1, 2019.
- Meaningful Consent in the Digital Economy (MCDE) is an EPSRC-funded research project that is examining issues related to giving and obtaining user consent online.
- The wiki page Financial User Consent extends this use case for where items of value are exchanged.
