RFC - Peer-Star-Identity

[satazor]

RFC Peer-Star-Identity

This is a proposal for an identity management system for Peer-Star, named Peer-Star-Identity. It's built upon standards to provide a good foundation for Peer-Star applications to authenticate and identify users.

Authors: André Cruz, João Santos, Pedro Teixeira

1. Standards & foundations
   1.1 Decentralized Identifiers
   1.2 Verifiable Claims
   1.3 Self-signed Key-chain
2. Proposal: The IdentityManager
   2.1 What is it?
   2.2 Managing identities
   2.3 Managing Verifiable Claims
   2.4 Authenticating on applications
   2.5 Signing artifacts on applications
   2.6 Managing application sessions
   2.7 Revoking a device
3. Diagrams & mockups
4. Glossary

Standards & foundations

Decentralized Identifiers (DIDs)

A Decentralized Identifier (DID) is a string that uniquely maps to an Identiy, e.g. did:btcr:123-445-333. This standard is fully described in the W3C DID spec and is being widely adopted to create digital identities.

There are already several DID methods, such as uPort and Sovrin, which are listed in the DID Method Registry. Each method has its own way to resolve a DID to a DID-Document. A DID-Document obeys a specified schema and it contains, among other things, a Public Key that entities can use to establish communication (encrypt, verify digital signatures) with the DID owner.

The owner of a DID can use the DID's private key to digitally sign artifacts. Any party can retrieve the DID-Document and verify the digital signature against the public key listed in the DID-Document.

Verifiable Claims

A verifiable claim is a qualification, achievement, quality, or piece of information about an entity's background such as a name, government ID, payment provider, home address, or university degree. This standard is described in detail in the W3C Verifiable Claims spec.

By linking one or more Verifiable Claims to an identity, we are strengthening the credibility of the identity itself. Those claims may be self-signed or made by other entities.

We will start off by leveraging self-signed Verifiable Claims based on social networks, similar to Keybase claims. They are easy to setup and they deliver a good base for trusting identities. Later on we can expand to other types of Verifiable Claims as well, like claims emitted by third-parties.

Self-signed Key-chain

In a simple configuration, the DID key (the one used to prove control of the DID) could be used to sign artifacts and to cypher communication. However, that solution is sub-optimal for the following reasons:

• Does not offer Perfect Forward Secrecy: If an attacker manages to gain access to the private key, he/she is able to decypher all previous communications made to, and from, that entity's DID.
• Over exposes the private key: A private key should be used as few times as possible. Using it a lot makes it easier for an attacker to gain access to the key.
• If the key is compromised, the attacker is able to completely impersonate the real DID owner.

For those reasons, we propose a mechanism where a master key pair is used to sign (authorize) other key pairs. The master key pair can then be used to sign others. This process can continue through many layers. The advantage of this mechanism is that if a key is compromised, only the keys that it signed need to be changed. All the other ones above it, remain safe.

In the first version of this proposal we envision three layers of keys, as shown in the figure below. The first, layer 1 is the DID key, called the Root Key. The Root Key is the one used to create the DID and authorize layer 2 keys. Each entity will use Peer-Star applications from different devices (laptop, smart-phone and others). For each device, an entity will have one key pair whose public key is signed by the Root Key. Those keys are called Device Keys and are layer 2 keys. Finally, Device Keys can be used to sign (authorize) new temporary keys, Ephemeral Keys, to be used by specific applications. These are layer 3 keys.

(layer 1)  rootKey
(layer 2)   |-- deviceKey1 {signed by rootKey}
(layer 3)   |---- applicationKey1 {signed by deviceKey1}
(layer 3)   |---- applicationKey2 {signed by deviceKey1}
(layer 2)   |-- deviceKey_n_ {signed by rootKey}

Revocation

It's important for the entity in control of the DID to revoke a Device Key in case of theft or other circumstances. Similarly to how public keys are made available in DID-Documents, revoked Public Device Keys of a DID should also be public. The way a revoked Device Public Key gets published and the way a relying party query the list of revoked devices depends on the DID method as well.

Verifying the chain

A relying party must always verify the signatures of the Key-Chain to be sure that the entity controlling the DID authorized a specific public key. This is a two step process:

• Verify the Public Key signature of each layer, up to the root.
• Check if the Device Public Key is not flagged as revoked.

At this point, a relying party just needs to prove that the entity owns the private key of the layer 3 key. This can easily be done by asking him to sign or decrypt a challenge.

Proposal: The IdentityManager

Usability is a crucial aspect on this proposal as it played a very important role on its concept.

On one hand, the experience for end-users should be intuitive, simple and familiar. Ideally, users should have little contact with private keys and most of the cryptographic operations should happen behind the scenes.
On the other hand, developers building DApps should have an easy way to authenticate users.

The IdentityManager leverages DIDs, Verifiable Claims and Self-signed Key-chain to provide identification and authentication to the Peer-Star ecosystem.

What is it?

The IdentityManager is a web-page hosted on IPFS and reachable via a specific URL, e.g.: https://peer-identity.io. The application will work completely offline thanks to the installation of a ServiceWorker.

Because it runs on its own domain, it provides a sandboxed environment where access to functionality and data is completely controlled. More specifically, all interactions made with the IdentityManager it will be made via postMessage where control and data segmentation is made via the messages' origin.

Using the postMessage API to directly communicate with the IdentityManager is a bit clunky. Instead, developers will use a library called IdentityManagerClient that abstracts all the communication layer with a intuitive API.

Moreover, any meaningful event on the IdentityManager, such as the removal of an identity, will be broadcasted to interested parties. This allows applications to immediately react to certain events by subscribing to them on the IdentityManager.

Among others, the most important advantages of this solution are:

• Embraces several DID methods instead of being tied to a specific method.
• Doesn't require any extensions, scanning of QRCodes, or any other unfriendly processes for daily use.
• Requires little updates to data stored in blockchains, hence incurring less costs
• Acts like a "server" in the sense that sensitive information may be safely stored in it. Many DID methods require a secret for certain actions, e.g.: uPort requires an app secret to request normal and verified credentials.
• Has a wide support among devices. If we make it a PWA, users may install the application in the OS itself, further enhancing the user experience.
• Allows the user to select between identities when authenticating, useful for people that manage companies, organizations or similar.

Managing identities

Users will be able to associate one or more identities using their preferred DID method. They will be guided throughout the process according to the chosen DID method. Once they complete it, they will have successfully created a Device Key associated with the identity Root Key (via signing).

All the Device Private Keys will be encrypted with a passphrase to improve security. Even if a device gets stolen, the robber won't be able to use most features without the passphrase as all the information stored locally will be encrypted with the Device Public Key. This gives time for the owner of the Identity to revoke the compromised device in the IdentityManager of another device.

Because the identity was linked to this device at setup time, and depending on the DID method, profile information and verifiable claims might become stale. For this reason, users will be able to sync up with their Root Identity to update any stale data.

Managing Verifiable Claims

Users will be able to add claims to their identities. Initially, we will focus on adding self-signed claims linked to some of the most popular social networks. The process of adding those claims (and proofs) will work similarly to Keybase in the sense that users will be guided throughout the process.

The exact way in how the claims will be stored is dependent on the DID method. For instance, uPort already provides a way to store these claims via attestations.

Authentication on applications

Peer-Star applications will use the IdentityManagerClient to manage the user's session.

When bootstraped, the IdentityManagerClient will read a pair of public and private keys, called the Session Keys, from the local storage. Alternatively, the Session Keys will be generated and stored in case they do not exist yet. Note that the Session Keys are considered layer 3 keys.
The IdentityManagerClient then takes the Session Public Key and queries the IdentityManager to retrieve the session data associated to it. If the IdentityManager responds back with the session data, the user is authenticated and, as such, there's an Authenticated Session. If that's not the case, the application can request the user to authenticate via the IdentityManagerClient.

When the application requests the IdentityManagerClient to authenticate the user, a popup pointing to the IdentityManager authenticate screen is open (via window.open). In this screen, the user is asked to choose an identity and to disclose some information, such as its name, its photo and a set of claims & proofs. If the user consented the disclosure of this information and entered the Device Private Key passphrase correctly, a new session for this application will be created and stored. The session data (including the signed Session Public Key) is sent back to the application. If the user denied the disclosure of the information, the operation will fail.
In both scenarios, the popup is closed and the outcome is made available to the application.

Applications might choose the TTL of a session depending on the degree of security they want to have.

Signing artifacts on applications

Applications may want to sign artifacts, such as regular data or Ephemeral Keys. This will be possible in two different ways:

1. Sign with the Session Private Key
2. Sign with the Device Private Key

The first method is less intrusive and happens transparently to the user, but is less secure. More specifically, a robber who stoled a device may still sign Ephemeral Keys with the Session Private Key as long as a session is valid (not expired). Relying parties will still see those signatures as valid until the DID owner revokes the stolen device.

The second method provides more security as the user is prompted for the Device Private Key passphrase, but it's more intrusive. The interaction is similar to the Authentication process, where a popup pointing to the sign screen gets open. The user either allows or denies the signing and the result gets back into the application. Please note that the passphrase might be stored in memory in the IdentityManager during a certain amount of time, which in turn makes this process less intrusive for subsequent signings.

Ultimately, the application may choose between both methods for different situations depending on the security degree they want to have.

Managing application sessions

Users will be able to revoke any application session listed on the identity's Authenticated Session list. Revoking a session will essentially delete the application session from the IdentityManager local storage.

Even if a malicious application persists the session data for future use, it will be unable to sign artifacts, such as Ephemeral Keys, with the Device Private Key, rendering the application useless in those scenarios.

Revoking a device

Users must be able to revoke a device associated with an identity. To do so, users may see the list of devices associated with an identity and revoke any device of that list, including the device from which they are interacting. This will require interacting with the DID method (Root Private Key) to publish the device being revoked.

If a device becomes aware that it was revoked, it will trigger a wipe-out process where all the identity data stored locally will be deleted, including the Device Key and Authenticated Sessions.

Diagrams & mockups

IdentityManager authentication flow diagram

IdentityManager authenticate screen diagram

IdentityManager application mockups

Glossary

• Entity: A person, company, organization or equivalent that controls an identity.
• DID: An identity identifier, which resolves to a DID-Document.
• DID-Document: A JSON-LD document which contains information about an identity, such as public keys to be used to communicate with entity that controls the identity.
• Root Keys: A pair of public and private keys that control the DID.
• Device Keys: A pair of public and private keys of a device, signed by the Root Public Key that controls the DID.
• Ephemeral Keys: A temporary pair of public and private keys, signed by the Device Private Key.
• Session: A unique pair of public and private keys stored locally by the IdentityManagerClient that identifies a visitor.
• Authenticated Session: A session that was signed by the entity controlling the Device Key.
• IdentityManager: An application that provides identification and authentication to the Peer-Star ecosystem.
• IdentityManagerClient: A library used by Peer-Star applications that makes it easier to interact with the IdentityManager.

---

The RFC above will be updated based on feedback given by everyone commenting. Note that the "Table of Contents" won't work because it's a GitHub issue and not a file.

There's currently a TODO item that I would like to have special feedback on "Signing artifacts on applications". As you know, applications perform a lot of signing such as signing arbitrary payload or Ephemeral Keys. The key point is that this operation should be pretty straightforward, ideally without requiring the identity owner intervention.
The issue here is that the Device Private Key is encrypted with a passphrase to improve security. This way, a robber won't be seeing the Device Private Key in plaintext if he goes into the IdentityManager application and inspects the local storage in DevTools. This will buy some time to the owner of the Identity to revoke access to the stolen device as the robber can't use most of the IdentityManager functionality.
But because of the passphrase, applications can't ask the IdentityManager to transparently sign stuff without prompting the passphrase for at least one time, or between certain time periods.

Me and @pgte have been discussing some solutions to this but all of them have flaws in the sense that the robber would still have access to the decrypted Device Private Key with little/medium effort. Does anyone have a solution for this? In case there's no solution, we can delegate that choice to the user themselves where they might compromise a bit of security for usability and vice-versa.

I'm very excited to hear all of your feedback!

[pgte]

@diasdavid @joaosantos15 @fritzy could you take a look at this and give feedback? Thank you!

[satazor]

I've reached a solution for the TODO that I've mentioned in the issue. It's described in the "Signing artifacts on applications" section. Feedback welcome!

[satazor]

Closing this in favor of a PR: #15