“We are surrounded by data, but starved for insights” - Jay Baer
By Yaman November 7, 2019
Specialized terminology is used for blockchain-based identity management schemes. Unfortunately, the terminology is not always consistent among the various projects and standards. Further complicating matters is that some domain-specific terms are related to identity management in general while others are specific to blockchain identity management.
With this terminology, we can identify the common roles that occur in blockchain-based IDMSs and the relationships between these roles. We can also identify common objects found in these systems and the relationships between those objects.
Below Figure provides a high-level overview of the identity management roles.
Note that these roles are not exclusive. For instance, a subject and an issuer can both take the requester role or a subject and a verifier can both be a relying party. Depending on the IDMS, the approval of a subject may be required to issue a new credential to that subject.
The next figure provides a high-level overview of the objects that entities interact with in a blockchain IDMS. The figure shows that entities can have one or more identifiers, that identifiers are associated with one or more credentials, and that presentations are derived from credentials.
The examples so far have shown that it is easy to extend the decentralized identifiers data model in a permissionless and decentralized way. The mechanism also ensures that decentralized identifiers created in this way prevent namespace conflicts and semantic ambiguity. An extensibility model that is this dynamic does increase implementation burden. Software written for such a system will have to determine if accepting DID document s with extensions is acceptable based on the risk profile of the application. Some applications may choose to accept but ignore extensions, others may choose to only accept certain extensions, while highly secure environments may disallow extensions. These decisions are up to the application developers and are specifically not the domain of this specification.
Conventional identity management systems are based on centralized authorities such as corporate directory services, certificate authorities, or domain name registries. From the standpoint of cryptographic trust verification, each of these centralized authorities serves as its own root of trust. To make identity management work across these systems requires implementing federated identity management . The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity for fully decentralized identity management. In a decentralized identity system, entities (in the sense of discrete identifiable units such as — but not limited to — people, organizations, and things) are free to use any shared root of trust. Globally distributed ledgers, decentralized P2P networks, or other systems with similar capabilities, provide the means for managing a root of trust without introducing a centralized authority or a single point of failure. In combination, DLTs and decentralized identity management systems enable any entity to create and manage their own identifiers on any number of distributed, independent roots of trust.
Your email address will not be published.
Save my name, email, and website in this browser for the next time I comment.
By Abhishek Jain
September 12, 2019
July 4, 2019
July 9, 2019
July 23, 2019
February 29, 2020
April 20, 2020
We use ‘cookies’ and related technologies to help identify you and your devices, to operate our site, enhance your experience and conduct advertising and analysis. You can read more about these uses in our Privacy Statement.