R4R: CLI keybase-sig -> identity

[rigelrozanski]

also fixes #1766

• Linked to github-issue with discussion and accepted design
• Updated all relevant documentation (docs/)
• Updated all relevant code comments
• [n/a] Wrote tests
• Added entries in PENDING.md
• Updated cmd/gaia and examples/

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #1818 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1818   +/-   ##
========================================
  Coverage    63.44%   63.44%           
========================================
  Files          117      117           
  Lines         6937     6937           
========================================
  Hits          4401     4401           
  Misses        2281     2281           
  Partials       255      255

[alexanderbez]

LGTM 👌

[ValarDragon]

We may need to plan the abstraction from keybase to any form of identity a bit more.

Do we need domain seperators? If not, how would end services tell what service its for (e.g. voyager)? Maybe its fine for the cases of uport and keybase (idk how uport authenticates), but I can easily imagine situations where its unclear, or even worse, situations where that identity corresponds to different identities on the different services.

[rigelrozanski]

@ValarDragon Identity should be verified outside of cosmos - we simply want to provide a generic space for third party identity verification. We don't want to fork for every single new identity verification technique

[ValarDragon]

I don't think supporting multiple forms of identity is that useful unless we have an ICS standard for verification techniques, or require that all verification identifiers have some domain seperation. (Which I'm unsure if keybase does?)

[cwgoes]

I don't think supporting multiple forms of identity is that useful unless we have an ICS standard for verification techniques, or require that all verification identifiers have some domain seperation. (Which I'm unsure if keybase does?)

We don't "support" or "not support" any forms of identity with this change - it's just a string, which validators can use to link to whatever external identity they want. UI conventions may emerge on top, but it's preferable that those don't need to depend on the state machine.

[ValarDragon]

Hrmm. I feel like we should come out with a UI convention here pretty soon. (We don't really want this to be hard to change later due to competing UI conventions)

We could just use amino encoding w/ prefixes.

This doesn't need to block this PR, but I think its an ICS standard which we should write soon. (Granted this isn't the correct place for ICS standard discussions)

[cwgoes]

utACK

[cwgoes]

This doesn't need to block this PR, but I think its an ICS standard which we should write soon. (Granted this isn't the correct place for ICS standard discussions)

Agreed - let's think about and/or draft such an ICS standard. I think we also want input from potential validators & delegators.