You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several DID methods that can be used by users (entities) to create their identities. DApps should embrace several DID methods to target as many users as possible. This process should be transparent and consistent to avoid having different code-paths and logic for each DID method in DApps.
Peer-Star applications are mainly peer-to-peer. This means that there are no servers talking to clients and vice-versa. Many DID methods, such as uPort, require applications to store secrets to perform certain operations, such as requesting credentials from users.
It should be straightforward to perform a "login". Ideally, users shouldn't be required to install plugins or extensions into their browsers to interact with DApps. Relying on doing so, will prevent the mass adoption of the technology.
Some DID methods have Verifiable Claims built-in, which is the case for did:erc725. This allows DApps to present additional information, such as a name, an email, social accounts, etc., to increase the trustiness on an identity right before giving him/her access to confidential information. For DID methods that do not have this feature, we can build on top of it via signing. Still, this should be done in a way that is consistent across DID methods, as outlined in point 1..
Security
Users will use the same DApps across several devices: laptops, desktops, mobile phones, tablets, etc. In a simple setup, the keys that control the DID are used for encryption and signing purposes. But over-using the master keys has one very important downside:
Users will keep them closer so that they are easily accessible, and possibly, replicate them across devices. Because of that, it increases the probability of them being compromised (e.g.: a device gets stolen).
In the event of the master key being compromised, an attacker has control over the DID, and therefore may impersonate the real owner. Some DID methods, such as Sovrin, embraced a Decentralized Key Management System where a set of trustees can agree on issuing a new master key for an identity. This effectively mitigates the issue for Sovrin identities.
Neverthless, most DID methods simply assume that the master key will be kept secure which contradicts the fact that they are often required for daily use.
DApps authentication
There are several DID methods that can be used by users (entities) to create their identities. DApps should embrace several DID methods to target as many users as possible. This process should be transparent and consistent to avoid having different code-paths and logic for each DID method in DApps.
Peer-Star applications are mainly peer-to-peer. This means that there are no servers talking to clients and vice-versa. Many DID methods, such as uPort, require applications to store secrets to perform certain operations, such as requesting credentials from users.
It should be straightforward to perform a "login". Ideally, users shouldn't be required to install plugins or extensions into their browsers to interact with DApps. Relying on doing so, will prevent the mass adoption of the technology.
Some DID methods have Verifiable Claims built-in, which is the case for
did:erc725. This allows DApps to present additional information, such as a name, an email, social accounts, etc., to increase the trustiness on an identity right before giving him/her access to confidential information. For DID methods that do not have this feature, we can build on top of it via signing. Still, this should be done in a way that is consistent across DID methods, as outlined in point1..Security
Users will use the same DApps across several devices: laptops, desktops, mobile phones, tablets, etc. In a simple setup, the keys that control the DID are used for encryption and signing purposes. But over-using the master keys has one very important downside:
Users will keep them closer so that they are easily accessible, and possibly, replicate them across devices. Because of that, it increases the probability of them being compromised (e.g.: a device gets stolen).
In the event of the master key being compromised, an attacker has control over the DID, and therefore may impersonate the real owner. Some DID methods, such as Sovrin, embraced a Decentralized Key Management System where a set of trustees can agree on issuing a new master key for an identity. This effectively mitigates the issue for Sovrin identities.
Neverthless, most DID methods simply assume that the master key will be kept secure which contradicts the fact that they are often required for daily use.
Comparison between DID methods
https://github.com/ipfs-shipyard/peer-star/pull/15/files#diff-9be4060055ce2a4657918dbb8ed105d3
These were the problems that lead us to do #15.
The text was updated successfully, but these errors were encountered: