Hello James, Thank you for your insightful email.
I have been a fan of the Linux Foundation's Hyperledger project for a while and I think the possibilities of blockchain are enormous. When the community has a release of Fineract CN, I think it'll be worthwhile to experiment with this integration. As a matter of fact, Myrle Krantz has done some work on Fineract CN / Stellar bridge which can be very useful for your proposal. Here is my two penny worth on the topic. Cheers, Isaac Kamga. On Mon, Sep 10, 2018 at 7:31 PM James Dailey <[email protected]> wrote: > 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 >
