Secure identities are needed for the trust of customers

Isolated, centralised or decentralised – here, two researchers from BFH Technik und Informatik compare the advantages and disadvantages of the different solutions for identification Identity management refers to processes and services that deal with the collection, administration and use of electronic identities. An electronic identity management system must find the right balance between user-friendliness, security and data protection. Classical models follow the approaches of isolated or centralised identities, which can only partially fulfil these goals. In recent years, decentralised approaches have been strongly discussed and have already gained a lot of international attention with Self-Sovereign Identity (SSI). This article will compare these models and the architectures and concepts behind them in order to show the advantages and disadvantages of the individual solutions.

In a networked world, machines have an identity, but users do not

The internet was basically built without electronic identities. An end device could not know who (person, organisation, service or thing) it was connecting to except on a technical level. Machines communicate with each other via IP addresses. They can also, to a certain extent, verify the authenticity of a partner, as they can resolve the link between a name and the associated IP address in a decentralised name register (domain, name, system) when a connection is established. In order to be able to establish genuine trust in names, a certificate must be created for a specific end device. For users, the scope of such certificates is usually limited to companies. In global networks, certificates are therefore almost only issued for web servers by specialised services. These certificate providers are usually central entities that must be trusted completely, even though they are often unknown (e.g. DigiCert). The problem of electronic identities on the internet (especially for user identities) has not (yet) been solved, although theft and deception of identities are spreading rapidly. This development undermines the public’s trust in the internet.

Isolated identities

This is the most common solution. Many websites or portals in our daily environment use such isolated identities. Here, a user must first have his identity verified at each portal before an electronic identity is issued for him. The user agrees – depending on the requirements of the service provider – on one or more means of authentication (password, mobile TAN etc….) in order to access his account in the future. However, this is an isolated identity as it can usually only be used for this purpose (service provider). As shown in the picture below, the service provider here is the administrator and issuer of electronic identities, i.e. a so-called Identity Provider (IdP).

Figure 1: Isolated identity management

Although this model has the character of a decentralised solution, since an identity can only be used for one application, it brings with it some decisive disadvantages:

  1. From the user’s point of view: – For each service provider, the user receives a different electronic identity and, in many cases, a different means of authentication. This is difficult for the user to manage, as he or she has to maintain several electronic identities and the associated means of authentication locally. Solutions for simplification can be provided by password managers or cloud services for storing the identities. – The user must fully trust the service provider and its handling of their identity information. This is not very transparent for the user, even though the latest data protection laws require it.
  2. From the service provider’s point of view: – In order for the service provider to be able to verify the identity of the user, he has to store a proof of identity of the user with him (usually together with other information). – He is responsible for the security of the identity information he collects. For this reason, he must increasingly protect himself technically against the threat of misuse, as otherwise his reputation could suffer. – In order to be able to offer a contemporary and more secure authentication option, the service provider has to implement cost-intensive 2-factor procedures (e.g. additionally sending an SMS to the user’s mobile number) himself.

Central identities

Today’s service providers have, of course, long recognised these problems and solved them by taking a step towards centralised identities. They moved to delegate account management to specific companies. They allowed users to log in with an electronic identity issued and maintained by another company. Especially in the area of ‘social login’, this makes it easier for the user as they can log in to multiple apps and websites with one login. But the world has also become simpler for the service provider, as ideally they no longer need to set up their own identities. In an operational context, a central authentication service is often used for this purpose to relieve the burden on the applications. With centralised identities, the login and/or validation function is outsourced by the service provider to a specialised operator (identity provider) (1). The service provider trusts the identity provider’s processes and thus its confirmations.

Figure 2: Centralised identity management

In order to access a service provider, the user must first authenticate himself with the identity provider. After authentication, the identity provider sends the result to the service provider in the form of a confirmation. This makes it possible for a user to use a single identity for different service providers.

Two versions are possible in this model:

  • Isolated identity providers: Each IdP has – independent of other IdPs – its own identity data of the user, which is valid in its context. (e.g. “social login” solutions, such as Facebook, Google, Twitter, Amazon, Instagram, LinkedIn, Microsoft)
  • Networked identity providers: Several IdPs trust each other and, depending on the trust level, have a common set of identity data (attributes such as surname, first name, e-mail, etc.) of a user. The user can easily register with different IdPs because they share a common identifier. This common identifier is usually assigned by a state authority, which certifies the IdPs and provides them with standard identity data of a user. Each IdP certified in this model is free to add further attributes from its context to an identity. (e.g. E-ID of CH)

“central identities” have clear advantages over “isolated identities”, but they still have certain disadvantages:

  1. From the user’s point of view: – For the user, the administration of his electronic identity becomes easier, because he only has one or a few identities that he has to maintain. They should be able to use them with as many service providers as possible. Conversely, however, the user’s privacy is severely restricted because the identity provider is involved in every authentication process (login function) and is therefore able to remember when and how often a user has visited a service provider. This information can be used for profiling and targeted advertising. This form of unnoticed surveillance can only be prevented if the IdP is no longer involved in authenticating the user. – The user must now fully trust the identity provider and their handling of their identity information. In the end, this is not much more transparent for the user, even if more trust can be placed in specialised or even state-certified IdPs. – The user – who is actually the identity holder – becomes dependent on this service. If this service can no longer fulfil its function, the user’s electronic identity is also no longer accessible.
  2. From the service provider’s point of view: – Service providers delegate authentication to a specialised system of identity providers, which they trust completely. – This frees them from a burden: o they no longer have to store a user’s proof of identity with them. o they can obtain authenticated and thus trusted attributes from an IdP specialised for this purpose. From the perspective of the identity provider: – As data of users accumulates from different areas (service providers), it is worthwhile to carry out a complex data collection, to collect the user data and, if legislation allows it, to make money with it. There is a temptation to create multi-dimensional profiles, which, with powerful targeting and profiling tools, allow for a very efficient form of monitoring. The rich information from the user’s behaviour can be used for public advertising, but increasingly also for propaganda and electoral politics. – Aggregated data sets are increasingly becoming worthwhile targets for hackers. More and more, available resources are being freed up for misuse. Serious security problems can arise and become almost unmanageable. Such an IdP must protect identity information particularly well.

Decentralised identities

Self-Sovereign Identities (SSI) (2) try to get a grip on the remaining disadvantages. In this model, central instances can be dispensed with, since the identity information is independent of a centralised registration or certification authority or an IdP. Here, the focus is on the user as the owner of an electronic identity, because only he is in possession of his personal data (and never a central service or a state issuer). He can use this identity as needed in any environment, be it private or business (e.g. online shopping or in a government context).

Figure 3: Self-Sovereign Identity

As shown in Figure 3, the user is his own identity provider. He creates his own key material, identity and data from the beginning. All of a user’s data is initially “non-confirmed”. Only when an authoritative authority has authenticated a user’s attributes (asserted properties) do they acquire a certain value for consumers (service providers). However, this approach raises a number of other questions:

  • How can a service provider trust a user’s information? Misuse would be easy to realise. A user could impersonate someone else, or present false properties without the service provider being able to verify the correctness.
  • What if a user no longer has access to his decentralised information (key material, identity information, …)? No one can help him, as there is no central authority that could restore the key material or re-issue confirmed identity data.

For these and other questions, some solutions have already been worked out in the past.

  • The verifiability of a statement is transmitted by the user in the form of verifiable credentials to a service provider. In order to build trust (verifiability) in identity data, a public, verifiable, distributed data register is used in the network. With this, verifiability and immutability of transactions can be implemented by users and issuers storing information in it that allows a service provider to form a proof of the authenticity of the information received. Instead of a classic, centrally managed system with which electronic identities can be issued, distributed and verified, a decentrally organised system is used to publish and securely retrieve meta-information about an identity.
  • Solutions have also been developed on how the deposit and recovery of lost key material – without a central authority – can be implemented. Proposals for this are discussed under the term “Distributed Key Management System” (DKMS).

Conclusion

Isolated and centrally managed identities show major gaps, especially in terms of flexibility and privacy protection. New data protection laws in the EU, and hopefully soon also in Switzerland, demand that privacy and the right to self-determination be guaranteed. Regaining sovereignty over data will become a central concern in the near future. It is therefore not surprising that “Self-Sovereign Identity” (SSI) seems to be establishing itself as a future identity management solution. Self-Sovereign Identities” replace conventional identity solutions with a flexible and dynamic ecosystem that covers a wide range of application areas. For the first time, communication in the global network is provided with an identity by default with SSI. Without an identity, communication between two partners cannot take place at all. This still very young approach has already attracted a great deal of international attention (3) and further advantages that a decentralised, user-centred solution could offer are constantly being recognised. Especially in the environment of heterogeneous system landscapes, which can often be found in our everyday lives and in complex organisations, such an approach offers an undreamt-of simplification. This form of electronic identity is analogous to previous procedures with which we are familiar. Legitimisation behaves in exactly the same way as we prove our identity to each other every day in the real world. We take the required evidence out of our wallet and show it to a verifying authority. Based on its appearance and content, the verifier decides on the authenticity of the evidence we have received from other trustworthy parties in advance (e.g. identity card or driving licence). When and where we use this evidence is completely unknown to the issuer, but it is possible in this scenario that anyone (whether person, organisation or thing) can be the issuer and verifier.


References

  1. This also includes solutions in which the identity data is handed over to the user in the form of a smart card.
  2. Also known as “Bring Your Own Identity” (BYOI).
  3. Further information on Self-Sovereign Identity: https://ssimeetup.org
  4. Roadmap to Self-Sovereign Identity: https://w3c-ccg.github.io/roadmap/diagram.html
Creative Commons Licence

AUTHOR: Gerhard Hassenstein

Gerhard Hassenstein is a lecturer at BFH Technology and Computer Science.

AUTHOR: Marc Kunz

Marc Kunz is a research associate at the Institute ICTM at BFH Technik & Informatik. He mainly researches digital identities, especially how they can be established, protected and used in a user-friendly way.

Create PDF

Related Posts

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *