keytransparency

> BTW, that draft cites Keybase as a motivation for their approach Yes, I know. Without Keybase this draft would probably never exist in the first place :) > I couldn't find it in the doc, is there a story for revocations? Yes, it supports revocation as links are stored as User Attributes (similar to UIDs). > In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain. Yes, I've been thinking about using Blockchain for that purpose but I'm waiting for something more concrete to materialize out of Key Transparency [0]. As far as I like Keybase for something so fundamental as identity I think a distributed solution would eventually be necessary. As far as I remember you write sigchai

I'm not 100% sure, but it sounds like that's outside the scope of key transparency, and Google is envisioning that the ["certification authority that the system [represents]"][1] would verify that you indeed own `eschmidt@google.com` before letting you register an account using that address. [1]: https://github.com/google/key-transparency/blob/master/docs/...

To understand the technical approach to the solution this is a good resource - https://github.com/google/key-transparency/blob/master/docs/... This is also useful for understanding some of the core differences between CONIKS and Key Transparency - https://github.com/google/key-transparency/blob/master/docs/...

The article links https://keytransparency.org/ which is currently just a pointer to https://github.com/google/key-transparency/ . The blog is more 'why' while the repo is mostly 'how'.