With increasing data protection requirements, it is becoming more and more important to take the data sovereignty of users into account. Therefore, user-centric approaches are being discussed in identity management that ensure user privacy in addition to overall system security. An identity holder should disclose as little information as possible to an auditing service and, moreover, no other service should be able to collect data about a holder’s activities. But what does this mean for the holder? What must a credential issuer consider when issuing credentials? Conversely, what are the requirements of a verifying service? This article contrasts the claims of issuer, holder and verifying service.

Regardless of what identity management system is considered, the following actors can be defined. On the one hand, the central figure is the identity holder, who has any number of attributes (claims) issued about him by a body responsible for this. The issuer of these attributes certifies certain properties to a holder by handling them cryptographically and transferring them to the requesting instance. This instance is a verifying service (verifier), which is presented with a statement about the holder so that it can decide whether and how it wants to allow the holder to access a resource controlled by it. The relationship and the characteristics of the triangle of publisher, holder and verifier have already been reported on (see Societybyte article on Crendentials). A very important criterion concerns the presentation of a credential to a verifying service. The question arises whether the publisher only produces a statement about the holder or whether he is additionally involved in the presentation process. When a publisher of evidence is not involved in the process of presenting to an assessing service, it is referred to as a user-centred (the holder is at the centre) approach. This type of presentation, in which there is direct communication between the holder and the assessing service, is considered in more detail below by presenting a selection of key requirements from different views.

Figure 1: Main requirements of the individual actors

From the issuer’s point of view:

• Authenticity of the holder: Before a publisher (issuer) can make a binding statement about a holder, the holder must first authenticate itself. The required strength of authentication depends on the statement an issuer makes. Only when an issuer is satisfied that a holder has authenticated itself according to its rules will it be willing to issue a generally verifiable statement about that holder. This statement is often called a proof or a claim.
• Revocation: It must be possible to revoke a proof without revealing the identity of the holder. Revocation may be initiated by the issuer or the holder.

From the holder’s point of view:

• Multiple sources: The holder should be able to compile statements about himself from multiple sources (from different publishers) and present them to a verifying service.
• Selective disclosure: A holder should be able to choose which attributes to disclose to an auditing service. The rest of the attributes shall remain hidden from a reviewing service.
• Anonymity: A verifying service shall not be able to learn the identity of a holder (unless the holder knowingly provides it with all necessary information).
• Derived attributes: The use of derived attributes must be possible (e.g. age limit or liquidity).
• Portability: A holder must be able to use his identity information from different end devices (desktop, notebook, mobile phone, tablet).
• Trust: A holder must be able to establish trust with a verifying service. He must be sure that a verifying service cannot misuse his personal data. A holder must be able to be sure that the verifying service is authorised to require these attributes from him and is allowed to appear in the function.
• Simplicity: An application on an end device must be easy for the holder to use and transparent.

The holder prepares the evidence issued by the issuers and presents it in an appropriate form to an examining service. This is illustrated in the above figure with envelope symbols.

From the perspective of the checking service:

• An examining service must be able to verify evidence presented to it and check that it is up to date. It must verify that the evidence presented has been issued to the holder.
• To ensure the protection of the privacy of the holder, a verifying service must not receive a unique identifier of the holder.
• When a verifying service accepts a credential, it trusts the issuer.
• A verifying service must be able to validate that the evidence submitted matches the attributes it requires.

Requirements do not have to be completely fulfilled in order to operate a system. There are requirements that cancel each other out or can only be implemented with great effort. Rather, this catalogue of requirements for an identity management system is intended to raise questions and stimulate discussion about possible solutions.

Conclusion

The following characteristics of an identity management system can be derived from these requirements: An issuer must pre-screen information from a holder for which he is responsible. He creates a proof based on authentication (the strength depends on the information). If he does not do this, the statement is not serious and reliable. A holder cannot therefore behave anonymously towards an issuer. A holder must be able to assume that the information he provides to a verifying service cannot be misused. The holder should have the possibility to behave anonymously towards a verifying service, even if this is illusory, because a verifying service does not normally create a business relationship with anonymous users. A verifying service must be able to rely on the validity of the evidence provided and on its legitimate use.