1. A guide for government organisations
Assurance levels for
authentication for electronic
government services
The Standardisation Forum
2. Management summary
Background and objective subsequently submit the outcome to the government
With the intention of achieving cost reductions, organisation (e.g. electronic declaration of taxes for
improved provision of services and in general a more private individuals). The guide is essentially aimed at
efficiently operating government, the government is the classification of the security/reliability level
now investing in large-scale comprehensive (‘assurance level’) for a certain service. If a govern-
electronic government services (e-government ment organisation offers multiple services with
services) for citizens and businesses. This implies varying assurance levels, it may consult this guide as
(effective) authentication measures. One wants to be an aid in determining whether or not a single level of
sure of who it is that they are doing business with. assurance can be implemented for all these different
In The Netherlands there is currently still an open services, and if so, which level would be most
standard in effect with respect to the necessary appropriate. It does not, however, include the
assurance level for identification and authentication mapping of the assurance levels to specific authenti-
of persons and parties using such e-government cation tools. These will – in part due to their dynamic
services. This open standard is established in the nature – be addressed in a separate document.
Dutch General Administrative Law Act (Awb) and
within the rules concerning information security. Initial principles & assumptions
An ‘open norm’ implies that the relevant requirements The processes behind e-government services in
have not been concretely defined. The on-going surge The Netherlands are typically similar in nature and
of e-services has consequently also increased the need structure. They generally follow a standard decision-
to further supplement this open standard, since it is making process, according to the rules of the General
important that government organisations in similar Administrative Law Act, possibly supplemented with
situations require (and implement) the same levels of requirements of domain legislation. Their relative
reliability and security. This guidebook provides this uniformity means that families of related services are
extra supplementary information, and thereby wants definable and allows for the implementation of a
to contribute to the transparency, accessibility and system for generically assessing and consolidating
credibility of the government and the legal security of risks. The assumption implied in this approach is
Standardisation Board and Forum citizens and businesses. that the associated services are provided from within
The Standardisation Board and Forum were established to promote digital This guide offers a foundation for dialogue between similar online environments and have similar
cooperation (interoperability) between the government, businesses and citizens. policy-makers, (process) architects and information vulnerabilities. The system used does however take
Interoperability ensures improved compatibility between different systems and security personnel for the implementation of into account the fact that offline measures can also
facilitates information sharing. Use of open standards plays an important role in e-services and back office processes. This booklet will be taken in order to ensure the confidentiality of data
this process. additionally offer managers insight into the rationale and to reduce the risk of a stolen or forged identity.
behind the determination of assurance levels, so that The guide is based on the nationally valid (legal) rules
The Standardisation Forum makes recommendations to the Standardisation they may make a well-informed decision. and is consistent with the European STORK frame-
Board based on research. Based on the advice of the Forum, the Board in turn work1 for the cross-border use of e-services.
makes recommendations to various ministers concerning policies in the areas of Scope
interoperability and open standards. The Standardisation Forum and Board were This guide is aimed at governmental e-services Methodology
established at the initiative of the Ministry of Economic Affairs. Their secretariat offered to citizens and businesses that use these Based on these initial principles, a framework
is part of Logius, the digital government service of the Ministry of Home Affairs through the internet; this primarily concerns (‘menu’) has been developed for the classification
and Kingdom Relations. services made available through an online portal of services in various assurance levels.
(e.g. Omgevingsloket online) or services for which This framework can essentially be seen as a simple
For more information go to www.forumstandaardisatie.nl. users perform actions in a local application and risk analysis. The method used assumes an estimate
1 Secure idenTity acrOss boRders linKed
The Standardisation Forum | Assurance levels for authentication for electronic government services 3
3. Table of Contents
of the value at stake, according to a number of Management summary .................................................................................... 3
objective (or objectifiable) criteria and interests.
Examples of this are legal requirements, the nature Contents............................................................................................................ 5
of the data exchanged (e.g. is personal information
involved) and the economic or social interest 1 Introduction ............................................................................................. 7
associated with a certain service or process. An 1.1 Uniform assurance levels as a prerequisite for e-government ........................ 7
estimate can subsequently be made of the potential 1.2 Guide offers sense of security ...................................................................... 7
damage if the service is not used in an appropriate 1.3 Realisation and management of the guide .................................................. 9
and legal manner. 1.4 Reading guide ..........................................................................................10
By coupling these interests on the one hand to the 1.5 More information ....................................................................................10
assurance levels designated by STORK, and on the
other hand to the features of services (and service 2 Scope of the guide ..................................................................................12
families), a generic classification of services can be
achieved with respect to the required assurance level. 3 Initial principles & assumptions .............................................................15
3.1 Risk assessment in broad terms ................................................................ 15
Status 3.2 Clustering of services ................................................................................16
The choice for an assurance level for a certain 3.3 STORK levels as a basis .............................................................................. 17
e-service, and therefore also the application
(adoption) of this guide, is and will remain the sole 4 Mapping of services to assurance levels ..................................................21
responsibility of the government organisation. 4.1 Criteria ..................................................................................................... 21
This guide serves as a tool for government organi 4.1.1 The menu .................................................................................................25
sations to – based on general legal frameworks – 4.2 Reference scenario ...................................................................................27
effectuate this responsibility in a proper and concise 4.3 Correction factors ....................................................................................27
manner. It would be wise for implementing 4.4 Examples of services and corresponding assurance levels ............................29
organisations to adopt and anchor this guide within
their implementation policy, and that when
determining an assurance level for a particular
service they also explicitly indicate the manner in
which this occurred.
This guide is not a static document. The continued
development of e-services and of identification and
authentication tools (e.g. credentials and tokens),
in combination with experiences by government
organisations with implementing the guide, will
reveal the need for any revisions and additions.
Logius and the Standardisation Forum will continue
to support the guide’s management and further
development.
4 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 5
4. 1 Introduction
1.1 Uniform assurance levels as a prerequisite for e-government
With the intention of achieving cost reductions, improved provision of services
and in general a more efficiently operating government, the government is
now investing in large-scale electronic government services (e-government
services) for citizens and businesses. The Dutch General Administrative Law Act
(Awb) requires that electronic traffic between citizens and authoritative bodies
takes place in a “sufficiently reliable and confidential” manner. In addition, the
Besluit voorschrift informatiebeveiliging rijksdienst (governmental information policy
guidelines) also state that the relevant line management team must determine
the assurance requirements according to a risk assessment, and subsequently
to ensure that appropriate measures are taken. This involves open standards.
An essential prerequisite in this is the availability of adequate resources for
identification, authentication and authorisation. This will give the government
certainty that they are dealing with the right person. Citizens and businesses
can in turn be assured that their (confidential) information is submitted in a
reliable way directly to the government or that they can be retrieved there.
The on-going surge of e-services has consequently also increased the need to
further supplement this open standard, since it is important that government
organisations in similar situations require (and implement) the same levels of
assurance for their e-services. This contributes to the transparency, accessibility
and credibility of the government. Furthermore, in the vein of due diligence, it
is important that the rationale behind the determination of an assurance level
is clear and transparent. This will be in the benefit of the legal security of
citizens and businesses. This guide provides this certainty and is based on the
nationally valid (legal) rules and is consistent with the European STORK
framework2 for the cross-border use of e-services.
1.2 Guide offers sense of security
A prerequisite for reliable and confidential e-services is the availability of
adequate resources for identification, authentication and authorisation.
This will give the government assurance that they are dealing with the right
person, and citizens and businesses will in turn also be assured that their
(confidential) information is submitted in a reliable way directly to the
government or that they can be retrieved there. A uniform solution for this
identification, authentication and authorisation does not exist within the
great diversity of electronic government services however. A solution with a
very high assurance level will in most cases be too expensive, and a solution
with a low assurance level may present significant liabilities with respect to
fraud and privacy. In order to avoid a proverbial ‘digital keychain nightmare’
2
Secure identities across borders linked. See document D2.3 - Quality authenticator scheme,
paragraph 2.3 and 2.4, available at www.eid-stork.eu, under ‘STORK Materials Deliverables -
Approved/Public’.
The Standardisation Forum | Assurance levels for authentication for electronic government services 7
5. for users and for the sake of managing costs, the government is currently will be necessary to conduct a comprehensive risk analysis in order to determine
working towards as-generic-as-possible implementable solutions. Examples the assurance level.
of this are DigiD (e-signature), PKIoverheid and the eHerkenning (eRecognition)
appointments registration system. It is advisable that the service provider makes the classification of their services
available in a scheme (policy rules or general binding guidelines, depending on
The basic question remains, however, of which tool ought to be used in the context).3 An explanatory note will substantiate the classification so that
different situations. This has proved difficult to determine in practice for this is also clear to the users of the service.
implementers of public services. This guide has been compiled based on this
background. It is intended to contribute to a concise, efficient and responsible
determination of the assurance level of electronic government services. 1.3 Realisation and management of the guide
This booklet was compiled in collaboration between various government
The guide includes a ‘menu’ which contains a generic association of (types of ) organisations4 , facilitated by the Standardisation Forum Bureau and the
services and assurance levels based on (legal) criteria. Indications are also eHerkenning (eRecognition) program.
included which may lead to classification in a higher or lower assurance level. This guide was presented to the Standardisation Board and Forum with the
The guide does not include an association (mapping) of the assurance levels question of whether or not it is sufficiently comprehensive to make a
to specific authentication tools (e.g. credentials). substantiated assessment with respect to the scope of application for
standards relating to identification and authentication. This was a result of
the initial stimulus to begin compiling the guide: namely, the discussion
Electronic services Assurance levels Credentials
within the Standardisation Forum about placing the requirements for
PKI-Overheid on the ‘Comply or Explain’ list of the Standardisation Board5.
The Standardisation Forum had previously decided that making a decision
Electronic services Credentials
High assurance about this matter would not be possible as long as there was insufficient
Depending on the nature of (and associated facilities) clarity about the scope of application of PKI-Overheid (that is, about the
the service, arrangement of for identification,
the process and the risks of
Moderate assurance authentication and services which require the assurance level that PKI-Overheid offers).
abuse, a particular service authorisation
will require a certain level of
assurance Limited assurance The draft of the guide was discussed in September 2011 in the
Standardisation Forum. The Forum approved the guidebook and deemed it
Minimum assurance
suitable for the determination of the scope of application of PKI-overheid.6
This decision will be taken into account for further assessment of and
decisions about placement of the programme of requirements of PKI-
Classification
Overheid on the Standardisation Board’s ‘Comply or Explain’ list. The
Figure 1: Scope of application of the guide Standardisation Board approved the guide in the autumn of 2011.7
3
Using this menu, architects, information security personnel, lawyers and Examples of such schemes are the Besluit vaststelling niveau DigiD for Mijnoverheid.nl
(Stcrt. 2008, 32) and the Regeling aanwijzing betrouwbaarheidsniveau elektronisch verkeer met de
authorities can make a qualified choice for the appropriate assurance level for bestuursrechter (Stcrt. 2010, 15000) (although this of course does not yet include a
their services. They are free in this to decide whether or not to apply the substantiation of the decision within the vein of this guidebook).
4
information in this guide. It is important to realise that this is based on a Tax Bureau, CoC, AgentschapNL, IND, Dienst Regelingen, Nictiz, Amsterdam municipality,
Ministries of Domestic Affairs, Economic Affairs and of Infrastructure and the Environmment.
generic approach. The guide will therefore provide an adequate assurance level 5
See: http://www.forumstandaardisatie.nl/open-standaarden/over-open-standaarden/
determination for the majority of cases, but exceptions are possible. If in a het-pas-toe-of-leg-uit-principe/
6
certain situation a choice cannot be made using the menu, e.g. because the See: http://www.forumstandaardisatie.nl/fileadmin/os/Vergaderstukken/
FS33-09-11_Verslag_21_september_definitief.pdf
nature of the service or the relevant circumstances are considerably different, it 7
See: http://www.forumstandaardisatie.nl/organisatie/college-standardisation/
vergaderstukken-van-het-college/2011/.
8 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 9
6. Following this approval the guide was widely distributed amongst govern-
ment organisations, accompanied by a recommendation regarding how they
may incorporate it into their implementation policies relating to e-services.
This guide is not a static document. The continued development of
e-services and of identification and authentication tools, in combination
with experiences by government organisations with implementing the
guide, will reveal the need for revisions and additions. Logius and the
Standardisation Forum will continue to support the guide’s management
and further development. This is in line with Logius’ management
responsibility for various identification and authentication tools and
standards, such as DigiD (e-signature) and PKIoverheid, and as of 2012 also
eHerkenning (eRecognition).
The parties which have been involved in the development of this guide
constitute the foundation for a community of users which Logius wants to
bring together for the maintenance and further development of this
guidebook. In addition, a meeting will be organised twice a year especially
for the users, in which a new adjusted version of the guide will be discussed
and established, based on the contributions of the meeting.
1.4 Reading guide
Chapter 2 addresses the scope of this reference guide. Chapter 3 contains
the initial principles and assumptions which apply to the formulation of the
‘menu’. Chapter 4 elaborates further on the method used and includes the
actual menu card for classification of services based on the required
assurance level. Annex 1 explains the legal framework in which different
criteria for the classification of services according to the required assurance
level are substantiated. Annex 2 contains several illustrations of the manner
in which legal requirements and formulations translate/relate to actual
electronic dimension. Annex 3 includes a list of common terminology.
1.5 More information
The guide is digitally available at the websites of Logius and The
Standardisation Forum (www.logius.nl, www.forumstandaardisatie.nl) and
from the eHerkenning (‘eRecognition’) program (www.eherkenning.nl).
Questions regarding the relevance and application of this guide may be
directed to: Forumstandaardisatie@logius.nl.
10 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 11
7. 2 Scope of the guide
The guide addresses services and processes which the government provides to relevant information. Confidentiality must similarly be safeguarded in such a
to or implements for the benefit of citizens and businesses. This concerns case. The same applies to exchanging of data between government organisati-
the domain which is essentially regulated by section 2.3 of the General ons amongst each other (e.g. to consult basic (e.g. municipal) registration
Administrative Law Act (Awb)8. In general, the following situations are records, or the exchange of information required for the assessment of an
distinguished: application for a permit).
1 Services whereby an individual uses the service on his/her own behalf via
internet and also completes the necessary steps him/herself (e.g. visit This domain is (in any case for the ministries and their direct subordinate
website, send e-mail, etc.). This definition includes both citizens and departments) covered by the Besluit voorschrift informatiebeveiliging rijksdienst (VIR,
independent entrepreneurs who are legally registered as a sole-proprietor- government information security regulations). Decentralised governments
ship business. typically already voluntarily employ a similar methodology, whereby they
2 Services which are used by an individual who completes the required operate in the vein of the VIR. Besides this, they are – like the various
steps him/herself, but does so on behalf of another natural person or governmental departments – bound to the information security regulations
legal entity. pursuant to the Wet gemeentelijke basisadministratie persoonsgegevens (Wet GBA,
3 Services whereby systems communicate with each other without direct Municipal Personal Records Act) and (the content of ) article 13 of the Wbp
human involvement (machine-to-machine traffic). (Dutch Data Protection Act). The administrative organisation and internal
control (AO/IC) and the government organisation’s security policy must,
This guide only addresses situation 1. For the time being the scope does not based on all these rules, fulfil the required assurances for the reliability and
refer to third-party authorisations/permissions; it only addresses services for confidentiality of the data streams.
private individuals themselves or for independent entrepreneurs. This is by no
means because the issue of third-party authorisation/permission is not
relevant, but rather because the domain of authorisation still remains in a
services, processes and associated departments,
state of continuous development. Effective methodologies for incorporation systems etc. under the responsibility of
of this aspect are therefore not yet available. The same applies to processes traffic between citizens
government organisation A
involving solely machine-to-machine communication with the government. and government body
Based in part on experiences with the use of this guide, further advancement
in addressing situations 2 and 3 above will become possible.
This guide is also aimed at the determination of the required assurance level for services, processes and associated departments,
systems etc. under the responsibility of
a particular service. A service provider may offer multiple services requiring government organisation B
traffic between burgers
different assurance levels – this guide does not specifically state which measures and government body
to take in such situations but instead outlines risk-increasing and -reducing
aspects relating to service provision. It thereby offers valuable reference points
in order to restrict – within limits – the number of assurance levels.
Not included in the scope of this guide is the issue of ‘return flow’ from the General Administrative Law Act VIR (civil service bureau) or other
frameworks relating to information security
government (the response to an application or notification), even though (with other government organisations)
identification, authentication and authorisation naturally also play a role in
this. It is important that it is understood that the organisation/employee Figure 2: Relationship between Awb (General Administrative Law Act) and regulations relating to
‘behind the counter’ is authorised to take certain decisions and may have access information security
8
Articles 2:13-2:17, included in the Wet elektronisch bestuurlijk verkeer (Act on Electronic
Government Communications), (Stb. 2004, 214).
12 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 13
8. 3 Initial principles assumptions
In this chapter the initial principles and assumptions are described which
were adopted for the compilation of this guide. These concern:
• Opting for a simplified and intuitive risk analysis.
• Defining families of services.
• Adoption of the STORK framework as a foundation for interoperability.
The outcome of the approach chosen based on these assumptions is a
methodology which gives a general estimation of the risks and which is
implementable with relatively little effort. This allows government
organisations to determine a required assurance level in a straightforward
manner, unless a detailed risk analysis is warranted or mandatory based on
rules for information security.
3.1 Risk assessment in broad terms
In a number of countries the classification of assurance levels is based on risk
analyses.9 The US has also adopted this approach. The Office of Management
and Budget established the E-Authentication Guidance for Federal Agencies in
2006.10 This guideline states that each body of the federal government must
determine the appropriate assurance level for each separate process or
service, based on an estimation of the risks in relation to a great number of
variables. It is expected that in time, based on the documented risk analyses,
certain fixed rules will become distinguishable.
This detailed risk analysis for determining assurance levels is inspired by the
liability aspects which play a dominant role in Anglo-Saxon culture. In The
Netherlands such an approach would be ineffectual. It is costly, time-consu-
ming and can still lead to fragmentation and unjustified inconsistencies,
while processes and services typically show many common (mutual)
features (e.g. through the application of the General Administrative Law Act
on decision-making processes).
That is the reason why a methodology was sought to generically estimate
and consolidate risks. This system assumes an estimate of the value at stake,
according to a number of objective (or objectifiable) criteria and interests.
Examples of this are legal requirements, the nature of the data exchanged
(e.g. is personal information involved?) and the economic or social interest
9
See Spain, for example: MAGERIT, Methodology for Information System Risk Analysis
and Management
10
Ministerio de Administraciones Públicas, June 2006, http://www.epractice.eu/
document/3215. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.
14 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 15
9. associated with a certain service or process. A prediction can subsequently 3.3 STORK levels as a foundation
be made of the potential damage. The STORK framework11, co-developed by the EU, constitutes the backbone
of the system of assurance levels to which on the one hand (families of )
The assumption implied with this method is that the associated services are government services can be mapped, and on the other hand the available
provided from within similar online environments and have similar authentication tools (e.g. credentials). STORK was initiated with an eye
vulnerabilities. The system used does however take into account the fact towards improving the interoperability of electronic identification and
that offline measures can also be taken in order to ensure the confidentia- authentication in Europe; so also with regard to cross-border services.
lity of data and to reduce the risk of a stolen or forged identity. These In order to answer the question of which tool to employ to facilitate the use
measures may include reporting back through another avenue, e.g. a letter of a certain service from one country in another country, it is essential to be
to the residential address recorded in municipal personal records. able to compare the relevant identification and authentication tools. This has
led to a common framework of Quality Authentication Assurance Levels12.
3.2 Clustering of services
As mentioned earlier, the processes behind e-government services are often The first step employed in the STORK framework for establishing the
of a similar nature and structure. They generally follow a standard decision- assurance level of an authentication tool (credentials) is the assessment of
making process, according to the rules of the General Administrative Law Act, the following independent aspects:
possibly supplemented with requirements of domain legislation. Their • The quality of the identification of the person for registration during the
relative uniformity means that families of related services are definable, even application process for the credentials.
if they differ with respect to the information required for the execution of the • The quality of the procedure with which the credentials are issued to the user.
service (both of the customer and from other government organisations) and • The quality of the organisation issuing the credentials and facilitating the
the (technical) structure of the service ((online portal, application). associated registration process.
• The technical type and robustness of the credentials.
We distinguish between the following families: • The security features of the authentication mechanism used to recognise
• Requesting general information the credentials every time it is used remotely (via internet).
• Signing up for/responding to discussion forums
• Applying for newsletters etc. The first 3 aspects serve primarily as procedural safeguards which apply to
• Requesting physical government services the registration process. The last two are more technical aspects of the
(waste container, collection of bulky refuse) manner in which the credentials are used.
• Registration for a personalised webpage
• Submitting complaints The eventual assurance level is then determined through a combination of
• Submitting applications (for a government service) these aspects. The STORK framework assumes 4 levels. The individual aspect
• Requesting/viewing personal information (partially pre-completed form) with the lowest score will ultimately determine the applicable assurance
• Providing/adjusting information level, on the principle that ‘the chain is only as strong as the weakest link’.
• Accountability This is illustrated in the figure on the next page.
• Filing objections
This uniformity of services at a higher abstraction level makes it possible to
make general conclusions about the required degree of reliability. This will
be determined by the general and specific characteristics of the particular
service. General characteristics include the nature of the data (personal
details demand greater certainty than non-personal data). Specific characte- 11
See www.eid-stork.eu.
ristics constitute legal requirements associated with the service (e.g. a (e) 12
The term “reliability level” may also be encountered in relevant literature – this term is
signature requirement). This has been an important assumption for the used interchangeably with “assurance level”.
classification of services and assurance levels in this guide.
16 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 17
10. Quality of the The quality of the Quality The technical type The security STORK QAA level 3
identification of procedure with requirements for the and robustness of features of the
natural person for which the organisation issuing the credentials authentication This level requires stricter methods for verifying the attested identity of the
registration during credentials are the credentials and mechanism
the application issued to the user facilitating the
user. These methods must offer a high level of certainty in identifying the
process for the registration process claimant. Identity providers are supervised or accredited by the government.
identity credentials
A 2-factor authentication is required; this would relate to soft certificates or
one-time password tokens. RDW, for example, requires this level of authenti-
assurance level is equal to the lowest score on the 5 aspects; a high score cation from businesses in the automotive industry which is authorised in that
on 1 aspect is pointless if there is a weaker link (lower score) elsewhere. capacity to view certain RDW data. Online banking applications for which
customers need a token also employ this level of authentication.
STORK QAA level 4
registration, withdrawal etc. use
This level requires at least the one-time (for initial registration) physical
presence of the user for the registration process and compliance with all
Figure 3: Determination of the assurance level according to STORK requirements of national law of the relevant country during issuance of
qualified certificates as intended in Annex II of the e-signature Directive
1999/93/EC. For The Netherlands this concerns the requirements of article 1.1,
The 4 levels defined by STORK are: part ss, of the Telecommunications Law. The identity credentials provider
must furthermore fulfil Annex I of the same directive. In The Netherlands this
STORK QAA level 1 article is addressed in article 18:16, section 1, of the Telecommunications Law.
This is the lowest assurance level; it either assures a minimal confidence in If government parties or for example notaries want to submit documents
the asserted identity of the user or no confidence at all. Identity credentials digitally to the national register, this will be possible through a special
are accepted without any form of verification. An example of this is a application: Web-Elan. This system requires the use of a token, a water-mar-
procedure in which the applicant receives an e-mail from the issuing agency ked certificate and a digital signature. Users must ensure these themselves.
with a hyperlink which must be clicked to be able to use the credentials. This
only certainty is that a similar email address exists at the time of application By coupling (mapping) the interests and criteria on the one hand to STORK
and that an outside party would theoretically be able to respond to e-mail assurance levels and on the other hand to the features of services (or service
messages sent to that address. An example of this is downloading of a tender families), a generic classification of services can be achieved with respect to
document from Aanbestedingskalender.nl. the required assurance level. Following from this – without compromising
the inherent complexity of the subject matter – a simple and intuitive system
STORK QAA level 2 for identification and authentication must be in the user’s interest. This
At this level, verification of the identity claimed by the user during the implies as little differentiation as possible, in any case with respect to the
registration process for obtaining the authentication credentials takes place reliability requirements set by the government. This is also a contributing
by means of a check based on an official document issued by the State (e.g. factor for adopting the 4 STORK levels.
a copy of the user’s passport or driver’s licence) or registration. Claimants
are not required to appear physically during registration. Credentials with a
single-factor authentication will suffice. ‘Factor’ is understood to mean an
identity token for a claimed identity, e.g. a username and password
combination or a unique code submitted by a trusted party (according to a
governmental agreement). Logging in with DigiD, for example for declaring
one’s taxes digitally, employs this method.
18 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 19
11. 4 Mapping of services
to assurance levels
Based on the initial principles and assumptions of Chapter 2, a framework has
been formulated for the coupling (mapping) of services to the different
assurance levels. This framework essentially serves as a simple risk analysis.
The method used for this is related to the usual elements of risk analysis.
The required assurance level for a certain service can be estimated based on a
number of criteria. These criteria all concern the importance of the data and the
potential damages if these were to be obtained or modified by unauthorised
third-parties.
The proposed method does not quantify the threat or the chance that a threat
will manifest itself. Instead, assumptions are formulated with respect to the
quality of the IT security features and other relevant features of the background
processes through which the particular service is provided. These assumptions
are incorporated into a so-called reference scenario. Based on the criteria and
this reference scenario, an assurance level can subsequently be assigned by
consulting a simple table (the ‘menu’, see page 24). The system also applies a
number of correction factors. These factors reduce or heighten the threat in
relation to the reference scenario. Especially in the latter case, such a simple risk
analysis will not suffice and will warrant a comprehensive risk analysis.
4.1 Criteria
The following criteria relate to the mapping of assurance levels:
1 Legal consequences
If a particular service is based on legislation, this will lead to legal actions by
the government organisation (e.g. taking a decision subject to appeal) and
will as such be aimed at liability. For cases involving actual performance
(e.g. provision of information) the service will not imply liability (legal
consequences). It may sometimes be the case that a certain service initially
purely involves actual performance, but that it may ultimately still lead to
legal consequences later. An example of this is the provision and registra-
tion of municipal waste containers according to name and address, whereby
these details can also serve as a basis for implementation (e.g. for the
correct scheduling of waste collection). This is important for the grading of
the assurance level.
Applicable values:
• No legal consequences/liability
• Legal consequences/liability
20 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 21
12. 2 Formal legal requirements Category Nature of the information
Many services require a signature, either based on the General
No personal information The information cannot be traced back to an identified or
Administrative Law Act (Awb) or based on specific legal rules. This may identifiable person.
involve signing for the sake of authentication, or to confirm a certain
action. In specific cases an advanced or qualified electronic signature may Risk category 0 Public information.
even be explicitly required, depending on the level of validation required. Publicly available personal information which has been generally
acknowledged to not form a risk for the involved individual.
Examples of this are telephone books, brochures and public
Applicable values: internet websites.
• Only general requirements relating to reliability and confidentiality are set
• Signature by or on behalf of the claimant is required Risk category I Basic information.
Limited number of personal details relating to a single type of
• Signature is required; other formal requirements also apply to the signature
validation, e.g. membership, employment or client relations,
provided that these cannot be considered to be special personal data.
3 Provision of personal information by the individual
Personal details are typically processed when using electronic services. Risk category II Increased risk.
Special personal data as intended in article 16 of the General
“Processing of personal data”, as intended in article 1, part b of the General
Administrative Law Act (Wbp), or financial/economic information
Administrative Law Act (Wbp), is understood to mean: “every action or every relating to the involved individual.
sum of actions relating to personal data [...]”. This involves all data
processing actions, from collection up to and including destruction. This Risk category III High risk.
criterion relates to situations in which a citizen or business provides or edits Data collected from investigation authorities, DNA database,
information subject to special legal confidentiality obligations,
personal data themselves from within an electronic service platform.
information falling under a code of professional secrecy (e.g.
medical) as intended in article 9, part 4 of the General Administra-
For the determination of the required assurance levels for the processing of tive Law Act (Wbp).
personal data, this guide adopts a classification of risk categories compiled by
the College Bescherming Persoonsgegevens (Personal data Protection Board) in the information, which is not subject to aggravating factors. As such, this
document Achtergrondstudies en Verkenningen (AV) nr. 2313 (see Annex 2, section 3). information is always classified into risk category II.
Risk categories for personal data are designated as follows: The table above further defines the various risk categories:
Applicable values:
Step 1. Make an initial prediction of the risk category based on the nature of • No personal information at all is processed
the data, according to the table on the right. • risk category 0
• risk category I
Step 2. Determine any aggravating factors. If the information is considerable • risk category II
(i.e. a lot of information of a single person or of multiple people), this can • risk category III
constitute an aggravating factor.
4 Displaying personal data, other than that provided by the user
Step 3. If one or more aggravating factors exist, advance to the next risk in the same session
category (one category higher). An exception to this is financial/economic With electronic services it may occur that personal data is provided or shown
through a website or in a message by the service provider to a citizen or
business. A higher assurance level may be required for this than for the
13
provision of the same (type of ) personal data by an individual or business
Blarkom, G.W. van, Borking, drs. J.J., Beveiliging van persoonsgegevens, Registratiekamer, april
2001, Achtergrondstudies en Verkenningen 23, http://www.cbpweb.nl/Pages/av_23_Beveiliging. themselves. If an applicant independently (on his own behalf ) provides
aspx. information, unauthorised validation of course cannot occur. But when
22 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 23
13. provided by the government, e.g. by displaying data on a governmental website, 7 Economic interests
this may be the case. That is why the displaying of personal data by a govern- Invalid identification may affect economic interests and lead to economic
mental website (or the provision of this data in a message) will receive a higher damages. This may involve financial damages due to misuse (abuse) or fraud,
sensitivity designation with respect to mapping: a higher assurance level is access by unauthorised parties to competition-sensitive information (potential
required for information within the same risk category. See the table on the lost order severity) or leaking of market price-sensitive information.
previous page for more explanation about the applicable risk categories.
Applicable values:
Applicable values: • Zero: There is no economic value – at least no economic damages – to be
• No personal data in addition to the information independently provided expected in the event of invalid/incorrect identification/authentication.
• risk category 0 • Limited: This concerns only limited economic interests of the individual.
• risk category I Incorrect identification/authentication can lead to damages in the order of
• risk category II €1,000.
• risk category III • Average: This involves greater interests at the individual level or limited
business interests. Potential damages are absorbable and/or rectifiable.
5 Processing of the BSN Number Involves amounts up to the order of €10,000 per case.
Following on the criteria with respect to the processing/recording of personal • Significant: Economic-scale damages (significantly) more than €10,000.
data, the recording of the BSN number (Citizen Service Number) is applied as a
separate criterion. The BSN number is by definition a key which can simplify the 8 Public interests
coordination (aggregation) of personal data within and amongst organisations. These interests essentially constitute a reflection of the risk for violation of
Moreover, stringent legal requirements apply to the use of BSN numbers. collective economic interests, collective security, compromise the integrity
of the legal system, etc. A distinction is made between public and social
Applicable values: disruption.
• BSN not recorded
• The BSN number is exclusively provided by the user and potentially Applicable values:
mapped (possibly in combination with for example a name for the sake of • Public – disruption of public trust in service provision
certainty about the correctness of the BSN number provided). The implicit Low: Complaints, commentary in newspapers;
provision of the BSN number by DigiD use is included in this Medium: Ombudsman becomes involved, official parliamentary questions, etc;
• The BSN and any supplemental personal data not provided earlier in the High: Minister resigns.
process are displayed • Social disruption
Low: Disruptions which can be resolved with a single organisation’s resources;
6 Correctness of the provided information Medium: Disruptions demanding coordinated efforts by multiple
A special category is formed by the recording of the data provided in a basic organisations, mostly public and private organisations;
registry. After all, the potential consequences of inclusion of information in High: Urgent situation; disruptions requiring emergency measures not
such a register can be considerable, since such information is considered accounted for in the normal legal, financial (etc.) framework
‘truthful’. A distinction is made however with respect to mutations in
non-authentic data and mutations in the authentic data. 4.1.1 The menu
In the ‘menu’ on the next page, the defined criteria are mapped against the
Applicable values: defined assurance levels. From each of the 8 mentioned criteria, the most
• There is no mutation or creation of a basic registry based on the data provided appropriate values can be designated for the corresponding service, resulting
• Mutations of non-authentic data in basic registers in the appropriate assurance level.
• Mutations of authentic data in basic registers
• Creation of authentic data in basic registers
24 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 25
14. Criteria Assurance level 4.2 Reference scenario
The ‘menu’ is very useful for a specific process- or IT vulnerability. The
- no legal consequences 0 (no authentication
- general requirements set for reliability and confidentiality requirements) assumptions about this vulnerability are explicitly stated below, and
- provision by involved individual (independently) of public essentially constitute the reference scenario. A number of common
personal data (risk category 0) deviations/inconsistencies with respect to this scenario have been identified
- no displaying of personal data by governmental service provider and serve as correction factors; that is, these factors (may) lead to an
- BSN Number not recorded
adjustment of the assurance level determined based on the menu card.
- no mutations in basic registry
- economic interest: zero
- public interest: low Assumptions relating to the scope
• This concerns interactive, online services for citizens and/or businesses.
- no legal consequences 1 • Citizens independently (on their own behalf ) use services, employees use
- general requirements set for reliability and confidentiality
- provision of personal data, up to and including risk category I
services on behalf of the company for which they work.
- displaying of personal data, up to and including risk category 0 • Third-party authorisation/permission is secure (elsewhere).
- BSN Number not recorded • The type of scheme and corresponding type of service process involved
- no mutations in basic registry are clearly distinguished.
- economic interest: zero
- public interest: low
Assumptions relating to the control of IT security and privacy
- possible legal consequences 2 • The organisation has working management systems for information
- legal requirements with respect to signature security and protection of personal data.
- provision of personal data, up to and including risk category II • An implemented and current security plan is in place for IT for the
- displaying of personal data, up to and including risk category I
particular service in question. This plan is based on common standards
- BSN Number is recorded, provided by user, possibly using DigiD
- no mutations in basic registry and/or a specific risk analysis.
- economic interest: limited • It is (made) known which personal data is processed for the specific
- public interest: medium scheme/service as well as the manner in which these are processed.
- legal consequences 3
- legal requirements with respect to signature or desired action Assumptions relating to the process which facilitates the service/scheme
- provision of personal data, up to and including risk category III • The valid legal requirements for the service are complied with.
- displaying of personal data, up to and including risk category II • The user’s identity is authenticated when providing access to the
- BSN Number is recorded, whether or not provided by the user requested service. This identity is subsequently adopted in the system
- mutation of non-authentic data in basic registries
during for following process(es). Supplemental measures for verifying
- economic interest: average
- public interest: medium this identity via alternative avenues remain restricted to back-office
controls; extra controls whereby the user is asked to provide additional
- legal consequences 4 validations with respect to their identity are assumed to not exist.
- legal requirements for signature, other formal requirements • For services involving a decision by an authoritative body, the decision
- processing of personal data of risk category III
will always be communicated to the concerned person. Other involved
- displaying of personal data - risk category III
- BSN Number is recorded, whether or not provided by the user parties may also be notified. This may take place via another avenue than
- processing of data leads to mutation or creation of authentic through which the service was originally requested.
data in basic registry
- economic interest: great 4.3 Correction factors
- public interest: high
The above-mentioned assumptions (the reference scenario) and the ‘menu’
based on these assumptions will not provide a correct outcome for all
situations. Both risk-reducing and risk-increasing factors exist. Risk-reducing
26 The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services 27