Give users the option to sign their profile information

[copumpkin]

It'd be nice if we could sign our profile data (blurb, location, image). It wouldn't have to be mandatory, but we're signing everything else, so why not?

[malgorithms]

@copumpkin = this is a good idea - we'll probably do this eventually.

There are other items we hope to add to people's profiles, and some of them will need to be signed. For example, a crypto currency address you'd like to be public. Things like that.

One usability point we need addressed: a lot of people new to this think that signing a statement makes the contents of the statement true. I think this simplification is natural to a lot of people and can lead to confusion / psychological attacks. Imagine I make a new account called Daniel Peebles, and while I don't prove my social identities in any way I create a public key and sign the profile, as you suggest, stating I'm Daniel Peebles. One fear I have is that people will see that this is signed and believe it's a proof of some kind.

Any thoughts on this?

A simple answer is you sign your profile and the client appreciates it, but we never really present it in the browser as signed. But that doesn't seem right either.

[copumpkin]

Yeah, it seems like the distinction we want to draw is between the user (identified by a public key and only a public key) signing a statement and some external verification entity (like a notary) doing that.

One UI approach to the thing I want might be to put some a verification icon next to the key ID rather than the profile information, saying something like "this key has certified the content this profile" (might make more sense if get multiple key support). That would avoid it looking like there is some universal notion of a "certified" profile, and make it clearer that there are specific (fallible) cryptographic entities doing the certifying.

The latter identity verification part could be supported by some sort of web of trust (signed statements from other people saying "I know this person in real life and certify that this is that person"), but that starts complicating the model a fair amount and has a bunch of issues of its own. I'd stay away from it for now.

[copumpkin]

Another thought I had was about the time-based aspect of the signature. Let's say that ten years down the line I've changed my name, live somewhere else, and don't consider bitcoin to be something worth putting on my "bio". A corrupt keybase could use my old signed statement to mislead people with old information. Not really sure why that would happen, but the notion of signatures over time I think still has some interesting questions :)

[BlacklightShining]

I'd love to see a sort of web-of-trust thing like @copumpkin described. Maybe not now, but eventually.

(If and when it is implemented, it should probably have different levels of trust—after all, I might know someone pretty well over the Internet, but never actually have met them offline. gpg has four different certificate trust levels; you might borrow those. Another thing that would be nice is an option to include a short description of how we know the person whose profile we're signing.)

[tildelowengrimm]

I know I've suggested this in #162 and #165 (and vaguely in #107), but I don't think that Keybase should display any information which hasn't been signed by the user. Unsigned information is information which Keybase has to authenticate with a user's account and password. This makes Keybase a sole authority and a single point of failure for that info, and prevents federation.

[bgpugh]

Other issues can be caused by having separate profile information and key information: #521