Re: Vetting connectors (was Interledger and Privacy)

On 26 October 2015 at 16:11, 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?
>

Yes.

Firstly, you are spot on by noting a modular separation of concerns.

You want to establish an identity, and verify that identity as two separate
processes.

On the (http) web it has the strength that identifiers are long lived, and
accrue reputation over time.  It has the weakness that moving URLs is
hard.  But that's how it should be.

We want to distinguish between trust and reputation.  Reputation is built
over time, and can be accrued through credentials, social signals, inbound
links, and inferencing algorithms.  This can be done by dereferencing the
identifer and finding out more information about it.

Next, we want to verify that someone is who they say they are.  Well this
can be done with PKI, shared secrets (passwords, cookies), delegated
credentials (oauth), security by obscurity or any number of methods.  Once
we have established *what* we are identifying there's many techniques to
verify that user.

Finally we get to the tricky subject of trust.  Trust is a confidence
interval that an actor will perform a given action in the future, in a
specific field.  Frankly, we're pretty bad at measuring trust (see 2008
ratings agencies) and we are likely to be for generations, so what is
better than trying to create perfect trust is fault tolerance, and minimum
standards for trust based on the use case.

I've been collecting interesting links on trust here:

http://www.w3.org/community/rww/wiki/Trust

I'd love to see more (or please edit the wiki page).

Of particular interest to this use case I think is TrustDavis :

http://web.cs.ucdavis.edu/~defigued/index_files/trustdavis.pdf

I've been thinking for a while about implementing this, and I have seen it
linked to ethereum too.  Ryan fugger's ripple also is along similar lines.
I think it might be a good exercise to compare and contrast these methods
with the various proposals in this group.

Just my 2 bits! :)