DSNP requires a unique identifier for a user. One simple path would just be using a public key as that unique identifier. Private keys are unique and have a simple 1:1 mapping with public keys. This is straightforward and requires the minimal amount of on-chain state to maintain. So why does DSNP have a more complicated implementation?
The simple 1:1 mapping does not work well for all users. Smart wallets like Gnosis Safe were created to expand the capabilities of an “account” on Ethereum. At DSNP, we wanted the ability to have many of the same capabilities and modeled some of the DSNP Identifier structure and the original v1.0 Ethereum Identity contract around smart wallet ideas. The properties we wanted were:
Consistent identifier for off-chain data
Safe key rotation
Key revocation for per-device keys
Key permissions for increased security
Consistent Identifier
Identifiers are critical for source-dependent messages. Those identifiers are easier to interact with when there is not a secondary search needed for migrations. DSNP uses the blockchain to produce a consistent identifier with associated keys that can be rotated.
Key Rotation
Security best practices always include key rotation. With Ethereum this is possible through transferring the assets from one key to another. However, there is a significant risk of mistakes and the consequences are potentially an entire loss. While having an on-chain identifier with connected public keys increases the chain storage requirements, it greatly reduces the risk of mistakes from simple typos and can include additional validity checks.
Key Revocation
Revocation is complex even in a centralized authority system like SSL certificates. Blockchain can enable revocation to be much more efficiently distributed and corrected with the distributed timekeeper of the block number. Thanks to the easier revocation provided by a blockchain, we can enable users to have per-device keys. Unlike Bitcoin and Ethereum where it is critical to maintain security and access to a single private key, with per-device keys we can instead secure different keys for each device. If a device is lost or compromised, other devices can act to revoke the compromised key without acting from the same key.
Key Permissions
Permissions for specific keys is another great way to increase security. Ownership level keys or recovery keys can then be kept off-line in what is called “cold storage.” This follows the Principle of Least Privilege, another security best practice. Delegation also tries to follow the same ideals.
There’s No Free Lunch
While the benefits are clear, the trade-off is one of storage and connected validation. Any account that exists must maintain active storage on the blockchain. This data is replicated to every node, which is very useful for validation but costly in storage requirements. Validation of a signature also requires connectivity to that network, however that already is a requirement for any form of revocation. Many chains that have embraced the concept of multiple keys with a common identifier have minimum deposit requirements. (NEAR and Flow for example) We think there are other ways to offset or shift this cost off of users, but the value to users and the network is clear: one public key is not enough.
Thanks @wil. Yes, “Private keys are unique and have a simple 1:1 mapping with public keys. This is straightforward and requires the minimal amount of on-chain state to maintain.”
Wondering if you think it helpful to draw a distinction – based on regulated or not – between different types/classes of key pairs where a) a key pair bound to a natural/living person, differs from, b) a key pair bound to each device (and many other inanimate objects).The latter does not involve the processing of PII governed by data protection regulation but the regulation does impact establishing the identity of a person who can generate their own public/private key pair (ownership and sole control of private key means non-repudiation).
This suggests that a) above would reside, as you say, “Ownership level keys or recovery keys can then be kept off-line in what is called “cold storage.”” i.e. retained for compliance purposes. Per-device key pairs generated on-chain is not burdened with data protection regulation. Hope this distinction helps allocate responsibility for data protection compliance.
Many thanks and regards,
Patrick
I do think there is a distention between keys that are used for a pseudo-anonymous identity and publishing and keys that are used for accessing monetary value. For example, I hope bank access is harder than access to a random fun website.
I think the difference you are referring to (between person and device) is not able to be clean cut. Not from a legal standpoint (others would need to comment on that), but from a technical one.
Keys can only ever refer to what they are. Pieces of data that could be stored anywhere. Keys don’t refer to a person or device. They refer to access to the private key where ever it is and whoever has it. It is possible that it is just one person or one device that has a key but it could be everyone.
So while it is easy to think of a key as referring to a device or identifying a person, it is not possible to guarantee it. This is especially true for a protocol. While it might be possible for a vertically integrated application to provide a certain level of guarantee, with DSNP we want a variety of applications and wallets to be possible. Thus, we can only trust one thing: The actor signing this data had access to the private key.
The key (couldn’t resist) difference is in how someone chooses to manage their keys. Someone could have one key per device. I think we will try to encourage this. Not sure if that is far enough for regulatory reasons however.
Thanks @wil for the helpful clarifications. Agreed that from a protocol perspective, DSNP need not be concerned about identity beyond the specification unique identifier. I don’t think the DSNP should be expected to guarantee that a key uniquely identifies a person but somewhere in the larger ecosystem, it may be necessary, especially for high-value.
A vertically integrated application to provide a certain level of guarantee (Levels of Assurance – LoA’s 1,2,3) about peoples’ identity would at least, encourage more online civility and less of the toxicity that prevails today; accountability comes into play. Caveat; anonymity and pseudonymity remain valid, though. It is interesting that Elon Musk’s ideas for Twitter include “authenticating all humans” to increase trust and defeat spam bots: ‘Authenticate all real humans’: Will Elon Musk end anonymity on Twitter? | Business Standard News (business-standard.com), but there is data protection regulation impact to consider.
You make a critical point; “Thus, we can only trust one thing: The actor signing this data had access to the private key.” ; Such a vertical application would also need to ensure that each actor has EXCLUSIVE control of their private key.
Should “authenticating all humans” or just maybe some humans , emerge as a requirement with Project Liberty then we can offer an application that deals with the compliance. Thanks again.
Kin Regards,
Patrick
We talk a bit about the idea of Attributes in the whitepaper, which I think could be extended for people to be able to build optional extensions which provided some of that, even at a simple “bot or not” level. Either way, applications on DSNP are still more than free to require additional checks before use. While an application will still want to connect users to their graph from outside that individual application, you have the advantage of being able to use the social graph as a check.
But that is all outside of the DSNP of course. I’m super excited to see how people build on top of the it.
Thinking about this more, we do have one more thing we can trust. That is the chain of events that a DSNP Id has authored. That might sound simple, but while we don’t know “who” is the holder of the keys, we can assume a level of trust (assuming non-breached keys) that the events are from a consistent actor. This I think is extremely close to real life as well, although with a slightly easier visual human check.
, emerge as a requirement with Project Liberty then we can offer an application that deals with the compliance. Thanks again.