Identity breakdown

identity-breakdown.md

1. Backend track

1.1. IPID

Depends on: 1.6

It's very important for DAPPs based on IPFS that they work in a P2P fashion.

As an example, the login feature of uPort requires you to create an application on their end. During this process, a unique and secret code is given to you which you should use when calling the uPort API. Since we want our applications to run entirely on clients, developers can't hide this secret since it would live within the JavaScript frontend code. This secret code is their only way to identify the applications requesting to login in a secure manner.

Having that said, we should focus on DID methods that work without resorting to servers. IPID is a DID method entirely made on top of IPFS. It uses IPNS for mutability and a DAG to store the DID-Documents and keep history. There's one issue though: if the key that owns the IPNS record gets compromised, your identity is permanently compromised.

• Brainstorm and formalise a solution to the "identity is permanently compromised if the IPNS key is compromised"
  • Discuss Shamir secret sharding
  • Discuss key layers: master, management, device
• Ask @jonnycruch to share ownership of IPID
• Review the IPID spec and make sure it's 100% compatible with the DID spec
• Design and implement the ipid module, similarly to muport-core, that offers a easy-to-use management API for IPID based identities
  • We probably want to use ipfs-did-document to help us manipulate a DID document stored on IPFS.

1.2. DID resolver

Depends on: 1.1

Have a module that resolves the DID-Document of a given DID. This ensures that DID methods other than IPID can be easily added and resolved in the future.

A module named did-resolver already exists in NPM and it's made by uPort. You simply attach a resolver function for a given DID method and, when resolving a given DID, the module will call the correct resolver function based on the method present in the DID itself (did:<method>:<method-specific-id>).

We will focus on having the IPID DID method first on the IDM. Similarly to muport-did-resolver and ethr-did-resolver, we should implement ipid-did-resolver so that we can integrate it in the generic did-resolver module.

• Implement ipid-did-resolver; this will use the ipid module to resolve the documents
• Make sure that it works within the more generic did-resolver

1.3. Verifiable claims

Depends on: 1.6

Have a module to create, read and verify Verifiable Claims.

• Design and implement verifiable-claims module that allows us to create, read and verifiable claims according to the spec.

1.4. Social (verifiable) claims

Depends on: 1.3, 1.6

Social Proofs is one of the ways one has to prove their identities by relying on social networks, such as Facebook and Twitter. The way it works is that you make a piece of text available publicly in your social profile along with a signature that can be used to check agains that piece of text. Relying parties can fetch that piece of text and verify the signature against one of the Identity's public keys (perhaps the master one).

We need to have a module that makes it easy to create, read and verify social proofs on the the most used social networks. I suggest we start with Facebook & Twitter and add others later on.

• Study and learn from the work made by @daviddahl on ipfs-social-proof, possibly using parts of it
• Design and implement social-veriable-claims so that we can create, read and verify social claims. This module will make use of the verifiable-claims detailed in the previous point.

1.5. DID-Auth

Depends on: 1.1, 1.2, 1.4, 1.6

The DID-Auth allows one entity to prove ownership over an DID to a relying party, additionally passing claims about themselves. This is important in scenarios where you must be sure that the entity behind the Identity is trustworthy before giving it permission to access private data.

• Design an implement the did-auth module that implements the most basic version DID-auth scenario: entity wanting to prove ownership of an Identity to a relying party

1.6. Crypto material

Many of the modules we are going to develop are based on cryptography. Ideally, we should have a consistently way to refer to a Public/Private keys. More specifically, I strongly believe there should be a common interface for the Public/Private keys.

• Decide what interfaces of crypto material would look like
  • Should we rely on WebCrypto API/interfaces?

1.7. Profile and social claims storage (public & private)

Depends: 1.1, 1.2, 1.4

As a user, you should attach public information to your identity, such as your name, avatar, facebook profile and so on. You should be able to decide which parts of this information are public or private.

Having a canonical and deterministic way to fetch the public information is a requirement for many DApps. Consider this scenario on Discussify: you leave a comment today in a public discussion. After some months, you change your avatar. Should the avatar displayed in that comment (and all others I've made) be the new one? If so, should this be a responsibility of the DApp or should the IDM help with this?

• Have a brainstorm and decide what to do about this subject
• Based on the what we decided, implement the necessary modules to add, update and remove profile & social claims data from the identity

1.8. DApp & IDM interaction

Depends: all

DApps will interact with the IDM to:

• isAuthenticated - check if we are authenticated
• authenticate - prompt for authentication
• unauthenticate - opposite of authenticate
• sign - signs a piece of data (requires user to be authenticated)
• verifySignaure - verifies the signature of a piece of data
• fetchProfile - fetch the public profile of an identity (name, avatar, ...)
• fetchClaims - fetch the public social claims of an identity

DApps may be running in different type of environments, the most important ones being:

• As a web DApp running on your browser
• As a native GUI DApp running on your OS

But how can they interact with IDM? What if IDM is not installed in the device I'm using? The RFC Peer-Star-Identity only predicted browser to browser environments but we should dedicate sometime to widen the possibilities. We should list all the possible combinations of environments that both DApps and IDM may be running, and define a communication strategy for each combination.

• Research about all the environments in which a DApp and IDM interaction may occur and how they communicate in all combinations
• Design and implement the IDM client interface for the browser to browser scenario

2. Web UI/UX track

2.1. Concept & branding

Concept: The goal is to end up with a polished interface with a catchy look and feel, through a premium approach. This will help selling the idea behind IDM, be distinct, reliable and accessible for the end users.

Branding: Promoting awareness and recognisability of the product on the market.

To accomplish this we must:

• Create a logo
• Choose the brand colors;
• Choose the typography
• Experiment with graphic elements such as, illustrations, iconography and other assets
• Research about projects with similar requirements (e.g.: blockstack), so that we can learn from them

2.2. User-journeys

Depends on: 2.1

• Setup IDM by choosing the device type and name (e.g.: type: mobile phone, name: André's iPhone)
• Homepage
• Identity page
• Create / import identity *1
• Manage identity profile (name, avatar, email, etc)
• Manage identity social proofs
• View devices associated with the identity
  • Revoke a device
• View apps that I've used with this identity
  • Remove an app (revoke session)
• Authentication request
• Signing request

1 - Have a brainstorm session so that the process it's intuitive to the average internet user.

2.3. Styleguide

Depends on: 2.1

Create a document that showcases all the IDM visual components, their variants and behaviours. This helps standardising all the visual language of the project so that it's consistent in the whole design & development process.

2.4. Brand manual

Depends on: 2.1

Create a document that provides guidelines to ensure the correct use of the Protocol Labs brand identity. They allow the creation of a strong and distinctive brand. It contains a summary of the thinking behind, an overview of our creative style and explanation of the basic elements of our brand.

As an example, this manual will ensure that the "Login with IDM" looks the same amongst all DApps.

3. Frontend track (web *1)

1 While the IDM can and should be running on the browser, as a desktop app, as a mobile app, and so on, we will focus on the browser first.

3.1. Styleguide components

Create all the styleguide components in react using Storybook.

3.2. Bootstrap web project & implement user-journeys

Create the project and implement all the user-journeys by using styleguide & backend components.

You may see the list of user-journeys in the 2.3.