"Virtual Trust" (in Cyberspace)

[alculexum]

“Virtual Trust” (in Cyberspace)

Note: This post shows a proof-of-concept for challenge-response mechanisms for Circles, it is not meant to be a best practice, especially as private key handling is involved. Please be careful!

Suppose you want to pay someone you don’t know personally and therefore she doesn’t trust you. If there is no transitive trust path between you and this person, you cannot pay in Circles.

However, if this person can verify “attributes” of yourself, she might trust you, allowing you to pay her directly.

What could these attributes be?

All kind of internet services which provide some kind of digital identity can be used:

• SMS, E-Mail
• Keybase, 3Box
• Telegram, WeChat, WhatsApp
• Twitter, FB
• Github (Gist)

Or a combination of those.

Use Case for Virtual Trust

The merchant wants to sell a digital service to a customer, but cannot be sure the Circles the customer wants to pay with are his “real” ones. To increase trust the merchant wants to link the Circles account to other services she trusts, like Mail, Twitter, etc. This still makes it possible for the customer to betray her, but at least she can refer to something then (like replying to the Mail).

To link the Circles account to a signed message transferred on these internet services, an indirection is necessary as the Signer’s account (the Device Address) is not identical to the Gnosis Safe Profile Address (but is the Owner of this Profile Address).

“Trust Flow”

1. As merchant, you have to pass a “challenge” to the customer. This can be almost anything, a number, a phrase, a sentence - something that is not easily guessable and individual.

2. As customer, you have to sign this “challenge” with your Device Address private key.

3. As merchant, you have to verify the signature and that the signing address of the signature matches the Owner address of the Circles Gnosis Safe.

4. If the addresses match, you can trust the Circles account and get paid. You now know that the Owner of the Circles account signed your “challenge” and sent you the signed message.

How-to Execute the Trust Flow Steps

• Merchant passes MyPersonalChallenge55523 to the customer to sign it with the Device Address private key and send it via Keybase, Mail, SMS, post it on Twitter, send it via Telegram, etc.

• Customer extracts private key from circles.garden and imports it into MetaMask, Nifty (recommended) or MyEtherWallet directly (not recommended).

• Import to Wallet

• Customer signs challenge in MyEtherWallet with “sign-message”.

• Customer sends the JSON via the agreed-upon services.

• Merchant uses “verify message” to verify the address.

• Merchant calls the Gnosis Safe (https://xdai.gnosis-safe.io/app/#/safes/SAFE_ADDRESS) of the Circles account she wants to trust and ensures (one of) the Owners is the recovered address.

• Merchant can now trust the Circles account.

[MatrixMan]

I’ve got a few nitpicks, but on the whole I really like the idea that we could broaden a user’s potential Circle by providing a standardized challenge-response process. I especially like the notion that I could put the challenge response in a github gist to prove ownership of that account.

My github account has very little in it that would be of interest to most third parties, but it has quite a bit that is of unique value to me and that has taken me quite a long time to accumulate. It’s a human verifiable proof of work. If my relationship with a merchant were tied to my github profile, I’d have to treat that relationship as non-disposable because it would take me a very long time indeed to make one that’s as real-person-looking as mine.

I also like how decoupled it is from github (or whatever) because different people spend time on different platforms. I could imagine collective agreement emerging about what third party internet identities constitute good choices for this kind of thing.

The nitpicks:

• Your screenshoted workflow has proved the concept, but I don’t think we should publicly recommend that users open dev tools and poke around. Too often, that’s a pattern recommended by scammers. The more legit, non-dev, workflows of that sort that exist, the more successful those scammers will be.

• Suppose that Alice trusts Bob because the two of them participated in a “virtual trust” ritual like you’ve described. To Alice, this means that she trusts Bob enough to do business with him online. Now suppose that I trust Alice because I admire her commitment to participating in economic behavior that benefits the communities that she interacts with. Because of the virtual trust ritual, transitive trust now flows from me to Bob, the details of which were handled out-of-band. So I don’t know that Alice’s trust of Bob is virtual. I might rely on this trust to do business with him in person–something that Alice herself might not have been comfortable with, especially if my business (unlike Alice’s) makes me vulnerable to some kind of bad behavior on Bob’s part.

The first point can be addressed by adding a “signatures” section to the circles wallet.

The second one is trickier. I think it requires that metadata be added to the trust relationship between Alice and Bob which gives me the information that I’d need to decide whether I should (for instance) invite Bob into my workshop–information that is lost if the challenge response ritual stays strictly between Alice and Bob.

[alculexum]

Thanks a lot for this detailed reply!

Your nitpicks are very valid.

1. I hoped it was clear that this process should be for the experienced user, the “UX” is horrible and I would not advice this process as a (best) practice for challenge-response to Circle users in general. I certainly agree that signing a (standardized) message should be a functionality of the Circles wallet. To stress this fact, I added a note to the beginning of the post.
2. It’s true that your scenario might happen as “trust” here of course might mean to someone that Alice actually really trusts Bob - and not just for the amount of the trust limit (though this might be a good indicator). I have not thought of this as I assumed already that this might be a pattern for “merchants” and therefore not “usual” Circles accounts. This seems to resemble “organisations” in Circle terminology, but I am not sure - but would like to know more about. For this “organisations”, I think it is clear that they have an other unterstanding of “trust” than common users.

Thanks again for adding your thoughts, I would love to proceed with this, eg. by addressing the message signing issue for Circles wallet, but I don’t really know how.

[alculexum]

Forgot to mention this: to your comment about metadata on the trust relationship, this reminds me of verifiable claims (https://www.w3.org/TR/vc-use-cases/) which would be really great if supported in Circles (then it would be “verified twitter account” on the Alice->Bob trust line and I could decide if this is fine with me).
Then again “organisations” could even monetize this verified claim (eg. ID-check, KYC, proof-of-something, etc.) “as-a-service”.

[MatrixMan]

Sorry for the lack of brevity. It’s something I struggle with…

dev-tools workflow

I assumed that you weren’t proposing the dev-tools workflow for ordinary users. I just figured we should make it explicit. It’s something I think about ever since the please-trust-me flood that happened last October–best to avoid leaving misleading signposts. I dig the note.

I’m uncertain about the future of the current web-based circles wallet. I think it’s more of a bootstrap mechanism than a long-term solution (someone correct me if I’m wrong here). Not sure what that means for the status of feature requests.

Sadly, my JavaScript isn’t where it would need to be for me to confidently add the feature. I’ve thought about hacking together a cli wallet (have you used Monero’s? It’s fantastic) just to get the lay of the land, but that’s a ways off.

organization accounts

It does make sense that transitive trust through an organization would be a different sort of thing (if it exists at all). Maybe that sidesteps the problem in this case, but I still think that ambiguity about what trust means is a likely source for issues. Assigning circles-trust to me could mean assuming either of the following:

• My trustees aren’t sybil accounts
• My trustees contribute to the wider community in meaningful ways and are therefore worth supporting

…and probably other things besides.

verifiable claims

Thanks for the link, I didn’t know that existed. Yes, verifiable claims are exactly what I want to achieve on the Circles web of trust.

Suppose AliceCorp wants to verify a claim about Bob. A graph traversal problem emerges: can we find a path from AliceCorp to a qualified verifier who also happens to know enough about Bob to verify the claim? If we can solve that problem, perhaps we can get AliceCorp to pay a small amount to everybody on the path in exchange for their participation in the verification. This gives an incentive for AliceCorp to accept circles (so that they’ll have them on hand to spend them on verification)–which creates demand for AliceCorp-adjacent circles and increases their value.

This is another case where “trust” as a primitive lacks desired specificity. I have friends that I trust to recommend a beer, or to belay me on a tricky climb, but that I wouldn’t trust with a can of spraypaint or a water baloon. We don’t just need a web of trust, we need a stack of them.

Suppose we want to verify that Bob fixed the pothole in AliceCorp’s parking lot. We need two trust “colors”:

• X trusts Y’s assessment asphalt/concrete work
• X trusts Y to give credit to the right person when work is done

We follow paths in the first color outward from AliceCorp until we find a cycle. The members of that cycle are likely to be qualified verifiers. Suppose that Valerie (our verifier) is willing to swing by and examine the work. Next, we find a path in the second color to Bob and we ask the hop before Bob: “did Bob do this work?” and we ask Valerie “is this good work?” Finally, the claim is verified and Alice pays everybody involved for either maintaining a trustworthy (and metadata rich) network, or for taking the time to answer one of the two questions.

If trust is uncolored, then asphalt experts are not distinguishable from people who are trusted in different domains–which doesn’t really scratch the verifiable claims itch.

[alculexum]

A lot of valid points here, but it kind of “opens the space” too much for me, though all these aspects are correct.

I think it makes sense to turn it around: seeing “trust” for now very specialized, exactly for what we want to do, transferring value from A to B, maybe transitively. For this, “trust” means the amount of value I trust the person with. That might be way more for someone at work than for a long-term friend or even a family member.

I brought in verifiable claims, but honestly that’s way ahead, for now getting a web of “value” trust would be great enough to me.

Back to the original issue: a verified twitter account means to me (as a merchant) that I would accept max. X Circles from this person. This is a very special view on trust, but for the first steps seems most feasible to me.

[MatrixMan]

Agreed re: “opening the space” too much. The application I have in mind probably belongs as it’s own separate thing to keep from overcomplicating Circles itself.

I’m just trying to figure out how to hook it into Circles so that users have a UBI incentive to maintain their trust networks (i.e. using MatrixMan’sSideThing makes your circles more valuable, and using Circles makes MatrixMan’sSideThing work… at all).