The world of the last few years has been buzzing with the need for personal privacy a world in which personal data is typically abused by large corporations on the (mistaken) belief that this is the only business model in a connected world. It seems to have got to the point where there has been so much focus on protecting the identity of an individual online that we have actually made it difficult, frustratingly and unnecessarily difficult, to actually claim a completely public identity online.
Why do people want and need a public identity online? Because for many people their public identity is key to work they do, and it is really important that the credit, the reputation and the kudos they get online and off is clearly seen to be associated with them and no one else. What do I want to be associated with?
and so on. And when you find me online, if you have come across me though any of these things, I want you to be able to find out how to contact me, join me, encourage me, fund me, and so on. I want you to be able to send me encrypted email which no one else can read, and for you to know that it indeed me as that public figure who has that key.
So in the world or people's public actions, privacy is not the name of the game, it is instead a well-known single public identity.
I say "single" -- is there a need for me to have more than one? That depends whether the fact that they belong to the same person is secret.
First lets talk about trying tp keep it secret. This is obviously seriously prone to failure. In general there so many ways of using public information to deduce the fact that they are in fact the same person. So that won't be an emphasis of this article. (Possibly legal constraints could make it work better. For example, take a person's Facebook identity and their US Social Security Number (SSN) The facebook identity is a public identity, which must legally be kept separate from the SSN, and facebook gets into trouble if it accidentally allows people to find the connection. A SSN is a quasi-public identity, in that within the worlds of banks and employers and loan applications and the tax authorities, everyone knows your SSN. So in a sense we arguably have a case of a person having two public identities, where the link between them is protected by law.)
But in general things which we think of as being public are linked. People go to great trouble to link their social network ids together, with a string of little SSN icons eveywhere. An academic may have identities on sites like Mendelay.com, ResearchGate.net, and Academia.edu and IAmResearcher.com, and when a publishing industry needed a registry of people it created ORCID another identity system. So in general there is no reason for there to be one true ID system for academics.
Of course in 2018, for professionals and employment in general, their One True Social Network is LinkedIn.com. The professional world -- that of people who are interested in their CVs being available to prospective employers -- largely revolves around LinkedIn. But meanwhile for specifically software developers, Github.com provides the global unique place to accumulate kudos and allow people to access, particularly, your contributions to open source projects. Other systems like gitter.im piggy-back off Github's' structure and its user base. Within this world, your github.com username is your key public identifier. So in many cases, we find that instead of having a personal self-sovereign identity people default to the largest SSN, which becaomes rapidly self-fulfilling though economies of scale. In an ideal world, life should not be centralized around a single identity provider.
In a decentralized world, then, a user will have many systems, sites, or organizations which help them maintain their public identity, and the identities will be linked together. Decentralized does not mean blockchain. A user can have many IDs, some grounded in DNS, some grounded in the Blockchain. A "self-sovereign" identity is a relatively recent word for an identity which a user has which they have control over, without having to use a large central social network.
Public Key cryptography is a natural match for the needs of a public identity. It gives is the ability have a secure public identity in a way which was not, before PK crypto, possible. I can put my public key on the web and I can pass it to people, and they can use many different systems for believing that it is indeed my key (and not revoked). Once you have a record of my public key, I can sign in to your systems, and you can send me encrypted messages securely. The private key I can keep on my computer, or on my phone, or on hardware gadget on my keyring designed for just that purpose, or I can keep parts of it in different places, in case of theft, or I can keep multiple copies in different places in case I lose them.
In fact several systems which work like this with public key are Secure Shell (SSH), Pretty Good Privacy (PGP) email, SMIME secure email, and also WebID-TLS, where as I keep a certificate in my computer for use by my browser. I can for example log into github by minting a kepy pair and loading the public key into it. These systems have completely different ways of helping me figure out which keys to trust. But they all use public key technology.
Two important questions in public key systems are:
In general, the public key technology should make the answers to these questions orthogonal.
At the moment, when I uses PGP, I use the PGP web of trust system to figure our which public keys to associate with different people, and I store them in the PGP system, and I use them in conjunction with my own private key pair which is also stored exclusively for signed and encrypted email. The GPG system doesn't have way to use keys I have found on the web, or stored in my physical key-fob.
To make these things work and grow, we should be able to bootstrap trust in one system using another. I should be able to look up your github public SSH key, and convert it into a PGP key and send you an encrypted message. I ought to be able to give you TLS access to a system using your PGP key, and so on. In each case you would have to convert the corresponidng private key from one system to another. This is just administrative format conversion, not rocket science.
The secure storage of private keys is a crucial function which it seems reasonable to be provided in only a few places, by my Operating System and/or by my browser, and then made available to applications and web applications under my control. I want as a developer to have a standard system API and web API for that.
As a user, I want to
While I do want to share the answer to the first question -- private key storage -- across applications, I do not want to share the answer to the second! The second question is about the network of trust which the system creates. Different systems do that in completely different ways. One of the problems with the Public Key Infrastructure as a project was that it divided the world into trusted and trusted things according to the needs foo one particular rather corporate idea about trust. We use it for HTTPS web site identity, but it isn't always a good fit even for that.
As a developer, I want to be able to invent new systemms in which people can do completely new things. I want also to be able to craete new trust systems with new ways of controllling who can do what and who can see what.
There is an important class of systems which just store the public key on the web, so the owner of the private key can demonstrate they are the author of (have write access to) that web page. This is fine for things like the identity of bloggers, and Indi Web site owners, etc The WebID-TLS system does this.
The take-away here is that as engineer I want to be free to design systems which manage trust in all kinds of powerful ways. I would like to be able to use the public key crypto software which is around, and I don't want my users to have to install another different keychain function: We should be able to use the key storage in the system, while making our own trust management. And in many of those systems, a user may use the same public identity to authenticate with many different parties and many different applications.
This article has been about public identity, but here we specifically focuss on the web browser.
Unfortunately, to date, the browsers have typically made a really bad job of providing user interface for certificate management. Users need to be able to
and somehow no browsers have managed to do that to date (2018). See a specific article on the handling of client-side certificates in the browser for more depth. Though they will in the end, I am sure,as the need to manage hardware key gadgets becomes apparent even to companies who eschew the generation of private keys by the browser.
Another problem has been that the authentication protocols, and the constraints on JS APIs for web developers, have been designed explicitly to make it really hard to have a common public identity across more than one site. That is described as a privacy violation, or leakage between sites, by those intent on securing the Same Origin Policy model of a single user talking to and sharing data with a single web site as an impenetrable silo.
Systems should be designed not only to protext privacy, but also to enable the use Public Identities. Public Key crypto is a clear tool for this, but we need to deploy it much more wideley, massively improve the management of private keys, which should be normally an operting system function, but available to any app and any web app. We need better tools for porting keys between dofferent systems. We must allow llowing engineers to design new systms which invent their own trust algorithms. The browser manufacturers need to urgently deploy this for web site acess and cross-site data access.
Katy Jordan, Academics and their online networks: Exploring the role of academic social networking sites, First Monday, Volume 19, Number 11 - 3 November 2014 http://firstmonday.org/ojs/index.php/fm/article/view/4937/4159 doi: http://dx.doi.org/10.5210/fm.v19i11.4937 and http://firstmonday.org/article/view/4937/4159
Decentralized Identifiers (DIDs) v0.7 Draft Community Group Report 15 January 2018
ORCID and the authors' ID in ORCID