Create a Fingerprint array to associate multiple public keys with Namecoin identities. about stacks HOT 11 CLOSED

Note that I'm working on an improved pull request that will replace #25

from stacks.

OK cool I was thinking we could discuss each of these points individually. I have some suggested improvements for this, for example, and I think we can get others to chime in as well.

from stacks.

I worked out a simpler schema overall, as well as an easier way to add features incrementally.

from stacks.

Sweet, look forward to checking it out.

from stacks.

I also have a few new ideas for improvements that I've been working on. I'll throw it into an issue and tag you.

Think the process works a bit better when things are first fleshed out and discussed in issues and then they're converted to code and submitted as pull requests. Take a look at these schema discussions for example: https://github.com/jsonresume/resume-schema/issues.

from stacks.

Anyway, back to the suggestion. I really like the idea of a fingerprints array. As you mentioned at an earlier date, having an entire section for PGP probably doesn't make as much sense as something more generic, like a section for various keys (including PGP and OTR keys) that the user is in control of.

I thought the section could be called "keychain." Here's an example of the format:

{
  "keychain": [
      { "type": "otr", "fingerprint": "756CE84F90ABDE840555F4E2E0B2ACB1297F9E65" },
      { "type": "pgp", "fingerprint": "DDA1CF3D659064044EC99354429E1A42A93EA312",
        "publicKey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\nVersion: GnuPG..." },
      { "type": "ssl", "fingerprint": "C1956DC8A7DFB2A5A56934DA09778E3A11023358" },
      { "type": "bitcoin", "address": "1FbynFXB1C6jSAQZivucAnzAm9N7GxURYa",
         "publicKey": "083a0518062cc3c5ad48501c60aa06059785449f579a256ed2f1a5e781a109d978e54b20fb43b6e90dc91d8f9898665b969e122df6e1d1e5ce06c790f618a2c4"},
  ]
}

You'll notice that I even included a Bitcoin public key in there (which could also be referred to as an ecdsa public key).

These keys could be used for identifying users in various ways, including

• when chatting over OTR messaging
• when chatting over PGP-encrypted email
• when logging into a web application (this could work nicely with BitId or some variation thereof)

from stacks.

Right now you're calling this a "user" schema, but I think it can be a more general "identity" schema.

People have identities, but so do organizations and businesses.

Imagine a business identity putting their name, and url, and SSL cert fingerprint in one of these entries.

Oops... I think I just destroyed the CA industry.

from stacks.

Yeah you're right. Could even have a { "type": "person" } or { "type": "organization" }.

Updating to include SSL.

from stacks.

For space reasons, I'd leave public key distribution out of this spec.

There are many ways to distribute public keys - that's the easy part of the problem.

Generating a secure mapping between logical identities and public keys is the hard part.

You can upload your public key anywhere, maybe even to Namecoin under another namespace, and provide a like to it in the URL section.

from stacks.

Agreed, linking to URLs is often better. That said, some people will want to include their full keys and I feel that the protocol should support that option.

URL references are already supported by v0.2. For example, my PGP data right now is:

{
  "pgp": {
    "url": "https://s3.amazonaws.com/97p/pubkey.asc", 
    "fingerprint": "DDA1CF3D659064044EC99354429E1A42A93EA312"
  }
}

from stacks.

Much has changed since this discussion. If you would like to reopen the issue please do so on one of these three repos:

• blockstack.js
• blockstack-core
• blockstack-browser

Closing as stale.

from stacks.