[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identity and Fineract

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.

Isaac Kamga.

On Mon, Sep 10, 2018 at 7:31 PM James Dailey <jamespdailey@xxxxxxxxx> 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
>    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