Difference between revisions of "Financial User Consent"

Revision as of 15:57, 15 April 2019

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.

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 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.

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, wo 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

1. A user in France has a bank account in the UK denominated in pounds.
2. That user goes to Amazon, where they have an account, and finds a product that is supplied by a merchant in Hong Kong.
3. The merchant uses Amazon in the US as their payment initiator.
4. 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.
5. 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.
6. 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?)
7. In this case the payment initiator of record may have no previous contact with the user, perhaps they would communicate via Amazon US?

Consent Taxonomy

• For the semi-static 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

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.