Principles Of Decentralized Identity Management
I had the great honor to present on the ‘Blockchain ID Innovation Night’, which took place just before the European Identity & Cloud Conference in Munich. According to the ‚call for speakers‘ send out in February, the organizer (KuppingerCole) was not looking for ‘pitches’, but for a ‘slam-style event where you try to entertain and convince the crowd that the world will be a better place with your contribution‘ at the same time. Well, I think the world is a better place since I presented, at least for me.
The basic idea of the talk was to compare the design principles for some recent (and also not that recent) papers and work around Identities, using the work on the ‘Design Principles of Identity Relationship Management’, from the Kantara Workgroup I am actively engaged in as the central starting point. In that group, we analyzed several systems doing relationships management ‘in the wild’ in some way. While we already had ‘blockchain’ as one of them in the list, the specific usage of DID and SSI was not taken into account specifically.
Principles, Laws and Goals
Identity Management Experts *love* principles. Remember: We are the good guys! Many of those principles overlap for different use cases, scenarios, technologies or disciplines, which lead to a situation where you have, in a fully implemented stack, covered those principles more than once. Which is good, as you should not rely on one part of your overall technology/ process stack only.
The new kids in town (and the old one)
Since 2-3 years now, everyone (at least in our industry) is talking about ‘Blockchain’ and Self-Sovereign Identities. Along with that we often find the requirement or functionality of a decentralized Identifier; and of course: Relationships are everywhere. And we have Kim Cameron’s ‘Laws of Identity’, as the oldest and most established set of ‘good practice’ around identities.
I asked myself the question: what do they have in common? Lets do a deeper dive into the four aspects of identities I have chosen to investigate
- The design principles of Identity Relationship Management
- The design goals and principles of decentralized Identifiers
- The principles of Self-Sovreign Identities
- The Laws of Identity
The Design Principles of Identity Relationship Management
The complete story is available here - but in short, relations must be provable, but only to authorized parties, which is a constraint on its own. Other constraints can be put on the usage. Mutability and also the definitions of immutabilities on its different edges, which includes revocability or delegations, temporary or infinitive. The scalability is a crucial one here, as the IoT is one of the main drivers for this topic.
Contextuality was in the initial design, but within a relation, context is everywhere. The actionable principle is something we have left over for the work of a relationship manager, whatever that one will be.
Design goals and principles of Decentralized Identifiers
Decentralization means to eliminate the need for a central external authority, while offering the power to own and fully control the digital identifier by humans or non-humans. Privacy and sufficient security by cryptographic proofs of authentication and authorization by design should be accompanied by functions to discover the relevant DIDs and enable its use through interoperability and portability. This should be enabled by any system which is capable of handling DIDs, in the most simple way possible, while allowing it to be extensible over time.
Again, for a complete view, just visit the W3C Draft-Document.
Principles of Self-Sovereign ID
This is from Christopher Allen and the ‘Rebooting the Web of Trust’ initiative. They did a great job (as always) on this, here is an extracted compilation of the important principles:
An independent Identity, fully controlled by the owner, including controlling the access to it and having access to any aspect of it. The underlying systems and algorithms should be transparent in its functions. The identifier itself should be persistent as long as the owner prefers it should live or moved (ported) to another party. The SSI must be enabled for interoperability with other systems, as long consent for this was given. The disclosure of those claims must support the concept of minimization. The individual rights of the owner must be protected and they take precedence over the rights and needs of the network.
The Laws of Identity
If you are working in the Identity Management Space, you most likely have heard of them. If not, I recommend to do it now.
Kim Cameron’s Laws require the reveal of information to be based solely on user‘s consent, with minimal disclosure for a constrained use, and only to justifiable parties. Offering identifiers based on the public or private requirements of it as a ‘directed identity’. The pluralism of the identity providers and technologies, including the definition of the human itself as a component of the overall system, requires those systems to offer a consistent experience and to be as simple and easy to use as possible.
What do they have in common?
When we put all those principles into a Venn Diagram to show which is used in more than one principle, we might get a good start.
OK, lets do it. The result is, well, somewhat disappointing:
What happened? All the principles are not comparable, without sorting or normalization, or in other terms: a categorization.
This is something we already tried on other occasions, and its a really hard thing to do. Once again, I realized that we miss something like (caution: stupid play of words now: ‘universal Principles Names’, a metaphysics of identity terms. But that is a completely different story.
As we lack this right now, I came up with a (simple) approach to normalization for those principles, reducing the original 36 principles from our four topics into 18 (by combining similar principles). These are:
Fine, now that we have normalized it, lets try again:
Looks much better now. We have many overlapping concepts and ideas, but what I would like to focus on is:
Where are the lonely wolves? Which concepts are not covered by at least two candidates, hopefully disclosing were we still have work to do?
You see them surrounded by the red boxes, I call them ’lonely wolves’.
The need for decentralized Identity Management
All the concepts and some common sense lead to a simple conclusion: There is a missing element (or elephant?) in the room. And this is (in my opinion) what we have identified as ‘relationship Manager’ in IRM, which might be, by its nature, a decentralized, or distributed Identity Management System, which needs to close these elements opened by IRM, DID, SSI and LoI.
A decentralized Identity Management system should therefore include the following functionalities (the lonely wolves we have seen) to complete the full stack of upcoming identity management services.
And I would like to add one more thing to this, which I see as a crucial new element: Semantics! We need a way to describe the processes around identities in a human understandable, and machine interpretable language.
The 7 Principles of Decentralized Identity Management
So here they are, the 7 principles you should consider adding to your Identity Management System (or Program, or project, or….)
- Human Integration
The human being, its fundamental rights and fundamental faults must be seen as an explicit and integral part.
- Availability
The given functionality needs to be provided even when some of the actors or components are not available.
- Extensibility
The solution must be able to adapt to new, currently unknown demands and to connect to already available infrastructures and procedures.
- Actionable
DIDM Systems must enable and enforce actions based on authorizations and obligations.
- Scalability
A DIDM needs to have a theoretically unlimited scale.
- Mutable
The mutability and /or immutability of relations and entities must be respected.
- Semantical
Any entity (which includes everything by definition) must be described in a semantic way to enable human/machine interaction.
Author: Thorsten H. Niebuhr / @idmpath
Download the Presentation here