Attributes and credentials represent a concept that strengthens data protection and informational self‑determination in e‑ID systems. The basic idea is that an asserted attribute (credential) rather than an identity is authenticated – without releasing any other data. This article by Klaus Schmeh and Steffen Scholze introduces attributes and credentials as an interesting, yet still little explored, future technology in the e‑ID sector. They will also explain the Enhanced Role Authentication (ERA) protocol which plays a major role in the handling of attributes and credentials.
When you log in to a computer, the operating system checks whether you are a legitimate user; if you draw cash from an ATM machine, the machine checks whether you are a legitimate account owner; if you pass a factory gate, the gatekeeper checks whether you are a legitimate visitor to the building. In each of these cases, a check is carried out to determine whether you are who you claim to be. However, it would be technically sufficient to simply check the validity of the right to log in, withdraw cash or access the facility without revealing your full identity.

To put it more formally: in today’s authentication processes, an identity (person or machine) is usually authenticated, although it is also possible to only authenticate an attribute of an identity. Typical attributes that can be authenticated are age, access permission, and signatory rights. Attribute‑based authentication offers several advantages. Rather than checking the complete identity, only the attribute is disclosed for verification. The validity period of an attribute may differ from that of the identity. Moreover, an attribute can be assigned to or withdrawn from an existing identity. It is also possible to change an attribute without changing the identity.
   In some cases, it is not even necessary to authenticate the attributes, all that is required here is to use attribute statements. For example, the age verification process does not usually require information about the date of birth itself but the attribute statement ‘person is over 18’.

Attributes on smart cards
Attributes are well‑suited for smart card authentication, especially in the field of e‑ID documents. For example, proof of permission to drive a car or pursue a medical or legal profession can be authenticated. Proofs of registration with insurance firms and professional organisations are other interesting applications.
Attributes have been well‑known for decades as a part of attribute certificates. An attribute certificate, as standardised in the X.509 framework, can be thought of as a digital certificate without a public key.1 The signature is supplied by a certification authority (CA). However, this kind of attribute handling is not important in modern e‑ID card systems, one reason being that it is too complicated to involve a CA every time a certificate is generated. In addition, attribute certificates have to be stored in the card during personalisation and cannot be changed during the useful life of the card. If a party is permitted to read the attribute certificate, all of the attributes stored are disclosed at once and can also be used, even outside the card.
   For the reasons mentioned, attributes are nowadays typically provided by the card itself. They are either signed by the card or provided via an authenticated channel. An attribute that is protected in such a way can be referred to as a credential because its originality and authenticity can be proven. Credentials created in this manner only include necessary attributes of the card holder explicitly permitted by the card holder. An elaborate way to handle attributes and to restrict permission to them has been implemented in the German ID card, using dedicated rights management. Each attribute can only be read out by a service provider who has been given the explicit consent of the holder and with dedicated permission issued by a federal CA. The service provider has to apply for this permission, which comes in the form of a card‑verifiable certificate which the service provider uses to authenticate itself.
   It is clear that credentials signed by the card are more secure than those provided merely via an authenticated channel. The section below explains how these credentials work and how new attributes are created during the validity period of the document.
How an attribute is assigned to a smart card
Even if an attribute is provided by a smart card it is, of course, independent from the card. It is therefore possible for one service provider to hand over an attribute to another service provider. If an attribute is signed, the receiver can be certain that the content is correct. If there is no digital signature, the receiving service provider has to trust the source of the attribute and the communication channel.

Figure 1
The ERA protocol starts with a message exchange between the card and the service provider (1). During execution, the service provider loses its session context to the attribute provider (2) and receives it back again (3), while the chip keeps its session context all the time.

However, handling attributes independent of the card is not often the option of choice because it means that the card user has to surrender control over a piece of personal information. Modern attribute management is therefore organised in a user‑centric manner. It is based on processes in which attributes are provided by the card itself. Although this approach is more complex than the concept of freely floating attributes, it does provide greater data protection.
   While an attribute can be integrated into a smart card during production, the full potential of this technology can only be exploited if an existing card can be equipped with an attribute. A special process is required in order to achieve this and it must ensure that only a trusted attribute provider may write an attribute onto a card chip. An attribute provider is typically commissioned by a service provider, such as an e‑government portal or an online shop. In order to achieve user‑centric attribute management, it usually makes sense to separate service providers from attribute providers and additionally to make them mutually invisible.

The Enhanced Role Authentication protocol
The Enhanced Role Authentication (ERA) protocol has been designed to support such a process. ERA is a three‑party protocol that is used between a smart card (controlled by its holder and smart card middleware), a service provider and an attribute provider. This protocol generally combines a user‑centred approach with no direction connection between the service provider and attribute provider. The entire process is executed in one single sequence. The protocol starts with a message exchange between the chip and the service provider. During execution, the service provider loses its session context to the attribute provider and gets it back again, while the chip keeps its session context all the time.
   The ERA protocol comprises several steps. It starts when the chip holder contacts a service provider, such as an online store or the online portal of a government agency, to obtain a specific service. The service provider will only provide its service if the chip holder provides certain attributes in an authenticated way. If, for instance, one attribute is required and is not yet stored on the user’s e‑ID chip, the service provider will send an attribute reading request to the chip holder. The chip holder will check the request and send his consent to the service provider. Using terminal authentication, the service provider will then authenticate itself to the chip. The chip uses chip authentication to authenticate itself to the service provider. A secure connection is now established between the chip and the service provider. In the next step, the service provider attempts to read out the attribute. If the attribute is already available on the chip, the connection will be terminated and the holder can use the requested service.
   If the attribute is not available on the chip, the service provider will store an attribute request on the chip. This request contains all the necessary information about the missing attribute. The service provider will put its session with the chip on hold. The user will now contact a suitable attribute provider. The chip stores the entire context for later use in the session with the service provider. The attribute provider now authenticates itself to the chip using terminal authentication. The chip authenticates itself to the attribute provider using chip authentication. This once again establishes a secure channel, however, between the chip and the attribute provider. The attribute provider now has its own session with the chip. The attribute provider reads out the attribute request from the chip and generates the requested attribute for the holder which it then stores on the chip, and subsequently deletes the request. The chip now restores the session context for the service provider which continues the session and reads out the recently stored attributes from the document with its already authenticated rights. Provided with all necessary data, the service provider drops the connection to the chip and delivers the service requested to the holder.

Figure 2. The German identity card.

Attributes with pseudonymous signatures
The use of domain‑specific pseudonymous signatures for signing attributes (i.e. for transforming them into credentials) is an interesting concept. This kind of signature is linked to a pseudonym, which in this case is a public key that is used by a large number of ID cards and is issued by the card issuer. It is possible to verify that a certain signature can only have been created by the pseudonym owner (authenticity), while the pseudonym owner cannot deny the signature (non‑repudiation). It is obvious that the properties of domain‑specific pseudonymous signatures make them suitable for attributes. If a card signs an attribute this way, a credential is created that is connected to a certain pseudonym.   There are interesting applications for attributes signed with domain-specific pseudonymous signatures. A medical practitioner, for instance, can use the same smart card with different pseudonyms to prove his medical affiliation and his permission to drive a car. It is not possible to establish a connection between different pseudonyms.
   There are plans to include domain‑specific pseudonymous signatures on the German identity card2. However, it is still unclear how this technology will be applied. Potential applications have been discussed but no detailed plans exist as yet.

Conclusion and outlook
While authenticated attributes are an old concept in security technology, known mainly from the X.509 standard, applying them on smart cards is still a new concept. There are some interesting applications, but it is not yet clear which ones will be attractive enough to be implemented. The advantages of credentials clearly lie in the areas of data protection and informational self‑determination, topics that are discussed quite differently in different countries. Generally speaking, the more important information technology becomes in daily life, the more important data protection and informational self‑determination will become. It remains to be seen whether efforts in this field will be strong enough to achieve a breakthrough. It goes without saying that additional research is needed in the field of attributes and credentials, which is what the authors hope to stimulate with this article.

References
1 Schmeh, K. (2013), Kryptografie Verfahren, Protokolle, Infrastrukturen, Dpunkt‑Verlag, Heidelberg.
2 Bender, J., Dagdelen, Ö., Fischlin, M., Kügler, D. (2012), Domain‑Specific Pseudonymous Signatures for the German Identity Card. Information Security Lecture Notes in Computer Science Vol. 7483, pp 104‑119.