We use cookies for Piwik Page Analytics. More details can be found in our privacy policy/ imprint

Wir verwenden Cookies für Piwik / Nutzungsanaklyse. Mehr Informationen finden Sie in unserer Datenschutzrichtlinie/ Impressum


An expert

Yes we are. We are WedaCon. Your experts for a wide range of IAM solutions from development to implementation.



Blockchain ID Innovation Night


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 & Clound Conference in Munich. According to the ‚call for speakers‘ send out in Febuary, the organizer (KuppingerCole) was not looking for ‚pitches‘, but for a 'slam-style event where you try to at the same time entertain and convince the crowd that the world will be a better place with your contribution‘.
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 enganged 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 usecases, 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 leaast in our industry) is talking about 'BlockChain' and Self-Sovreign 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 Camerons 'Laws of Identity', as the oldest and most etsablished set of 'good practice' around identities.

I ask 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 complete story is available here, but in short relations must be provable, but only to authorized parties, which is a constraint of 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.

Contextual 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 as possible, while allowing it to be extensible over time.

Again, for a complete view, just visit the W3C Draft-Document.

Principles of Self-Sovreign 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, in fully control 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 interoperatbility with other systems, as long consent for this was given.
The disclosure of those claims must support the concept of minimalization.
The individual rights of the owner must be protected and takes precedence against the righs 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 requires to reveal information only based on user‘s consent, with minimal disclosure for a constraint use, and only to justifyable 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, which requires those systems to offer a consistent experience as simple and easy to be used as it can be.

What do they have in common?

When we put all those principles into a Venn Diagramm 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 disapointing:

unnormaized VennWhat happened?
All the principles are not comparable, without sorting or normalization, or in other terms: a categorisation.

This is something we already tried on other occasions, and it is a really hard job to do this. Once again, I realized that we miss something like a (caution: stupid play of words now: 'universal Princples 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 similiar principles). These are:

  Directed Identity
  Human Integration

Fine, now we have normalized, lets try again

Looks much better now. We have many overlapping concepts and ideas, but what I would like to fokus on is: Where are the lonely wolfes?

Which concepts are not covered by at least two candidates, hopefully disclosing were we still have work to do?

You see them sorrounded by the red boxes, I call them 'lonely wolves'


The need for decentralized Identity Management

All the concepts and 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 therefor 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 to 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 which you should consider to be added 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 be adaptable to new, currently unknown demands and to be connected 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 theoretical unlimited scale.
  • Mutable
    The mutability and /or imutability of relations and entities must be respected.
  • Semantical
    Any entity (which includes everything by definition) must be described in a semantical way to enable human/machine interaction.

Author: Thorsten H. Niebuhr / @idmpath

Download the full presentation