Hi Devs - I'd like to raise an issue with regard to how Fineract 1.x and the new Fineract-CN treats the concept of Identity.
I was recently looking at Isaac's work on https://github.com/apache/fineract-cn-customer/pull/7/commits/65a88b9879a46103fae440c42d1b0058909a93aa . It got me thinking... I was unclear if the tests are fully covering our functionality, and wonder about how we are collectively thinking about identity. So, there has been a lot of work done recently on Digital Identity and Credentials globally. I think we should have as part of our thinking and structure of the identity service: 1. Issuing authority (this could be any relevant civil authority such as Federal Government, State Department, Provincial Gov't), any private or non-profit but recognized entity (e.g. University), and also any commercial entity that has a pre-existing relationship including Bank, Mobile Provider, Microfinance Entity, or even Facebook/WeChat/Alibaba. When dealing with the unbanked, or underbanked, a form of digital identity may be self-issued or issued on the spot, and be trusted up to a point (see KYC below). 2. Credentials and Forms of verification - this could be a separate concept in Fineract of [one to many] relationship where Fineract CN stores that information or simply notes that multiple sources of verification of identity or "claims" have been verified. For example, a person my present a paper form from the local utility company showing they are a customer. Or, for example, a person may be verified by the mobile provider as being on that network with that specific IMEI (device) and that specific telephone number. I think it is important to treat such forms as security tokens (encrypted). 3. Claims - there have been attempts at the W3C (world wide web consortium) related to the issue of verification of digital identity, to describe these as "claims" where an individual may have multiple sources in the formal and informal sectors by which they can claim identity. I think of Claims as IssuingAuthority+Verified, but that may be oversimplification. Please see https://www.w3.org/TR/verifiable-claims-use-cases/ . 4. Relationship with KYC and AML/CFT - In Mifos and now in Fineract we have a set of requirements around the relationship between the validity of the identity against regulations dealing with "know your customer" and "anti-money-laundering" (inbound flows) and "counter the financing of terrorism" (outbound flows). These requirements generally start with KYC where the levels are generally thought of as KYC-0 (e.g. we don't know much about them, but the authorities allow us to transact up to $300 per month), KYC-1, KYC-2, up to KYC-3 (e.g.they have a formal and verified identity credential from the national biometric system and they have up to the limit of banking rules) In Fineract, I believe that what needs to be stored is the initial authorized level of KYC, the record of how much is expected to be transacted and then a calculated actual amount transacted so that exceptional transactions can be flagged, and the movement from one KYC level to another. It is common in banking at least to have a SAR (Suspicious Activity Report) based on a comparison of expected transactions and actual. The banking sector has been practicing this for a long time and rules are understood. At OSCON we also learned about INDY, which is part of the Hyperledger project, and deals with Identity using some new distributed ledger based tools. I think it would be interesting to create a proof of concept where we link our identity service to the Indy code. https://www.hyperledger.org/blog/2017/05/02/hyperledger-welcomes-project-indy . This builds out the concept of a globally accessible public utility for decentralized identity. What would be a useful next step on this? Hoping for comments and exploration of requirements. Thanks, James
