devol
/
ecosistema-social-decentralizzato
mirror of https://gitlab.com/bluesky-community1/decentralized-ecosystem.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update identity section

This commit is contained in:
Jay Graber 2020-07-20 12:44:55 -07:00
parent e95ad1d4b9
commit b6d8d21263
1 changed files with 19 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
topics/identity.md
View File

@ -18,45 +18,49 @@ Desirable qualities for decentralized identities:
## Decentralized Identity ## 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)) OpenID was originally developed by the creator of LiveJournal in 2005 as a decentralized identity system. The goal was for users to own their identity, and to make logins easier, but the protocols has since mostly [been abandoned](https://meta.stackexchange.com/questions/307647/support-for-openid-ended-on-july-25-2018) due to its complexity and poor user experience.
OAuth is currently the most successful identity standard. OAuth was created as an authorization protocol to securely transfer user credentials from one site to another. OpenID Connect is an authentication layer built on top of OAuth 2.0. OAuth allows different identity providers, but in practice identity providers became centralized because users could not run their own identity provider, or manage to choose among a long list of identity providers.
### Identity in federated applications: ### Identity in federated applications:
Email is the most successful federated social application. As a result, many user identifiers in federated applications look similar to email addresses. Email is the most successful federated social application. As a result, many user identifiers in federated applications look similar to email addresses.
- XMPP - User identity in XMPP is a username followed by the homeserver: `alice@example.com` - [Diaspora](../applications/diaspora.md) - 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.
- Matrix - User identity in Matrix is a username followed by the homeserver: `@bob:matrix.org` - [Mastodon](../applications/mastodon.md) - User identities in Mastodon are the username followed by the instance the user belongs to: `@alice@mastodon.social`
- 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. - [Matrix](../protocols/matrix.md) - User identity in Matrix is a username followed by the homeserver: `@bob:matrix.org`
- Mastodon - User identities in Mastodon are the username followed by the instance the user belongs to: `@alice@mastodon.social` - [Solid](../protocols/solid.md) - 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`
- 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` - [XMPP](../protocols/xmpp.md) - User identity in XMPP is a username followed by the homeserver: `alice@example.com`
### Identity in p2p applications: ### Identity in p2p applications:
P2p systems that put identity entirely in the hands of users must deal with [key management](##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. P2p systems that put identity entirely in the hands of users must deal with [key management](##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. - [Aether](../applications/aether.md) - 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.
- 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. - [Gun](../protocols/gun.md) - 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. - [Peergos](../protocols/peergos.md) - 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.
- 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. - [Ssb](../protocols/ssb.md) - 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.
### Blockchain Identity Systems ### Blockchain Identity Systems
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. 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. - [Namecoin](https://www.namecoin.org/) - 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). - [ENS](https://ens.domains/) - The Ethereum Name Service gives users a `.eth` domain associated with an Ethereum address, or allows them to manage DNS names they already own. 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. - [Blockstack](https://www.blockstack.org/) - Blockstack originally registered names on the Bitcoin blockchain, and later became a general purpose blockchain platform.
- Handshake - [Handshake](https://handshake.org/) is a blockchain for name registrations. - [Sovrin](https://sovrin.org/) - Sovrin is a permissioned blockchain identity network where consensus is maintained by approved validator nodes.
- [Handshake](https://handshake.org/) - Handshake is a blockchain naming protocol for ownership rights to Top Level Domains, as a decentralized alternative to DNS. Names are allocated through an [auction process](https://www.namebase.io/blog/tutorial-3-basics-of-handshake-auction-and-bidding/).
## Decentralized Identifiers (DIDs) ## Decentralized Identifiers (DIDs)
@ -104,6 +108,7 @@ Reputation in decentralized networks is established using many of the same [mech
## Links ## Links
- [OAuth](https://en.wikipedia.org/wiki/OAuth)
- [Decentralizing the Social Web](https://hal.inria.fr/hal-01966561/document) - [Decentralizing the Social Web](https://hal.inria.fr/hal-01966561/document)
- [What are Decentralized Identifiers](https://www.evernym.com/blog/what-are-decentralized-identifiers-dids/) - [What are Decentralized Identifiers](https://www.evernym.com/blog/what-are-decentralized-identifiers-dids/)
- [DIDs](https://github.com/didecentral/didecentral.github.io) - [DIDs](https://github.com/didecentral/didecentral.github.io)