ecosistema-social-decentralizzato/topics/identity.md

# Identity

Centralized identities are administered and controlled by a single authority. Centralized social networks offer users centralized identities, administered and controlled by the service. Decentralized social networks offer forms of identity that are not centralized, with varying degrees of user control. Decentralized identities may be [federated, user-centric, or self-sovereign](https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/ThePathToSelf-SovereignIdentity.md).

We will call entities with identities "actors", because non-human entities such as companies, organizations, and bots may have identities on a social network.

Identity allows an actor to:

- control an account and access private data
- communicate with another actor
- establish visible reputation and credibility

Desirable qualities for decentralized identities:

- Allow authentication and migration between services
- Allow communication across services
- Unique, global, and memorable

## Decentralized Identity

OAuth is currently the most successful identity standard. OAuth was created to securely transfer user credentials from one site to another. OAuth identity providers became centralized because users could not run or choose their own identity providers. (See decentralized identity protocol comparisons in [Decentralizing the Social Web](https://hal.inria.fr/hal-01966561/document))

### Identity in federated applications:

- XMPP - User identity in XMPP is a username followed by the homeserver, and looks like an email address: `alice@example.comq`

- Matrix - User identity in Matrix is a username followed by the homeserver: `@bob:matrix.org`

- Diaspora - User identities in Diaspora are tied to their pod, and cannot be migrated. Diaspora uses the Webfinger protocol to discover users from other pods. User information is returned via hCard, an open microformat standard for identity.

- Mastodon - User identities in Mastodon are the username followed by the instance the user belongs to: `@alice@mastodon.social`

- Solid - Solid uses WebID URIs as universal usernames. The WebID URI's function is to point to the location of a public WebID Profile document: `https://alice.databox.com/profile/card#me`

### Identity in p2p applications:

P2p systems that put identity entirely in the hands of users must deal with key management, key verification, and key backup. Account recovery is usually not possible, because there is no third party to recover an identity if a user loses their password or key.

- Peergos - Peergos users are identified by unique usernames linked to public keys. The uniqueness of usernames is ensured through a global append-only log for [public key to username](https://book.peergos.org/architecture/pki.html) mappings that is mirrored on every node in the Peergos system. Names are taken on a first come first served basis. Currently, a single server determines the canonical state of this log, and other nodes sync to it. Long-term considerations include decentralizing the name server through a blockchain architecture. Peergos allows [multi-device login](https://book.peergos.org/features/multi.html) through a password-based interface. A user's private keys are derived every time they log in using their username, password and a published salt.

- Gun - Gun's [User System](https://gun.eco/docs/Auth) creates a username and password, with usernames are global but not unique. [Multi-device login](https://gun.eco/docs/Auth) is handled by encrypting a user's crytographic keypair, which is stored in the GUN graph. Keypairs are not derived from the password. PBKDF2 proof is derived from the password, and AES keys are derived from that to encrypt the keypair. GUN treats this method as "secure enough" for applications in which private keys do not control financial information. "Auth" is doing a GUN query for that account, subscribing to it, and then attempting to brute force decrypt the keys of all accounts that match that username. Once an account has been loaded once, it's cached on that device, loading from localstorage or the local harddrive.

- Ssb - Ssb user identities are cryptographic keypairs, stored locally. Multi-device login is not possible because keys are stored on user devices. Users can pick a human-readable nickname that is associated with their key, but nicknames are not unique because there is no global registry.

- Aether - Identities in Aether are keypairs. Users can choose a custom nickname, but it is not unique. Multi-device usage is possible, but difficult, and requires manually porting a user config file across devices.

## Decentralized Identifiers (DIDs)

The [DID W3C standard](https://www.w3.org/TR/did-core/) is an emerging standard around decentralized identifiers. [DIDs](https://w3c-ccg.github.io/did-primer/) are a new type of globally unique identifier that do not require a centralized registration authority, and can serve as a decentralized public key infrastructure.

The format of a DID is: a scheme identifier, followed by the DID method, followed by a method-specific identifier. A simple example: `did:example:123456789abcdefghi`

- IPFS - Identity solutions have emerged that use IPFS as a data storage layer for decentralized identifiers. A recent blog post on [IPFS and Decentralized Identity](https://blog.ipfs.io/2020-06-11-identity-ipfs-ion/) lists examples of identity systems on IPFS, including [3ID](https://www.notion.so/3ID-Identity-System-fac2f47862a84602b366af1cd64f3523) and Microsoft's standards-based identity service ION.

### Blockchain Identity

In 2001, Zooko Wilcox-O'Hearn named three desirable properties of decentralized network identifiers: human-meaningful (memorable), decentralized (global), and secure (unique). This became known as [Zooko's triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle). Prior to the invention of cryptocurrency blockchains, which enabled decentralized global consensus, it was thought that only two of these three properties could be achieved at one time. Now, many projects have created blockchain-based protocols for naming systems that fulfill all three properties.

- Namecoin - One of the first forks of Bitcoin to create a blockchain with an alternative use case, [Namecoin](https://coincentral.com/namecoin-nmc-beginners-guide/) functions as a blockchain-based key/value pair registration and transfer system. The Namecoin chain is used for NameId, which combines identities on NameCoin with OpenID, and Dot-Bit DNS, which distributes a DNS registry over the network.

- ENS - The Ethereum Name Service gives users a `.eth` domain associated with an Ethereum address. It is managed by a smart contract on the Ethereum blockchain. Names are allocated through an [auction process](https://medium.com/the-ethereum-name-service/a-beginners-guide-to-buying-an-ens-domain-3ccac2bdc770).

- Blockstack - Blockstack originally registered names on the Bitcoin blockchain, and later became a general purpose blockchain platform.

- Handshake - Handshake is a blockchain for name registrations.

- Microsoft - [ION](https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-booting-up-the-network/ba-p/1441552) is a Microsoft-led digital identity system built on Bitcoin.

- IBM - IBM is helping to create, operate and maintain [permissioned decentralized identity networks](<(https://www.ibm.com/blockchain/solutions/identity/networks)>) built using Hyperledger

## Reputation & Trust

Reputation in decentralized networks is established using many of the same [mechanisms](http://www.lifewithalacrity.com/2005/12/collective_choi.html) as reputation in centralized networks: ratings, peer connections, and metrics such as follower counts. Reputation systems in decentralized networks also suffer from sybil attacks and spam, addressed below.

## Failure modes

- Sybils and spam - Spam, and the creation of many fake users to carry out attacks or misinformation campaigns, are problems for existing centralized social networks. These problems are also present in decentralized networks, and approaches to combat them are still evolving. Federated architectures allow server administrators to intervene and block or filter malicious accounts. In p2p systems, other approaches are necessary. Aether requires a hash computation to be performed for every event posted, raising the computational power required to mass spam the network. Steemit, a blockchain social network, requires new user registrations to be approved by a centralized service in order to combat the problem of fake accounts created to rig the voting system that determines monetary rewards for posts.

- Account Loss and Recovery - Federated networks can allow server admins to help users reset lost or forgotten passwords. For example, Mastodon users can ask their server for a password reset as they would any other service. P2p networks do not generally allow users to recover lost accounts, as there is no third-party to facilitate the exchange. [Dark Crystal](https://darkcrystal.pw/), a project in the ssb ecosystem, implements social key recovery to attempt to address this problem. User keys are split into shards that can be shared with trusted friends and family, and later used to reconstruct a lost key.

- Impersonation - Attempts to impersonate users for fraud or defamation purposes are widespread on centralized social networks. This threat also exists in decentralized social networks, although it has not been exploited to large extent because these networks have not achieved the same scale and prominence.

## Links

- [What are Decentralized Identifiers](https://www.evernym.com/blog/what-are-decentralized-identifiers-dids/)
- [Decentralizing the Social Web](https://hal.inria.fr/hal-01966561/document)