STORK 2.0 Overview For Member States

COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME
ICT PSP Fifth Call for proposals 2011 - Pilot Type A

Towards a single European electronic identification and authentication area
ICT PSP call identifier: CIP-ICT-PSP-2011-5
ICT PSP Theme/objective identifier: 4.2
Project acronym: STORK 2.0
Project full title: Secure idenTity acrOss boRders linKed 2.0
Grant agreement no.: 297263
STORK 2.0 Overview for new MS

Deliverable Id :
Deliverable Name :
Status :
Dissemination Level :
Due date of deliverable :
D4.15
Commercially Packaged Software
Final
PU
September 30th, 2015
Actual submission date :
October 21st , 2015
Work Package :
Organization name of lead contractor for
this deliverable :
Author(s):
Partner(s) contributing :
WP4
MINHAP
WP4 core team
ALL
Abstract: This document presents an overview of STORK 2.0 for new MS, in order to allow them to get
acquainted quickly with the history of STORK, the reasons for connecting, its architecture and
procedures. It ends with a cookbook which explains the steps to establish yourself as a STORK 2.0
enabled MS and a readers suggestion for full information.
Project co-funded by the European Community under the ICT Policy Support Programme
Copyright by the STORK 2.0 Consortium
STORK 2.0 Overview for new Member States
History
Version
Date
Modification reason
15/07/2011
A STORK overview for new

MS is used as a template
0.1
28/08/2015
Update for STORK 2.0
John Heppe
0.2
10/10/2015
Quality check
ATOS
0.3
15/10/2015
Inclusion of comments from

John Heppe
quality check by editor
0.4
15/10/2015
Final Quality check
Final
21/10/2015
Final deliverable
0.0
Modified by
ATOS
2|Page
Table of contents
History............................................................................................................................. 2
Table of contents ............................................................................................................. 3
List of figures ................................................................................................................... 5
List of tables .................................................................................................................... 6
List of abbreviations ......................................................................................................... 7
1
Introduction ............................................................................................................. 8
History ..................................................................................................................... 9
2.1 Cross border use of eID .................................................................................................. 9
2.2 STORK architectures ....................................................................................................... 9
2.3 Variety of eIDs and their quality................................................................................... 10
Why establishing oneself as a STORK 2.0 enabled MS? ............................................ 12

3.1 STORK 2.0 or eIDAS ...................................................................................................... 12
3.2 STORK 2.0 or STORK ..................................................................................................... 13
3.3 STORK 2.0 or Kantara Initiative .................................................................................... 13
The Interoperability model ..................................................................................... 14

4.1 PEPS structure .............................................................................................................. 14
4.2 V-IDP structure ............................................................................................................. 15
4.3 PEPS or MW: Centralized or Decentralized Deployment ............................................. 16
4.4 Systems in the STORK platform .................................................................................... 17
4.5 Communication structure ............................................................................................ 17
4.6 Authentication and registration ................................................................................... 18
4.7 Certificate Validation .................................................................................................... 19
4.8 Circles of Trust .............................................................................................................. 19
4.9 User control and Consent ............................................................................................. 19
4.10
Attribute provisioning .............................................................................................. 20
4.11
Legal persons and mandates.................................................................................... 20
Governance ............................................................................................................ 21
5.1 Billing and pricing ......................................................................................................... 21
5.2 Support ......................................................................................................................... 21
5.3 Change control ............................................................................................................. 22
5.4 Version control ............................................................................................................. 22
5.5 Relationship with your national service providers ....................................................... 23
5.6 Testing and Going Live.................................................................................................. 24
The How to connect to STORK Cookbook ............................................................. 25

3|Page
6.1 Basic functionality ........................................................................................................ 25

6.1.1
Getting national credentials accepted ..................................................................... 25
6.1.2
Allowing my services to obtain foreign credentials ................................................. 25
6.1.3
Connecting my service ............................................................................................. 26
6.2 Advanced functionalities .............................................................................................. 26

6.2.1
Connecting attribute providers ................................................................................ 26
6.2.2
Supporting signatures .............................................................................................. 27
6.2.3
Version control ......................................................................................................... 27
6.2.4
Anonymity ................................................................................................................ 27
6.3 Estimated timeline ....................................................................................................... 27

7
What documents to read ........................................................................................ 30
References ............................................................................................................. 33
4|Page
List of figures
Figure 1 PEPS and its interfaces ..................................................................................... 14
Figure 2 Two PEPSes communicating ............................................................................. 14
Figure 3 PEPS interfaces which may be personalised....................................................... 15
Figure 4 V-IDP internal structure .................................................................................... 15
Figure 5 V-IDP Communicates with a PEPS ..................................................................... 15
Figure 6 PEPSes and V-IDPs in Europe............................................................................. 17
Figure 7 PEPS-PEPS communication structure ................................................................ 18
Figure 8 PEPS-V-IDP communication structure ............................................................... 18
Figure 9 Estimated Gantt chart ...................................................................................... 28
5|Page
List of tables
Table 1 : STORK vs eIDAS evaluation ................................................................................. 13
Table 2: PEPS vs MW evaluation ....................................................................................... 17
Table 3: Documents to read .............................................................................................. 32
6|Page
List of abbreviations
AP
Attribute Provider
A-PEPS
Attribute PEPS (PEPS role for attribute collection in foreign countries)
AQAA
Attribute QAA, quality of attribute(s)
AUB
Authentication on behalf of
C-PEPS
Citizen PEPS
CRL
Certificate Revocation List
CSR
Create Signature Request
eID
Electronic Identity
EU
European Union
IDP
Identity Provider
LSP
Large Scale Pilot
MS
STORK 2.0 Member State
MW
MiddleWare
OASIS DSS
OASIS Digital Signature Services
OCSP
Online Certificate Status Protocol
PAdES
PDF Advanced Electronic Signatures
PEPPOL
Pan-European Public Procurement Online
PEPS
Pan European Proxy Server
PKI
Public Key Infrastructure
QAA
Quality Authentication Assurance
SAML
Security Assertion Markup Language
SP
Service Provider
S-PEPS
The PEPS role to attend SP requests
STORK 2.0
Secure idenTity acrOss boRders linKed 2.0
VCF
Version Control File
V-IDP
Virtual Identity Provider, the system of the MW architecture
XAdES
XML Advanced Electronic Signatures
7|Page
Introduction
This document presents an overview of STORK 2.0 for new Member States which consider or
have decided to connect to the STORK 2.0 platform. Its objective is presenting a quick view of
what STORK 2.0 is and how it works, thus those countries may avoid reading the complete
documentation. For complete information, these documents are still relevant and valid, but a
quick overview is considered a welcome complement.
The STORK 2.0 overview is meant for new Member States, therefore it focuses on what
STORK 2.0 is, its internal structure, integration of national specific functionalities, etc., as well
as agreed procedures for governance, update and maintenance.
It does not contain technical or very detailed information; it is not meant as a reference
manual.
This document presents a brief history of STORK, the structure of the platform and
collaboration and communication mechanisms. Finally it includes the cookbook with the
recipes to establish yourself as a STORK connected MS and a recommendation of most
important documents.
8|Page
History
Since decades, the different EU Member States have invested large amounts of money in
building their own identity systems, often including citizen cards. Modernisation of those
physical credentials led to the inclusion of electronic identity in those tokens.
In some other Member States also businesses, especially banks, have also invested in building
electronic identification system based on strong authentication means, especially PKI.
Such electronic identity systems were frequently of little use: there were few applications
which allowed people to use their credentials to access their own information. But, as time
passed by, the number of applications increased constantly, especially since the EU published
its services directive and its implementations in the different Member States.
2.1 Cross border use of eID

Acceptance of national credentials was increasing but still, cross border usage was even
harder. Not knowing about legal implications, nor knowing about trusted eID providers, nor
about internal formats of the different credentials made it in practice impossible to accept
any foreign credential. As this was recognised during the Ministerial eGovernment
Conference Transforming Public Services of the United Kingdom Presidency of the
European Council and of the European Commission, in Manchester 2005, they established
this as one of the priorities in the initiative i2010: A European society for growth and
employment in Europe. In 2008 a consortium of 29 participants of 14 European countries was
founded, to execute the STORK project 1. The project had as main objective to establish a
European eID interoperability platform, within existing legal restrictions, respectful with all
national cultures and complying with the requirements of scalability, trust and security,
especially the privacy. This platform was to be piloted during 12 months. There was a clear
focus on achieving interoperability on a technical level as each MS has individual legal
frameworks for using own and possibly foreign electronic identities.
The eIDAS regulation forms a new boost of the cross-border usage of electronic identity.
In April 2012 the STORK 2.0 project was started by 58 participants of 19 European countries,
in order to extend the STORK results to legal persons, especially SMEs as customers of
eServices. Additionally the scope was extended to the private sector, starting with banks, as
identity consumers.
2.2 STORK architectures

Following development of interoperability models in the eEurope
eID subgroup which led to signposts and a roadmap, this
objective had been further developed and studied by a working
group of the EC, IDABC. A model that has been recommended by
IDABC has been the establishment of national gateways, which it
called PEPS: Pan European Proxy Service. The main objectives of
these gateways were 1) to hide national problems for the other
Member States, and 2) to be an anchor of trust, which allows leveraging the national circle of
trust to Europe. Furthermore, this gateway guarantees scalability, as any change in a Member
State will only affect its own gateway.
1 STORK project https://www.eid-stork.eu/
9|Page
Some countries saw serious problems in such a gateway, legal, liability and security problems,
as well as compatibility problems with their decentralised national Middleware 2 architecture.
Basically this decentralised architecture implies that each Service Provider has a software
installed (sometimes referred to as SPware), which interacts with the users credential
through some middleware installed at the users PC.
A direct communication between SP and the user directly using MS-specific SPwares is for
several reasons not scalable and a problem for trust in a cross border scenario: first of all, you
cant expect all European service providers to support an increasing number of interfaces to
SPwares from each country, with all corresponding maintenance consequences. In the second
place, you can not really expect thousands of Service Providers to update their trusted
(ID)servers list every time a new ID provider is recognised in any of these MW countries, and
including them in the ways to verify the validity of the presented credentials.
So an abstraction layer was put above the SPwares enabling the SP to support any number of
SPwares using a unified interface and put into a single component, which is called a Virtual
IDP, or V-IDP. This V-IDP has the same objectives as a PEPS: to hide the national problems for
the other Member States, and to be an anchor of trust which allows to leverage the national
circle of trust to the Europe. The main difference is the location: it is supposed to be located
as close as possible to the SP, thus enabling true end-to-end communication between SP and
user, but also enabling usage of or location beside national gateways, depending on each
countrys decision.
As far as architectures are concerned the conceptual interoperability model is explained in
D5.1. This model explains how these 2 models can interoperate.
2.3 Variety of eIDs and their quality

As stated in the first paragraph, since decades governments need
to enable users to electronically access their administrations. So
each government has implemented some mechanisms to allow
such access; some with just the traditional username / password
scheme, others use this scheme, and have reinforced it with onetime-passwords generated by specific devices or sent to the
citizen by SMS. In most countries also PKI is used, in soft
certificates and most of all implementing these certificates in secure crypto-chips on the
citizen card.
Not only the identity tokens themselves vary, also the issuing procedures are different: some
of them can be achieved with a visit to an Internet site, in which the citizen is requested to
type some of his data, others require the citizen to visit a registration office before issuing his
credential.
Some countries only allow access with governmental eID, other also or even exclusively with
eIDs issued by private organisations, especially by banks.
It will be clear that so many different types of credentials are not equally trustworthy; the
authentication with some tokens is better than with other tokens. And as a consequence,
some should not be allowed in some portals as their quality of authentication assurance is
considered insufficient for the risks associated with the use of the application.
Please note that this is the name given to this approach. Client middleware is also required for e.g.
the access to crypto cards in PEPS countries.
10 | P a g e
Thus the STORK project has defined a QAA, Quality of Authentication Assurance, which on a
scale from 1-4 expresses this quality. This number takes all 7 underlying factors into account
in both the registration and issuing procedure as well as the quality of the credential itself.
In the STORK 2.0 project these QAA categories were found to be insufficient to cover
additional attributes, so this model has been extended with an Attribute-QAA, or AQAA.
11 | P a g e
Why establishing oneself as a STORK 2.0 enabled MS?
The trend in Europe is to have more Europe, more citizens having cross-border business,
work, holidays, etc. Along with this trend, governments should support cross-border
interactions with foreign European governments, to facilitate the management of required
procedures by the user from his home.
Another reason is to give more value to your credentials. The design and deployment of the
citizen card has been a big investment, and the more usage you can offer, the better the
return of the investment.
3.1 STORK 2.0 or eIDAS

STORK and eIDAS are very similar systems, using the same architecture, but there are some
important differences.
STORK
Legal support
eIDAS
No laws are in place to oblige The regulation obliges MS to accept

acceptance of credentials and EU credentials and a minimal set of
other personal data
data
Implementations STORK is operational in 19 No eIDAS node is operational yet.

countries, with some 100 portals However, is to be implemented by all
EU countries
Available data
A large set of attributes is A minimal set is defined, which may

defined and available in many be extended.
countries,
especially
about
academic data
Metadata and Metadata are exchanged through

an XML version control file. This
version control
also allows for automatic
propagation
of
renewed
certificates.
Metadata are exchanged according to

the SAML standard. No interpretation
of these data is available in the
common eIDAS code.
Also
alerts
to
systems
administrators are supported.
Legal
person Legal person information and Only direct mandates supported.
information
corresponding mandates are Retrieval of such information is not
implemented. The common code common code.
offers one standard solution for
the retrieval of such information.
Cross-border retrieval of this
information is supported.
Multiple cross Attributes can be retrieved from Only the citizens home country is
different countries.
border support
supported
Cross
border Cross border signatures on XML,
signatures
pdf and any other data (XadES,
PadES and CadES) is supported.
12 | P a g e
For any size documents a

document transport layer is
implemented
Other functions
Supports eIdentifier privacy, No other functions are supported

similarity of names and version
control for SPs
Maintenance
After the project finishes, the The code is being maintained by the
maintenance will be taken over EC General Directorate for IT (DIGIT)
by the eSENS project
Table 1 : STORK vs eIDAS evaluation
Please note that the communication protocol is very similar, but not compatible.
Although previous table would recommend you to adopt STORK 2.0 rather than eIDAS, due to
its better adoption and improved functionalities, it is also quite clear that the future number
of countries and the legal support of eIDAS will be an important factor.
In fact, a convergence is foreseen between these two. As a summary, STORK 2.0 is
recommended if you want a quick and complete solution without legal basis. A quick and
limited solution with a legal basis is the eIDAS one, available from autumn 2015. A complete
solution with legal basis will take some time.
3.2 STORK 2.0 or STORK

STORK 2.0 is an extension of the STORK project, including the support for legal persons and
extending the usage to the private sector. In fact STORK and STORK 2.0 are compatible,
except for signature format: in STORK the common hashing mechanism was SHA-1, and in
STORK 2.0 SHA-2 (256) is strongly recommended. And of course, extensions of STORK 2.0 are
not supported by STORK.
3.3 STORK 2.0 or Kantara Initiative

STORK 2.0 is an implemented standard platform for eID federation, in which all portals allow
the same set of ID providers, within the requirements of each portal. Governments guarantee
the quality of the provided credentials, and each portal relies on these mostly foreign
governments. Kantara Initiative is a standard, implemented at many sites. However, its set of
ID providers is heretogeneous, and the trust in these providers is explicit: the portal has to
know the IDP in order to rely on the quality of its credentials.
13 | P a g e
The Interoperability model
A PEPS connects its national eID infrastructure to foreign service providers, as well as its
national service providers to foreign eID infrastructure. To be able to use such eID
infrastructure, the user plays an important role; without her/his participation theres no way
to get data exchanged. Thus a PEPS has 4 interfaces, as made clear in the following diagram:
National eID interface
Service
Provider
Interface
PEPS
Colleague
interface
User
Interface
Figure 1 PEPS and its interfaces
This schema is used to explain briefly the conceptual interoperability model.
4.1 PEPS structure

When connecting a service provider to the STORK platform, this connection will be done
through his national STORK node. This node connects to each of the other national nodes of
the platform, which on their turn connect to the national eID infrastructure and national
users.
User
Interface
Colleague
interface
S-PEPS
C-PEPS
Service
Provider
Interface
Figure 2 Two PEPSes communicating
Thus one of the two PEPSes has the role of S-PEPS, attending requests from Service Providers,
in the SP country, the other one has the role of C-PEPS, taking care of the interface with the
citizen, in citizens country. This last role also assumes the interface with eID provisioning and
possible additional Attribute Providers.
Please note that, even though the redirection from SP to the C-PEPS goes twice through the
users browser and through the S-PEPS, these intermediate steps are transparent for the user.
These roles, S-PEPS and C-PEPS can also be seen within the structure of the PEPS software
and the connectors to be interrogated. Normally, in one cross-border transaction, a PEPS will
only assume one of these roles; only if SP country and citizen country are the same, this PEPS
would assume both roles. But this scenario is not cross-border, so outside STORKs scope, and
in some countries would not work.
14 | P a g e
Of course, the PEPS is designed to be adapted to whatever your country may need, so for
each of these interfaces standard examples are included, which may or should be
personalised or substituted by the software of your needs. In the diagram just below this text,
the Member State where the Service Provider is located may determine the specifications for
his SP interface, the citizens Member State will personalise the user interface (at least to
national language) as well as the interface with the national eID infrastructure.
User
Interface
Colleague
interface
S-PEPS
C-PEPS
Service
Provider
Interface

Figure 3 PEPS interfaces which may be personalised
STORK not only included the common software; it also included the integration and testing
tools. All these tools implement the common communication standard at national level, as a
consequence most countries have implemented this standard nationally.
4.2 V-IDP structure

Internally a V-IDP has a modular backbone, called MARS, which can be personalised with
plug ins and plug-ons.
S-PEPS
Modular Authentication Relay Service

AT
DE
C-PEPS
Figure 4 V-IDP internal structure
These pieces of software allow the system to behave like a C-PEPS or S-PEPS when
communicating with the rest of Europe, but also as an AT / DE service provider or eID
provider, depending on its usage. When communicating with PEPSes, exactly the same
protocol is used as the one used between PEPSes.
C-PEPS
S-PEPS
Modular Authentication Relay Service

AT
DE
C-PEPS
Figure 5 V-IDP Communicates with a PEPS
15 | P a g e
In Figure 5 a AT or DE service provider may request credentials from citizens of PEPS

countries. A similar scheme applies for PEPSes requesting credentials from AT or DE.
4.3 PEPS or MW: Centralized or Decentralized Deployment

As indicated in section 2.2, each country should have his PEPS located in his own installations,
except for the MW countries which have their V-IDP located in each of the other countries.
Additionally, in MW countries there may be several additional V-IDPs. When choosing on
PEPS or MW architecture, you will of course choose the most convenient one; for this reason
we have summarised the advantaged and disadvantages of each solution in the following
table:
PEPS
MW
Scalability:
We may foresee the need for Fully Scalable.
more
users, cryptographic hardware (HSM) in
more
the PEPS
transactions
Scalability:
IDPs: Inclusion in the circle of IDPs: Inclusion in the circle of trust of

its countrys SPWare in all VIDPs
trust of its countrys PEPS
New SPs, IDPs,

or countries
SP: if trust is required, inclusion in SP: if trust is required, inclusion in the
the circle of trust of PEPS of its circle of trust of SPWare of all VIDPs
country
Country: inclusion in all SPWare; and
Country: inclusion in all PEPSes
in all cases distribution of the SPWare
of all VIDPs
Flexibility (more Architecture foresees APs to be Architecture foresees APs to be
attributes)
attached to the systems.
attached to the systems.
Each country should consider the Each country should consider the
need for such APs.
need for such APs.
Such inclusion affects the SPWare in
all VIDPs.
Availability
Is designed and tested to work Is guaranteed

behind a load-balancer.
Mobility
On users own PC guaranteed.

With username
guaranteed
On users own PC guaranteed.
password On other PCs, limited by presence of

card-readers
With token, limited by presence

of card-readers
ID Federation
Yes, within defined limits.
Yes, within defined limits.
Implementation Limited amount of installations, Larger amount of installations, more

& maintenance so easy.
complex. Restricted interventions due
issues
to software distribution procedure.
Restricted interventions due to
16 | P a g e
high availability.
Table 2: PEPS vs MW evaluation
The MW architecture looks like easier, as you do not exploit your own hardware.
Furthermore, it has better guarantees for security: it allows you to build tunnels from the
users crypto-card to the endpoint of communication, immune to infection of the users PC.
On the other hand it has a more problematic procedure on changes of parameters and
software, as these need the collaboration of each of the involved countries. This limits in
practice the scalability of new ID providers, and new countries, and limits the flexibility with
additional attributes.
4.4 Systems in the STORK platform

As indicated, each country should have his PEPS located in his own installations, except for
the MW countries which have their V-IDP located in each of the other countries. Additionally,
in MW countries there will be several additional V-IDPs to serve the national SPs.
SP
MS A
MS B
SP
IDP
IDP
SP
VIDP
PEPS
PEPS
IDP
VIDP
STORK
Layer of Trust
VIDP
DE
VIDP
SP
VIDP
SP
SP
AT
VIDP
SP
SP
Figure 6 PEPSes and V-IDPs in Europe
4.5 Communication structure

When a user from one country connects to a service provider in another country, and
accesses the personalised part, the Service provider will request the user to authenticate. If
he chooses to authenticate with foreign credentials, he is requested to answer the from
where question. So the service provider sends this request to its national STORK node, which
redirects the user to the authentication portal of the country of his choice. All these
redirections pass through the users browser. This is presented in the following (simplified)
diagram.
17 | P a g e
Figure 7 PEPS-PEPS communication structure
In case of MW countries this scheme is of course very similar; just the national node is located
in the other country, and optionally the SP can also have a V-IDP.
STORK
node V-IDP
Figure 8 PEPS-V-IDP communication structure
4.6 Authentication and registration

Most eID management systems are about authentication, understood as the application
obtains just the users identifier. The STORK platform promotes the minimal disclosure, so
allows authentication even without such an identifier; if only age and gender are needed the
application may request only these attributes.
More in general, the STORK platform defines the authentication process to be able to obtain
any combination of the data items defined in the platform. Thus, the process of registering
for a service is only different from re-entering this same service in the amount of attributes,
but both send an authentication request to the STORK infrastructure.
18 | P a g e
4.7 Certificate Validation

Most people, when referring to STORK they limit themselves to the
Authentication process, which is defined as the same as the registration
process. Another process included in STORK is the Certificate Validation.
Right from the start, STORK was thought of as to support digital
signature. As there are so many signature formats the consortium
considered it little useful to support the validation of the signatures
themselves; normally a service provider which has decided to use one of these formats
already has implemented the software to verify the signature on mathematical correctness
(does it match the document which is supposed to be signed), is the signer authorised, does
the certificate have the right characteristics, etc.
But what a SP can not always do, is to verify that the certificate was valid when the signature
was produced. Not all CAs publish their OCSP service or CRL freely in the Internet. Thus the
STORK project built an OCSP gateway, which allows SPs of any country to validate the
certificate. Not all countries have implemented this facility.
The STORK project team was aware that developments in its sibling LSP PEPPOL [16] on
eProcurement and/or the Commission Decisions on signature formats and trust lists related
to the Services Directive may enable a comprehensive cross-border infrastructure. Thus,
STORK limited itself to the helper functions described above until it can adopt those
developments.
4.8 Circles of Trust

The STORK circle of trust is formed by each of the national PEPSes,
together with each of the corresponding V-IDPs. These systems,
which in figure 6 are on the border of the STORK layer of trust, trust
each other explicitly. This explicit trust means translated in more
technical terms - that the relevant data of these colleagues are
stored at each of the other colleagues sites. Relevant data are e.g.
the certificate which is used for signing, the URL where to send
requests to, the countrys name and abbreviation, etc.
This trust requires that each of these systems is secure; thus each of them has passed a
Security Self Assessment, with which each of the Member States makes sure to fulfil most
usual security criteria.
4.9 User control and Consent

When designing the STORK authentication business process, one of the requirements was
that the user should always be in control of his data. Thus the platform is build around the
user centric approach. One of the steps is the user consent. No data item is being sent abroad
unless the user allows the administration to do so.
The user can give his consent in various different ways:
1) Implicitly. By introducing his credential, he implicitly allows the included data to be
transferred to its destination service provider.
2) Explicitly for data types. Such consent can be given before data is collected, it just
needs to know the requested data. This consent may allow the user to exclude some
of the attributes to be sent.
3) Explicitly with data values. Such consent is after having collected all data, and shows
the data which will be sent to the SP. Due to legal restrictions in some countries, this
19 | P a g e
process is implemented in the following way: the data is signed by the authority, and
these signed data are given to the user. This procedure is very similar to the
authorities giving the user an official document like a passport, which the user may
present to others, like the customs office. As the data are signed, the user may not
exclude any item.
Also both consents may be requested. In some cases intermediate consent may be
advisable: if data are retrieved from external sources others then the credential, such consent
should be considered.
4.10 Attribute provisioning

In STORK 2.0 a category of attributes was defined as Domain-specific attributes. Most of
these attributes have only a meaning in a certain domain; in STORK 2.0 the Academic domain
was the most important one supplying a dozen of these attributes. Some do have a meaning:
hasDegree indicates what university degree a person has (Bachelor in Psychology, Master in
Maths, etc.), but the majority is worthless outside the academic domain.
These attributes should be maintained in their definition and implementation by an
organization independent of the STORK MS. E.g. for academic attributes an academic
organization should be responsible for this job. As a consequence, the attributes themselves
are understood by the PEPSes, but their underlying structure and contents are not being
interpreted, nor are they altered.
These attributes are provided by attribute providers (APs), independent of the STORK MS
representative. With the signature on the STORK response to the SPs, the PEPS does not take
responsibility for the contents: it only certifies that the AP is a trusted provider of these types
of attributes. The assertion in which attributes are packaged is also signed by the AP, thus the
Service Providers portal knows the organization which has provided the data. The assertion
may be kept for evidential purposes.
Attributes may be retrieved from several countries: a person may have a Mathematics degree
in Spain and a psychology degree in Italy. Attributes from one attribute provider are normally
packages in one assertion; different APs always send (at least) one assertion. All assertions
about one person are packaged in one SAML response.
4.11 Legal persons and mandates

For legal persons a set of attributes has been defined as being desired by most SP portals. For
the representation of legal persons the mandate has been defined, with three underlying
attributes: the represented, representative and the mandate-content. Each of these persons
can be either a natural person or a legal person, allowing a maximum flexibility.
Mandates may be chained, e.g. a company may delegate its administrative task in an
administration office, which on its turn delegates in an employee. Such chains may be crossborder: a Dutch company may delegate in a Belgian administration office, which delegates in
a German employee, being the mandates registered in Belgium and Germany respectively.
20 | P a g e
Governance
This infrastructure needs several procedures to be in place to be operational. Below we

describe the practice in the pilot scope and for the future.
5.1 Billing and pricing

According to the eIDAS regulation, basic personal data can be
obtained freely by any eGovernment service. However, for
non-government services, or for extended attributes data
nothing is regulated by law.
During the STORK 2.0 project, free interchange of data has
been used, as pilots use little volume of data. But in many
countries it costs money and time in the paper world to
obtain mandates, and in the electronic world also some fee is charged. The electronic
procedure is cheaper and costs less time, but still this fee is charged. Based on the project
results, we have recommended to keep data exchange free of charge for a defined service
introduction period beyond the duration of STORK 2.0, but in a long term perspective, fees
may apply.These fees will vary from one country to the other and from one type of data to
others.
No pricing policy has been agreed. However, all agree that prices for electronic documents
should be lower than their paper equivalent.
Implementing a pricing policy would lead to organizational challenges: in the STORK project
there was also a discussion on billing schemes. In most countries, the national representative
wont be available to be an intermediate organization, in the first place because none of them
is a private company, so this would create problems with the VAT. So a possible billing
scheme could be the direct one: each provider of such extended attributes should bill each
consumer of them (banks, other governments, ), which on their turn may bill their
customers, who save time and money with this procedure.
This may result in a complex structure: each attribute provider would need to know the billing
data of all consumers. Another discussed solution is the establishment of an intermediate
billing organization, which would centralize the billing; this seems the most feasible solution:
it would need to know all providers of attributes and all consumers of them. A mixed solution
could also exist: one central billing organization for each domain of domain-specific
attributes, which for the moment are only 3: Academia, Business and mandates and eHealth.
At the time of writing this document nothing has been organized yet.
5.2 Support
During the lifetime of the STORK 2.0 project, a Change Control and
Support Procedure was accepted, which in the first place describes
the support organisations. Please remind that STORK 2.0 is a
platform integrating systems of many organisations, and each of
these organisations may (will) have their own support organisation;
normally even organised for information systems, and not for the
complete organisation. Thus many of such organisations need to
have a common understanding of how support of the platform is organised.
In general we may expect that, if they experience any problem, the users will contact the
service provider who has STORK integrated. So if this service provider can not solve the issue,
he(she) will have to contact his local STORK representative. If this representative cant solve
21 | P a g e
the problem, he(she) will get into contact with the representative of the country the user is
from, which on his turn could need the help from the eID provider or attribute provider.
Each representative has a list of contacts, as well the STORK national partners (Service
Providers, ID providers and Attribute Providers), as the international partners: the STORK
support colleagues.
In general, this STORK second line support has an availability of 8x5, excluding official bank
holidays. This support is in general available, also if there iss no problem of a user; you can
also count on it if you have problems installing or integrating the STORK 2.0 common
software.
After STORK1, DIGIT took up the maintenance of the common code, and later on the technical
workgroups of eIDAS have taken up the responsibility for the maintenance of the
specifications. After a transition period, the final responsibility is foreseen to be layed at DIGIT
and the technical workgroups of eIDAS.
5.3 Change control

The same procedure as above also applies to the change control. Change control has two
objectives:
1) to make sure that any change applied to the common STORK software is correctly
agreed, and
2) to make sure that any change is correctly assigned a priority.
The document describes the procedures of change control, both for error corrections and for
improvements. In general it describes the use of the Joinup platform for bug-tracking and
software distribution, although email may/should also be used. For this reason we can also
use the distribution list stork-support@lists.atosresearch.eu.
Changes of the specifications are to be discussed by email, to get all points of view clear, and
possibly by phone to achieve, through an interactive discussion, getting those points of view
as close as possible, and the best decision for the STORK community. Such email discussions
may start somewhat informally, but should always end with some proposed updated formal
documents with specifications, for which a reasonable time is given to all involved parties to
read and comment it. Normally a reasonable time is two weeks, but typical holiday periods
like Easter, summer and Christmas oblige us to increase this period.
If any priority issue or major changes would arise, these will be discussed by the Change
Control Supervisory Board, which will adopt decisions concerning as well the issue on itself, as
the migration strategy, as far as necessary. This board is composed of the responsible persons
of the development teams of common code, as well as the persons responsible for
development of independent implementations.
Just like described in the previous section, the final responsibility is foreseen to be layed at
DIGIT and the technical workgroups of eIDAS.
5.4 Version control

The major problem the STORK 2.0 countries have faced has been version
control. In the first place when going live it cost quite some effort to be
compatible with every country. But once achieved this compatibility,
things all of a sudden stopped working, due to the fact that someone
changed something in his installation and didnt test this change with
22 | P a g e
every other country.

So after some time, knowing the problems with version control and foreseeing many changes,
a proposal was made and accepted to include an automated version control facility in STORK.
Basically this is a program which executes every day, and extracts from the software its
version number, and from the configuration files the modification date, and publishes this in
an XML file accessible to other STORK 2.0 partners.
This way all partners can at least know when changes have taken place, and verify that
everything is still working.
The same mechanism is proposed to apply changes of your own parameters at all partners
sites, like renewing your SAML signing certificate, or changing the name of your STORK
connector. Such changes need this file to be signed; with the old certificate in case of
certificate renewal.
All partners version control files are downloaded on a daily basis, and a similar version
control file is composed to be published to all service providers in a country. This file includes
the same description for the national PEPS as previous file, and additionally for each other
country a summary of available data and QAA. A country selector updater downloads this file
every day, and updates this service providers country selector, taking into account the
attributes and QAA level required by the service, as well as countries to be excluded. This
way, new countries will automatically be included in all country selectors of all service
providers, once the national STORK node includes this country.
On the other hand, this SP version control facility also publishes the version data of this
installation, thus allowing the national PEPS organisation to see whether or not patches have
been applied, and on this basis decide if a new patch, depending on previous patches, may be
applied.
5.5 Relationship with your national service providers

The STORK circle of trust is between all STORK countries and their
national STORK nodes (PEPSes or V-IDPs). A similar circle of trust is
proposed for your national service providers: you explicitly trust each
of them. The common code proposes that you store their certificate
in the keystore, using as an alias of their provider name, just as theyll
use it in the SAML token.
Any country may establish alternative mechanisms to verify that a SP
is allowed to request foreign users credentials, according to its own policy. There is just one
restriction: it must check that the provider name is correct. This name may be a commercial
name, which is known to European public, instead of the official name if this is less known.
E.g. Mercedes-Benz may be used instead of Daimler AG. This name is shown on the user
consent page, before the data is sent to the service provider.
Apart from the provider name, it would be useful to store some more data about the SP, like
contact persons.
In the STORK integration package (for SPs) some easy procedure and connection request form
is included. In your national implementation you will have to adapt these to what you
estimate best.
In STORK nearly all countries consider any nationally authorised SP as valid. No checks are
done in Spain on Belgian SPs: any SP the Belgian authority accepts is accepted all over Europe.
Thus, once theyre connected to your national S-PEPS, they can accept nearly all foreign
credentials. One of the exceptions to this general rule is Germany, which requires an
additional validation of the SP before any data from German citizens can be transferred.
23 | P a g e
5.6 Testing and Going Live

As STORK is not a system, it is a platform consisting of
systems. Before we can add a new node to the platform,
exhaustive testing must be performed. After unit and system
test, integration tests are performed in preproduction
environment in several stages.
In the first stage, exhaustive testing should be performed with
the DemoSP, a standard testing tool which is delivered in the
STORK toolkit. At first, these tests should be performed
against the system itself, i.e. the system simulates that a citizen from this country accesses
services in the same country.
Once these tests have been successful, the second stage of testing includes involving real
national service providers; of course also in preproduction environment. As SPs will normally
not have many different requests (one for authenticating known users and a few for new
users), this task will usually be done in less time than the previous step.
The third stage includes cross border testing with the DemoSPs of different countries; first of
one country, and later on expanding this to all countries. All tests are against the eID
infrastructure of the new country. Getting things working with one country will cost some
time, but the expansion to all countries can be relatively quick, as all use the same protocol
and there are only few implementations of it.
The last stage of testing is cross border testing with of the eID infrastructure of the new
country against real foreign SPs.
Although in each stage we test all components, the accent of testing in stage 1 and 3 is on the
C-PEPS/V-IDP, the one which will request the users credentials and send these data abroad.
In stage 4 the accent is on integrating national or foreign credentials in applications. As a
consequence, the responsibility for stage 1-3 is mainly for the owner of the national STORK
node, often the owner of the eID infrastructure. For testing purposes he(she) will need testing
credentials of his own eID. In stage 4 however, testing is done by foreign organisations with
test credentials of the new country. These foreign organisations are responsible for executing
these tests, but need the new country to send them test credentials.
An excellent draft test plan with a detailed description of test cases is available at the
STORK website. In this description youll find a more or less exhaustive enumeration of tests
youre suggested to execute, and youre encouraged to personalise this list, adding your cases
and stating that you dont need to do other cases.
Once testing is completed, you should migrate to production. In production environment you
should execute a security self assessment, also mentioned in 3.8, replying a set of questions.
Obviously in production several of these tests should be repeated. The report on Security Self
Assessment, together with the test reports should be sent to all other Member States, to
approve your connection to the STORK platform. These other Member States will also need
some data, like the certificate you use for signing the SAML tokens and where requests for
your eIDs should be sent to.
When going live, you should make sure to notify all partners on time, thus they will be able to
verify that everything is working.
24 | P a g e
The How to connect to STORK Cookbook

This section will describe in a nutshell, what a country needs basically
to carry out, if connecting to STORK 2.0. The two underlying use cases
granting foreign citizens access to my services and getting my
citizens electronic identity accepted by STORK are discussed
separately this as also MS can connect Service Providers to STORK
even if no national eID system is yet in place (consider e.g. connecting
your Points of Single Contacts under the Service Directive to STORK).
A first step to be taken by the country is the decision if the centralised

model (PEPS) or the decentralized model (Middleware) better fits the national legal and
organisational environment. Both cases are discussed below. 3
6.1 Basic functionality

The first steps to establish a STORK 2.0 node offer your citizens and service providers the
basic functionality of being able to use their national credentials in foreign portals and
accepting foreign credentials in the national portals respectively.
6.1.1 Getting national credentials accepted

This assumes that the country connecting to STORK 2.0 has an eID
infrastructure in place and that national protocols are employed
(that not necessarily need to adhere to international standards).
In both models (PEPS/MW), the eID tokens to be used need to be
assessed against the Quality Authentication Assurance (QAA) scheme developed by STORK.
The QAA labelling (ranging from 1 low to 4 high assurance) is based on the quality of the
eID issuance process and the security of the eID token. It allows the service provider to
request credential fitting its needs.
If the central PEPS-model is opted for, the country needs to
1. Deploy a C-PEPS (common open source code is provided)
2. Integrate the national eID protocols at the C-PEPS national interface (cf. figure 2)
3. Carry out a security self-assessment of its implementation and deployment
4. Communicate its C-PEPS parameters (addresses, SAML signers, etc.) to the
governance body (ISA), which will distribute them to the partner MS
If the decentralised V-IDP model is chosen
1. Implement a national protocol plug-in for the V-IDP MARS components (cf. figure 4)
2. Carry out a security self-assessment of its implementation
3. Deploy the plug-in at all other V-IDPs (hosted at the S-PEPS or SP)
6.1.2 Allowing my services to obtain foreign credentials

To be able to allow SPs to connect to STORK 2.0, the corresponding
actions depend on the architectural model you have chosen:
If the PEPS-model is opted for, the country needs to
1. Deploy a S-PEPS and a V-IDP (common open source code is
3 Please note that V-IDP could also be deployed centrally
25 | P a g e
provided)
2. Integrate the national SP protocols at the S-PEPS national interface (cf.Figure 2) 4
3. Communicate its S-PEPS parameters (addresses, SAML signers, etc.) to the partner
MS
If the MW model is chosen the country needs to
1. Implement SP-connector plug-on for the V-IDP MARS components (cf. Figure 4)
2. Deploy this connector at each V-IDP attending SPs.
6.1.3 Connecting my service

Each Service Provider which wants to connect to STORK needs to
integrate the Integration Package for his country into his
application. Apart from the technology, hell need to decide the
minimum QAA level hell require for his service, and which
attributes hell request as mandatory and which ones as optional.
This, and the criteria for making these choices, is explained in the
manuals in the integration package.
If the PEPS-model is opted for, the Service Provider needs to
Integrate the Integration Package into his application
If the MW model is chosen, the Service Provider needs to
Integrate the SPware into his application (part of the integration package)
Of course, a country opts for either or both cases 6.1.1 and 6.1.2/6.1.3. The combination of
the steps described needs to be carried out then. Please note that, even though the actors
are different, 6.1.2 and 6.1.3 should be done together; one does not make sense without the
other.
6.2 Advanced functionalities

STORK 2.0 offers many advanced functionalities, boosting the value of the platform for your
citizens and service providers.
6.2.1 Connecting attribute providers

Each Attribute Provider which wants to connect to STORK needs
to integrate the Integration Package for his country into his
application. Apart from the technology, hell need to decide the
price hell require for his service, and which attributes hell be
able to provide. This, and the criteria for making these choices, is
explained in the manuals in the integration package.
If the PEPS-model is opted for, the Attribute Provider needs to
Integrate the Integration Package into his application
If the MW model is chosen, the Attribute Provider needs to
Integrate the V-IDP into his application (part of the integration package)
Most countries implement just the STORK protocol, without any change. This is the easiest and
existing solution if you start from scratch. If needed you may implement other protocols instead
26 | P a g e
Attribute provisioning only makes sense as a complement to identity provisioning, as

described in section 6.1.
6.2.2 Supporting signatures

STORK 2.0 supports electronic signatures in most used formats
and standards, on any type of document. This functionality is
designed in the first place for the following two applications:
The user signs a transaction, like an XML document

confirming a transfer from his bank account.
The user electronically agrees on a contract with the service provider; this pdf document
is to be signed electronically.
The first application uses the XAdES format, the second one uses PAdES. In agreement with
the EC Decision on signature formats, also CAdES is supported.
As documents can be huge, the platform implements a Document Transport Layer, which,
contrary to the normal STORK flows through the users broswer, uses a direct server to server
communication.
In order to request and receive PAdES and CAdES signatures, this Document transport layer
must be present, at the service provider and the SPs PEPS.
In order to produce signatures, your national signature solution should be integrated with the
PEPS signature function. In case your country does not have a satisfactory signature solution,
two standard solutions are available; the first is the ECs SD-DSS solution, available at the
Joinup portal as an independent project; the second one is the Spanish signature applet, also
available at the joinup portal, as part of the STORK project.
6.2.3 Version control

As explained in section 5.4, the version control verifies the
software versions of the environment of the PEPS, and warns if
any change has taken place; it also allows propagating
automatically the renewal of signing certificates.
The Version Control is the simplest module of STORK 2.0 to
implement. As it as a stand-alone process, you just have to
install it and notify the location of the produced file to the European Commission, together
with your signing certificate.
6.2.4 Anonymity
STORK 2.0 supports an anonymity layer, which dis-correlates the
time of sending an eSurvey to a user from the repection of the
answer.
Both the SP and the PEPS need the anonymity module installed;
it automatically connects to all other nodes as required.
6.3 Estimated timeline

This section has the objective to give you some orientation of times in which you may be able
to do this integration. We are quite aware that every country has its own problems with legal
and technical issues, so there can not be a universal planning. But as a first approach it might
be useful for new partners. Before making a serious planning, please be aware that
everything depends on the scope of the system you want to establish: if you want to connect
27 | P a g e
a business register, attribute providers; if you want to enable Version control and Anonymity.
The following planning shows an estimation for all of these, supposing that most things can
be done in parallel.
Weeks
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
5.1 Offer national eID to foreign services

Deploy common software
Integrate your national eID infrastructure
Test
Go Live
Migrate to production
Security Self Assessment
Communicate your data
5.2 Connecting a Business Register
Decide service parameters (AQAA, attributes, pricing)
Integrate common software in application
Test
Go Live
5.3 Connecting Attribute Providers
Decide service parameters (AQAA, attributes, pricing)
Test
Go Live
5.4 Enabling Version Control
Test
Go Live
5.5 Enabling Anonymity
Test
Go Live
5.6 Allowing services to obtain foreign credentials
Test
Go Live
Security Self Assessment
5.7 Connecting a SP
Decide service parameters (QAA, attributes)
Test
Go Live
Legend
Member State, PEPS owner
Business Register
Attribute Provider
Service Provider
Figure 9 Estimated Gantt chart
Some notes on this planning. In the first place it does not take into account that there may be
holidays. In the second place, as mentioned, the authors of this document can not really
estimate the difficulty of integrating your systems into STORK 2.0.
In the third place, in our experience testing takes quite more time than in ordinary systems.
This is due to the fact that we are not working with a system; this is a platform of many
systems, which makes it more complicated to execute all tests thoroughly.
In the fourth place, the migration to production, which should be a matter of very little time,
in practice has always resulted far more than what was expected, due to the same reason.
28 | P a g e
And, last but not least, this plans to have the core operational. Getting several add-ons, like
administration tools, statistics, version control, etc. into operational state will take several
weeks more.
As a summary, depending on the scope, half a year may be a too tight planning.
29 | P a g e
What documents to read
STORK 2.0 has produced a large amount of documents. All of them are necessary to better
understand STORK 2.0, its achievements, and why where things were done in specific way. In
order make it easier and faster to get into the project and to be able to connect to STORK 2.0
platform, below is a suggestion of documents to read before starting to integrate your
country in STORK 2.0. The documentation is available in the STORK 2.0 web site under the
Results section.
Name
Who
Description
STORK D2.3 - Quality Leaders, 5

authenticator scheme
Legal experts
Defines the STORK QAA framework, including the

four levels of authentication assurance, also
facilitates mapping of national levels and eID
solutions onto each other.
STORK 2.0 D3.2 QAA Leaders,

Status Report
Legal experts
Defines the STORK 2.0 AQAA framework,

describing the four levels of attribute assurance.
STORK
2.0
Addendum
Guidelines
One of the primary outputs of STORK was the

QAA (Quality Authentication Assurance) model,
which permitted quality levels to be assigned to
various eID solutions, based on some of their
main characteristics. As a part of the expanded
scope of STORK2.0, a D3.2 QAA Status report was
drafted that expanded upon the original QAA,
allowing it to be applied to attribute providers
and legal entities.
D3.2 Leaders
AQAA
Legal experts
However, several STORK 2.0 partners expressed

the desire to receive more specific practical
guidelines on how the criteria of the D3.2 should
be addressed, in the form of a pragmatic
cookbook. The present report, intended as an
addendum to the D3.2, aims to satisfy this
request.
STORK
2.0
Consolidated
Report
D3.4 Leaders
Trust
Legal experts
Contains the MoU that was ultimately provided,

and describes its genesis, including an assessment
of its strengths and weaknesses. Adoption of the
MoU will also be briefly summarised, as well as
the issues and solutions encountered during the
Go-Live phase of the pilots. Finally, long term
sustainability recommendations are provided,
focusing on the interaction with the now adopted
and published eIDAS Regulation and the
governance mechanisms suggested therein.
Leaders is thought of as the leader of the STORK integration project, as well as the leader of the
development team.
30 | P a g e
STORK
2.0
Consolidated
Entities Report
D3.6 Leaders
Legal
Legal Experts
One of the key challenges of STORK 2.0 is the

expansion of its scope to cover legal entities. This
is an evolution that implies a number of legal
challenges, related to the legal value / reliability
of any available information on these legal
entities, and how these entities can be legally
identified and represented. The latter question
implies that the STORK 2.0 project must have a
clear perspective on which natural person has a
mandate to represent a legal entity, and how
such mandates can be managed and verified in
STORK 2.0. This deliverable provides a summary
of these issues (including issues and solutions
encountered during the Go-Live phase of the
pilots), and describes the role of the STORK 2.0
Attribute Quality Authentication Assurance
(AQAA) framework as a tool to address legal
challenges. Practical experiences and feedback on
the AQAAs use are also provided, as well as long
term sustainability recommendations, focusing
on the interaction with the now adopted and
published eIDAS Regulation.
STORK
2.0
Consolidated
Entities Report
D3.8 Leaders
Legal
Legal Experts
Fundamentally, all pilots and the STORK

infrastructure as a whole need to comply with
European data protection principles. These
principles include legitimacy of data processing,
purpose restrictions, security and confidentiality
of the personal data, and data subject rights. In
D3.7 Initial Data Protection Report, the relevant
challenges within STORK 2.0 were identified,
along with possible solutions for addressing these
issues. This deliverable explains which solutions
were implemented, including the main drivers
behind the choices made, and their actual
implementation. This includes interactions with
the Article 29 Working Party, and the creating of
model privacy policies that could be implemented
by STORK participants.
D4.8 Final version of Leaders

Process Flows
Legal experts
Provides generic process flows for authentication,

attribute transfer and e-signature transfer.
D4.9 Final version of Development

team
Functional Design
This document is the functional design of the

STORK platform, and the interoperability of
electronic identifiers.

Technical Design
team
In this document the specification of the two

STORK systems is presented: PEPS and V-IDP, as
well as commodities
31 | P a g e

Technical Specifications team
for the cross border
Interface
In this document the specification of the crossborder communications between PEPSes and
VIDPs is presented

Security
team
Recommendations
This document describes the analysis of (parts of)

processes from the security point of view
Table 3: Documents to read
32 | P a g e
References
[1]
STORK1
specifications:
https://www.eidstork.eu/index.php?option=com_processes&Itemid=&act=streamDocument&did=1805
[2]
STORK1
process
flows:
https://www.eidstork.eu/index.php?option=com_processes&Itemid=&act=streamDocument&did=1465
[3]
How to Construct Pseudorandom Permutations from Pseudorandom Functions,

Luby,
Michael,
Rackoff,
Charles
(April
1988),
SIAM Journal on Computing 17 (2): 373386, doi:10.1137/0217022, ISSN 0097-5397
[4]
New European Schemes for Signatures, Integrity, and Encryption (NESSIE),

http://www.cryptonessie.org/
[5]
The Transitioning of Cryptographic Algorithms and Key Sizes, NIST 02-07-2009,

http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_0702
09.pdf
[6]
Deterministic and efciently searchable encryption, Mihir Bellare, Alexandra Boldyreva,

and Adam ONeill, CRYPTO, volume 4622 of Lecture Notes in Computer Science, pages
535552. Springer, 2007.
[7]
Anonymous Pseudonyms for Cross-Border Identication, M. Barbosa and A. Pinto, Preprint, CCTC/Departamento de Informtica, Universidade do Minho, Portugal 2010
[8]
Efficient Constructions of Deterministic Encryption from Hybrid Encryption and CodeBased PKE, Yang Cui, Kirill Morozov, Kazukuni Kobara, and Hideki Imai, Research
Center for Information Security (RCIS), National Institute of Advanced Industrial Science
&
Technology
(AIST),
Japan
http://staff.aist.go.jp/kirill.morozov/docs/cmki09efficient.pdf.
[9]
ISCED Fields of Education and Training in 2013

http://www.uis.unesco.org/Education/Documents/isced-fos-consultation-draft-2013en.pdf.
[10] Policy requirements for certification authorities issuing qualified certificates, ETSI TS
101 456.
[11] Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0, OASIS
Standard;
2007
http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html
[12] Advanced Electronic Signature Profiles of the OASIS Digital Signature Service Version
1.0,
OASIS
Standard,
2007
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.html
[13] STORK 2.0 Deliverable D4.9: Functional Design, 2013 (not available in the public section
of the STORK 2.0 web site at the time of the edition of D4.10)
[14] PEPPOL Deliverable D1.3 Demonstrator and functional Specifications for Cross-Border
Use of eSignatures in Public Procurement; Part 7: eID and eSignature Quality
Classification; Revision: 2.1
[15] STORK 2.0 Deliverable D4.11 Interface Specification, 2013 ((not available in the public
section of the STORK 2.0 web site at the time of the edition of D4.10)
[16]PEPPOL http://www.peppol.eu/
33 | P a g e

STORK 2.0 Overview For Member States

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

STORK 2.0 Overview For Member States

Uploaded by

Copyright:

Available Formats

COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME

ICT PSP Fifth Call for proposals 2011 - Pilot Type A

STORK 2.0 Overview for new MS

Actual submission date :

October 21st , 2015

STORK 2.0 Overview for new Member States

A STORK overview for new

Update for STORK 2.0

Inclusion of comments from

Final Quality check

STORK 2.0 Overview for new Member States

Why establishing oneself as a STORK 2.0 enabled MS? ............................................ 12

The Interoperability model ..................................................................................... 14

Attribute provisioning .............................................................................................. 20

Legal persons and mandates.................................................................................... 20

The How to connect to STORK Cookbook ............................................................. 25

STORK 2.0 Overview for new Member States

6.1 Basic functionality ........................................................................................................ 25

Getting national credentials accepted ..................................................................... 25

Allowing my services to obtain foreign credentials ................................................. 25

Connecting my service ............................................................................................. 26

6.2 Advanced functionalities .............................................................................................. 26

Connecting attribute providers ................................................................................ 26

Supporting signatures .............................................................................................. 27

Version control ......................................................................................................... 27

6.3 Estimated timeline ....................................................................................................... 27

What documents to read ........................................................................................ 30

STORK 2.0 Overview for new Member States

STORK 2.0 Overview for new Member States

STORK 2.0 Overview for new Member States

Attribute PEPS (PEPS role for attribute collection in foreign countries)

Attribute QAA, quality of attribute(s)

Certificate Revocation List

Create Signature Request

Large Scale Pilot

STORK 2.0 Member State

OASIS Digital Signature Services

Online Certificate Status Protocol

PDF Advanced Electronic Signatures

Pan-European Public Procurement Online

Pan European Proxy Server

Public Key Infrastructure

Quality Authentication Assurance

Security Assertion Markup Language

The PEPS role to attend SP requests

Secure idenTity acrOss boRders linKed 2.0

Version Control File

Virtual Identity Provider, the system of the MW architecture

XML Advanced Electronic Signatures

STORK 2.0 Overview for new Member States

STORK 2.0 Overview for new Member States

2.1 Cross border use of eID

2.2 STORK architectures

STORK 2.0 Overview for new Member States

2.3 Variety of eIDs and their quality

STORK 2.0 Overview for new Member States

STORK 2.0 Overview for new Member States

Why establishing oneself as a STORK 2.0 enabled MS?

3.1 STORK 2.0 or eIDAS

No laws are in place to oblige The regulation obliges MS to accept

Implementations STORK is operational in 19 No eIDAS node is operational yet.

A large set of attributes is A minimal set is defined, which may

Metadata and Metadata are exchanged through