Add a way to retrieve up-to-date information about the Validator set

[Reisen]

SUMMARY

Currently it is difficult to keep track of validator information as there is nothing on-chain to help identify who is who. It would be fantastic to be able to do this through the Oasis API somehow to eliminate the manual bookkeeping required staying on top of the data as it changes.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

Unsure as it depends on which solution is chosen, though I imagine it will likely require modification to the staking module in any case.

ADDITIONAL INFORMATION

A couple of other chains do this through publishing validator information on chain, and additionally some allow verifying that the validator is who they say they are using some kind of attestation. A couple of examples of this are Celo and Solana, which allow claiming ownership of a Keybase account. You can use the Keybase sigchain to verify that that account truly owns their website.

Solana Validator Info Celo Validator Info

[kostko]

I assume you mean entity metadata like human readable name, URL, etc.? This was already considered once (#2234), maybe we need to revisit it. So in Oasis Core there is a registry service that stores (signed) metadata about entities, nodes, runtimes, etc. These can be retrieved via the GetEntity API call exposed by the registry service.

Currently for an entity it is only storing an entity's public key and a whitelist of nodes allowed to register under that entity.

What kind of additional information do you think should be stored?

The fear in #2234 was that such extra data could end up containing a bunch of bogus information that could easily be misinterpreted (e.g., you can use arbitrary names, URLs, even if they are similarly looking to other existing entities etc.). On the other hand linking entities to real-world identities can be an important security-critical service so it is better to get it right than to leave it up to various external registries.

Linking to a Keybase account sounds interesting, but I'm not sure if tying it to a single service is a good idea. Maybe allow publishing a map of opaque key/value pairs (of limited size) and let client applications interpret them (maybe prescribing some common ones)? Thoughts?

[Afauvre]

@kostko I think we should reconsider this one. The alternative is that names are crowdsourced which could in practice be even less validated than what is suggested above.

[Reisen]

@kostko Yeah the main goal for my use case is human readable information. My fear with something like an opaque Key/Value mapping is exactly that it's left completely up to interpretation as to what a validator should do with it. If the original fear you had was that anyone could pollute the chain with arbitrary data then an opaque map would end up being the least enforceable way to manage identity.

I do think arbitrary metadata is probably valuable but I think the idea of identifying information should be well typed and treated specially.

As an API consumer wanting to keep track of validator identity, an opaque map means I now need to manually interpret all metadata changes on the network and figure out which ones I care about, which is assuming everyone actually even manages to use a consistent format for managing their identity information.

I think this proposal for the Celo network might be a good inspiration -- it describes multiple methods of attestation (Keybase just being one), which makes it much easier to trust on-chain claims. I definitely agree that just relying on just Keybase would be a bad choice though, especially with the recent Zoom acquisition.

[kostko]

I do think arbitrary metadata is probably valuable but I think the idea of identifying information should be well typed and treated specially.

Yeah that's a good point, my thinking about opaque maps was more to go with not explicitly supporting a "keybase identity link type". But you're right if not designed correctly this can end up with a mess of incompatible identity providers.

I think that verifiable identity links like mentioned in the Celo proposal are preferable to any direct human readable names. We should prepare a design proposal around this and gather some feedback from the operator community. Based on the above my current thoughts are something like:

• Avoid arbitrary names, URLs or other identifiers without an associated verifiable proof that they are who they say they are. E.g., an URL with a defined proof verification scheme is ok (e.g., publish this signed statement at a well-known URL), but just a URL without this scheme is not ok as you can put in anything so best avoid such scenarios. Same goes for "arbitrary name strings" as anyone can use any name without any way to verify this (and this opens up the door of using names similar to known entities).
• Support for publishing different "identity proofs" which have clearly defined structure as specified in the proposal. Should be extensible but clearly defined (and enforced at registration time). Initially things like URLs with well-known locations of proofs (possibly reusing existing URL verification schemes), DNS names, etc.

[Yawning]

I am still largely against this, primarily due to why I was against it when it was brought up in the first place. I will grudgingly tolerate structured data, if it is verifiable without interaction with third party services (they are entirely self contained, ie: nothing in @kostko's initial set).

(If we foolishly are going to allow DNS names, I need time to register xn--osb-6cdb4tde003b.com)