You are here: Resources > FIDIS Deliverables > Interoperability > D4.1: Structured account of approaches on interoperability > 
Identification and authentication in G2C digital interactions  Foreword
 Case study: eID projects, from capability to use


Use of credentials systems in e-commerce

Michaël Vanfleteren and Els Kindt, K.U.Leuven R&D 



The wider use of on-line credential and authentication services is emerging and changing the Internet landscape. Indeed, more and more websites require visitors to submit credentials or to identify themselves, sometimes through a secure authentication mechanism.  Such a mechanism is aimed at ensuring the integrity of certain electronic transactions, especially those involving on-line payments.


A credential system in the widest sense could be described as a system whereby information is submitted that attests to the truth of certain stated facts, e.g., the identity of a given person.  Such a system could be a mechanism in which users can obtain credentials from internal or external organisations and demonstrate possession of these credentials in order to have access to particular applications, services or sites. This development inevitably raises a number of legal issues which must be addressed, including issues relating to data protection. This section will focus on the restrictions imposed upon credential systems by the data protection legislation.  Most credential systems will indeed contain directly or indirectly a link to an identifiable individual and, in this respect, raise privacy concerns. For credential systems to be interoperable, these concerns must be dealt with and are likely to be a condition for its legality.


As an example of a credential system, the NET.Passport of Microsoft represents a good starting point. Microsoft .NET Passport was an Internet user-identity—management system that let Internet users use just one login name and password to sign in, access Web services, and shop on-line at all participating Web sites. Users could control what personal information they wanted to register in their accounts and what personal information they wanted to release to the Web sites that they visit. In addition to .NET Passport sign-in, the .NET Passport Service also included .NET Passport wallet and .NET Passport express purchase. the Article 29 Working Party released an opinion on on-line authentication services and especially analysed the .NET Passport system provided by Microsoft, asking it to comply with the EU data protection legislation

Since then, the Redmond’s multinational made important changes in order to ensure the compliance of the .NET Passport system with the European Data Protection Directive. 


At the same time, Microsoft is currently developing an Identity Metasystem. The Identity Metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers.


Only so-called anonymous credential systems raise no privacy concerns.  Anonymous credential systems may allow anonymous yet authenticated and accountable transactions between users and service providers. Such systems are anonymous  in the sense that transactions carried out by the same user cannot be linked. An anonymous credential system is of significant practical relevance because it is the best means of providing privacy for users .  As such, these systems represent a powerful technique for protecting users’ privacy when conducting Internet transactions. However, most credential systems do not use such anonymizing tools, and as a result such credential systems will have to comply with the existing legal framework for data protection.



Legal & Regulatory Framework 


The right to privacy is considered a core value of a democratic society. It is recognised as a fundamental right in all major international treaties and agreements on human rights and in the constitutions of most countries in the world, either explicitly or implicitly. 


In Europe, the fundamental right to respect for privacy is recognised in, among other texts, Article 8 of the European Convention of Human Rights and Fundamental Freedoms.  It states that everyone has the right to respect for his/her private and family life, his/her home and his/her correspondence.


The major relevant specific acts of European legislation are the Data Protection Directive 95/46 and the Directive 2002/58 on electronic communications. Directive 95/46 of 24 October 1995 aims at promoting the free movement of personal data within the European Union, while preserving the right to privacy (hereinafter the Directive 95/46/EC). Directive 2002/58/EC complements the principles of the Directive 95/46/EC in terms of specific rules for the electronic communications sector. Its provisions apply to the processing of personal data in connection with the provision of publicly available electronic communications services in public communication networks in the Community. 



Relevant data processing principles applicable to credential systems  


Several data protection principles must be respected when implementing credential systems. These principles are mentioned in the European Directives, and prior to these Directives, in the OECD Guidelines of 1980. 



Finality and proportionality  

One of the basic principles of data protection is embedded in article 6 of Directive 95/46/EC. It states that personal data must be collected for specified, explicit and legitimate purposes and may not be further processed in a way incompatible with those purposes (finality principle, also sometimes referred to as use limitation principle). In addition, the data should be adequate, relevant and not excessive in relation to the purposes for which they are collected and further processed (the proportionality principle).


The purpose(s) of the processing of personal data in a credential system should thus be defined at the moment of the collection and any further processing should not be incompatible with the purpose(s) initially defined.  


When setting up interoperable credential systems, one should hence first determine the purpose(s) and the way the system will function. In particular, one must decide whether the system will be used to authenticate, identify or verify someone’s identity, and hence which data are relevant and proportional to these purposes.  


In addition, all other functional requirements of the credential system and ID-concept shall be clearly defined, for example, whether the system would also be used to conclude contracts. The answer will not only determine which the relevant data are, but also which other legal rules have to be complied with.  





Fair and lawful processing 


Article 6 of the Directive 95/46/EC lists several other important principles relating to data quality. Firstly, any processing of personal data should be carried out in a fair and lawful way with respect to the data subjects (principle of fair and lawful processing). Further, data should be accurate and, where necessary, kept up to date. The last principle refers to the duration of storage of data and sets out that data may not be kept in a form permitting identification of data subjects for longer than is necessary for the purposes for which the data were collected or for which they are further processed. 



‘Owner’ versus ‘operator’ of the credential system 


Most obligations under the data protection legislation are imposed upon the so-called ‘controller’.  Article 2 (d) of the Directive 95/46/EC defines the ‘controller’ as the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined by national or Community laws or regulations, the controller or the specific criteria for his nomination may be designated by national or Community law.  


Given that legal consequences are attached to the failure to respect these obligations, it is therefore of utmost importance to know precisely who is considered controller or owner of the data.  


The function of controller or ‘owner’ is to be distinguished from the one of processor or ‘operator’ of the data processing.  Article 2 (e) of the Directive 95/46/EC states that  ‘processor’ shall mean a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller. Therefore, the relationship shall be confirmed in a written agreement between controller and processor.  


Indeed, the two functions may not always be very clear.  For example, in a public-private partnership and therefore the designations may need attention. Both those who design and those who actually implement on-line authentication systems (authentication providers) bear distinct responsibility for the data protection aspects, although at different levels, and therefore it is advisable for the different players to have between them clear contractual agreements in which the obligations of each party are made explicit.



Legitimate processing. 


The Directive explicitly lists in article 7 the cases in which personal data may be processed. This means that for each processing of personal data – collection, recording, storage, adaptation, alteration, retrieval, consultation, disclosure, dissemination, etc. – the controller has to verify if the processing falls under one of the criteria for making data processing legitimate. 


The first case in which processing of personal data can be considered legitimate is when the data subject has unambiguously given her consent.


For credential systems, it is of particular relevance that the value and quality of the consent given by the users of these systems complies with the legal requirements.  

The processing is equally legitimate when it is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject for entering into a contract. In the third case, the processing is authorised when it is necessary for compliance with a legal obligation to which the controller is subject. For example, a person is obliged to communicate some personal data concerning the persons living with him to the unemployment agency in order to obtain a benefit. In the fourth case, processing of personal data is legitimate when necessary to protect the vital interest of the data subject. The processing is also authorised when it is necessary for the performance of a task carried out in the public interest pursued by the controller or by a third party or parties to whom the data are disclosed. Finally, processing personal data is legitimate when it is necessary for purposes of the legitimate interests pursued by the controller or by a third party or parties to whom the data are disclosed, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.  



Data minimisation principle 

The processing of personal data should be limited to data that are adequate, relevant and not excessive (the principle of data minimization) (Article 6(1) c of the Directive 95/46/EC). This idea is further expanded by adding that data should only be kept in a form that permits identification of the data subject for no longer than is necessary for the purposes for which the data were collected or for which they are further processed. As a consequence, technical tools and Privacy Enhancing Technologies in particular, should be available to contribute to the effective implementation of these requirements. 


Citizens need an identity to distinguish themselves from others and to benefit from a whole range of public services, such as e.g. health and other social services, or to fulfil certain obligations, e.g. taxation. Citizens are using their identity as ‘evidence’ for specific competences, roles, capacities, authorizations, rights, access to services. However, although a basic data protection principle states that personal data should only be processed where necessary, people use their ‘real’ identity in most cases. This use is often neither necessary nor desirable from a privacy perspective. In parallel with physical identity, the concept of ‘digital identity’ has indeed emerged as a whole set of digitized personal data (PINs, accounts, multiple user names, passwords, tokens, smart cards) and individuals can also perform different roles and accordingly adopt multiple virtual identities. Hence, each system shall determine whether the personal data collected are relevant and not excessive.





Any collection of personal data implies prior supply of certain information to the individual concerned (Article 10 of the Directive 95/46/EC).  


The person whose data is collected must at least be provided with information about the identity of the controller (which includes the name as well as the physical and electronic address) and the intended purpose(s) of the processing. 


Therefore, it is vital to credential systems to provide adequate information to the users concerning the data protection implications of the system. This information should be provided in an easily accessible and user-friendly way. 





Article 17 of the Directive requires that controllers implement security measures which are appropriate to the risks presented for personal data in storage or transmission, with a view to protecting personal data against accidental loss, alteration, unauthorised access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing. 


Credential systems shall provide the required security.  The level of security will differ from the application of the system.  A personalised financial service site clearly requires a higher level of security than a general retail site.





Another important obligation of data controllers is the requirement in principle to notify the respective national data protection authority before any data processing operation is carried out, unless any exceptions or exemptions apply (Article 10 of Directive 95/46/EC). 



Use of Globally Unique Identifier (GUID)? 


Article 8.7 of the Directive 95/46 states that “Member States shall determine the conditions under which a national identification number or any other identifier of general application may be processed.”  


The use of one single identification number for accessing and using services could result in an important simplification both for citizens and administrations. However, the use of identifiers, whatever form they take, entails data protection risks as already analysed by the Art. 29 Working Party in its opinion on the use of unique identifiers. Full consideration should be given to all possible alternatives. If user identifiers are indispensable, the possibility of allowing the user to refresh the identifier should be considered. Security plays a fundamental role in this context.  The question will be how to incorporate guarantees from a data protection perspective.



National applicable law? 


In the Data Protection Directive, article 4 provides that the processing of personal data is subject to the national law of the activity of an establishment of the controller. 


Therefore, the national data protection law where the controller(s) is/are established, will apply to the processing of personal data by a particular ID - concept.  The place of the establishment of the processors will in principle not determine which law is applicable.  However, the rules on the transfer of data will have to be complied with.



Transfer of data 


The transfer of personal data may take place within the Member States of the European Union or in relation to third countries. The data protection Directive allows the transfers of personal data within the Member States of the European Union in principle. However, Member States shall only allow a transfer to third country if the third country in question ensures an adequate level of protection (article 25, paragraph (1) of the Directive 95/46/EC). The second paragraph explains that ‘adequacy’ should be assessed on a case-by-case basis ‘in the light of all the circumstances surrounding a data transfer operation or set of data transfer operations’. Where there is an absence of adequate protection, the Directive also envisages the possibility of ad hoc measures, notably of a contractual nature, which could result in the establishment of adequate safeguards on the basis of which the transfer in question could proceed (Article 26(2) of the Directive 95/46/EC). So far, the European Commission has issued decisions on the adequacy of the data protection on some third countries, including Argentina, Canada, Switzerland and the United States.


When personal data are to be transferred to third countries, authentication providers should work with service providers who take all necessary measures to provide adequate data protection or that it put in place sufficient safeguards to ensure the protection of the personal data of the users of the system, by using contracts or binding corporate rules. 





The Directive 95/46/EC states that any person who has suffered damage as a result of an unlawful processing operation or of any act incompatible with the national data protection legislation is entitled to compensation from the controller for the damage suffered (Article 23).  The controller may be exempted from liability, in whole or in part, if he proves that he is not responsible for the event giving rise to the damage.  


It is clear that this provision may be applicable to credential systems.  However, it seems unclear whether the credential system providers could be exempted from any other liability under the general liability system for electronic commerce.  




In conclusion, there are several rules, not only about electronic commerce but also about data protection which must be respected in order to assess the validity of an identification/authentication system. In this section we have focused at the formal level of the TFI model presented in section 4. This overview is only a first step in the legal analysis of the interoperability of credential systems. 


Identification and authentication in G2C digital interactions  fidis-wp4-del4.1.account_interoperability_02.sxw  Case study: eID projects, from capability to use
9 / 15