Re: Vetting connectors (was Interledger and Privacy)

Thanks, Evan. I understand the use case for ILP and the necessity to allow
it to interface with the multitude of ledgers in existence. In the end,
this might turn out to be the best route to achieve the Internet of Value
vision championed by Ripple.

In terms of vetting the connectors issue, I propose a vision in which there
are two main kinds of connectors.

The first is An enterprise-grade connector able to handle very large
payments at high volume and high frequency. The vetting of these will
be structured with standard qualifications, insurance, business presence
and maturity. Perhaps W3C can help establish these guidelines. Part of the
conditions required for these connectors  can be borrowed from how
financial institutions today select which correspondent bank to use when
they want to transfer payments globally. The number of these connector and
market-maker types will be limited as not too many will be able to meet the
liquidity requirements risk assessment and insurance required to handle
such high volume high value high frequency transactions. From an
implementation standpoint, the API interfacing with these connectors can
contain a pre-built list of "approved" connectors that are pre-vetted to
handle these transactions globally. The sending company/bank then selects a
suitable connector from the pre-built list.

The second type is a consumer centric connector. These connectors handle
low volume low value transfers with low frequency.  For these, there is an
entirely different risk profile and exposure, therefore the vetting
requirements will be some what different. I envision the creation of what
is equivalent to today's Better Business Bereau where different small size
connectors and market-makers are compared and rated based on different
factors such as usage history, consumer reviews, fees...etc. The rating
system can mirror the stars rating commonly used today ( 5 stars= low risk
and recommend, 1 star= high risk not recommended). From an implementation
standpoint, I see a third party business independent of Ripple developing
this rating system. I can also envision banks having commercial
relationships with some of these market-makers and connectors. When a
consumer logs into his ILP enabled bank account to make a cross border
payment, in addition to selecting the amount and destination, he will be
presented with a page containing a list of connectors with corresponding
fees, history, user reviews, and star rating. He will then select whichever
connector he likes similar to the merchant rating system you see today when
you buy stuff on Amazon.com.

Again, just my 2 cents.

Yassin Mobarak

On Wednesday, November 4, 2015, Evan Schwartz <evan@ripple.com> wrote:

> I don't see a need for a connector if we are both on the RCL ledger.
>
>
> Yassin, you're right that connectors are not needed if everyone is on the
> same ledger. ILP is all about the use case when people are on different
> ledgers. We've found that it's infeasible to expect one ledger to fulfill
> all requirements for everyone, but we still want to enable universal
> payments between people. Instead of convincing lots of people that RCL is
> better than whatever they're already using, I'd rather connect all of the
> ledgers and let people keep using whatever systems serve them best.
>
>
> Wouldn't it be the job of each particular ledger to to answer these
>> questions about connectors and communicate that information to each other
>> as needed (without revealing any more about the connector's identity than
>> absolutely required)?
>
>
> One way to look at the issue of who the connectors are, and how you know
> if they actually have accounts at the ledgers they claim to have accounts
> on would be: you don't have any guarantees. A connector can advertise that
> they can facilitate payments between Ledger A and Ledger B. If that's true
> it'll mean that if A or B are banks they will have done whatever vetting is
> necessary (if either ledger is Bitcoin it won't care and the only
> requirement will be having a Bitcoin wallet). If the connector is lying and
> doesn't have accounts on both of those ledgers, the worst that can happen
> to the sender is:
>
>    - The connector will make off with the fees
>    - The sender will be delayed in sending their payment and will have to
>    retry
>
> The protocol protects the sender from losing the principal of their
> payment. I would argue that the easiest way of addressing the fee and delay
> issues is to keep data on how long connectors have been operating, evidence
> of successful payments, etc. If banks or other specific entities kept track
> of it it would be relatively easy. Keeping this in a public, trustworthy
> and distributed way seems a little more difficult. Anyone have ideas about
> how this could be done?
>
>
>
> On Fri, Oct 30, 2015 at 6:04 AM, Brian Walden <brianwalden@outlook.com
> <javascript:_e(%7B%7D,'cvml','brianwalden@outlook.com');>> wrote:
>
>>
>>
>>
>>
>>
>>
>> *Arie can correct me but I interpreted this as; how do connectors assert
>> who they are and what credentials they have (such as licenses, if required)
>> that users can use to decide if they wish to trust a connector?I think we
>> can seperate this into two "tests" that the user must do:1) Is the
>> connector who they say they are?2) Is the connector qualified to perform
>> the transaction that is being requested?*
>>
>> Wouldn't it be the job of each particular ledger to to answer these
>> questions about connectors and communicate that information to each other
>> as needed (without revealing any more about the connector's identity than
>> absolutely required)?
>>
>> If Alice at A-Bank wants to send money to Bob at B-Bank and Carol has
>> been identified as a possible connector. Wouldn't A-Bank have already
>> performed AML/KYC on both Alice and Carol to the extent needed for them to
>> perform the transaction. A-Bank can ask B-Bank if the account holders
>> involved in their end of the transaction meet the relevant compliance
>> requirements and B-Bank can respond, perhaps with a certificate from an
>> authority that they both trust asserting that B-Bank is compliant. Each
>> bank would be responsible for making sure it's own accounts are compliant.
>>
>> As for the question of when Carol signs up to be connector between A-Bank
>> and B-Bank, how does each bank know she's the same Carol? I don't think
>> ledgers should be revealing the identity of their account holders to other
>> ledgers unless absolutely necessary. A simple system verifying that each
>> account has agreed to the connection would work. For example Carol signs
>> into her account at A-Bank and requests that her account #123 act as a
>> connector to account #456 at B-Bank. A-Bank then asks B-Bank if their
>> account #456 has requested to be a connector to A-Bank account #123. The
>> response is no, so no connection is formed yet. Then Carol signs into her
>> account at B-Bank and requests that her account #456 act as a connector to
>> account #123 at A-Bank. This time, when B-Bank asks A-Bank if their account
>> #123 has requested to be a connector to B-Bank account #456, the connection
>> will be formed.
>>
>> A question for those of you who know all the financial regulations. Does
>> the same person have to own the account on both ends of a connection as
>> long as both ledgers are compliant? Say that Dave is actually the owner of
>> account #456 at B-Bank and he and Carol have worked out some deal to act
>> together as an interledger connector. A-Bank would be able to answer any
>> questions or provide any reporting for account #123, and B-Bank would be
>> able to do the same for account #456. Does that meet current regulations?
>>
>> ------------------------------
>> Date: Mon, 26 Oct 2015 17:11:01 +0200
>> From: adrian@hopebailie.com
>> <javascript:_e(%7B%7D,'cvml','adrian@hopebailie.com');>
>> To: public-interledger@w3.org
>> <javascript:_e(%7B%7D,'cvml','public-interledger@w3.org');>
>> Subject: Vetting connectors (was Interledger and Privacy)
>>
>> Arie raised a few questions on another thread which I don't want to get
>> lost in the discussion. The first was the question, how do we vet "trust"
>> of the connectors?
>>
>> Arie can correct me but I interpreted this as; how do connectors assert
>> who they are and what credentials they have (such as licenses, if required)
>> that users can use to decide if they wish to trust a connector?
>>
>> I think we can seperate this into two "tests" that the user must do:
>> 1) Is the connector who they say they are?
>> 2) Is the connector qualified to perform the transaction that is being
>> requested?
>>
>> I think for both the user must establish some level of trust, either with
>> the connector itself or with some entity that makes assertions about the
>> connector.
>>
>> If, for example, the connector is a registered bank then user's will
>> likely trust the fact that the bank is licensed and their funds are FDIC
>> insured (in the US). They could verify that they are dealing with the
>> actual bank's API using something like SSL certificates.
>>
>> If on the other hand if the connector is an independent organisation like
>> a specialist market-maker then the user may decide to use a third-party
>> verification service that under-writes or guarantees the connector.
>>
>> These are two extremes but it illustrates the point that ultimately
>> user's (in determining the path for their payment) will make decisions
>> about who to trust and that will depend on various factors like the value
>> of the payment, the user's appetite for risk etc.
>>
>> In terms of standardisation, we should begin documenting these use cases
>> and risk factors so we can figure out what data a connector should be
>> sharing with users to allow them to make their trust decisions and do their
>> path finding.
>>
>> Any thoughts on what that list might look like?
>>
>
>
>
> --
> Evan Schwartz | Software Architect | Ripple Labs
> [image: ripple.com] <http://ripple.com>
>