digital state

I don’t want to type in my address at each new onlineshop I want to order something from. I don’t want to remember which companies have which kind of information about me. I don’t want to contact ten different services when I’ve changed my home address. I don’t want to keep five different cards in my purse and install multiple apps on my smartphone to use for authentication. I think its time to unify personal data and its authentication (“who sees what”) into one central system.

Now, how can you combine credit cards, identification cards, online logins etc into one system, while keeping the user in control of who, when and how his data is used? Here’s my idea how:

Each participant of this system receives a private key, a public key and access to an administration webpage. There is an api which gives access to the data managed by this system to authorized services.

the administration webpage

A webpage which gives the user control over the api. It visualizes requests to the api (which service called when, and received which information), and all active Authentications. The user is able to create new Authentications, and invalidate existing ones.

On this webpage, the user will manage all his personal data. His data will be split into various parts; one may be the home address, other work infos, payment information… If the user edits his data, he can choose if he wants to notify the services with access to this data.

Other connected services can provide additional personal data (which can also be shared over this api of course): The service called “police” provides access to criminal records, or “health services” provides access to the allergies the users has.

The user can select for each Authentication to which parts of the api he will grant access to.

the api

The api contains all information about a member of this system.

/authenticate: the first request every service has to do as soon as registering a new user. It will have to provide details about the service itself, an url to be called by the api for event callbacks (those are invoked if personal data of the user is changed the service has access to), the users private key, and the users password. It will receive an Authentication Hash for future requests, the public key of the user, information which parts of the api it will have access too, and for how long the Authentication will be valid.

/info: all following request go to this url. The calling service needs a valid Authentication, and specification which data it would like to receive. The response will contain all data requested, if the Authentication permits access to it of course.

/valid: This node is called with a public key, and simply return a boolean if it is still valid or not.

the keys

The two keys are not related to one another, and not resolvable from one another.

They could be supplied in form of a credit card, or an application on your smart phone, it does not really matter. It should be removable from the carrier, so nothing terrifying like tattooed barcodes or implemented chips. If the user chooses to do so, he should be able to leave the public key at home. The private is only needed for the authentication of new services, and should be kept out somewhere inaccessible to others.

If the public or the private key is lost, the user has to contact an authority as soon as possible, which invalidates the old key, and sends a new one. If its the public key, all services with access to user data will receive an event callback over the specified URL. If its the private key, it does not really matter, as this one is only used whilst authenticating new services.

the authentication of a new service

If you need your personal information, for example when registering at a onlineshop, or opening a banking account, you perform following steps:

  • go to the administration webpage
  • create a new Authentication
  • choose the information this new Authentication has access to
  • choose the time span this Authentication is valid
  • confirm the creation

The administration webpage will provide you with a unique password for this newly created Authentication.

You provide the new service with this new password and your private key. Now the service can authenticate itself against the api. It can do this multiple times, each time it does it, it will receive a different Authentication hash. But as soon as the first request with one of those hashes to /info is made, the password will be invalidated, and the used Authentication hash is the only one remaining valid. The new service is now authenticated and has access to the api!

advantages of this approach

You will only have to carry around the public key with you, and all companies, bank or public transportation service, know who you are. All other cards will become obsolete.

The possibilities for the api are limitless; as all data is gathered at one place, you may combine information about a user never possible before. Some examples:

  • Banks can expose asset information to be consumed by the tax administration
  • Users can share their medication & disease records to be consumed by research to find correlations
  • If users change important data like their address, all services will be automatically contacted

dangers of this approach and how to avoid them

As you have only one public key to authenticate yourself, if someone has access to the system and is able to invalidate your card you lose all access to all your services. Therefore, the system must be an independent authority.

If someone unauthorized gets access to the administration webpage, it could end pretty badly for the rightful user. This can be prevented by choosing a save way to authenticate the user, and take all steps necessary to develop a well-tested, high quality implementation without security holes. As the concept is not overly complicated, this should be possible. Also, to authenticate a new service, one does always need the private key.