Difference between revisions of "Financial User Consent"
From MgmtWiki
(Created page with "==Full Title or Meme== Financial User Consent extends the User Consent use case with significant exchange of value, typically payment data. ==Context== *This page is...") |
(→Context) |
||
| (29 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
| − | + | This context is specific to this use case and may not apply in all legal jurisdictions. For example,not all legal jurisdictions agree that a holder of user assets has a [[Fiduciary]] responsibility to the user. | |
| − | |||
| − | |||
| − | |||
| − | == | + | *This page is about the use case of a [[User]] on a [[User Agent]] authenticated by an [[Identifier or Attribute Provider]] (IAP) with two areas of consent: |
| − | User consent is discussed in the [[GDPR]] for transfers of [[User Information]] between two [[Data Controller]]s on the internet. It is not clear if the [[GDPR]] or other regulations apply to a | + | ** the IAP requests [[User Consent]] to [[Authorization|Authorize]] release of [[User Private Information]] and other [[Resource]]s to a [[Relying Party]] (RP). |
| + | ** some fiduciary holder of user assets (Account Servicing Payment Service Provider (ASPSP)) needs [[User Consent]] to release those assets. | ||
| + | *During an authorization request for [[User Information]] by a [[Relying Party]], the [[Identifier or Attribute Provider]] requires user consent redirecting the user to the consent page. | ||
| + | *User Consent to release information may be cached by the IAP with permission from the user which does not alter a requirement to notify the user of release of information. | ||
| + | *User Consent to release money (or other assets) by likewise be cached by a Payment Initiation Service Provider (PISP) which does not alter a requirement to notify the user of release of funds. | ||
| + | *This use case considers the process from user consent to user notification to be a single process that must be managed in a single manner for the best [[User Experience]]. | ||
| + | |||
| + | ==Problems== | ||
| + | *User consent is discussed in the [[GDPR]] for transfers of [[User Information]] between two [[Data Controller]]s on the internet. It is not clear if the [[GDPR]] or other privacy regulations apply to a transaction where an existing relationship exists between [[Data Controller]]s who then enter into a transaction that involves the exchange of money. Note that the details in the transaction may be very sensitive based on the contents of the item purchased. | ||
| + | *Much of the current emphasis on technology improvement in financial transaction is the same change found already in technology improvement in existing industries, reduction in [[Friction]]. But [[Friction]] serves an important function where money in involved. For example, in "the UK, the introduction of a Faster Payments Service (FPS) resulted in an unfortunate reality - faster fraud."<ref>Kristopher Rogers, ''The Future of Direct Debit: 2 key drivers for change in 2019.'' Split Payments (2019-04-01 -- Hmm, I guess he really means it?0 https://www.linkedin.com/pulse/future-direct-debit-2-key-drivers-change-2019-kristofer-rogers/</ref> Somehow the current [[Open Banking]] effort there seems to believe that they can solve this problem. That remains to be seen. | ||
==Solution== | ==Solution== | ||
| Line 15: | Line 21: | ||
===Consent Page=== | ===Consent Page=== | ||
| − | In order for the user to grant consent, a consent page must be provided by the [[Identifier or Attribute Provider]]. | + | In order for the user to grant consent for collecting [[User Information]], 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. | *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. | ||
| Line 21: | Line 27: | ||
===Back at the Relying Party=== | ===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. | + | *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. |
| + | *The [[Relying Party]] may be a Payment Initiator, or may use some other service for that function. | ||
| + | *Only the [[Relying Party]] may set the conditions that it needs for compliance in its legal jurisdictions; so it must have the means to express the consent conditions that are required of the user. In a hyper connected environment there may be as many jurisdictions as there are parties. Consider the following all to real path. | ||
| + | |||
| + | ===Possible Complexity of a Financial Transaction=== | ||
| + | #A user in France has a bank account in the UK denominated in pounds. | ||
| + | #That user goes to Amazon, where they have an account, and finds a product that is supplied by a merchant in Hong Kong. | ||
| + | #The merchant uses Amazon in the US as their payment initiator. | ||
| + | #Since Amazon has an account with the user and has obtained permission to bill their account, it sends a payment via its subsidiary in Ireland to the bank in the UK. | ||
| + | #The bank in the UK may, or may not need to get consent from the user to bill this transaction, assuming it does not the user still needs to know that the transaction completes. | ||
| + | #Either the bank or the payment initiator needs to notify the user that the transaction completed. From the legal perspective that would the Amazon subsidiary in Ireland (maybe?) | ||
| + | #In this case the payment initiator of record may have no previous contact with the user, perhaps they would communicate via Amazon US? | ||
| + | |||
| + | The real reason for showing the potential complexity of financial transaction in a fully disbursed regulatory environment, is that some entity must be tasked with getting user consent. In my understanding of the reality of this transaction, only Amazon US has sufficient detail to determine which legal jurisdiction(s) apply and must be the [[Entity]] to establish the consent regime. | ||
| + | |||
| + | Note that in the US today there are many new payment initiators (like square) that result in a posting on the user account statement that is pretty much complete gibberish. Some banks in the US have resorted to AI as a service to the users to try to disambiguate the transaction record. That case may be happening soon with the transaction records in Europe. It should be clear that a little foresight can help to establish the appropriate [[Entity]] based on the knowledge that they have of the complete transaction. That [[Entity]] should be the one to craft the notification record for the user as well. In any case the contemporaneous notification to the user really should match the record that appears on the user's monthly statement. | ||
===Consent Taxonomy=== | ===Consent Taxonomy=== | ||
| − | + | * For the semi-static [[Attribute]] information the user must be shown a list of categories of [[User Private Information]] one the wiki page [[User Consent#Consent Taxonomy]]] 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. This is typically user [[Attribute]]s. | |
| − | + | * For the transactional information the user must know what value is being transfered, both in terms of the money (or other value tokens) sent in one direction and the goods or services sent in exchange for that money. This transaction typically exposes user [[Behavior]], which can still be very personal especially if the goods or services are related to health care issues. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==References== | ==References== | ||
<references /> | <references /> | ||
===Other Sources=== | ===Other Sources=== | ||
| + | *The wiki page on [[Open Banking]] discuses some of the transactional consent that the UK OBIE have documented. | ||
*See the [http://hl7.org/fhir/secpriv-module.html FHIR section on security and privacy] for the HL7 take on privacy consent. | *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. | *[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. | *[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. | ||
| + | * [https://www.notion.so/Knowledge-Base-78ccd4e0d1144e3e9ca76b7b1345a0c1 Use of SSI in Financial Transactions] | ||
| − | [[Category:Glossary]] | + | [[Category: Glossary]] |
| − | [[Category:Privacy]] | + | [[Category: Privacy]] |
| − | [[Category:Consent]] | + | [[Category: Consent]] |
| − | [[Category:Use Case]] | + | [[Category: User Experience]] |
| + | [[Category: Use Case]] | ||
Latest revision as of 15:18, 13 September 2024
Contents
Full Title or Meme
Financial User Consent extends the User Consent use case with significant exchange of value, typically payment data.
Context
This context is specific to this use case and may not apply in all legal jurisdictions. For example,not all legal jurisdictions agree that a holder of user assets has a Fiduciary responsibility to the user.
- This page is about the use case of a User on a User Agent authenticated by an Identifier or Attribute Provider (IAP) with two areas of consent:
- the IAP requests User Consent to Authorize release of User Private Information and other Resources to a Relying Party (RP).
- some fiduciary holder of user assets (Account Servicing Payment Service Provider (ASPSP)) needs User Consent to release those assets.
- During an authorization request for User Information by a Relying Party, the Identifier or Attribute Provider requires user consent redirecting the user to the consent page.
- User Consent to release information may be cached by the IAP with permission from the user which does not alter a requirement to notify the user of release of information.
- User Consent to release money (or other assets) by likewise be cached by a Payment Initiation Service Provider (PISP) which does not alter a requirement to notify the user of release of funds.
- This use case considers the process from user consent to user notification to be a single process that must be managed in a single manner for the best User Experience.
Problems
- 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 privacy regulations apply to a transaction where an existing relationship exists between Data Controllers who then enter into a transaction that involves the exchange of money. Note that the details in the transaction may be very sensitive based on the contents of the item purchased.
- Much of the current emphasis on technology improvement in financial transaction is the same change found already in technology improvement in existing industries, reduction in Friction. But Friction serves an important function where money in involved. For example, in "the UK, the introduction of a Faster Payments Service (FPS) resulted in an unfortunate reality - faster fraud."[1] Somehow the current Open Banking effort there seems to believe that they can solve this problem. That remains to be seen.
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 for collecting User Information, 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.
- The Relying Party may be a Payment Initiator, or may use some other service for that function.
- Only the Relying Party may set the conditions that it needs for compliance in its legal jurisdictions; so it must have the means to express the consent conditions that are required of the user. In a hyper connected environment there may be as many jurisdictions as there are parties. Consider the following all to real path.
Possible Complexity of a Financial Transaction
- A user in France has a bank account in the UK denominated in pounds.
- That user goes to Amazon, where they have an account, and finds a product that is supplied by a merchant in Hong Kong.
- The merchant uses Amazon in the US as their payment initiator.
- Since Amazon has an account with the user and has obtained permission to bill their account, it sends a payment via its subsidiary in Ireland to the bank in the UK.
- The bank in the UK may, or may not need to get consent from the user to bill this transaction, assuming it does not the user still needs to know that the transaction completes.
- Either the bank or the payment initiator needs to notify the user that the transaction completed. From the legal perspective that would the Amazon subsidiary in Ireland (maybe?)
- In this case the payment initiator of record may have no previous contact with the user, perhaps they would communicate via Amazon US?
The real reason for showing the potential complexity of financial transaction in a fully disbursed regulatory environment, is that some entity must be tasked with getting user consent. In my understanding of the reality of this transaction, only Amazon US has sufficient detail to determine which legal jurisdiction(s) apply and must be the Entity to establish the consent regime.
Note that in the US today there are many new payment initiators (like square) that result in a posting on the user account statement that is pretty much complete gibberish. Some banks in the US have resorted to AI as a service to the users to try to disambiguate the transaction record. That case may be happening soon with the transaction records in Europe. It should be clear that a little foresight can help to establish the appropriate Entity based on the knowledge that they have of the complete transaction. That Entity should be the one to craft the notification record for the user as well. In any case the contemporaneous notification to the user really should match the record that appears on the user's monthly statement.
Consent Taxonomy
- For the semi-static Attribute information the user must be shown a list of categories of User Private Information one the wiki page User Consent#Consent Taxonomy] start with a list of OpenID Connect Scopes and move on from there. This is typically user Attributes.
- For the transactional information the user must know what value is being transfered, both in terms of the money (or other value tokens) sent in one direction and the goods or services sent in exchange for that money. This transaction typically exposes user Behavior, which can still be very personal especially if the goods or services are related to health care issues.
References
- ↑ Kristopher Rogers, The Future of Direct Debit: 2 key drivers for change in 2019. Split Payments (2019-04-01 -- Hmm, I guess he really means it?0 https://www.linkedin.com/pulse/future-direct-debit-2-key-drivers-change-2019-kristofer-rogers/
Other Sources
- The wiki page on Open Banking discuses some of the transactional consent that the UK OBIE have documented.
- 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.
- Use of SSI in Financial Transactions
