W3C home > Mailing lists > Public > public-interledger@w3.org > November 2015

Re: Vetting connectors (was Interledger and Privacy)

From: Frédéric Meignien <frederic.meignien@cantonconsulting.fr>
Date: Fri, 6 Nov 2015 17:27:02 +0100
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Ryan Fugger <arv@ryanfugger.com>
Cc: Interledger Community Group <public-interledger@w3.org>
Message-ID: <563CD4D6.1010500@cantonconsulting.fr>
Hello,
I would like to know your position about the routing criteria or 
identifiers:
In card schemes, the BIN is used to find the bank or the scheme which 
issued the card.
For other types of payments, the institution which manages the target 
account can be found via the BIC and IBAN codes.
What do you envision for such a function on the connectors ?
Thank you
Frédéric

Le 06/11/2015 09:33, Adrian Hope-Bailie a écrit :
> +1 to all of Ryan's comments
>
> It would be great to start capturing ideas about how each of these 
> routing mechanisms would work.
>
> Even better would be if there were folks in the group that forked the 
> reference implementations and tried to implement some alternate 
> routing mechanisms so they can be proven and tested.
>
> On 6 November 2015 at 06:27, Ryan Fugger <arv@ryanfugger.com 
> <mailto:arv@ryanfugger.com>> wrote:
>
>     The purpose of vetting connectors is so payers can choose payment
>     paths that are appropriate for their payments.  There will be
>     tradeoffs between payment speed, price, reliability, as well as
>     connector privacy.  (I'll reiterate Evan's point that the payment
>     principal is never at risk -- only the connector fees and the time
>     wasted if a connector allows the transaction to timeout are.)  Any
>     vetting of connectors will be closely coupled to the methods by
>     which payers choose paths.  ILP, as a core value transfer
>     protocol, doesn't specify *how* connectors will advertise
>     themselves to potential payers, and so can't really specify any
>     vetting procedures.  That will be up to routing systems built on
>     top, and there may be many of them, each with a different use case
>     in mind.
>
>     In my earlier work, I envisioned several different types of
>     routing systems:
>
>     * Centralized services run by third parties that aggregated
>     connector information and offered fee- or subscription-based
>     routing services to various payers
>
>     * Decentralized global link-state connector advertisements in a
>     P2P connector network (now perhaps organized on a
>     blockchain/decentralized ledger)
>
>     * Decentralized routing-in-the-dark path-search mechanism using
>     only local knowledge for maximum connector privacy
>
>     The best design of ILP allows for any of these and any other type
>     of routing mechanism we can imagine.  The way we vet connectors
>     for desired features will need to be built into these routing
>     mechanisms.
>
>     On Thu, Nov 5, 2015 at 3:24 AM, Yassin Mobarak <ymobarak@gmail.com
>     <mailto:ymobarak@gmail.com>> wrote:
>
>         Koen,
>
>         The 2 types of connectors I talked about are for two different
>         types of use level, audience and market. Average  users do
>         not transfer millions of dollars of payments in high
>         frequencies. The vast majority of them send small amount
>         of money to their relatives overseas once in a while.
>         Companies, however, do send millions of dollars in global
>         transactions regularly for all sorts of business reasons.
>         Recognizing the reality of these two different use levels and
>         types, I thought it would be appropriate to classify
>         connectors in similar fashion.
>
>         Additionally, please note that I did not say the consumer
>         centric connector will be of lower quality than the
>         enterprise-grade connector. Every time one deals with people
>         and companies money, extensive due diligence must be
>         excersized and appropriate insurance ( depending on the value
>         transferred) should be considered.
>
>         You are correct in comparing the connectors to the different
>         shipping channels of merchandise in existence today. I'm sure
>         you can see that bulk shipping of goods overseas by companies
>          is structured a little different than a consumer sending
>         small packets of stuff through UPS or DHL service.
>
>         Yassin M.
>
>
>         On Thursday, November 5, 2015, Koen Vingerhoets
>         <koen.vingerhoets@telenet.be
>         <mailto:koen.vingerhoets@telenet.be>> wrote:
>
>             Dear Yassin, While I do appreciate your thoughts
>             concerning the enterprise level connector , I fail to
>             understand why any consumer would be happy with a
>             connector of lower quality, even for a lower price, to
>             transfer property .
>             If a public ledger is translated into distributed trust,
>             every consumer should be able to fully trust the system.
>             It's not like the seller selection in Amazon, it's the
>             shipment method you choose imho. Why provide a "parcel
>             might be delivered service"?
>
>             Verstuurd vanaf mijn iPhone
>
>             Op 5 nov. 2015 om 02:02 heeft Yassin Mobarak
>             <ymobarak@gmail.com> het volgende geschreven:
>
>>             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 <http://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> 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
>>                     To: 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
>>                 ripple.com <http://ripple.com>
>>
>
>
Received on Friday, 6 November 2015 16:27:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 6 November 2015 16:27:39 UTC