>From reading a description of the issue in 1034 (have not looked into the PR), an example where this functionality could eventually help (and is distinct from our usage of HTTPS) would be in scenarios involving PCI compliance in server to server communications.
Assume Org A offers Fineract on a SaaS model. Further assume that Org A is PCI SAQ D compliant, which means that this organization may store/transmit personal details (Card number, CVV code, and expiry date) linked to cards. Assume Org B is a lending Fintech that builds on top of the API's offered by Org A and has use cases like pushing loan disbursals directly to external debit/credit cards (think of a country like the US where payment rails provided by card networks are faster/cheaper than account to account transfer alternatives like ACH or FedWire). To reduce compliance costs, Org B decides to opt for PCI compliance level SAQ A, this means that Org B will not have any card personal data (in un-encrypted format) flow through their network (or be stored by their servers). If Org B wants to allow their clients to provide details of their external debit /credit cards (assume from a mobile device) , these details need to be encrypted from the Clients device, flow to Org B's backend, from where a request is made to Org A's API. Org A would then decrypt the card details, tokenize this card and pass an identifying token back to Org B's backend, which is then used for identifying this card for future transactions. Regards, Vishwas On Thu, 16 Jul 2020 at 09:58, Awasum Yannick <awa...@apache.org> wrote: > Hi All, > > Is there anyone here with experience on how this PR can help Fineract? > https://github.com/apache/fineract/pull/1032 > > This might be valuable work but I don't understand the use case and > am reaching out to you all to see if someone can help. > > I tried to review it but could not understand it adequately to comfortably > merge. > > > Here is the JIRA: https://issues.apache.org/jira/browse/FINERACT-1034 > > Thanks. > Awasum >
