Identity management in blockchain projects

06.12.2018

To operate private permissioned blockchains, which are also used in this project, the parties within the consortium (in this case, companies) need to be identified – including on the technical level.  A clear allocation and scaling of these identities must be considered and optimised for use in the future. There are three types of identity in the system:

1.  Network identity

Each node in the blockchain network has an identity. In other words, each one is assigned to a member of the consortium (in this case, a company). Technically speaking, this is implemented using a public/private key procedure, which enables authentication in the network. The administration of identities, as well as the onboarding of new nodes in the future, must comply with the consortium’s governance rules.

In more precise terms, the administrator of the specific node must enter a command in the command line, which includes the name of the blockchain and the physical address (IP address) of a node that is already being run. In non-public networks, executing this command creates and issues the address (wallet) of the node. This address must, in turn, be accepted by the blockchain network. Specifically, there needs to be exactly the same number of endorsements for the authorisation of the network identity as there are votes in the admin quorum.

For the sake of simplicity, network identities in the pilot project were approved with a 50% quorum of two admin nodes, meaning that one node was enough for approval. The technical authorisation for streams and administrative rights are administered via this network identity, meaning that it is key for the consistency of the blockchain network.

2.  User identity

The stakeholders involved in the exchange (lorry drivers, logisticians) must also be identified.  The member of the consortium (in this case, a company) in charge of these people is always responsible for creating their identities.  Cross-company identity administration, authentication, and authorisation brings little value, since the relevant decision always falls under the sovereignty of the company concerned.

In the pilot project, we assigned network identities statically to the identity of the consortium members. It goes without saying that if the project were to be rolled out, this approach would be inconceivable, but any other approach would have involved considerably more effort within the framework of the field test. There were two roles defined in the pilot project: the logistician at the loading bay and the lorry driver. Depending on the role specified when signing up, the user is assigned either a readpoint GLN (global location number) or a vehicle number plate.

Usually, companies would administer identities and roles of employees themselves and use these – via a possible link to an external identity provider – with the blockchain solution and their network identity. Spot market drivers (service providers hired on an ad-hoc basis) are a unique case. The fact that these are used, together with the challenges they represent, was first brought to our attention during the <link innovation blockchain-blog identitaets-management>Identity Management Workshop in Potsdam. In order to avoid violation, the hiring company needs to create an identity that is only valid for this specific operation.

3.  Consortium identity

The dynamic administration of a company’s own identities and their correlation with the identities of consortium members in the blockchain is a complex issue and not absolutely necessary for a pilot test. Moreover, because the field test and decisions regarding data visibility were expected to result in other types of identity management approaches, this decision and model was ignored for the time being. Instead, static identities (based on the corresponding GLN) were assigned to the individual people involved, which were also attached to a specific member of the consortium.

Further considerations for the future

In order to efficiently manage and scale identities in a consortial blockchain in the future, a few points need to be considered: 

• Whenever possible, an identity should not be issued to a specific person, to avoid any problems with the GDPR.
• The consortium identity is critical, since there is no logical link from the technical network identity to the user identity. It provides a company (GLN) with a virtual clearing account. 
• The consortium onboarding process is responsible for the allocation of the consortium identity to the actual company.
• Temporary identities are probably a common feature within logistics processes, and absolutely indispensable for mapping reality.

In this article, we have not come close to discussing complex issues such as self-sovereign identities for natural persons – the subject matter is complex enough as it is! This is where a paper-based system meets the digital world, and the transition must be designed to be both simple and secure.

Zurück zur Übersicht