Re: Vetting connectors (was Interledger and Privacy)

I would say, we have to clarify who we mean by the "User" in this context.
Is the user banks and other FIs that already have ILP enabled ledgers? If
so, then establishing connectors with other FIs to transfer payments on
behalf of their clients is similar to deciding what correspondent bank to
trust today when they transfer payments globally. The connectors in this
case will need to be enterprise-grade able to handle high levels of volume.
They also need to be well known and held accountable should the payment
does not make it to its intended destination.

However, if we mean by "User", the individual consumer who has a checking
account at a bank with ILP enabled ledger, then we would need some kind of
clarification as to who assumes the risk of transferring the payment, the
bank or the consumer?. If the consumer, as part of requesting to make a
payment transfer, has to decide which connector to use, then he/she would
need some kind of a Better Business Bureau agency that lists all available
connectors for that particular market and geographic area with a ratings
system (1 star = High Risk, 5 stars = Low Risk). He can then instruct the
bank on not only how much to transfer where, but also on which connector he
would like the bank to use.

If, on the other hand, the bank takes ownership of the payment transfer
mechanism (and risk), then they decide what connector to trust and use, and
we are back to what I said above in the first paragraph.

Just my 2 cents,

On Mon, Oct 26, 2015 at 10:11 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> 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?
>