Blogs

A great spirit of collaboration among the participants at the workshop on principles and guidance for eID interoperability for online platforms!

  • Marina Kirova profile
    Marina Kirova
    25 April 2017 - updated 4 years ago
  • 2 comments
    Total votes: 7

A big thank you to all participants in yesterday's Workshop "Towards principles and guidance for eID interoperability for online platforms" for making it such an enjoyable and productive event. We greatly appreciated the active involvement, the insightful contributions and fantastic collaboration of everyone throughout the day, and especially during the participative sessions. We collected lots of valuable ideas and will be reporting on them soon. Meanwhile, we wanted to share some moments and give you a flavour of the spirit of the day.

 

 

Tags: 
eIDonline platforms

Comments

Log in to post comments
Denis PINKAS's picture
Denis PINKAS,
02/05/2017 17:03

Two of the four aims of the workshop were:

•    Hear the views of key stakeholders on which challenges may need to be addressed.

•    Collect ideas for a set of principles for eID interoperability as well as on the process to further elaborate and jointly agree on them.

Unfortunately, these two aims have not been reached, since during this full-day workshop, the organising team didn't allowed to mention any challenge, nor to collect any idea for a set of principles for eID interoperability.

Since an email has been sent on April, Friday 28 by the organising team of the workshop welcoming suggestions and ideas "on the topic which you may share by posting in the eIDAS Observatory", this post is sent to address topics related to these two aims.

Which challenges may need to be addressed

I have identified four challenges:

1.    identify the "privacy by design" principles that may/should be supported.

2.    prevent “inside-country nodes” and “inter-country nodes” (if any) to be able to act as "Big Brother".

3.    establish an interoperability framework that allows countries that are not part of the EU to take advantage of the interoperability framework.

4.    minimize the number of “nodes” or “translation protocols” required by the Commission Implementing Regulation 2015/1501, and get rid of them, when possible.

 

1. The requirement for "privacy by design" is coming from the eIDAS Regulation itself (Article 12):  "the interoperability framework shall facilitate the implementation of the principle of privacy by design".

A model needs to be defined. It should contain at least three major components: a client, a server and an Attribute Issuer (on-line or off-line).Four main privacy principles may be identified for this model :

– Unlinkability: to prevent the linkability of transactions of a user among different servers.

– Data minimization: to minimize the amount of attributes being disclosed by a user to the minimum necessary to achieve a stated purpose,

– User Consent: to enable users to agree to consent for the communication of their attributes through an affirmative process, and

– Untraceability: to prevent an Attribute Issuer to know to which server issued attributes will be presented by a client.

It is important to notice this set of principles is not coming from the GDPR (General Data Protection Regulation) which takes care about the duties of the data controllers, ... but does not care about the user's needs. This means that simply following the GDPR principles would be insufficient.

·    In order to prevent the linkability of transactions of a user among different servers and to minimize the amount of attributes being disclosed by a user to the minimum necessary to achieve a stated purpose, that minimum set should be "no attribute at all" and hence pseudonyms specific to every target server should be used.

Unlinkability is antagonist to the Annex from the Commission Implementing Regulation 2015/1501, since the use of pseudonyms is not permitted. Currently, not only the interoperability framework does not "facilitate" the principle of privacy by design, but excludes it.

Note 1: FIDO (First IDentity On-line) is an architecture that is conformant to this requirement.

Note 2 : the German eIDcard supports pseudonyms, but at least allows to know that the user is using a German eID card, while it is not the case for FIDO.

•    The user (and no one else) shall decide which attributes will be presented for a given access through an affirmative process. The decision should not be global to the service but related to each access.

Note :     the German eID scheme mandates the issuance of a CV certificate (Card Verifiable certificate) by a department of the German government for every server established in a Member State. It is unclear whether the user has the possibility to reduce the set of attributes that is permitted in the CV certificate.

•    When an on-line Attribute Issuer is being used, the Attribute Issuer should not be able to know to which Service Provider an access token will be presented by a user (otherwise it would be able to act as Big Brother). Nevertheless when access tokens are used, they should always be targeted to one (or more) service provider(s).

2. The untraceability property applies both to “inside-country nodes”, i.e. "on-line" Attribute Issuers, and to “inter-country nodes” which may need to translate one protocol into another (when/if this is technically possible). These nodes shall not be able to know which are the service providers a given user will connect to. This is of particular importance, when/if the scheme is/will be expanded to the private sector.

The goal is not to consider that the nodes should not act as Big Brother, when they are in a position to do so, but to consider that the nodes cannot act (by design) as Big Brother, even when they would like to do so. This makes a big difference.

3. The interoperability framework that does not care about countries that are not part of the EU (or will not be part any more of the EU). It currently mandates the existence of nodes between EU Members States, as required in Article 5.1 of the Commission Implementing Regulation 2015/1501 : "A node in one Member State shall be able to connect with nodes of other Member States".

4. In order to achieve a world-wide interoperability, inter-country nodes should be eliminated. This implies the use of direct trust relationships.

A Russian contribution made on 30 January 2017 for the fifty-fifth session of the UNCITRAL (United Nations Commission on International Trade Law) which took place in New York from April the 24 th to April 28 th, 2017 states in particular:

"On the basis of interaction between a State and other States or international alliances:

–    In the first phase, a State creates an isolated national e-commerce TTE cluster operating under a national legal regime determined by that State;

–    In the second phase, the protocols for trusted interaction with other States and/or international alliances are defined in relation to the mutual recognition of different legal regimes.“

 

The Russian contribution may be interpreted in the following way : A Service Provider established in a State would need to support :

-    whatever kind of protocol(s) is being used within the State, and

-    other protocols to be used for relationships with other States.

This means that a standardization process should have been initiated from the very beginning to support relationships with other States in order to avoid the need to support nodes. This implies one standardization process to define the structure and the semantics of access tokens and another one to define the protocols to transmit them.

This would avoid each MS, to develop, support and maintain (in the worse case) 26 protocols (702 protocols altogether) according to the Commission Implementing Regulation 2015/1501.

Interestingly on 20/02/2017, Germany initiated the notification procedure of the German eID contained on the German ID card and the electronic residence permit according to Article 9 of eIDAS Regulation.

Due to the nature of the German eID scheme without any node, the German eID scheme will be supported via a middleware integration model. However, strictly speaking, such an integration is not compliant with Article 5.1 of the Commission Implementing Regulation 2015/1501. This does not mean that the German eID scheme should be ruled out, but that the Commission Implementing Regulation 2015/1501 should be modified to be able to integrate the German eID scheme.

Basically, the German eID scheme mandates the installation of a specific piece of middleware on every Service Provider from any Member State. It is as if the service provider will be able to directly understand the German language without using any translation node.

If every Member State was making the same approach, the benefit would be that "only" 27 pieces of software would need to be integrated on every Service Provider, which is already much better than the support of 702 translation protocols between the nodes of the 27 Member States.

However, this number could be lowered by using an access token based approach.

Set of principles for eID interoperability and the process to further elaborate and jointly agree on them

•    Truly allow to support “privacy by design” eID schemes and hence allow such eID schemes to be worldwide scalable for both the private sector and the public sector.

•    Allow a comparison of the eID schemes according to the privacy principles they support (or they don’t support).

•    Go beyond identity: support attributes, like “graduated from University X with a Master of Science”. This means that Attribute Issuers will not necessarily be governments, but could also be banks, Universities, Schools, Golf-Clubs, etc ... and hence the goal would be to allow eID schemes supporting a continuous range of identification options using access tokens that will not be restricted to the EU, nor to relationships with government administrations.

A technical goal should be to establish a technical working group opened to all ”interested parties” (i.e. not restricted to officials from Member States) to deal with the technical issues identified here above.

A legislative goal should be to prepare a revision of the Commission Implementing Regulation 2015/1501 :

-    to address the German eID interoperability case, and

-    to make sure that the interoperability framework truly facilitates the implementation of the principle of privacy by design (as mandated by Article 12 from the eIDAS Regulation).

It is unfortunate that a discussion around these topics has not been able to take place during the workshop.

Denis PINKAS

President of DP Security Consulting SAS. France.

Total votes: 4
Nathalie LAUNAY's picture
Nathalie LAUNAY,
19/05/2017 09:00

Thanks Denis for your very clear vision.

I have already warned in the past DG connect about the absolute need to review eIDAS regarding GDPR and at least to consider this topic within the observatory group. Recently I have also try to underline this issue once again  while

-  commenting the ENISA recent guidelines that need to be updated regarding GDPR compliancy

- and during the last eiDAS market study/validation workshop organized by DG CONNECT/PwC, I have emphasize about absolute requirement of a privacy impact assessment before any new or update of any eID scheme in Europe. By the Way, a PIA will involve to consider Privacy by design and Privacy by default solutions.

I will be pleased to share with you further.

Nathalie LAUNAY

 

 

 

Total votes: 3