Web of trust

[jayrbolton]

https://en.wikipedia.org/wiki/Web_of_trust

A major initial problem with authority-less key sharing (ie adding someone as a trusted contact), is being able to verify that someone is who they say they are. Pgp has a system where people can sign each other's keys, so you can verify that someone is who they say they are based on other contacts you have in common. It would be cool to have a UI that showed this web of trust for new contacts

[jayrbolton]

PGP notes:

• Since we're no longer using openpgp.js, we'll most likely need to reconstruct a lot of what pgp does, particularly around user certificates and signing
• Expirations on certificates
• in the certificate (we can include any/all of: name and version of encryption program, algorithm used, dat-pki version number, cert format version, expiration date, user identity information, user signature
• could have a separate file for the list of signers for a cert
• Validations and trust: we can start by using the same system as PGP
  • userA assigns a level of trust to userB's cert to be one of: complete, marginal, none. If userA assigns "complete", that means that userA 100% trusts userB to correctly validate other keys.
  • A key is marked as valid if someone you completely trust validates it (possibly in a chain), or if two people you partially trust validates it.
  • Could simplify this system by only assigning marginal trust to other users?

[millette]

Might be of interest: Establishing Identity Without Certification Authorities by Carl M. Ellison, CyberCash Inc.

[pfrazee]

I've been thinking idly about an identity protocol.

My idea is that any archive can have a folder of identities. Maybe /users/. Contains .json files that identify people with a shortname. Eg pfrazee.json:

{
  "alias": "pfrazee",
  "name": "Paul Frazee",
  "url": "dat://.../"
  // other identifying info?
}

This record could then be published on a dat with a shortname, such as dat://beakerbrowser.com/users/pfrazee.json. To signify the record, some syntax could be used, such as @[email protected]. That identifier could be used to look me up.

Shortnames are provided in Dat via DNS+TLS, so we'd effectively be allowing sites to act as identity providers underneath the PKI, much like they do know (ie @pfrazee provided by twitter).

This model could be expanded to act as a WoT by having clients index multiple Dats' /users/ folders. A search against that index would then reveal the agreement (or lack of agreement) on an identity. Eg a search for "Paul Frazee":

Searching for "Paul Frazee"

3 Results
<dat://...> via beakerbrowser.com, hashbase.io, bob
<dat://...> via alice
<dat://...> via shady-sue

[jayrbolton]

I think it makes sense. I like the user friendliness of using dns. It can certainly provide a bit more authentication as well, if your domain is tied to your identity. When you combine it with having a number of other contacts that validate an identity, then it could work.

One important thing is for the underlying platform to clearly show people's validity (or lack of validity) when you interact with them, including in UIs like direct messaging, to prevent imposters. This is something that SSB doesn't really do much. For example, in a direct message thread you don't want the platform to show you just their name and picture. Anyone can imitate that very easily. You want it to show identity validation info as well.

It might also be worth having a system that allows you to mark contacts as invalid. If some impostor does gain some traction, then the network can start to flag them to reverse the damage more quickly.

GnuPG has a system where each contact gets assigned a level of validity and a level of trust. I've always thought that while this may be more technically thorough, I think it works less well in practice because it requires too much user education. See "Why Johnny Doesn't Encrypt" and all followup papers. Something like SSB where you just reference the number of followers (which also serves as a crypto mark of validity), works surprisingly well I think. The more validators you have, the harder and harder it will be for someone to fake your identity. In gnupg terms, you just have a system where all the contacts you have validated always have marginal trust.

Pet names are also something that may be important to this discussion. I was definitely wanting to include it as part of something, but i'm not sure how it would fit into dns or Beaker: http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

I still think having more concrete use cases is important. I have a hard time imagining how you can make secure apps with Beaker unless you build a lot of extra crypto stuff into the browser itself. I have some fuzzy concept of a distributed file system that is also a JS app platform, but it doesn't look so much like a browser, but looks more like google drive.

My and @Karissa's use case was making a p2p DropBox replacement with strong crypto features, but we haven't worked on it in a while

[pfrazee]

For example, in a direct message thread you don't want the platform to show you just their name and picture. Anyone can imitate that very easily. You want it to show identity validation info as well

Yeah. The solution used in SSB was to show petnames assigned, which can be helpful sometimes. I think you actually need tools like the old-school Facebook wall that lived on profile pages -- basically a forum attached to a given identity where you can put information. "This is his old account, he had to ditch it when he lost the key" that sort of thing.

See "Why Johnny Doesn't Encrypt" and all followup papers.

I wrote a little summary blogpost about that, very insightful paper.

Something like SSB where you just reference the number of followers (which also serves as a crypto mark of validity), works surprisingly well I think. The more validators you have, the harder and harder it will be for someone to fake your identity.

Especially the "followed followers" count & listing (people you follow that follow this user).

I still think having more concrete use cases is important. I have a hard time imagining how you can make secure apps with Beaker unless you build a lot of extra crypto stuff into the browser itself.

I'm going to do some experimentation in userland and only expand core if we have to. For certain, key management (and therefore many crypto ops) need to be managed by the browser. We're also going to put some identity management into the browser, but that's basically creating flows for treating some dats like identities. We'll see how it goes. Identity but not encryption is my priority for immediately after 0.8.0's release (which should be sometime mid february).

[tswast]

Regarding identity verification, I just tried out the way IndieWeb does user identity verification and it seems to be a pretty robust way to do it.

Basically, it requires a link from a central identity homepage to other profiles as well as a link back from the other profiles to the homepage. This means that IndieWeb can verify that my website and my Twitter profile represent the same person. Since the homepage is a lot harder to spoof since it uses DNS, I think this gives a lot more proof that you really are you.

[jayrbolton]

@tswast I agree that the rel-me auth setup seems like a cool idea.
It might be worth having a server that people can use for all kinds of auth in that vein, such as email verification, DNS stuff, etc. When I add you as a contact, then I can make a request to this server to see what kind of verifications it can give me about you. The server would be centralized, but can be open source and re-hosted.

I think more and more that the best decentralized verification is simply a list of mutual contacts, scrapping all the PGP trust level stuff. When I add you, I see all mutual contacts that we have both added. This of course requires no server. This, combined with the above verifications, would be a pretty robust system

[tswast]

One of the the RelMeAuth mechanisms is a PGP key, so that could work offline. PGP keys can be signed by others, creating a public offline contact list of sorts that way. The current way of doing keysigning is a bit awkward of a flow, so supplementing with online contact mechanisms is probably going to be more user friendly.