Private Data on Public Networks

TLDR; Only public keys are going to be stored on IPFS, no other user data.

Introduction

The first versions of uPort required that all user information be stored on the user profile object. This object is a JSON structure, which is stored on IPFS (a decentralized storage network) and the identifier of this object (an IPFS hash of the file) is stored in the uPort registry (a smart contract on the Etheremun blockchain) under the user’s personal ID. This record on the uPort registry can only be changed by the user herself.

So if the user wanted to change the information about his identity, a new user profile object, with the new information, would be created and stored on IPFS and the new ID registered by the user would be stored on the uPort registry. This ensures that the user, and only the user, is in control of his personal information: a truly self-sovereign ID. In the event that a user wanted to share her profile data with a dapp (or any other user or application), she simply needs to share her user ID. The dapp then reads the uPort registry, and with the identifier of the object, the full user profile object can be retrieved from the IPFS network.

While this previous version was a very convenient way of sharing identity data, the user’s personal information is stored publicly on IPFS, meaning anyone can read it, even if the user didn’t give them explicit access. This is a problem for user privacy.

As a result, we have made some changes to uPort to solve for this issue. Therefore, if you have built a dapp or any application that relies on this older model of accessing information, you need to review it because you may experience some issues.

What We’re Changing

In short: we are storing only public information about the user in IPFS. Right now some user profiles have this object stored on IPFS:

{
 ‘@context’: ‘http://schema.org',
 ‘@type’: ‘Person’,
 ‘name’: <user name>,
 ‘image’: {
 ‘@type’: ‘ImageObject’,
 name: ‘avatar’,
 contentUrl: <ipfsHash of the image>
 },
 ‘description’: <user description>,
 ‘country’: <user country>,
 ‘publicKey’: <user public key (to sign attestations)>
}

The new profile object will only have this:

{
 ‘@context’: ‘http://schema.org',
 ‘@type’: ‘Person’,
 ‘publicKey’: <user public key (to sign attestations)>
}

As you can see, any other information besides the public key is going to be stored only on the user’s phone, and no longer on the public profile.

Changes for your dapp

If your dapp relies on aspects of the public profile to be present, it will no longer work properly. A typical use case is to ask the user for her uPort ID, query the registry, retrieve the name and the image (avatar) from the public profile, and then display it on the dapp in the “logged as” area.

Since the public profile no longer stores this information, you will need to ask the user to disclose it directly.

You can conveniently request information using “uport-connect”:

uport.requestCredentials({
 requested: [‘name’, ‘avatar’, ‘country’],
 notifications: true
}).then((credentials) => {
 …
})

Public keys

The user’s public key is still going to be stored on public IPFS. This is needed to verify any attestation that the user has made about herself or to other users. In the future there will likely be some sort of revocation entries for keys stored on the public profile.

As we continue to make updates and improvements to uPort, we want to be sure that we are supporting our community in similarly improving their dapps as well. Please be sure to reach out if you have any questions or comments at our Gitter channel.

Happy uPort Coding!