RE: Vetting connectors (was Interledger and Privacy)

I second Yassin, could we clarify terms? I'm sorry, I'm new here and may
 have missed some of the background conversation, but I thought the 
whole point of ILP is to connect ledgers in such a way that the 
connectors do not need to be trusted? Is the vocabulary slightly 
different here than in the whitepaper? Does connector refer to any 
ledgers traversed as a payment goes from sender to recipient?

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?