Multiple Registration

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

A party registers a unique identifier for each relationship (i.e., every identity) it has.

Context

An identifier is used to uniquely identify a party and to retrieve the identity attribute data. A party is engaged in multiple transactional relationships.

Problem

The use of a single key for all the transactions has privacy implications where the transactions could be correlated to expose the identity of the party. Alternatively, key management becomes a nightmare when different keys are used to sign different transactions. How can a party sign multiple transactions without potentially exposing his/her identity?

Forces:

Identifiability – A party needs to create an identity to send transactions in the blockchain network.
Re-identification – Each party can have more than one identity in the real world. For example, one person is both a client of a bank and a patient of a hospital. When the party handles all the interactions with the same identity or a single key representing that identity, his/her privacy could be compromised as the transactions on a blockchain are transparent hence can be correlated.
Transparency – All the historical transactions on blockchain can be accessed by every participant within the same blockchain network. The transactions on a public blockchain are also accessible to everyone on the Internet.
Security – There is no standard approach to protect or recover a user’s secret key when exposed/compromised.

Solution

Each party can establish a unique identifier for every relationship (i.e. every identity) they have. This enables the party to isolate interactions with one party from another. For example, the relationship a person builds with a hospital is separate to the one that is established with a university. Neither the hospital nor the university could proactively use the identifiers to correlate this person’s activities. For each of those relationships, store a separate identifier and identity attributes tuples in the identity registry. Only the identifier owner should be allowed to update the identity attributes. Hence, each tuple should also track ownership information. However, this should still be at the respective identifier level to prevent one from linking different identities of the same party/user. Similarly, we need to ensure identity attributes do not provide information that could be used to link two identifiers.

Benefits

Identifiability – Each sub-key maintains its own identity. The transactions sent under different identities are less likely to be mapped and correlated to re-identify the user.
Availability – The loss of signing key of one identifier does not affect the other identifiers.

Drawbacks

Cost – Compared to a single identifier, multiple identifiers cost more for identifier registration and updates.
Re-identification – On-chain identity attributes such as date of birth, gender, and zip code could be compared against multiple tuples to link multiple identifiers from the same party. For e.g., while different identities could be presented a hospital and university attributes such as date of birth, gender, and zip code could be requested by both organisations.

Related patterns

Registered identifiers are stored in the identifier registry.
Parties could use different subkeys to conduct multiple registrations using the master and sub-key generation pattern.

Known uses

Sovrin suggests users to use a separate identifier for every relationship. Consequently, if a relationship suffers a breach and the identifier is compromised, the user can still have normal interactions in other relationships.
Blockstack allows entities to create as many identities as they want. Each identity is represented by an identifier and a secret key. Entities can utilise their identities to sign in different decentralised applications.
In DAML, participants can use human-readable strings as identifiers to identify themselves. A real-world entity is able to possess multiple identifiers in the same ledger network to denote different identities.