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

Vetting connectors (was Interledger and Privacy)

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Mon, 26 Oct 2015 17:11:01 +0200
Message-ID: <CA+eFz_JGvq14zL0djQ3zOapUX+3isMpoREO9i8v_7g6KERwQgg@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>
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 Monday, 26 October 2015 15:11:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 October 2015 15:11:30 UTC