Potential Impacts in Citizens’ Privacy of using Federated Identity

Management to Offer e-Government Services

Jorge Navas and Marta Beltr

Department of Computing, ETSII, Universidad Rey Juan Carlos, Madrid, Spain

Keywords:

e-Government, Federated Identity Management (FIM), Mobile Connect, OpenID Connect, Privacy, SAML,

Threat Modelling.

Abstract:

The ability to verify citizens’ identity and to authenticate and to authorize them when accessing to e-

Government services (such as on-line voting, licence renewal or tax payment) is crucial for the digital transfor-

mation of public administrations. Governments need identity management mechanisms valid across different

services, platforms, devices, technologies and even physical borders. Federated Identity Management (FIM)

can help in ensuring secure identity management, in improving citizens’ experience and in increasing services’

accessibility. But this comes with a price since relying on Identity Providers, whether public or private, poses

new privacy threats that has to be faced. This paper presents a threat model of the most promising and extended

FIM speciﬁcations, OpenID Connect and Mobile Connect, when used as federated identity management solu-

tions for e-Government services. A set of three improvements is proposed to avoid these threats or to mitigate

their impacts, taking into account both, speciﬁcation and implementation aspects. Furthermore, guidelines

and recommendations in order to improve future versions of the speciﬁcations and/or their implementations

are provided for developers, providers and policy makers.

1 INTRODUCTION

e-Government is the use of information and com-

munication technologies to enable and to improve

the delivery of public services to citizens, employ-

ees, businesses and agencies. As the adoption of e-

Government increases, Identiﬁcation, Authentication,

Authorization and Accounting (IAAA) is becoming

one of its main challenges and opportunities. Pro-

posed solutions must be secure, robust, scalable, com-

pliant with regulations and laws, technically feasi-

ble, economically acceptable, socially inclusive and

easy to use for citizens. At the same time, the is-

sue of privacy is central, because public administra-

tors must play a key role in protecting the privacy

of citizens when accessing to their services. Citizens

very likely will reveal their real identity (and asso-

ciated attributes) when accessing e-Government ser-

vices, just the opposite that they may do, using ﬁc-

titious identities, pseudonyms or anonymous modes

for example, when browsing web pages or accessing

social networks.

In these e-Government scenarios federated and

token-based mechanisms already proposed and stan-

dardized in web and cloud contexts such as SAML

(OASIS, 2005), OAuth (IETF, 2012), OpenID Con-

nect (OIDF, 2014) and/or Mobile Connect (GSMA,

2015) are being adopted. These mechanisms al-

low citizens as end users (EU) to access different

e-Government resources, applications and services

through a single Identity Provider (IdP), avoiding the

need of having an account (with its related password)

for each resource, application or service. Resources,

application and services are the relying parties (RP)

in these schemes, relying on IdPs to support authenti-

cation and/or authorization decisions and to store ac-

counting information.

To the best of our knowledge there are not previ-

ous works devoted to analyse privacy threats posed

by the use of these federated identity management

mechanisms in e-Government scenarios. This threat

modelling would be a valuable source of informa-

tion to propose speciﬁc improvements which can

be made to speciﬁcations such as OpenID Connect

or Mobile Connect or to their speciﬁc implementa-

tions when trying to improve the privacy levels of

IAAA within e-Government scenarios beyond the tra-

ditional web. These are the main contributions of

this paper (1) The selection of a threat model of

OpenID Connect/Mobile Connect suitable for sce-

350

Navas, J. and Beltrán, M.

Potential Impacts in Citizens’ Privacy of using Federated Identity Management to Offer e-Government Services.

DOI: 10.5220/0007797703500355

In Proceedings of the 16th International Joint Conference on e-Business and Telecommunications (ICETE 2019), pages 350-355

ISBN: 978-989-758-378-0

narios when these speciﬁcations are used for Feder-

ated Identity Management in e-Government scenar-

ios (2) The proposal of three improvements regarding

speciﬁcation and implementation aspects, capable of

avoiding and/or mitigating these threats (3) The vali-

dation and discussion of these contributions using real

use cases.

The rest of this paper is organized as follows.

Section 2 presents background of Federated Identity

Management in e-Government, after that Section 3

motivates our research contributions and introduces

the considered threat model for e-Government scenar-

ios, focusing on privacy threats. Section 4 proposes

different mitigations and countermeasures focused on

improving privacy levels when using Federated Iden-

tity Management in e-Government contexts and dis-

cusses validation results obtained within a controlled

lab replicating real scenarios. Finally, Section 6 sum-

marizes the main conclusions of this work, discussing

obtained results and giving some recommendations.

2 E-GOVERNMENT AND

FEDERATED IDENTITY

MANAGEMENT

In 2008 New Zealand launched the e-Government

Interoperability Framework (Mckenzie et al., 2008)

relying on a federated identity management solu-

tion, SAML. The United Kingdom, Austria, Canada,

Hong-Kong, Denmark, Malta, Switzerland, the

Netherlands or Italy, to mention only some exam-

ples, followed the same direction a bit later (Bal-

doni, 2012). In this context the European regulation

on electronic IDentiﬁcation, Authentication and trust

Services, or eIDAS, was born in July of 2014 (Eu-

ropean Parlament, 2014). It is an initiative designed

to provide a regulatory environment that promotes the

use of electronic identiﬁcation (eID) schemes within

the European Union. Countries that are part of this

Union must accept those eIDAS digital identities that

meet the regulation working within an identity feder-

ation. The eIDAS technical speciﬁcation is based on

SAML 2.0 and there is a speciﬁc implementation pro-

ﬁle of SAML focused on interoperability aspects in

order to enable e-Government applications (Kantara

Initiative, 2010).

Federated identity management speciﬁcations

have signiﬁcantly evolved since then and all these

governments have progressively adopted or at least,

tried to adopt, new standards and speciﬁcations such

as OpenID Connect or Mobile Connect (GSMA,

2018), (Chausson, 2015), (Future Trust Services,

2017). The main advantage of these new schemes is

two-fold. On one hand, unlike SAML or OAuth, they

are able to solve authentication and authorization with

only one ﬂow (through the use of two tokens, and ID

token and Access token). On the other hand, many

citizens are already enrolled at Identity Providers sup-

porting these speciﬁcations, being Facebook, Google,

Twitter and MNOs the most extended providers. This

enables the evolution from government-issued eIDs

to third parties-issued eIDs. For example, Estonian

mobile-ID (e-Estonia, 2018) allows citizens to use

a special SIM card (which must be requested to the

mobile phone operator) in order to use their mobile

phone as a form of secure digital identity. BankID (Fi-

nansiell ID-Teknik BID AB, 2019), supported in Nor-

way, Sweden and Finland, enables the use of bank-

issued eIDs to access to e-Government services.

All these solutions, with their speciﬁcities, have

certain aspects in common regardless the underlying

FIM speciﬁcation or the kind of IdP. Perhaps the most

important is that, a citizen, in order to use any Identity

Provider (public or private, i.e. governmental or third-

party), needs to register or to enrol ﬁrst. This usu-

ally requires to provide some Personally Identiﬁable

Information (PII) such as full name, email address,

telephone number, etc. At the enrolling moment it is

also required to provide a citizen ID, passport num-

ber, Unique Tax Number or National Insurance Num-

ber, something that the government is able to check or

to verify against existing data in order to know who is

the real person behind the eID.

3 MOTIVATION

When evaluating the use of OpenID Connect to solve

citizens IAAA, a government has two options: to de-

ploy its own infrastructure as Identity Provider relying

on any of the available frameworks, both open source

or proprietary certiﬁed OpenID Provider Servers and

Services (OIDF, 2018), or to rely on an external

provider such as Facebook, Google, an MNO etc. In

either case, as it has been mentioned before, the cit-

izen needs an account at the IdP with its associated

authenticators (at least a password)

Governments have shown a great interest in intro-

ducing OpenID Connect and Mobile Connect as an

alternative to SAML for eID due to their aforemen-

tioned advantages, but they hesitate whether to evolve

in this direction because they are younger speciﬁca-

tions less tested than the mature SAML. Figure 1

shows the login page of the Spanish Ofﬁcial State

Gazette (BOE). Citizens are able to perform this login

with a local account or using their Twitter, Facebook

Potential Impacts in Citizens’ Privacy of using Federated Identity Management to Offer e-Government Services

351

Figure 1: Login page of the Spanish Ofﬁcial State Gazette.

or Google accounts, i.e. using one of these third par-

ties as Identity Provider with OpenID Connect. Fig-

ure 2 shows the login page when using France Con-

nect to consume any e-Government service in France.

In this case, ﬁve different identity providers can be

used: one of them is governmental (the French tax

agency) and the rest are private (a postal service com-

pany, two assurance companies and Orange, when re-

lying on Mobile Connect).

In these two cases different concerns arise. Citi-

zens lose control over their PII at Twitter, Facebook,

Google, La Poste, Orange, etc. (at the selected IdP)

and at the government website (the BOE or any other,

the RP in this scenario), citizens are not able to know

if this PII is shared with third parties or how this shar-

ing is performed, PII can be leaked from the IdP or

the RP infrastructures as well as from the citizen’s

devices (since HTTPS is used, we assume that com-

munication channels are properly protected within the

different performed ﬂows), both, the IdP and the RP

have the ability to track citizens activity at the ac-

cessed resource, application or service and to gather

information about their speciﬁc interests and ﬁnally,

both, the IdP and the RP are able to track citizens

locations over time through different techniques and

mechanisms.

All these threats may lead to different kinds of im-

pacts such as exclusion, loss of autonomy and/or lib-

erty, stigmatization, power imbalance, economic loss

or even, physical harm. As a result, citizens will likely

lose trust on their government, being reluctant to en-

gage in further e-Government initiatives due to their

bad experience about how sensitive data is collected,

used, secured, transmitted, shared, etc.

In (Navas and Beltr

an, 2019) a complete and

generic threat model of OpenID Connect/Mobile

Connect is provided, taking into account all security

and privacy aspects and considering both, speciﬁca-

tion and implementation issues. From this model, the

set of privacy threats affecting e-Government services

considered in this work is:

1. Lack of control over required PII.

Figure 2: Login page when using France Connect.

2. Lack of transparency in the sharing of PII.

3. PII leakage.

4. Citizen proﬁling.

5. Location tracking.

4 PROTECTING CITIZENS

FROM IDENTIFIED THREATS

In this section we propose a set of speciﬁc mitiga-

tions, countermeasures and remediation options capa-

ble of avoiding or mitigating impacts of threats identi-

ﬁed in the previous section, acting on aspects of both,

speciﬁcation and implementation of OpenID Connect

(OIDF, 2014).

4.1 Encryption of PII

PII must be hashed and encrypted by citizens before

sharing it with identity providers. This measure pro-

vides control over the data stored at IdPs, protecting

conﬁdentiality and integrity. Therefore, when an end

user is registering with an IdP she has to hash and

to encrypt with a private key her sensitive PII (email,

telephone number, picture, address, credit card num-

bers, social security numbers, etc.), not essential for

IdPs operation. This procedure must be performed

by some kind of agent running on end users’ side (a

browser plugin, an app: some component at the User

Agent). This plugin or app can rely on cryptographic

software primitives or on some kind of trusted hard-

ware (following the FIDO Alliance standards or rely-

ing on Trusted Platform Modules) to guarantee iso-

lation from other applications running on the same

device and better protect the private key. These as-

pects may be out of the scope of the new speciﬁcation,

the essential recommendation here is to use crypto-

graphic mechanisms regardless of how they are im-

plemented.

SECRYPT 2019 - 16th International Conference on Security and Cryptography

352

Figure 3: Authorization Code Flow with encrypted PII.

Figure 4: Authorization Code Flow with Privacy Arbiter.

Furthermore, when the step 5 of Figure 3 takes

place, the end user not only performs her authentica-

tion or gives her consent, she also decides, explicitly,

which attributes of her PII can be revealed to this spe-

ciﬁc RP. To avoid this kind of decisions to the end

user, she could be asked during her registration at the

IdP what subset of PII attributes she would like to re-

veal to all RPs or to all RPs within certain categories

(for example, by sector, by domain name, etc.).

If any of these attributes is encrypted at the IdP,

the end user decrypts it and encrypts it again with the

public key of the RP involved in this speciﬁc ﬂow.

This public key is provided by the IdP and it must

be gathered during the RP registration at the IdP (the

JSON Web Key speciﬁcation is recommended to rep-

resent the cryptographic keys (IETF, 2015)). In this

way, only the RP, using her private key, will be able

to recover this sensitive PII.

4.2 Flow ID

To mitigate threats regarding proﬁling and tracking,

we propose to change the meaning of the sub parame-

ter of the ID token, instead of being a unique identiﬁer

of the end user at the IdP it should be a unique iden-

tiﬁer of a speciﬁc IAAA ﬂow. The Flow ID can be

generated at the IdP after receiving an Authentication

Request from the RP, based on the RP identiﬁer, the

end user identiﬁer and a salt. It has to be pointed that

IAAA ﬂows do not change, only the meaning of this

parameter.

4.3 Privacy Arbiter

The main idea is to have a third-party, different from

the Identity Provider, allowing the citizen to know

how her attributes are being shared, to have an ef-

fective and real-time control over her data deciding

Potential Impacts in Citizens’ Privacy of using Federated Identity Management to Offer e-Government Services

353

to who, when and how are forwarded, to easily use

metrics such as reputation, trust or risk to make de-

cisions, to use pseudonyms, etc. To avoid signiﬁcant

modiﬁcations in the current speciﬁcation of OpenID

Connect/Mobile Connect, we propose this mitigation,

mainly, as an implementation improvement, extend-

ing the IdP standard functionalities with an additional

service provider, the Privacy Arbiter or PA (instead

of the aforementioned Validation Service, or actually,

extending it). This new provider should not have,

ever, the aforementioned dual-role (RP and PA at the

same time), avoiding therefore the threat of ampliﬁ-

cation that arises from account compromises, etc.

Figure 4 shows the Authorization Code ﬂow with

OpenID Connect when a Privacy Arbiter is used (it

can be also used with the Implicit Flow, it is only an

example). As in previous mitigations, some kind of

agent running on end users’ side (a browser plugin, an

app: some component at the User Agent) is required.

Again, when the step 5 of Figure 4 takes place, the end

user not only performs her authentication or gives her

consent, she also decides, explicitly, which attributes

of her PII can be revealed to the RP when the PII is

shared with the RP using the Standard Claims of the

ID token. This would be the ﬁrst modiﬁcation affect-

ing the current OpenID Connect speciﬁcation.

The second modiﬁcation is related to the UserInfo

Endpoint, no longer required since the sharing of ad-

ditional PII with RPs will be performed, if necessary,

through the Privacy Arbiter. When the RP presents

the Access Token at the IdP, the IdP has to redirect

this information request to the Privacy Arbiter speci-

ﬁed by the End User during her registration process.

4.4 Validation

All proposed mitigations have been validated and

evaluated in a controlled lab reproducing real use

cases like those introduced in the Motivation section.

The proposed privacy improvements at the IdP in-

frastructure have been implemented through a proxy

(located before the IdP), proposed measures and best

practices act as a wrapping improving current solu-

tions without changing core implementations, adding

as a new layer additional privacy capabilities.

The development of the plugin/app for the end

user and of a complete Privacy Arbiter are out of the

scope of this research, in our experiments for valida-

tion and evaluation their behaviour has been assessed

with very preliminary prototypes executing only their

essential functionalities. As a proof of concept, to

know how easy or complicated it would be for RPs

to adapt to the proposed improvements when working

with the most popular IdPs, Facebook and Google,

we have extended the Facebook ID PHP SDK (Face-

book, 2018) and the Google’s OAuth 2.0 APIs in

Python (Google, 2018) to implement all the speciﬁ-

cation modiﬁcations and best practices proposed to

mitigate privacy threats and it only required a little

more than 60 code lines.

It has to be pointed that the costs of incorporating

proposed mitigations comes from required changes

in current software projects, not from a signiﬁcant

increase in the computational complexity of using

OpenID Connect (not in terms or resource - CPU,

memory - consumption). This complexity is in-

creased only by using cryptographic mechanisms and

in this case all the burden falls on the IdP (Twitter,

Facebook or Google ) and on the new Privacy Arbiter,

therefore, on the agents of the ﬂow in possession of

large and powerful resources.

As it can be observed, almost all proposed miti-

gations imply changes in the OpenID Connect core

speciﬁcation, but the two ﬁrst trying to add certain

aspects that until now has been considered out of its

scope (use of encryption for PII, meaning of the sub

parameter of the ID token). Only the proposal of the

Privacy Arbiter can be considered a signiﬁcant modi-

ﬁcation to the current speciﬁcation approach. But we

think that it is conveniently justiﬁed given the intro-

duced threat model and that our proposal minimizes

required modiﬁcations in the speciﬁcation.

5 CONCLUSION

When considering to offer a new e-Government ser-

vice, public administrations must analyse what form

of eID is most secure, robust, scalable, compliant with

regulations and laws, technically feasible, economi-

cally acceptable, socially inclusive and easy to use for

citizens within the speciﬁc considered context. Nowa-

days, an additional value is that electronic identities

can be used for cross-border transactions. It is very

likely that the result of this analysis will lead to the

deployment of a FIM based on OpenID Connect or

Mobile Connect. If this is the case, the IdP can be

controlled by the own government or it can be a third-

party such as Facebook, Google, Twitter, an MNO, an

assurance company or a bank. Governments should

ensure that citizens without third party-issued elec-

tronic identities are not excluded from e-Government

services, citizens cannot be forced to enrol with a

private company. All threats identiﬁed in our threat

model must be thoroughly considered before making

this decision.

Finally, proposed mitigations and measures

should be deployed. We have checked that the en-

SECRYPT 2019 - 16th International Conference on Security and Cryptography

354

cryption of PII and the use of the Privacy Arbiter re-

turns citizens the control over required PII, signiﬁ-

cantly improves the transparency in the sharing of PII

and makes very complicated the leakage of PII. The

use of the Flow ID, on the other hand, hinders citizens

proﬁling and location tracking.

Ideally, future versions of speciﬁcations will in-

clude these or other similar. Or new e-Government

proﬁles of current speciﬁcations will be proposed

considering privacy aspects and not only interop-

erability aspects as it has happened so far. But

this is not the scenario yet, so governments and/or

third-parties should follow the generic speciﬁcations

(OpenID Connect, Mobile Connect) and add the pro-

posed privacy improvements afterwards. Whatever

the chosen option (government-issued or third party-

issued IDs, set of implemented improvements, etc.),

the principle of data minimization must be always

applied, gathering only the PII required by the FIM

scheme to work. Identities must be revocable when

necessary at the request of any of the agents the IAAA

scheme (in the event of compromise, for example).

We also wish to note that the use of biometric data

should be avoided unless absolutely necessary, be-

cause in the event of a compromise, biometric data

cannot be revoked.

ACKNOWLEDGEMENTS

This research has been partially supported by the

Government of Spain (RTC-2017-6253-1) and by the

Ericsson-URJC Chair (”Data Science applied to 5G”).

REFERENCES

Baldoni, R. (2012). Federated identity management sys-

tems in e-government: the case of Italy. Electronic

Government, An International Journal, 9:64–84.

Chausson, C. (2015). France Connect: an ID fed-

eration system to simplify administrative pro-

cesses. https://joinup.ec.europa.eu/document/france

-connect-id-federation-system-simplify-

administrative-processes.

e-Estonia (2018). Mobile-ID. https://e-estonia.com/

solutions/e-identity/mobile-id.

European Parlament (2014). Regulation (EU) no 910/2014

of 23 july 2014 on electronic identiﬁcation and

trust services for electronic transactions in the inter-

nal market and repealing directive 1999/93/EC.

https://eur-lex.europa.eu/legal-content/EN/

TXT/HTML/?uri=CELEX:32014R0910&from=EN.

Facebook (2018). Facebook login. https://developers

.facebook.com/docs/facebook-login/.

Finansiell ID-Teknik BID AB (2019). Bankid.

https://www.bankid.com/en/.

Future Trust Services (2017). Overview of eID services.

https://ec.europa.eu/research/participants/documents/

downloadPublic?documentIds=080166e5b52e19d7

&appId=PPGMS.

Google (2018). Google identity platform.

https://github.com/googleapis/google-api-python-

client.

GSMA (2015). Mobile Connect.

https://github.com/GSMA-OneAPI/Mobile-Connect.

GSMA (2018). Mobile Connect for cross-border

digital services lessons learned from the eI-

DAS pilot. https://www.gsma.com/identity/wp-

content/uploads/2018/02/MC-for-cross-border-

digital-services eIDAS Feb2018-FINAL-web.pdf.

IETF (2012). The OAuth 2.0 authorization framework.

http://tools.ietf.org/html/rfc6749.

IETF (2015). JSON web key (JWK).

https://tools.ietf.org/html/rfc7517.

Kantara Initiative (2010). eGovernment implemen-

tation proﬁle of SAML v2.0 (version 2.0bis).

https://kantarainitiative.github.io/SAMLproﬁles/

eGovImplProﬁle.html.

Mckenzie, R., Crompton, M., and Wallis, C. (2008). Use

cases for identity management in e-government. IEEE

Security & Privacy, 6:51–57.

Navas, J. and Beltr

an, M. (2019). Understanding and mit-

igating OpenID connect threats. Computers & Secu-

rity, 84:1–16.

OASIS (2005). SAML v2.0 standard. https://wiki.oasis-

open.org/security/FrontPage.

OIDF (2014). OpenID Connect 1.0.

http://openid.net/connect/.

OIDF (2018). Certiﬁed OpenID Connect implementations.

https://openid.net/developers/certiﬁed/.

Potential Impacts in Citizens’ Privacy of using Federated Identity Management to Offer e-Government Services

355