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

RE: Vetting connectors (was Interledger and Privacy)

From: Brian Walden <brianwalden@outlook.com>
Date: Thu, 29 Oct 2015 15:04:41 -0400
Message-ID: <SNT146-W73FCCE88BB9BFC40887308BF200@phx.gbl>
To: Interledger Community Group <public-interledger@w3.org>
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?
 		 	   		  
Received on Thursday, 29 October 2015 19:05:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 19:05:11 UTC