Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling consents given for transactions #109

Open
Pushpalanka opened this issue Sep 25, 2017 · 5 comments
Open

Handling consents given for transactions #109

Pushpalanka opened this issue Sep 25, 2017 · 5 comments

Comments

@Pushpalanka
Copy link

Hi,

If think along the directions of PSD2 (Payment Services Directive 2), it needs to keep consents for transactions and specifically need to address consents given for recurrent transactions. As far as I understand this implies for example,
User will give consent for a particular amount to be paid on a specific date may be monthly per weekly. If it's to pay a loan premium, user will consent, in each month on date 31st pay x amount to this third party.
As per the current consent receipt specification, it deals with an specific termination period which fails to address a case like this. Also since the consent is given for a PII category, how would that exactly deal with the real amount user has consented to pay in a transaction?

Is the above use case is something out of this specification?
Appreciate your inputs to understand this bit.. Thanks in advance.

@TomCJones
Copy link

As I understand the consent receipt it is related to personal information, not monetary commitments.

@Pushpalanka
Copy link
Author

Thanks @TomCJones for pointing out. I assume the specification has closely considered the 'ISO/IEC
29100 - Information technology — Security techniques — Privacy framework' standard which includes 'financial profile' as an example of a PII. But yes, it really doesn't mean to deal with the transaction values and commitments.

On the other hand, if we take a step back and think of 'Consent and Information sharing' as a whole, won't it be good to address this? If considered in general this means handling consent based on the value of a PII of PII principal along with other attached attributes.

Eg.

  • In Financial domain, if consider a transaction as a PII, the transaction value and other attributes such as currency.
  • In a health care domain, if we consider a medical record, patient may consent a 'cardilogist' to access his/her ECG reports etc. only if his/her heart rate value is abnormal.

In order to automate such scenarios, it will be useful to consider more attributes attached with PII.
I am not sure, if this is going into too much details than the intentions of the specification. Appreciate your thoughts..

@TomCJones
Copy link

It is more oriented to the GDPR https://www.privacy-regulation.eu/
I believe that each vertical is planning their own framework as each will have its own set of nomenclature with respect to authentication. I would expect consent to follow that pattern.

@Pushpalanka
Copy link
Author

Yes, understood.. Thanks a lot for thoughts..

@dturnerx
Copy link

The examples above represent two different types of consent. In the case of a financial transaction, the user is consenting to the execution of the transaction, which we are not trying to address. The transaction process may also include consent for the use of PII, unless such consent was provided by the user beforehand, which is in-scope.

The healthcare example should be in-scope of our work because it is specifically about the use and transfer of PII.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants