Electronic Identification Based on OpenID Connect - KTHann/exjobb/tom_johansson.pdf · i Abstract Electronic identiﬁcation is used by an individual to prove who he or she is by

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2017

Electronic Identification Based on OpenID ConnectA Design Proposal

TOM JOHANSSON

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF COMPUTER SCIENCE AND COMMUNICATION

Electronic IdentificationBased on OpenID ConnectA Design Proposal

TOM JOHANSSON

Master in Computer ScienceDate: June 12, 2017Supervisor: Sonja BucheggerExaminer: Johan HåstadSwedish title: Elektronisk legitimation baserad på OpenID Connect

– Ett designförslagSchool of Computer Science and Communication

i

Abstract

Electronic identification is used by an individual to prove who he or she is by electronicmeans and is normally used for logging in to various services. In Sweden there are anumber of different solutions that are developed and provided by different parties. Inorder to promote and coordinate electronic identification for public services, the SwedishE-identification Board was founded in 2011. The Board has developed a technical frame-work for integration between the Relying Party and the Identity Provider based on theSecurity Assertion Markup Language V2.0 (SAML) standard. SAML is a quite old stan-dard that has some limitations complicating an electronic identification solution based onit. A newer competing standard is OpenID Connect, which could be a possible candidateas an alternative to SAML. The objective of this thesis is to determine to what extent itis possible to ensure confidentiality, integrity, and accountability in an electronic identi-fication based on OpenID Connect. To achieve this, a number of requirements for elec-tronic identifications were identified and a design proposal based on OpenID Connectwas developed together with a proof-of-concept implementation. The design proposalwas evaluated against the requirements, with the final result that an electronic identifica-tion based on OpenID Connect could meet the requirements.

Sammanfattning

E-legitimation används av en individ för visa vem han eller hon är på elektronisk vägoch används vanligtvis för att logga in på olika tjänster. I Sverige finns ett antal olikalösningar som utvecklas och tillhandahålls av olika parter. För att främja och samordnaelektronisk legitimation för offentliga tjänster grundades E-legitimationsnämnden 2011.Nämnden har tagit fram ett tekniskt ramverk för integrationen mellan Förlitande Partoch Legitimeringstjänst baserad på Security Assertion Markup Language V2.0 (SAML)standarden. SAML är en relativt gammal standard med vissa begränsningar som kom-plicerar en elektronisk legitimationslösning baserad på den. En nyare konkurrerandestandard är OpenID Connect, vilket kan vara en möjlig kandidat som ett alternativ tillSAML. Syftet med detta exjobb är att undersöka i vilken utsträckning det är möjligt attsäkerställa sekretess, integritet och ansvarighet i en elektronisk legitimation baserad påOpenID Connect. För att uppnå detta, identifierades ett antal krav för elektroniska legiti-mationer och ett designförslag baserat på OpenID Connect utvecklades tillsammans meden proof-of-concept implementation. Designförslaget utvärderades mot kraven, med detslutliga resultatet att en elektronisk legitimation baserad på OpenID Connect kan uppfyl-la kraven.

Preface

TODO Thanks for . . .

ii

Contents

1 Introduction 11.1 Thesis Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Choice of Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 42.1 Requirement Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Level of Assurance (LoA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Confidentiality, Integrity, Availability, and Accountability . . . . . . . . . . . 52.4 OpenID Connect (OIDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.3 OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.4 JavaScript Object Notation (JSON) . . . . . . . . . . . . . . . . . . . . . 9

2.5 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.1 Secure Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.2 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.3 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.4 Digital Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.5 Secure Enclave and Trusted Execution Environment . . . . . . . . . . 132.5.6 Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6.1 Something You Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6.2 Something You Have . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6.3 Something You Are . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7 Security Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7.1 Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7.2 Man-in-the-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7.3 Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7.4 Cut and Pasted Code Attack . . . . . . . . . . . . . . . . . . . . . . . . 162.7.5 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii

iv CONTENTS

3 Related Work 183.1 The Swedish E-identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Electronic Identification Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Research Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 The Design Proposal 214.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Problem Identification and Motivation . . . . . . . . . . . . . . . . . . . . . . 224.3 Define the Objectives for a Solution . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6.1 OpenID Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.6.2 Relying Party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.6.3 eID-app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.6.4 The eID Solution Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.6.5 Authentication Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.6.6 ID Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.6.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.8 Authentication with eID Certificate . . . . . . . . . . . . . . . . . . . . 36

4.7 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.7.2 Authentication Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Evaluation 395.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 eID Certificate Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.6 Model of Adversary and Potential Abuse Scenarios . . . . . . . . . . . . . . . 41

5.6.1 Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.6.2 Man-in-the-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.6.3 Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.6.4 Cut and Pasted Code Attack . . . . . . . . . . . . . . . . . . . . . . . . 425.6.5 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.6.6 Relatives and Related Persons . . . . . . . . . . . . . . . . . . . . . . . 43

6 Discussion 446.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.3 Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.5 eID Certificate Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.6 Model of Adversary and Potential Abuse Scenarios . . . . . . . . . . . . . . . 46

6.6.1 Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.6.2 Man-in-the-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

CONTENTS v

6.6.3 Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.6.4 Cut and Pasted Code Attack . . . . . . . . . . . . . . . . . . . . . . . . 466.6.5 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.6.6 Relatives and Related Persons . . . . . . . . . . . . . . . . . . . . . . . 47

6.7 Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.8 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.9 Level of Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.10 Sustainability and Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.11 Societal Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Conclusions 51

8 Future Work 52

Bibliography 53

Chapter 1

IntroductionThis chapter introduces the thesis, presenting the objective, motivation, and delimitations of the the-sis. The chosen methodology will also be described.

Electronic Identification (eID) is the process of utilizing a persons identification data to elec-tronically prove the identity of a person or an organization, for example when loggingin to services provided by government authorities, banks etc. It can also be used to signelectronic documents. The importance of eID has increased along with the digitalizationof the society and most likely the importance will continue to increase, as more servicesare dependent on eID.

In Sweden there are a number of different solutions for eID; the most widely usedis BankID [1] with over 7 million1 users [2] and 1.8 billion transactions during 2016 [3].BankID is developed and maintained by Finansiell ID-Teknik BID AB [4], a company ownedtogether by the major banks in Sweden.

In 2011 The Swedish E-identification Board was established to promote and coordinateeID for the public services [5]. The Swedish E-identification Board have developed aframework for the Swedish eID [6]. The framework requires the use of Security AssertionMarkup Language V2.0 (SAML). SAML is a framework based on Extensible Markup Lan-guage (XML) for exchanging authentication and authorization data between parties [7]. Apossible candidate as an alternative to SAML is OpenID Connect. OpenID Connect is anauthentication protocol based on OAuth 2.0 and JavaScript Object Notation (JSON) [8].

As mentioned earlier the most used eID in Sweden is BankID and in 2013 there wasfor the first time more transactions with Mobile BankID2 than with BankID on smartcard or file [9]. Since then, there has been a clear trend where more and more transac-tions are made with Mobile BankID and in January 2017 86.4% of the BankID users hadMobile BankID [2]. This clearly shows the importance of mobile based eID solutions.

SAML V2.0 was released in 2005 [10], back then smartphones only had a minor mar-ket share [11] and was not fully accounted for. This legacy has lead to that SAML ispoorly suited for mobile applications. The SAML profile [12] used in the the Swedish E-identification assumes that the user is connecting to the service with a web browser. Thisassumption has made it cumbersome for developers and also negatively affects the userexperience, because users have to connect to a web server in order to authenticate [13].OpenID Connect on the other hand was designed with mobile clients in mind and sup-port native and mobile apps [8]. This has lead to speculations [13] [14] [15] that OpenIDConnect is the future and SAML belongs to the past when it comes to eID.

1Over 70% of the Swedish population.2A mobile app designed to run on mobile devices.

1

2 CHAPTER 1. INTRODUCTION

1.1 Thesis Objective

The objective of this thesis is to develop a proper design proposal for electronic iden-tification based on OpenID Connect. In order to satisfy this objective the requirementsfor an electronic identification regarding confidentiality, integrity, and accountability (de-scribed in Section 2.3) must be established. A design proposal have to be created andevaluated against these requirements in order to justify that it is a proper design. To sup-port the evaluation, a proof of concept in compliance with the design proposal should bedeveloped. The work will also include an analysis of the surrounding requirements forissuing an electronic identification, which could support further discussions about futuredevelopment.

1.2 Problem Statement

The aim of this thesis is to answer the following question:

To what extent is it possible to ensure confidentiality, integrity, and accountability in an electronicidentification based on OpenID Connect?

1.3 Delimitations

Within the scope of this thesis only confidentiality, integrity, and accountability will betaken into consideration when developing and evaluating the design proposal. Availabil-ity will be out of scope for this project and protection against denial of service attackswill not be taken into consideration nor discussed. Even though it is a large research areaand it is of great importance for an eID solution in order to provide service at all time,can availability be dealt with separately from this work.

1.4 Motivation

Although eID has become an increasingly important function in the society, there hasnot been much work done, in trying to design eID solutions based on different technolo-gies. Therefore, there is certainly of great importance to explore this area and broadenthe knowledge, particularly in Sweden which will likely face new needs regarding eID inthe near future.

This thesis work is performed with support from the Swedish Police Authority, whichhas to stay well informed about the present situation and upcoming trends regardingeID. The Swedish Police Authority is currently having an ongoing discussion with theambition of start issuing eID, even though nothing is settled at the moment. These arethe main reasons for their interest in the study of different technologies, on which an eIDcould be based.

1.5 Choice of Methodology

In order to perform and evaluate the work in a structured way, the Design Science Re-search Methodology (DSRM) [16] will be used during this project. This methodology is well

CHAPTER 1. INTRODUCTION 3

suited for the task of developing and evaluate a design proposal. DSRM consists of sixactivities; listed and described below:

1. Problem identification and motivation: Define the problem and if possible break it downinto smaller subproblems. This will be useful during the development of the designproposal. The importance of a solution to the problem should be explained and jus-tified.

2. Define the objectives for a solution: Specify the objectives of a solution. This will bedone by studying the field in order to determine the present state and explainingwhat unsolved problems the design proposal is expected to address.

3. Design and development: Create the design proposal. This work consists of determin-ing the required functionality and developing a design proposal that fulfills the re-quirements.

4. Demonstration: Demonstrate how the design proposal solves the problem. For thispurpose, a proof of concept prototype will be developed.

5. Evaluation: Determine to which extent the design proposal addresses the problem,by comparing the objectives of the solution to the observed results from the demon-stration.

6. Communication: Present the problem, its importance, the design proposal, and theresults. This will be presented by this thesis and during an oral presentation atKTH.

Chapter 2

BackgroundThis chapter explains the concepts and technologies needed in order to understand OpenID Connectand eID solutions. It also lay the foundation for the requirements, design choices, and analysis pro-vided in Chapter 4, 5, and 6.

2.1 Requirement Levels

In this report the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" forrequirement levels, should be interpreted in accordance with RFC 2119 [17]. Note thatthis only applies when the words are written in all capital letters.

2.2 Level of Assurance (LoA)

The Internation Organisation for Standardization (ISO) has published the standard ISO/IEC29115:2013 [18] specifying four Levels of Assurance (LoA) for entity authentication and guid-ance on how to achieve each level. The levels range from LoA1 to LoA4, where LoA1is the least confident and LoA4 is the most confident. In the trust framework for theSwedish E-identification [19], the levels of assurance correspond to ISO/IEC 29115:2013[18] levels, but for the Swedish E-identification level 1 is not implemented. Each level hasminimum requirements (presented in table 2.1) regarding:

• Confindence: the level of trust in a claimed or asserted identity.

• Identity Proofing: the process of capturing and verifying the information to identifyan entity.

• Multi-Factor Authentication: the process of authenticating an entity based on it pre-senting at least two separate pieces of evidence of claimed identity.

4

CHAPTER 2. BACKGROUND 5

Table 2.1: Least requirement for each level of assurance.

LoA Confidence Identity-Proofing Multi-Factor Authentication Comment

1 Minimal None OPTIONAL Not used in theSwedish eID

2 Some Remote OPTIONAL

3 High Remote REQUIRED

4 Very high Local REQUIRED All se-crets/privatekeys SHALL bestored on tamper-resistant hard-ware. Describedin Section 2.5.4.

In order for an eID to be approved by the Swedish E-identification Board the eID mustreach at least LoA2 [20]. When applying to become an issuer of the Swedish eID the ap-plicant have to specify which LoA the eID is aimed to reach [21]. The choice of whichLoA that is needed when using a service of a Relying Party (described in Section 2.4.1),is determined by the Relying Party. If for example the Relying Party requires LoA3 onlyeID fulfilling LoA3 and above are accepted. The Relying Party should take the six riskareas defined in table 2.2 into consideration when determining the required LoA. Theleast required LoA should ensure, that for all six risk areas, the damage should not ex-ceed the limitation specified by the table 2.2 in case of incorrect identification [20].

Table 2.2: Acceptable consequences for each risk area and LoA.

Possible damage in case of incor-rect identification

LoA1 LoA2 LoA3 LoA4

Inconvenience, concern, or reputa-tion damage

Limited Moderate Considerable Serious

Financial damage or liability Limited Moderate Considerable Serious

Disclosure of sensitive informationto unauthorized

Moderate Considerable Serious

Civil or criminal offenses Limited Considerable Serious

Damage to business or publicinterest

Limited Moderate Serious

Personal safety Moderate Considerable

2.3 Confidentiality, Integrity, Availability, and Accountability

Confidentiality, integrity, and availability are well established concepts within the computersecurity field are often referred to as the fundamental concepts of computer security. To-

6 CHAPTER 2. BACKGROUND

gether they form the so called CIA triad [22]. For eIDs one additional concept is needed,namely the accountability. The accountability is important in order to be able to trace ac-tions afterwards and determine who should be held responsible for a certain action. Thisis also important in order to be able to counteract and prosecute counterfeits and othermisuse of the eID [23].

In this thesis availability will (as stated in Section 1.4) not be taken into consideration.For the three remaining concepts the following definitions will be used within the con-text of this thesis:

• Confidentiality: information MUST be protected against unauthorized access.

• Integrity: information MUST be protected against unauthorized modification.

• Accountability: an action performed by an entity MUST be timestamped and uniquelytraceable to that entity.

These requirements are also identified by eSam et al. [24] and are specified in Juridisk vä-gledning för införande av e-legitimering och e-underskrifter [Legal guidance for the introduc-tion of e-legitimation and e-signatures].

2.4 OpenID Connect (OIDC)

OpenID Connect (OIDC) 1.0 is an authentication protocol also capable of authorizationreleased in 2014 [25]. The data in the communication flows of OIDC (described in Sec-tion 2.4.2) are sent as JSON Web Token (JWT) (described in Section 2.4.4).

2.4.1 Terminology

The OpenID Connect [25] and OAuth 2.0 [26] introduce a number of terms. In order tounderstand OpenID Connect the definitions of the following terms need to be known:

• Access Token: A token used to access protected resources.

• Authentication Request: Request that the End-User should be authenticated by theOpenID Provider.

• Authorization Code: After the authentication the End-User is redirected back to theRelying Party with the Authorization Code. The Relying Party sends the Authoriza-tion Code in to the OpenID Provider in order to get the Access Token.

• Claim: Some piece of information about an Entity.

• End-User: The human participant.

• Entity: Something that can be identified in a context and has separate and distinctexistence. For instance an End-User.

• ID Token: A JSON Web Token containing the Claims about the authentication ofthe End-User. It could also contain other Claims.

• Identity: Some set of attributes associated with an Entity.


• OpenID Provider (OP): The authorization server which also is capable of authenti-cating the End-User.

• Relying Party (RP): The client application requiring the End-User to be authenti-cated by the OpenID Provider.

• User Agent (UA): The client initiating a request. This could for example be a browser [27].

2.4.2 Protocol Flows

OpenID Connect specify three kinds of authentications flows: the Authorization Code Flow(figure 2.1), the Implicit Flow (figure 2.2), and the Hybrid Flow (figure 2.3).

End-User User Agent (UA) Relying Party (RP) OpenID Provider (OP)

Request service

Request service

Redirect to OpenID Provider with End-User Authentication Request

Request End-User authentication

Authentication and authorization request

Authentication and authorization response

Authorization code

Authorization code

Authorization code

ID and Access TokenService granted

Service granted

Figure 2.1: Authorization Code Flow



Request service

Request service





ID Token and Access Token

ID Token and Access TokenService granted

Service granted

Figure 2.2: Implicit Flow


Request service

Request service





Authorization Code and/or Access Token and/or ID Token

Authorization Code and/or Access Token and/or ID Token

Authorization Code

ID Token and Access TokenService granted

Service granted

Figure 2.3: Hybrid Flow

The flows have some different characteristics desirable in different situations, dependingon the implementation. The Authorization Code Flow are for Relying Parties able to main-tain a secret between them and the OpenID Provider. This has the advantage that theAccess Token does not become known to the User Agent, to which instead only the Au-thorization Code is revealed. The Authorization Code is sent to the Relying Party, thatis able to exchange it for an Access Token. The Implicit Flow is built for Relying Parties


not able to securely maintain a secret with the OpenID Provider. This flow reveals all thetokens including the Access Token to the User Agent [28]. In general, the Implicit Flowis for browser-based applications, like a JavaScript-based applications [29]. The HyrbridFlow is (as the name suggests) a combination of the Authorization Code Flow and theImplicit Flow. The tokens can be sent to the Relying Party from the OpenID Providerboth through the front channel via the User Agent and the back channel (directly fromthe OpenID Provider to the Relying Party). An additional benefit of the Hybrid Flow isthat it also also mitigates against the so called cut and pasted code attack [30] described inSection 2.7.4.

The OpenID Connect specification [25] does not require signing and encryption forthe overall communication and this might lead to security risks, because the integrityand confidentiality of the messages are not guaranteed. Also the method used by the Au-thorization Server to authenticate the End-User are beyond the scope of the specification,even though it will directly affect the overall security of the system. An insecure authen-tication method results in an insecure system.

2.4.3 OAuth 2.0

OAuth 2.0 is an authorization protocol released in 2012 and specified by the RFC 6749 [26].OAuth 2.0 obsoletes the OAuth 1.0 protocol and is not backward compatible with OAuth1.0, in fact most implementation details are different between the two versions. OAuth2.0 is designed to support native and mobile applications. The main difference betweenOpenID Connect and OAuth 2.0 is that OpenID Connect adds a specified way to handleidentities by specifying an ID Token described in Section 2.4. This means that OpenIDConnect is an authentication and authorization protocol while OAuth only is an autho-rization protocol. In short terms OAuth is about accessing an End-User’s resources andOpenID Connect is for verifying an End-User’s identity. Note that OpenID Connect is anextension of OAuth and is therefor capable of both.

2.4.4 JavaScript Object Notation (JSON)

JavaScript Object Notation (JSON) is a text based human readable data format for lightweightand language independent data exchange. JSON was first specified by Crockford [31] inthe RFC 4627, which was released in 2006. This RFC was obsoleted by RFC 7159 by Bray[32] that together with the standard EMCA-404 [33] specifies JSON.

JSON Web Token (JWT)

Jones et al. [34] specify JSON Web Token (JWT) in RFC 7519. JWT is a space efficient for-mat for claims transmitted between parties as JSON objects. The JSON objects are en-coded in a JWS and/or JWE structure. JWT does not exist on its own, it is either a JWSor JWE as described below.

JSON Web Signature (JWS)

Sakimura et al. [35] specify JSON Web Signature (JWS) in the RFC 7515. JWS is a represen-tation of content with digital signatures (public/private key) or Message Authentication


Code (shared secret) providing integrity. JWS consists of three main parts: header, pay-load, and signature. The header specifies the cryptographic algorithm used for the sig-nature, if the algorithm is set to none the JWS will not contain a signature. The payloadconsists of the claims, e.g. iss (issuer) and email. The signature is the cryptographicsignature, to protect the integrity of the JWS.

JSON Web Encryption (JWE)

Hildebrand and Jones [36] specify JSON Web Encryption (JWE) in RFC 7516. JWE is a rep-resentation of encrypted content providing integrity and confidentiality. Since the encryp-tion algorithms used in JWE provide integrity, there is no need for separate signing whenusing JWE in order to achieve integrity.

2.5 Cryptography

Cryptography provides a number of methods used to address security concerns. For in-stance it can provide confidentiality by the use of encryption and integrity by the use ofdigital signatures. Encryption is often divided into two branches: symmetric cryptogra-phy and asymmetric cryptography (also called public key cryptography). The symmetricencryption relies on one secret key, which is kept secret from unauthorized parties. Theasymmetric cryptography is based on the use of key pairs, where one key is publicly dis-tributed and the other one is kept secret. More information about asymmetric cryptogra-phy is provided in Section 2.5.2.

2.5.1 Secure Hash Functions

A Secure Hash Function also called a one way function is used to calculate a fingerprintof a message. The secure hash function takes a message m of arbitrary length as inputand outputs, a hash code h of fixed length. The following must be true for a secure hashfunction:

• H(m) should be easy to compute.

• It is not computationally feasible to find m such that H(m) = h given h.

• It is not computationally feasible to find x 6= y such that H(x) = H(y).

2.5.2 Public Key Cryptography

Public Key Cryptography is a cryptographic system based on the use of key pairs, one pub-lic and one private key, that are mathematically related. The key pair is generated andthe private key is kept secret while the public key can be distributed publicly. The foun-dation for the public key cryptography was published in 1976 by Diffie and Hellman[37]. They set up the following requirements for public key cryptography:

1. It must be computational feasible to generate key pairs.

2. It must be computational feasible encrypt/decrypt a message.

3. It must be computational infeasible to obtain the private key from the knowledgeof the public key.


4. It must be computational infeasible to obtain the plaintext from the knowledge ofthe ciphertext and the public key.

2.5.3 Digital Signatures

Digtal Signatures is a way to digitally sign information. The act of digital signing is roughlyanalogous with signing by hand and in some cases a digital signature implies the samelegal consequences [38].

The process of digitally signing is based on public key cryptography and involvethree functions, Gen, Sign, and V erify. The Gen function is used to generate the keypair, consisting of the public key pk and the private key sk. The Sign function 2.1 takesthe message m to be signed and a private key sk. The output is a signature s.

s := Signsk(m) (2.1)

In order to evaluate the signature, the V erify function 2.2, takes the message m, the pub-lic key pk, and the signature s. It outputs a v, that is true if the signature is valid formessage m and public key pk otherwise false.

v := V erifypk(m, s) (2.2)

In order for the digital signature to work the following must hold.

true = V erifypk(m,Signsk(m)) (2.3)

The digital signature provides message integrity, because if the message is modified, thesignature will not be valid and only the signer (holder of the private key) can generatethe signature. This also provides two additional properties. Firstly, because the signatureis bound to the signer by the private key, the digital signature can be used to authenti-cate the signer. Secondly, the signer cannot deny the creation of the signature and can behold responsibly for the signing of the message. This is called non-repudiation and it isthis property which make it possible to sign contracts electronically with digital signa-tures [39]. Compared to handwritten signatures, a digital signature add an extra layer ofprotection, because the signature is bound to the content of the signed message. A digitalsignature cannot be copied from one message to another message with different content.A handwritten signature can be copied from one message to another message, regardlessof the content of the messages. Neither does a handwritten signature provide integrityprotection of the message [40].

2.5.4 Digital Certificate

Digital Certificate, also known as Public-Key Certificate, is typically some entity’s public keytogether with the identity information of the entity signed by some trusted third party.The certificate also includes some additional data, such as information about the trustedthird party and the expiration date of the digital certificate. The process of creating a dig-ital certificate is also called issuing. The reason for issuing a digital certificate, is to be


able to distribute the public keys in a way that ensures which entity the public key be-longs to. If the public key is not distributed inside a digital certificate, the receiver cannotdetermine in a secure way to which entity the public key belongs, which result in thatthe public key cannot be trusted [22].

Certificate Authority

The trusted third party described in Section 2.5.4 is typically a Certificate Authority (CA).The CA is some party trusted by the user community, for instance some financial insti-tution or government agency [22]. The CA creates hierarchy of trust by issuing certifi-cates to others in a tree structure. A CA can also issuing a self signed certificate, called aroot certificate. The root certificate function as the fundamental point of trust and can beused to verify certificates issued by the CA. [41]. Ordinary browsers ships with a numberof pre-installed root certificates in order enhance the user experience by supporting TLS(described in Section 2.5.6) for certificates issued by CA:s of the pre-installed root certifi-cates [42].

Certificate Revocation List

Certificate Revocation List (CRL) is a way to solve the problem occurring if a digital certifi-cate should be invalid before the time of expiration. When a digital certificate is issuedit is expected to be used until it expires, but for different reasons the digital certificatemay have to be revoked before the expirations date. This could be for example if the cor-responding private key is compromised or expected to be compromised. The certificaterevocation list is a signed data structure consisting of a time-stamped list identifying therevoked certificates [43].

Soft Certificate

Soft certificate is a somewhat misleading term, because it does not say anything aboutthe digital certificate. It is instead often used to declare, that the user’s private key isstored on regular disk memory and thereby vulnerable to attacks where the private keyis stolen or exchanged. In most cases these type of attacks can be performed without theuser detecting that the private key has been compromised [44].

Hard Certificate

Hard certificate denotes that the private key is stored in some special portable hardware,for example a so called smart card. This is a way to make it substantially harder to ex-tract or exchange the private key. Some smart cards even make it possible to generate thekey pair on the hardware of the card, meaning that the private key never have to existsoutside the secure environment of the card. Hard certificate also has the advantage, thata careful user will not lose it unnoticed. A big problem with the use of hard certificatesis that the device needs to interact with the hard certificate in order to utilize it. This isnormally done with a reader and far from all devices has a reader installed [44].


2.5.5 Secure Enclave and Trusted Execution Environment

Because of the security issues with soft certificates and the implementation issues withhard certificates described in Section 2.5.4, Apple and Android have developed alterna-tive solutions. Apple is calling their alternative Secure Enclave. The Secure Enclave is acoprocessor that uses encrypted memory and is able to performs all cryptographic func-tions for handling the private keys. The Secure Enclave is separated from the rest of thekernel, meaning that even if the kernel is compromised, the Secure Enclave will still besecure. Key pairs can be generated inside the Secure Enclave and thereby, the privatekey never has to exists outside the Secure Enclave. The keys are protect against unau-thorized used by either passcode or the Touch ID1 [45]. Android’s alternative is calledTrusted Execution Environment and has similar characteristics and functions as the SecureEnclave [46].

2.5.6 Transport Layer Security

Transport Layer Security (TLS) protocol are based on Secure Sockets Layer (SSL) [47] and pro-vides security for communications over the Internet. It utilize cryptography in orderto provide privacy and data integrity between two communicating parties. The proto-col could be used to provide server authentication and thereby protect against a Man-in-the-Middle described in Section 2.5 [48]. It should be noticed that weaknesses havebeen identified in earlier versions of TLS and SSL. Open Web Application Security Project(OWASP) has published recommendations regarding versions and settings that should betaken into account in order to ensure a secure configuration [49].

2.6 Authentication

The approach of authentication humans is divided into three different methods [50]. Themethods are often referred to as something you know, somthing you have, and something youare, each described in detail in the sections below. If more than one of the methods areused this is referred to as multi-factor authentication [51].

2.6.1 Something You Know

Something you know is the form of authentication approach where the user is expectedto prove knowledge of a secret, something that is only known by the user. This is typi-cally a password or a PIN code. This type of authentication approach has a number ofproblems. The secret could be forgotten by the user, or could be known by a third party.Users often tend to choose simple passwords in order to not forget them, making themeasy to guess or brute force. In the case they choose a complex passwords, they tend tostore the passwords by for example writing them down, in which case they could bestolen. Passwords also need to be manually changed by the user, which means that acompromised password would probably be valid until the user changed it. There is usu-ally a need for a function to restore forgotten passwords. The restore function could beused for social engineering attacks described in detail in Section 2.7.5 [50].

1A fingerprint sensing system.


2.6.2 Something You Have

Something you have is an authentication approach based on the user proving the possessof some object. The object could for example be a smart card2. This type of authentica-tion removes the problem of having the users remembering something and also removesthe constraints of the human memory and computational ability, but instead introducesthe problem that the users have to carry some object with them in order to authenticate.The object can be stolen and used by a malicious party if it is not protected by any otherauthentication mechanism, for example a PIN code [50].

2.6.3 Something You Are

Something you are is based on the user authentication by proving something he is. It doesnot require that the user remembers something or carries some external object. This au-thentication mechanism is based on different biometric authentications schemes, thatverifies some biometric characteristics of the user. This could be a fingerprint, retina, orkeystroke timing [50]. Because nature of these characteristics are not binary, there is arisk for error in form of false positive3 and false negative4. Some attacks have also been de-veloped in order to fool this type of authentication mechanism, except from social engi-neering deceiving the user to for example place his finger on the fingerprint sensor, at-tacks involving lifting a fingerprint from a surface and present it to the fingerprint sensorhave been developed [52].

2.7 Security Threats

There are a number of different security threats to eID-solutions. The following sectionsdiscuss attacks that have to be taken into account and mitigated in order to ensure a se-cure design proposal.

2.7.1 Man-in-the-Middle

A Man-in-the-Middle (MITM) attack compromises the confidentiality and integrity of theactual data that flows between endpoints [53]. This is done by a malicious party (MITM)that intercepts the communication between legitimate endpoints (victims). The flow of atypical MITM attack is illustrated in the figures 2.4 and 2.5 below.

Alice Bob

Alice key

Bob key

Encrypted data

Figure 2.4: The flow seen by Alice and Bob during the typical Man-in-the-Middle attack.

2A challenge response card capable of performing some sort of cryptographic calculation.3The user authentication is incorrectly accepted.4The user authentication is incorrectly denied.


Alice MITM Bob

Alice key

MITM key

Bob key

MITM key

Encrypted data

Modified encrypted data

Figure 2.5: Actual flow of the typical Man-in-the-Middle attack.

As illustrated in the figure 2.5, the key exchanged between Alice and Bob is interceptedby the MITM. This gives the MITM the ability to intercept, modify or replace messagessent between Alice and Bob without them noticing it.

2.7.2 Man-in-the-Browser

Man-in-the-Browser (MITB) is a Trojan that infects the user’s browser. The Trojan has thecapability to intercept and modify information sent and received by the user’s web browserin real time [54]. Because the Trojan is in control of input and output of the web browserthere are few effective ways to mitigate against a MITB. Many of the possible methods toprotect against MITB are inconvenient, for example using a separate computer or hard-ened browser only for connecting to the target site. One of the more convenient ways toto protect against MITB is to use Out-of-Band Transaction Detail Conformation. This involvesusing a separate communication channel, which the user has to operate in order to au-thorize the action. For instance the user could get an SMS with One Time Password andinformation about the action to performed. The user could review the information, be-fore typing the the One Time Password in to the web browser. This way, if the MITB hasmodified the information sent in the request, this modification will be presented to theuser in the SMS and the user would be able to detect the modification performed by theMITB [55].

2.7.3 Replay Attack

Replay Attack is an attack on security protocols. The attack is preformed by an adversarycopying messages sent between two parties. The copied messages are later sent to someof the legitimate party, in order to fool the party to process the messages as legitimateand believe that they have successfully executed the protocol [56]. The attack is visual-ized in the figure 2.6.


•Interception Point

VictimServer

Attacker

1. Original Connection

1. Capture Messages

2. Replay Messages

Figure 2.6: Replay attack.

The attack consist of the following steps:

1. The Victim sends messages to the Server and the Attacker captures the messages.

2. The Attacker uses the messages at a later time in order to impersonate the Victim.

In this way the Attacker can perform a number of different task by impersonating theVictim. For instance if the Victim sign in to the server, the Attacker could log the Au-thentication messages and use it later in order to sign in as the Victim. Another exampleis if the Victim is performing an transaction, the Attacker could use the captured mes-sage in order to perform the same transaction multiple times.

In order to mitigate Replay Attacks Session IDs can be utilized, this way an attackercannot reuse an already used message. The Session IDs should include a cryptographi-cally nonce and a per-session state value, that is unguessable to attackers.

2.7.4 Cut and Pasted Code Attack

This attack basically consists of two steps. The attacker gets hold of an AuthorizationCode belonging to the victim. The attacker replace the code in the authorization responsewith the victim’s code. The Relying Party will then use the replaced code in order to getthe Access Token of the victim, resulting in privilege escalating to the attacker. The rootof this attack is the fact that the code is not bound to the state [30].


Attacker User Agent (UA) Relying Party (RP) OpenID Provider (OP)

Request service

Request service

Redirect with request End-User authentication




Authorization codeSwap to victim’s Authorization Code

Victim’s Authorization Code

Victim’s Authorization Code

ID and Access TokenService granted with victim’s privileges

Victim’s service

Figure 2.7: Cut and Pasted Code Attack

Two ways of mitigating against this attack, stop the attacker from getting the code orbind the code to the state. The attack is possible on the assumption that the attacker hasgot the code in some way, so mitigate against this would be a valid protection. If the ac-cess code is somehow leaked, it should better be bound to the state. This is achieved ifthe Hybrid Flow described in Section 2.4 is used. The Hybrid Flow mitigates against thisattack by including a signed token containing a hash of the access code and a nonce link-ing the state. If the attacker swaps the access code, the hash will not match and if theattacker swaps the token, the nonce will not match [30].

2.7.5 Social Engineering

Social engineering is the art of psychologically exploiting humans. The practices could beused to extract sensitive information by manipulating employees to reveal information,without them realizing that the information is sensitive. It could also be used to circum-vent security measures by for example fooling a user to divulge his password [57]. Mo-bile BankID has been exposed to social engineering where users have been contacted andurged to log in [58] [59].

Chapter 3

Related WorkThis chapter place the thesis in the context of the present situation of the problem domain.

3.1 The Swedish E-identification

The public authority The Swedish E-identification Board was founded in 2011 and is com-missioned to promote and coordinate electronic identification and signatures for the pub-lic sector e-services in Sweden.

The board has the following goals [5] (freely translated):

• Everyone should be able to have access to secure electronic identification that iseasy to use.

• It should be easy and secure for digital services to include electronic identificationand electronic signing.

• It should be cost effective for the public sector to utilize electronic identificationand electronic signing.

To fulfill these goals the board has issued a number of documents in order to regulateand support development of electronic identification. They have also developed a qualitylabel for the Swedish eID called “Svensk e-legitimation” [Swedish eID], which is pro-vided to eIDs approved by the Swedish E-identification Board. The purpose of the labelis to inform the users that the eID is reviewed and approved by the Swedish E-identificationBoard [60].

The Swedish E-identification Board is also commissioned by the government to be re-sponsible for the Swedish eIDAS node project. eIDAS is established by the EU regulationNo 910/2014 stating that from September 29, 2018 is obligatory for public digital servicesto accept foreign eID [61]. The eIDAS node will work as the border between the domes-tic Relying Parties and foreign eID services [62].

The Swedish E-identification Board [6] has issued E-legitimationsnämndens Tekniska ramverk[The Swedish E-identification Bord’s Technical Framework] in order to make the intro-duction of eID easy, secure, and efficient. The framework require SAML V2.0 Web BrowserSSO and should be followed in order to connect the Swedish eIDAS node.

18

CHAPTER 3. RELATED WORK 19

The Swedish E-identification Board [63] has performed a requirement analysis and in-vestigated the surroundings regarding the upcoming eIDAS and published the result inBehovsanalys eIDAS -utländska e-legitimationer i Sverige [Needs Analysis eIDAS -foreign eIDsin Sweden]. The report state that the Denmark, Holland, Great Britain, and, Norway willuse SAML 2.0 and that several of the countries are interested in testing OpenID Connect.

The investigation has taken the following alternatives into consideration and the SwedishE-identification Bord has come to the following conclusions:

• SAML 2.0 in accordance with the Swedish E-identification Bord’s Technical Frame-work. This method is natural for both governments and municipality. SAML 2.0 thecurrent international standard for eID and is used for eIDAS.

• SAML 2.0 in accordance with the specification for traffic between countries withineIDAS. This method could be implemented quite easy, but is expected to not fulfillthe needs of the Relying Parties in order to utilize eIDAS.

• OpenID Connect is regarded as an upcoming technology, that is not ready to be theonly alternative in Sweden. It could possible be added later on.

• BankID Relying Party API used by BankID in Sweden. This protocol is proprietaryand not an open international standard. It is not regarded as a possible solutionbased on mainly two arguments. First, in the current situation it is not possible touse as a generally interface. Secondly, because it is not an open standard and thefuture of the protocol is unknown.

This argumentation has lead to the intent to use SAML 2.0 in compliance with The SwedishE-identification Bord’s Technical Framework and when the need for new methods arise,like OpenID Connect, could they be added to the framework.

Oehme [64] at the MSB – Swedish Civil Contingencies Agency published a summary of theresult from a classified report conducted by MSB requested of three Swedish authorities:Arbetsförmedlingen [Swedish Public Employment Service], CSN – Centrala Studiestödsnäm-den [National Board of Student Aid], and Försäkringskassan [Swedish Social InsuranceAgency]. The summary contains a number of recommendations for the Swedish eID. Therecommendation, most relevant for this thesis, is regarding developing policies on whatshould be logged by the system.

Hermansson [65] at the National Defence Radio Establishment published a partiallyclassified report Säkerhetsgranskning [Security Audit] on the initiative of MSB – SwedishCivil Contingencies Agency. The report analyzes the Swedish eID proposed by the SwedishE-identification Board and reveals a number of security vulnerabilities. Example of iden-tified risks are Man-in-the-Browser and Man-in-the-Middle attacks. These risks in particu-lar depend on how SAML is used and the risks could possibly be avoided. These risksmust be taken into consideration when developing the design proposal because they arewithin the scope of this thesis.

20 CHAPTER 3. RELATED WORK

3.2 Electronic Identification Solutions

Terbu et al. [66] present a mobile ID Solution called My Identity App (MIA) in the paperOne mobile ID to secure physical and digital Identity. It aims to solve the problem of eID andalso provide the users with a way to perform a person-to-person authentication. This workcould serve as an inspiration for the work performed in this thesis.

Feld and Pohlmann [67] have performed a security analysis of OpenID 2.0 in combi-nation with the new German national identity card (nPA). They revealed a number of weak-nesses in OpenID. However, they state that the weaknesses could be compensated forby using nPA. For instance the biggest security threat consisting of phishing is eliminatedwhen using the nPA. A similar analysis has to be performed on the design proposal de-veloped within the scope of this thesis.

Nilsen [68] is working on an OpenID Connect Provider platform for BankID in Nor-way. It is currently a pilot for evaluation purposes. The pilot is not for commercial appli-cations at the moment and has undergone major changes in parallel to this thesis work.This clearly shows that the demand for an eID solution based on OpenID Connect is im-minent.

3.3 OAuth

Paul [69] has highlighted a security vulnerability later confirmed by Pai et al. [70]. Theclient credentials are at risk of being extracted if they are saved in the source code. Thisis an important aspect to be taken into consideration when creating the design proposalduring this thesis work.

Pai et al. [70] have in the Formal Verification of OAuth 2.0 using Alloy Framework formal-ized OAuth 2.0 using flow analysis and the Alloy modeling language for specification.The Alloy Analyzer was used for verification and found a known vulnerability in OAuth.This lead to a greater confidence in the model used in the Alloy Analyzer and its abilityto find security flaws. This work provides better confidence in the OAuth 2.0 protocol.

3.4 Research Gap

OpenID Connect is an upcoming standard competing with SAML. The market has showngreat interest in introducing OpenID Connect as an alterntive to SAML for eID, but isafraid of supporting a rather young standard that is regarded as untested. The marketinterest of OpenID Connect indicates an eagerness to find alternatives to the somewhatmature SAML and at the same time expectation of OpenID Connect being the next in-ternational standard for eID. The lack of studies and open design proposals for eID so-lutions based on OpenID Connect, provides the opportunity to contribute by increasingthe understanding of how OpenID Connect could be used to meet the requirements of aneID. This is the objective of this thesis specified in Section 1.1.

Chapter 4

The Design ProposalThis chapter describes the design proposal along with the identified problems and motivation, as-sumptions and delimitations of the proposed design.

4.1 System Model

The system consists of five parties: the End-User, the eID-app, the User Agent, the Rely-ing Party, and the OpenID Provider. The purpose of the system is to authenticate the End-User and authorize some action performed at the Relying Party. The different parties andtheir roles are described below.

• End-User: A person trying to perform some task at the Relying Party that requiresthe End-User to be authenticated and authorized by the OpenID Provider.

• eID-app: A mobile app used by the End-User in order be to authenticate with theuse of his eID.

• User Agent: The client used to access the service of the Relying Party. Examples ofUser Agents are web browsers and mobile apps.

• Relying Party: The service that request the End-User to be authenticated and autho-rized in order to perform some action. For instance logging in to an account at theRelying Party. The End-User interact with the Relying Party and is then redirectedto the OpenID Provider in order to be authenticated and authorize the action to beperformed by the Relying Party.

• OpenID Provider: The authorization server which also is capable of authenticatingthe End-User. The End-User is redirected to the OpenID Provider and has to au-thenticate and authorize the request made by the Relying Party.

The parties are interacting with each other in the way described in figure 4.1. The End-User request a service from the Relying Party, which redirect the End-User to the OpenIDProvider where the End-User is authenticated. After the authentication is accepted anAccess Token is issued and sent to the Relying Party. The Relying Party are then able toperform the service requested by the End-User. The purpose of this is to enable the Rely-ing Party to hand over the responsibility of authenticating and authorizing the End-Userto the OpenID Provider.

21

22 CHAPTER 4. THE DESIGN PROPOSAL

User Agent

End-User

eID-app

Relying Party

OpenID Provider

1. Request Service

2. Redirect to OpenID Provider3. Sign in

4. Authenticate End-User

5. Access Token

Figure 4.1: Overview of the system model.

4.2 Problem Identification and Motivation

Creating an eID solution is a challenging task, that requires a number of different prob-lems of various nature to be solved. This task has many dimensions and within the scopeof this thesis, the focus will be on solving the identified problems with technical solu-tions. The following problems have been identified:

1. SAML 2.0 requires that the User Agent is a web browser [71]. This means that SAML2.0 is not future-proof, because devices without a web browser would not be ableto be used.

2. The End-User is not assured that the authentication is made to the intended serviceand session.

4.3 Define the Objectives for a Solution

For the design proposal the following requirements were specified:

1. Confidentiality: the logged service request of the End-User SHALL NOT be expos-able at a single point.

2. Integrity: requests and authentication SHALL be protected against unauthorizedmodifications.

3. Accountability: it MUST be possible to determine which eID certificate that was usedto sign an Authentication Request.

4. Authentaction:

(a) the Relying Party MUST be assured that the End-User is in possession of theclaimed eID certificate.

(b) the End-User MUST be assured that the authentication is made to the intendedservice and session.

5. eID certificate revocation:

CHAPTER 4. THE DESIGN PROPOSAL 23

(a) an eID Certificate SHALL be revocable.

(b) a revoked eID certificate SHALL NOT be trusted.

4.4 Assumptions

A number of assumptions have been made regarding the system and the surroundingenvironment. In order for the system to work the following must apply:

1. The Relying Party and the OpenID Provider trust each other and have exchangedcertificates.

2. The End-User is registered at the OpenID Provider. At the time for registration theEnd-User has distributed its eID certificate and the OpenID Provider is able to vali-date the End-User by a challenge-response authentication.

3. The eID-app has a pre-installed root certificate and is able to trust the OpenID Providerscertificate.

4. When the eID-app is installed, the a client certificate (for the eID-app) is installed.This certificate is tied to the End-Users identity at the OpenID Provider.

4.5 Delimitations

Within the scope of this thesis a number of delimitations have been made. The problemof ensuring sufficient availability and making the system robust against denial-of-serviceattacks has not been taken into account. Availability is by no means an unimportant as-pect of an eID solution, rather the opposite. It is of great importance that the End-Usersare able to authenticate in order to utilize the underlying service. Hence a disruption ofthe eID service could have a big impact on the availability and affect many services. De-spite this it will not be taken into account, because it could be handled separately fromthe rest of the solution.

The eID solution will not take the signing of electronic information or documents intoconsideration. The solution will only concern the process of logging in to a Relying Party.The authentication flow and the mechanics are adapted to this process. The process ofsigning electronic information or documents can be performed with a similar flow, butthis will be outside the scope of this design proposal and will not be discussed further inthis thesis.

The underlying technologies like OpenID Connect, OAuth etc. will not be analyzedand will be trusted to work as expected. The analysis of each underlying technology is acomplex and comprehensive task that will not be included in this work. The underlyingtechnologies are open source and they are therefore under constant review.

4.6 Overview

The eID solution design proposal was designed through an iterative process where theobjectives of the solution described in Section 4.3 was carefully taken into account foreach design choice. The reason behind each design choice is discussed in Section 6.8.


The solution is based on the Hybrid Flow specified by the OpenID Connect 1.0 speci-fication [25] explained in Section 2.4. All the messages in the flow SHALL be signed andencrypted and the communications between the parties MUST employ TLS with serverauthentication in accordance with the latest recommendations published by OWASP [49].The eID solution flow is described in Section 4.6.4. The authentication mechanism isbased on a two channel solution, where the End-User first enters his credentials in theUser Agent and then uses the eID-app to complete the authentication described in Sec-tion 4.6.7.

4.6.1 OpenID Provider

The OpenID Provider (OP) is responsible for receiving the Authentication Request, au-thenticating the End-User and respond with the ID Token and the Access Token. The fol-lowing listed requirements MUST be fullfilled by the OpenID Provider:

• The OpenID Provider MUST only accept one request at the time and parallel re-quest should not be handled.

• Each request SHALL also be bound to a Session ID and in order to authenticate therequest the corresponding Session ID MUST be provided by the eID-app.

• The OpenID Provider MUST store all the authentications together with informa-tion about the eID certificate the End-User used to be authenticated and be able tolink the authentication with the Access Token sent to the service. In order to fulfillthis the OpenID Provider MUST store the signature of the Authentication Requestlinked to the secure hash value of the Access Token and ID Token.

• The OpenID Provider SHALL NOT store the Access Token, the ID Token, or theAuthentication Request and it SHALL NOT be able to link the authentication witha particular Relying Party.

• It SHALL only store information, so that if it is presented with a previously issuedAccess Token, it should be able to link it to the particular authentication resultingin issuance of the Access Token.

• During the authentication the OpenID Provider MUST check that the End-Userscertificate is valid and not revoked.

4.6.2 Relying Party

The Relying Party is responsible for redirect the End-User to the right OpenID Providerand wait for an Authorization Code. The Authorization Code will then be exchanged foran Access Token at the OpenID Provider. The Relying Party MUST store the Access To-ken, ID Token linked with the Authentication Request, together with information aboutthe service request performed by the End-User.

4.6.3 eID-app

The eID-app is a mobile app that is installed on a smartphone and is used to get Au-thentication Requests from the OpenID Provider and authenticate with the installed eIDcertificate. The following requirements MUST be fulfilled:


• The smartphone SHOULD have either Secure Enclave or Trusted Execution Environ-ment described in Section 2.5.5.

• The private key SHALL be locked with multi-factor authentication of at least some-thing you know (described in Section 2.6.1) and something you are (described in Sec-tion 2.6.3).

4.6.4 The eID Solution Flow

The flow of the eID solution is described in figure 4.2 and all steps are explained on thepage following the figure.


End-User eID-app User Agent Relying Party OpenID Provider

1. Request Service A

2. Request Service A

3. Redirect to OpenID Provider

4. Authentication Request for Service A

5. Please enter username and password

6. Please enter username and password

7. Username and password

8. Username and password

9. Please use eID-app to authenticate. Enter Session ID: x

10. Please use eID-app to authenticate. Enter Session ID: x

11. Launch eID-app and enter Session ID: x

12. Get Authentication Requests

13. Authentication request

14. Present Authentication Request for End-User

15. Accept Authentication Request

16. Signed Authentication Request

17. Response that the authentication is accepted

AuthenticationAuthentication Described in detail in Section 4.6.7

18. Present result for End-User19. Get Authorization Code and ID Token including signature

20. Authorization Code and ID Token including signature

21. Authorization Code and ID Token including signature

22. Send Authorization Code request ID + Access token

23. ID + Access token24. Requested service A

25. Present result

Figure 4.2: The Protocol Flow of the eID Solution.


All steps of the flow in figure 4.2 are explained in the following list:

1. The End-User requests service A through the User Agent.

2. The User Agent sends the requests to the Relying Party.

3. The Relying Party redirects the User Agent to the OpenID Provider (OP) with anAuthentication Request as specified in Section 4.6.5.

4. The User Agent use the Authentication Request to request authentication from theOpenID Provider for service A.

5. The OpenID Provider response to the User Agent with information that the End-User should enter username and password. (The password is used in order to pro-tect against unauthorized initiation of Authentication Requests at the OpenID Provider.)

6. The User Agent presents the information for the End-User.

7. The End-User enter username and password.

8. The User Agent sends the credentials to the OpenID Provider. If the username andpassword are valid, the OpenID Provider creates a challenge.

9. The OpenID Provider respond that the End-User should authenticate with the eID-app and enter Session ID x.

10. The User Agent presents the information for the End-User and possibly launchesthe eID-app if the User Agent and the eID-app is working on the same device, inthis case the Session ID should preferable also be passed to the eID-app.

11. The eID-app is launched.

12. The eID-app requests the Authentication Request from the OpenID Provider.

13. The OpenID Provider respond with the Authentication Request.

14. The eID-app presents the information about the Authentication Request for theEnd-User.

15. The End-User reviews the information and accepts the Authentication Request.

16. The eID-app signs the Authentication Request with the eID Certificate and sendsthe signature to the OpenID Provider.

17. The OpenID Provider verifies the signature and responses that the authentication isaccepted.

18. The eID-app presents the information for the End-User and redirect it back to theUser Agent.

19. The User Agent requests the Authorization Code and ID Token from the OpenIDProvider.

20. The OpenID Provider respond with the Authorization Code and ID Token aftersuccessful authentication through the eID-app and redirects the User Agent backto Relying Party.


21. The User Agent is redirected back to the Relying Party and sends the AuthorizationCode to the Relying Party.

22. The Relying Party sends the Authorization Code to the OpenID Provider in ex-change for End-User ID Token and Access Token.

23. The OpenID Provider respond with the End-User’s ID Token and Access Token tothe Relying Party.

24. The Relying Party respond to the User Agent with the requested service A.

25. The User Agent presents the result for the End-User.

4.6.5 Authentication Request

The Authentication Request is specified in the OpenID Connect specification [25] and uti-lized by the Relying Party in order to request authentication of the user. For this designproposal the following parameters are used in the way specified in the table 4.1. Notethat some extensions of the OpenID Connect are made: the authorization_info pa-rameter is added specified in table 4.2 and some scope values specified in table 4.3.


Table 4.1: The parameters are REQUIRED in the Authentication Request.

Parameter Example Value Description

scope openid openid is REQUIRED.

response_type code id_token The parameter value codeid_token specifies thatthe Hybrid Flow is usedand the Access Code andID Token will be sent backvia the User Agent from theOpenID Provider.

client_id foobar Unique ID of the RelyingParty, set up at the OpenIDProvider.

redirect_uri https://client.foobar.org/cb URI of where to send theresponse. https:// MUSTbe used in order to utilizeTLS.

state bf0efj8ldkj Some opaque value used tomaintain the state betweenthe request and the callback.

nonce z-0w6_Wzr8Jd This value should be a aper-session state value thatis unguessable by attackers.

request <JWT> Information sent as a JWE(base64 encoded) in theAuthentication Request,encrytped and signed by theRelying Party.

In addition to the REQUIRED parameters above, the parameters listed in table 4.2 arealso REQUIRED in the request parameter JWT.


Table 4.2: Additional parameters REQUIRED in the request (JWT) of the Authentication Request.

Parameter Example Value Description

iss foobar The issuer is the ID of theRelying Party.

aud https://server.oidc.com The OpenID Provider’sIssuer Identifier URL.

claims <JSON> Claims are request of infor-mation about the End-User,specified in the table 4.3.

authorization_info <JSON> Information to be displayedin the eID-app, in order forthe End-User to be able tomake an informed decision.Extension of the OpenIDConnect specification.

In the table 4.3 are OPTIONAL Claims that the Relying Party could request in the claimsparameter of the request JWT.

Table 4.3: This table list the OPTIONAL Claims that can be requested for the id_token in therequest parameter.

Parameter Description

profile Default claims according to the OpenID Connect specification.email Email according to the OpenID Connect.address Address according to the OpenID Connect.phone Phone according to the OpenID Connect.spin The End-User’s Swedish personal identity number. Extension of the

OpenID Connect specification.uname The End-User’s username. Extension of the OpenID Connect specification.

Figure 4.3 shows an example of the HTTP 302 redirect response sent from the RelyingParty to the User Agent. Which triggers the User Agent to make an Authentication Re-quest to the OpenID Provider. Note that the requests parameter is a JWE, that is en-crypted and signed by the Relying Party.


HTTP/1.1 302 FoundLocation: https://server.oidp.com/authorize?

scope=openid&response_type=code%20id_token&client_id=foobar&redirect_uri=https%3A%2F%2Fclient.foobar.org%2Fcb&state=bf0efj8ldkj&nonce=z-0w6_Wzr8Jd&request=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXRSJ9.eyJzY29wZSI6Im9wZW5pZCBzcGluIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJjbGllbnRfaWQiOiJmb29iYXIiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL2NsaWVudC5mb29iYXIub3JnL2NiIiwic3RhdGUiOiJiZjBlZmo4bGRraiIsIm5vbmNlIjoiei0wdzZfV3pyOEpkIiwiaXNzIjoiZm9vYmFyIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIub2lkYy5jb20iLCJjbGFpbXMiOnsiaWRfdG9rZW4iOnsic3BpbiI6eyJlc3NlbnRpYWwiOnRydWV9fX0sImF1dGhvcml6YXRpb25faW5mbyI6eyJhY3Rpb24iOiJzaWduX2luIiwic2VydmljZSI6IkZvb0JhciJ9fQ.vlc4BHdkOsjK9xffmmV4NRi5PMnhOfc71euCNZUHfrs

Figure 4.3: HTTP 302 redirect response to trigger Authentication Request.

Figure 4.4 shows the request parameter, base64 encoded JWE in the Authentication Re-quest in figure 4.5.


{"scope": "openid spin","response_type": "code id_token","client_id": "foobar","redirect_uri": "https://client.foobar.org/cb","state": "bf0efj8ldkj","nonce": "z-0w6_Wzr8Jd","iss": "foobar","aud": "https://server.oidc.com","claims":{

"id_token":{

"spin": {"essential": true}}

},"authorization_info":{

"action": "sign_in","service": "FooBar"

}}

Figure 4.4: The JWT request parameter.

The following figure 4.5 is the corresponding example (triggered by the redirect in fig-ure 4.3) of the request that would be sent from the Relying Party to the OpenID Provider.


GET /authorize?scope=openid%20spin&response_type=code%20id_token&client_id=foobar&redirect_uri=https%3A%2F%2Fclient.foobar.org%2Fcb&state=bf0efj8ldkj&nonce=z-0w6_Wzr8Jd&request=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXRSJ9.eyJzY29wZSI6Im9wZW5pZCBzcGluIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJjbGllbnRfaWQiOiJmb29iYXIiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL2NsaWVudC5mb29iYXIub3JnL2NiIiwic3RhdGUiOiJiZjBlZmo4bGRraiIsIm5vbmNlIjoiei0wdzZfV3pyOEpkIiwiaXNzIjoiZm9vYmFyIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIub2lkYy5jb20iLCJjbGFpbXMiOnsiaWRfdG9rZW4iOnsic3BpbiI6eyJlc3NlbnRpYWwiOnRydWV9fX0sImF1dGhvcml6YXRpb25faW5mbyI6eyJhY3Rpb24iOiJzaWduX2luIiwic2VydmljZSI6IkZvb0JhciJ9fQ.vlc4BHdkOsjK9xffmmV4NRi5PMnhOfc71euCNZUHfrs

Host: server.oidp.com

Figure 4.5: The Authentication Request sent by the User Agent.

4.6.6 ID Token

The ID Token is specified in the OpenID Connect specification [25] and issued by theOpenID Provider corresponding to the Authentication Request made by the RelyingParty. The OpenID Provider issues the ID Token after the authentication and authoriza-tion of the End-User. For this design proposal the Claims are used in the way specifiedin the table 4.4. Note that the extensions of the OpenID Connect specification specified intable 4.3 must be extensions of the ID Token as well.


Table 4.4: The Claims are REQUIRED in the ID Token.

Claim Example Value Description

iss https://server.oidp.com Issuer Identifier for the Issuer of theresponse.

sub u101 Subject identifier. An identifier for theEnd-User within the Issuer. This valueare not allowed to be reassigned.

aud foobar MUST contain the client_id.

exp 131328241 Experation time, when the ID TokenMUST NOT be accepted for processing.

iat 131329241 Time when the ID Token was issued.

auth_time 131329240 Time when the Authentication of theEnd-User was performed.

nonce z-0w6_Wzr8Jd Nonce to associate the Relying Partysession with the ID Token.

acr loa_3 Level of Assurance.

c_hash <hash value> Hash value of the Access Code.

spin 121212-1212 The End-User’s Swedish personal iden-tity number. Extension of the OpenIDConnect specification.

uname tolvan12 The End-User’s username. Extension ofthe OpenID Connect specification.

Figure 4.6 is the an example response of an ID Token and Access Code response from theOpenID Provider.

HTTP/1.1 302 FoundLocation: https://client.example.org/cb#code=Zcb0grv1zh3gvL1aPRsbm-diHsMwcsLyZvn1grpZv-Jxf_11jgpEe3Tgfv&id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXRSJ9.eyJpc3MiOiJodHRwczovL3NlcnZlci5vaWRwLmNvbSIsInN1YiI6InUxMDEiLCJhdWQiOiJmb29iYXIiLCJleHAiOjEzMTMyODI0MSwiaWF0IjoxMzEzMjkyNDEsImF1dGhfdGltZSI6MTMxMzI5MjQwLCJub25jZSI6InotMHc2X1d6cjhKZCIsImFjciI6ImxvYV8zIiwiY19oYXNoIjoiNGlVM1Bid2NkVWMvdHlHL1ZjbEIrQSIsInNwaW4iOiIxMjEyMTItMTIxMiJ9.7k1GzSauoZMX8idoZMZ93mO_mtGF4Rzg1svqIzz29EI&state=bf0efj8ldkj

Figure 4.6: Example of the Claims in the ID Token.


In figure 4.7 an example of Claims in the ID Token, included in the id_token JWT infigrue 4.6.

{"iss": "https://server.oidp.com","sub": "u101","aud": "foobar","exp": 131328241,"iat": 131329241,"auth_time": 131329240,"nonce": "z-0w6_Wzr8Jd","acr": "loa_3","c_hash": "4iU3PbwcdUc/tyG/VclB+A","spin": "121212-1212"

}

Figure 4.7: Example of the Claims in the ID Token.

4.6.7 Authentication

The authentication of the End-User, in compliance with the Authentication Request initi-ated by the Relying Party, is performed with the use of the eID-app. This operation con-sists of the following steps:

1. The End-User launches the eID-app and provides it with the Session ID. This Ses-sion ID MUST correspond to the Session ID of the session started at the RelyingParty.

2. The eID-app performs a mutual TLS authentication with the OpenID Provider. TheeID-app use the client certificate in order to perform the mutual TLS authentica-tion. After the TLS tunnel is established, the eID-app will send the session to theOpenID Provider.

3. The OpenID Provider look up the last Authentication Request for the End-User,specified by the client certificate and checks that the Authentication Request is stillvalid (not expired). If it is still valid, the OpenID Provider validates that the SessionID form the eID-app is equal to the Session ID of the Authentication Request.

(a) If the Authentication Request and the Session ID is valid, the OpenID Providerwill send the information Authentication Request to the eID-app. The authen-tication will continue to the next step.

(b) Otherwise it will send an error message to the eID-app and cancel the authen-tication.

4. The information of the Authentication Request will be presented for the End-Userby the eID-app. The information MUST be sufficient, in order to let the End-Usermake an informed decision. The End-User can either accept or deny the Authenti-cation Request.


(a) If the End-User accepts the Authentication Request, he has to unlock the eIDcertificate. The eID certificate SHOULD be unlocked by multi-factor authenti-cation, presented by the End-User to the eID-app. The authentication of Au-thentication Request will be performed by a challenge response described inSection 4.6.8.

(b) If the End-User denies the Authentication Request, it SHALL be marked bythe OpenID Provider as handled. It SHALL NOT be possible to accept a de-nied Authentication Request. The response that the Authentication Request isdenied by the End-User is sent to the OpenID Provider and the authenticationis canceled.

5. The OpenID Provider register the response and issues an Access Token. The OpenIDProvider MUST store information in order to be able to prove which Authenticationthat correspond to the issued Access Token. The OpenID Provider also marks theAuthentication Request as handled.

Note that the Authentication Request is only valid for a limited amount of time. Whenit has expired it SHALL NOT be possible to request the Authentication Request from theOpenID Provider and it SHALL NOT be possible to authenticate the Authentication Re-quest. It SHALL NOT be possible for a Authentication Request marked as handled, to beprocessed again. All Authentication Request MUST only be possible to handle at mostonce.

4.6.8 Authentication with eID Certificate

The authentication is a plain Challenge-Response authentication, where the End-User’seID certificate is used to sign the Authentication Request. Prior to the signing of the Au-thentication Request, the steps 1 to 4 (a) described in Section 4.6.7 is performed. Thismeans that the eID-app and the OpenID Provided have setup a secure communicationtunnel with the use of mutual TLS. The End-User has provided the right Session ID andaccepted the Authentication Request sent from the OpenID Provider. The challenge con-sist in signing the Authentication Request with the eID certificate and respond to theOpenID Proivder with the signature, as described in figure 4.8.

eID-app OpenID Provider

1. Sign Authentication Request

2. Signature

3. Verify Signature

4. Result

Figure 4.8: Challenge-Response procedure.


All steps in the authentication flow in figure 4.8 are explained in the following list:

1. The Authentication Request is signed with the eID certificate. Note that the Au-thentication Request include a cryptographically nonce with per-session state valuemaking it resistant against replay attacks.

2. The signature is sent to the OpenID Provider.

3. The OpenID Provider verifies the signature.

4. The result of the verification is sent to the eID-app.

4.7 Proof of Concept

In order to evaluate if the design proposal is feasible, a proof of concept solution wasimplemented. The proof of concept is built on the library MITREid Connect [72] that is acustomizable Java-based open source certified [73] reference implementation of OpenIDConnect. MITREid Connect uses Spring Security [74] framework for the End-User au-thentication mechanics which is not specified by the OpenID Connect specification [25].MITREid Connect was chosen based on the following:

• It is an open source library, making it customizable.

• It is a certified library, making it more trustworthy.

• It is a reference implementation, which implies that the implementation is intendedto comply with the OpenID Connect specification.

• It is based on Spring Security, making it possible to customize the End-User au-thentication mechanics.

4.7.1 Overview

The proof of concept works as follow:

1. The End-User requests login by the User Agent at the Relying Party and chooses toauthenticate via the proof of concept OpenID Provider (OP).

2. The End-User is redirected to the OpenID Provider.

3. The End-User is presented a random Session ID and a login form.

4. The End-User enters his credentials.

5. The End-User launches the eID-app and enters the credentials together with theSession ID presented by the OpenID Provider.

6. If the credentials and the Session ID is legitimate, the server will reply with a chal-lenge.

7. The End-Users eID-app respond to the challenge.

8. If the response is valid the End-User will be logged in at the User Agent.


4.7.2 Authentication Provider

The Spring Security framework utilizes authentication providers [75] in order to implementthe authentication. A custom authentication provider was developed that have the fol-lowing authentication mechanics:

1. The End-User submits an authentication request with its credentials.

2. Pre-authentication of the End-User is performed by validating the credentials. If thecredentials are valid, the OpenID Provider will create a challenge with an associateSession ID presented to the End-User in the database.

3. The authentication provider then waits for the challenge to be handled.

4. If the challenge is handled before the authentication provider times out, the re-sponse to the challenge will be verified by the authentication provider.

5. If the response is correct the End-User will be logged in. In all other cases the End-User will get the information that he was not able to be logged in.

Chapter 5

EvaluationIn this chapter the design proposal and the proof of concept are evaluate against the requirementsspecified in Section 4.3. The evaluation was conducted as an analysis, concerning to which extentthe different requirements are fulfilled and how the different potential abuse scenarios are mitigated.

5.1 Confidentiality

The confidentiality is ensured as long as the OpenID Provider works as expected. If theOpenID Provider is compromised, the confidentiality cannot be ensured, because all traf-fic containing the Authentication Requests and responses is passed through the OpenIDProvider. If the assumption is made that the OpenID Provider is not compromised andwork as expected, then the End-Users Authentication Requests are only stored with ref-erences to the Access Token. The Access Token is not stored at the OpenID Provider andthereby, the information about which service the End-User has authentication against isnot stored centrally. Instead each Relying Party is responsible for storing the Access To-kens. The information about which services the End-User has authenticated to thereby isspread out over the Relying Parties.

All communications between the different parties SHALL be secured by TLS and thetokens SHALL also be secured by the use of JWE described in Section 2.4.4.

5.2 Integrity

The use of JWE adds in addition to confidentiality by encryption, also integrity as de-scribed in Section 2.4.4. The use of the hybrid flow (described in Section 2.4) ensures theintegrity of the Authorization Code, because c_hash value in the ID Token is calculatedover the Authorization Code and is validated by that the Relying Party. This protectsagainst Authorization Code substitution, where an attacker could exchange one Autho-rization Code against another valid Authorization Code it has get hold of.

5.3 Accountability

The accountability regarding the authentication with the eID is ensured by a chain start-ing at the Relying Party. The Relying Party is responsible for proving which Access To-ken that was used for each request. In order to maintain this requirement the RelyingParty SHALL store each Access Tokens corresponding to the Authentication Request so

39

40 CHAPTER 5. EVALUATION

that it can trace the interaction from each End-User. The Access Token, ID Token in com-bination with the corresponding Authentication Request, could be used to trace the eIDused by the End-User through the OpenID Provider. The OpenID Provider MUST storethe signature of the Authentication Request made with the eID of the End-User linkedwith the secure hash of the Access Token and the ID Token issued to the Relying Party.The Relying Party stores the Authentication Request, the Access Token, and the ID Tokenand can present it to the OpenID Provider. The OpenID Provider is able to calculate thesecure hash values of Access Token and ID Token linking it to the signature of made bythe End-User’s eID certificate. If the signature is correct for the Authentication Request,the End-User is responsible for the issuance of the Access Token and ID Token and theaccountability is thereby ensured as long as the Relying Party and the OpenID Providerfulfills their commitments.

5.4 Authentication

In order to ensure the Relying Party that the End-User is in possession of the claimedeID, the Relying Party does have to rely on the OpenID Provider. If the OpenID Providerperforms its duty as expected, it should only issue an Access Token after an acceptedauthentication preformed with the End-User’s valid eID. The OpenID Provider MUSTstore enough information in order to be able to prove that the claimed eID was used.This is the signature of the Authentication Request made by the End-User with the useof the eID-app.

When the End-User is authenticating with the eID-app, the End-User has to includethe Session ID, connecting the authentication with the session initiated at the RelyingParty. This ensures the End-User that the authentication is made to the intended RelyingParty and the intended session.

The eID-app is presenting all information needed for the End-User to make an in-formed decision regarding, if the authentication should be accepted or not. This informa-tion is securely passed from the Relying Party via the OpenID Provider to the eID-appwithin the Authentication Request. If the End-User decides to accept the authentication,then the Authentication Request will be signed with the eID certificate of the End-User.Only the End-User will be able to sign the Authentication Request with the eID and inthis way the End-User is authenticated by the OpenID Provider.

5.5 eID Certificate Revocation

The eID is validated at the OpenID Provider by a challenge response. During the chal-lenge response the OpenID MUST check that the eID certificate still is valid, this willalso include to verify that the eID certificate have not been revoked. If the eID certifi-cate have been revoked it SHALL NOT be trusted. As long as the certificate revocationlist, described in Section 2.5.4, is updated and the OpenID Provider checks the certificateagainst the certificate revocation list, will it be possible to revoke an eID certificate andthe revoked eID certificate will not be trusted.

CHAPTER 5. EVALUATION 41

5.6 Model of Adversary and Potential Abuse Scenarios

A number of different attacks, by a number of various adversaries, could be launched inorder to try to exploit the design proposal. Below is a diversity of attacks and potentialscenarios described.


MITM is an attack described in Section 2.5. In the protocol flow there are four placeswhere a MITM could place itself, between: the User Agent and the Relying Party, theUser Agent and the OpenID Provider, the eID-app and the OpenID Provider, and theRelying Party and the OpenID Provider. In the list below will all the four cases be evalu-ated:

• Between the User Agent and the Relying Party: the communication between the UserAgent and the Relying Party MUST be secured with TLS in accordance with thelatest recommendations published by OWASP [49]. TLS will protect against MITMattacks between the User Agent and the Relying Party, because the server will pro-vide its certificate and a secure communication will be established between the par-ties. This eliminates the risk for a MITM attack between the User Agent and theRelying Party, as long as all the installed root certificate in the User Agent could betrusted. The User Agent is typically not a secure environment and malicious certifi-cates could be installed and if the User Agent is an ordinary web browser there isgenerally a large number of certificates of different kinds installed which increasesthe risk [65].

• Between the User Agent and the OpenID Provider: the communication between the UserAgent and the Relying Party MUST be secured by TLS in the same way as betweenthe User Agent and the Relying Party. The same applies for this situation as for thesituation between the User Agent and the Relying Party.

• Between the eID-app and the OpenID Provider: the communication between the eID-app and the OpenID Provider MUST be secured by mutual TLS in compliance withthe latest recommendations published by OWASP [49]. The eID-app has a root cer-tificate pre-installed, in or to be able to authenticate the OpenID Provider and theOpenID Provider has a root certificate installed, in order to authenticate the eID-app. The communication between the eID-app and the OpenID Provider is there-fore protected against MITM. It should be added that the eID-app does not shareroot certificate with the system, the web browser, or, the User Agent.

• Between the Relying Party and the OpenID Provider: the communication between theRelying Party and the OpenID Provider MUST utilize TLS in accordance with thelatest recommendation published by OWASP [49], this will protect against MITMattacks. In addition to this will the ID Tokens and the Access Token be signed andencrypted utilizing JWE. The use of JWE will protect against MITM between theRelying Party and the OpenID Provider, even when the User Agent is an intermedi-ate party where the TLS tunnel is terminated.

The countermeasures in order to protect against MITM are based on the use of TLS forall connections between the different parties. TLS is assumed to work as expected and

42 CHAPTER 5. EVALUATION

MUST follow the latest recommendations published by OWASP [49]. The use of TLS bythe User Agent will not completely protect against MITM because TLS is relying on thecertificates installed in the User Agent. The User Agent is typically not a secure environ-ment where malicious certificate could be installed and if the User Agent is an ordinaryweb browser there is generally a large number of certificates of different kinds installedwhich increases the risk [65]. This is, however mitigated by the use of a two channel so-lution. The End-User is authenticated by the use of the eID-app, if an MITM has inter-cepted this would be displayed for the End-User through the information presented inthe eID-app. In addition to this the use of JWE will add an extra layer of protections, be-cause the Authentication Request and ID Token passing the User Agent sent between theRelying Party and the OpenID Provider is encrypted and signed.


MITB described in Section 2.7.2, is another security threat with the similar characteris-tics as MITM, but in contrast TLS will not be able to protect against this attack. The rea-son for this is simply that, the MITB is able to take control of all information sent to andfrom the User Agent and the information sent in the TLS tunnel is decrypted at the UserAgent. The MITB will therefor be able to read the decrypted information and manipulateit.

The design proposal counter the MITB attack by utilizing a Out-of-Band Detail Con-formation. This is done through a two channel solution, by the use of the eID-app witha separate communication channel in order to exchange information with the OpenIDProvider. The details of the action performed in the User Agent are present to the End-User by the eID-app. This means that if the MITB performs any changes, this will be dis-coverable for the End-User before accepting the Authentication Request in the eID-app.

An additional countermeasure is the use of JWE for the Authentication Request. Thismeans that the Authentication Request are encrypted and signed by the Relying Party.The JWE is not decrypted at the User Agent and passed as encrypted information to theOpenID Provider, where it is decrypted. A MITB would therefor not be able to changethe Authentication Request even though the TLS encryption is terminated at the UserAgent.

5.6.3 Replay Attack

The Replay Attack, as described in Section 2.7.3, is mitigated by the use of nonce in theAuthentication Request. A replay of a captured message would not result in an valid au-thentication, because of the use of nonce in the Authentication Request. Every Authen-tication Request include a per-session state value that is unguessable to attackers. If anattacker reuse any captured messages this will be discovered by the fact that the nonce isreused.


The cut and pasted code attack, as described in Section 2.7.4, is the reason for using theHybrid Flow. The Hybrid Flow in the design proposal is configured to send the Autho-rization Code and the ID Token via the User Agent to the Relying Party. The ID Token

CHAPTER 5. EVALUATION 43

include a hash value of the Access Code and the ID Token is signed, this means that theintegrity of the Access Code is protected and the cut and pasted code attack mitigated.


There are two countermeasures in order to prevent against the known Social Engineer-ing attack described in Section 2.7.5. The first countermeasure is to present informationfor the End-Users in the eID-app of what they authenticate. The second countermeasureis to assign the authentication made in the eID-app with the session in the User Agent.These two countermeasures together ensure that the End-User is informed about the con-sequences of the authentication.

5.6.6 Relatives and Related Persons

People in close contact with the End-User could possible get hold of the smartphone,with the installed eID-app. In order to stop them from using the eID-app and the eID ofthe End-User, the private keys of the End-User’s eID MUST be protected. This should bemet by the eID-app protecting the private keys with both something you know and some-thing you are. At the moment Secure Enclave described in Section 2.5.5 does not offer thecombination of these two authentication methods, this is at the moment a limitation ofthe design solution. Either something you know or something you are could be utilized in or-der to protect the private keys by the uses of the Secure Enclave.

Chapter 6

DiscussionThis chapter discusses the outcome of the evaluation performed in the previous chapter and puts theresult of the evaluation into context.

6.1 Confidentiality

The confidentiality of which Relying Party the End-User authenticate against, is of greatimportance, because this would otherwise lead to a potential security risk for the End-User. Where the authentication history could be extracted from the OpenID Provider re-vealing to which Relying Parties the End-User has authenticated. If the Relying Party,the End-User is authenticating against, is some type of sensitive service, a leakage ofthe information could be troublesome for the End-User. The OpenID Provider SHALLtherefore NOT store information making it possible for the OpenID Provider to extractwhich Relying Parties the End-User has authenticated to. If the OpenID Provider is com-promised, it would of course be possible to monitor all the Authentication Requests andthereby be able to track the End-Users and the confidentiality would be jeopardized. Butat the same time if the OpenID Provider is compromised the eID solution is failing innearly all aspects of security. The most important single point of the eID solution is theOpenID Provider and it should be configured, handled, and monitored in a way, makingit nearly impossible to compromise without getting noticed.

As described in Section 5.1 the confidentiality is enforced by configuring the OpenIDProvider to not store information about the authentications made by a End-User linkinghim to the Relying Party. At each Relying Party the Authentication Request, the ID To-ken, and the Access Token SHALL be stored, but not the authentication made with theEnd-User’s eID. This means that the overall authentication history will not be stored ata single point and it will be significantly harder to monitor a End-User’s authenticationbehavior.

6.2 Integrity

The integrity of the messages are secured by the use of TLS and JWE in combinationwith the hybrid flow as described in Section 5.2. These three countermeasures will re-sult in that the messages sent between the parties are sent through TLS tunnels as signedJWE messages and thereby manipulations of these messages will be discovered.

44

CHAPTER 6. DISCUSSION 45

6.3 Accountability

The accountability will be dependent on that the Relying Party and the OpenID Provideract as intended. This is also a matter of setting up agreements between the parties re-garding what and how long the information needs to be stored, in order to secure theaccountability. Typically, the Relying Party has to store enough information to be able toprove that the OpenID Provider has issued the Access Token. The OpenID Provider hasto store enough information to prove that the Access Token was issued corresponding toan authentication made by the End-User with the eID certificate. The OpenID Providershould preferable also store some information of the eID certificate used to perform theauthentication.

6.4 Authentication

The authentication should be performed by the OpenID Provider and the OpenID Providermust be trusted by the Relying Party. If the OpenID Provider is compromised the secu-rity of the whole solution is failing. The OpenID Provider has to be protected and moni-tored by the highest standards in order to provide a safe solution.

The goal of the solution is to make it nearly impossible for the End-User to authen-ticate to the wrong Relying Party or wrong session. If the End-User is fooled or by mis-take authenticates to the wrong Relying Party or session it could actually result in seri-ous consequences for the End-User. For instance if the End-User is trying to authenticateto Relying Party A and session X and instead authenticates the session Y and the sessionY is initiated by a request made by a malicious attacker, the attack would be able to im-personate the End-User. By the use of a Session ID associated with the session started bythe End-User, the End-User could be confident that the right session is authenticated. Inthis way the attacker would not only have to fool the End-User to authenticate to the Re-lying Party A, he would also have to fool the End-User to authenticate a session that isnot corresponding to the session initiated by the End-User. A situation where the End-User is not able to tell which session that is authenticated should not be able to occur inthe proposed eID solution.

6.5 eID Certificate Revocation

The eID certificate has to be revocable because there is a number of circumstances thatwould result in the certificate being invalid before the time of expiration. The circum-stances could for example be that the eID has been stolen or compromised in some way.But it could also be the case that the End-User have disposed or sold the device (for ex-ample a smartphone) to which the eID was issued and the certificate is no longer at thehand of the End-User and SHALL be revoked. In order to invalidate the certificate itmust be added to the certificate revocation list and the OpenID Provider must utilize thecertificate revocation list. This might seem like a simple solution, but in reality this couldbe quite cumbersome. The list has to be updated frequently and it will affect the perfor-mance negatively as the list increase in size. The server also has to store when the certifi-cate was revoked. The reason is if the certificate is revoked and later on the accountabil-ity of some authentication should be traced, the OpenID Provider must be able to provethat the certificate was valid and not revoked at the time of authentication.

46 CHAPTER 6. DISCUSSION

6.6 Model of Adversary and Potential Abuse Scenarios

Different adversaries and potential abuse scenarios are discussed in the following sec-tions. Some of the abuse scenarios are mitigated by well established countermeasures,while others depend on the surrounding environment and are not considers to be withinthe scope of this work.


The resistance against MITM attacks are undoubtedly dependent on that the underlayingsecurity measures working as expected. In all communications between the different par-ties TLS is used in order to secure the communication. If we assume that TLS is workingas expected and only legitimate certificates are trusted, then this would effectively miti-gate against MITM attacks. Unfortunately, the User Agent cannot be counted as a secureenvironment and might trust malicious or compromised certificates, which could jeopar-dize the MITM protection obtained by TLS. This problem is rooted in the fundamentalproblem with the Certificate Authority Model [76].

In order to add extra protection, two additional countermeasures are added to thedesign proposal. First, the side channel used by the eID-app adds extra protection by in-forming the End-User regarding the consequences of the executed action. Secondly, theJWE add extra protection because the tokens are signed and encrypted at the RelyingParty and the OpenID Provider and decrypted at the receiving party. This way a MITMwould not be able to change or access the data even if the MITM is able to break theTLS. These protections together should result in good confidence in the MITM protec-tion.


MITB is a frequently used attack method today [65] and therefore important to protectagainst. TLS is not able to protect against MITB, because the TLS tunnel is terminatedat the User agent. The MITB is instead mitigated by the use of JWE and the side chan-nel in form of the eID-app receiving information directly from the OpenID Provider. JWEprotect the message integrity and in the eID-app is the End-User able to review the infor-mation and discover manipulations made by a MITB.

6.6.3 Replay Attack

The Replay Attack is an easy attack for an attacker that is able to eavesdrop the com-munication. This could be performed in different ways, but it is effectively mitigated bythe use of the nonce. As long as the nonce is a per-session state value, that is not guess-able by an attacker, it would protect against the Replay Attack. It is therefor of great im-portance that the nonce is implemented correctly and always validated by the receivingparty.


The cut and pasted code attack is a known attack and important to protect against. Thereis a number of different ways to protect against this attack. The most obvious is to pro-


tect the Authorization Code from leaking, this is nearly impossible and not practical inthis situation. The attack is instead mitigated by the use of the Hybrid Flow.


The design proposal could not assumed to be entirely protected against social engineer-ing, because there are various numbers of attacks and humans are sometimes easily fooled.But the two countermeasures of presenting clear information to the End-User via theeID-app and link the session in the User Agent to the authentication in the eID-app,should make it significantly harder for the adversary to fool the End-User to authenticatea session started by the adversary.

6.6.6 Relatives and Related Persons

The typical scenario would be that a person get hold of the smartphone with the eID-app installed. This person could try to perform an authentication with use of the eID-app. This would be prevented because the private keys of the eID certificate should belocked by multi-factor authentication of something you know for instance a password ora pin code and something you are for instance a fingerprint. If the adversary person insome way get hold of the secret (password or pin code) the adversary also have to foolthe End-User to place his fingerprint on the fingerprint reader or in some way bypassthe reader. The act of bypassing the reader, requires a sophisticated adversary, in orderto perform the attack in the short amount of time the End-User would leave his smart-phone unguarded. The use of multi-factor authentication in order to unlock the privatekeys of the eID certificate, should be regarded as sufficient to protect against attacks per-formed by relatives and related persons. The alternative of having an hard certificate (de-scribed in Section 2.5.4) would probably not add any extra security in this case, becauseif an attacker is able to get hold of the End-User’s smartphone, it would as well be ableto get hold of the hard certificate.

6.7 Proof of Concept

The design and development of the proof of concept lead to a number of insight regard-ing OpenID Connect and also influenced the design proposal. In order to develop theproof of concept, a number of different OpenID Connect libraries where examined, be-fore MITREid Connect [72] was chosen. The market of OpenID Connect libraries seemedquite immature regarding solutions for eID. The libraries are at the moment more fo-cused on pure web authentication for web sites.

The proof of concept was developed iteratively and during this process the need totie the session to the authentication by the eID-app was recognized. This resulted in theidea to introduce a Session ID, connecting the session initiated in the User Agent withthe authenticate performed through the eID-app.

6.8 Design Choices

The most fundamental design choice was to decide which OpenID Connect flow to basethe solution on. The reason to build the solution based on the Hybrid Flow are the com-bination of the characteristics of the flow being able to not revealing the Access Token to


the User Agent and provide a signature of the access code. This is a crucial advantageover the Authorization Code Flow, because it mitigates the Cut and Pasted Code Attackdescribed in Section 2.7.4. The Implicit Flow is not suitable for this kind of solution be-cause the Access Token is revealed to the User Agent as described in Section 2.4.

The design choice of utilizing a two channel solution and multi-factor authenticationin order to authenticate the End-User was made in order to be able to reach LoA3. Multi-factor authentication is required in order to reach LoA3 described in Section 2.2.

The reason for the design choice to develop a solution with an eID-app was basedon the findings of the literature study, which clearly shows an increasing usage and de-mand for mobile based solution. Also, Apple and Androids work with implementing asecure environment for the private keys of the certificate described in Section 2.5.5, hasprovided a more secure way of handling certificates without the need for hard certifi-cates described in Section 2.5.4. The design choice of disregarding the hard certificate ona smart card, was based on the fact that this adds extra complexity both implementa-tion wise and for the End-User. For instance a smart card would require a reader. Thedecision of not using a hard certificate means that the solution will not fulfill the require-ments for LoA4. The questions remain if the use of a hard certificate in practice wouldresult in extra security worth the extra complexity. The secure environment provided bymodern smartphones would for this practice certainly add enough protection against ex-traction of private keys. If we rely on this assumption, there is mainly one remaining ar-gument in favor for the use of a smart card. Namely, that the End-User would handlethe smart card with care and easily discover if it is stolen. However, one can argue thatthe same applies for a smartphone.

The Session ID is designed to make it possible for the End-User to determine whichsession the Authentication Request corresponds to. The solution is designed to only han-dle one request at the time and the request cannot be replied without providing the cor-rect Session ID. The Session ID could be implemented in a number of different ways. Ifthe User Agent and the eID-app is executed on the same device the Session ID shouldpreferable be passed by the User Agent to the eID-app. If the User Agent and the eID-app is executed on separate devices, a possibility would be to scan the code with thecamera of the smartphone. This would make it user friendly to utilize complicated Ses-sion IDs, by not forcing the End-Users to type them.

An alternative solution would be to not use Session IDs and instead rely on the factthat only one request can be handled at time. If more than one request is initiated by theUser Agent, all request should be canceled. This approach would however be vulnera-ble, because the End-User is not in control of which session that is authenticated. If forexample a third session is started after that the two first has been canceled, the End-Usercould be deceived to authenticate the third session.

The reason for divide the responsibility of accountability between the Relying Partyand the OpenID Provider is to increase the confidentiality of the End-Users authentica-tion history without losing the tractability. One possible solution in order to provide ac-countability would be to use the private key of the End-Users eID to sign some informa-tion that is passed all the way to the Relying Party. This would ensure the accountabil-ity in an easy and secure way. Nevertheless, would this risk of compromising the End-Users privacy. There may be situations when the End-User of an eID only want to sharesome personal data with the Relying Party. Desired extent of shared personal data couldeven change from time to time. If the eID is used to sign information sent to the Relying


Party, the Relying Party would be able to track the End-User in an undesirable manner.If instead the Relying Party only stores the Authentication Request, the Access Token andthe ID Token and the OpenID Provider only stores enough information to bind the thesethree to the End-User’s eID, is the only possibility to track the End-User if both the Re-lying Party and the OpenID Provider collaborates. This way the accountability is main-tained, but the End-User privacy is protected.

The authentication procedure is designed to be a simple mutual challenge-responseauthentication between the OpenID Provider and the eID-app. The protocol use sequencenumbers and random nonces in order to be resistant against replay and reflection at-tacks.

6.9 Level of Assurance

The proposed design solution will at most reach LoA3, because it does not use hard cer-tificates. The question still remains if this a reasonable requirement and if this in prac-tices add any crucial security. The LoA is based on a quite old standard and maybe theassumptions made back in 2013, is not still valid today. If the assumption is made that,one of the easiest attack against the solution is to steal the smartphone, would it be rea-sonable to assume that it is not significantly harder to also steal the smart card for a mo-tivated adversary. Most End-Users would probably handle these two objects with thesame level of caution, or even handle the smart card more carelessly then the smart-phone.

6.10 Sustainability and Ethics

Aspects of sustainability and ethics are constantly present concerning eID solutions. Thesolution have a direct economic impact, because a complex solution could result in highdevelopment and service costs. This will also have an indirect impact on the serviceprice for the End-User. The obvious question is also who should be able to issue eIDs.Should this be an open market or should it be strictly regulated by the government. Ifthe eID is issued by a private actor, is the actor allowed refuse the issuance to some citi-zens based on their own regulations. For instance BankID in Sweden is only issuing eIDto citizens who fulfill the requirements set by the bank [77]. This raises the question ifit is ethically right to discriminate citizens in such a way and indirectly refuse them theright to access certain electronic services of the public sector.

6.11 Societal Aspects

The eID solution is a fundamental cornerstone of the modern society and the societal as-pects is most unpredictable as the information age evolves. This work in essence, is thusof relevance, for a number of different parties. The technical part of this work is mainlyrelevant to issuers and the providers of eID solutions, thus they could gain insights sup-porting their work. In the long run this could even influence the direction of the futureeID solutions.

A transition to use of open international standards have the potential of creating syn-ergies and make eID solutions more cost effective, secure, and future-proof. The citizens


is probably not deeply interested in the technical aspects of the solution, but they are in-creasingly dependent on eID solutions and are most probably interested in the offer ofa secure, user friendly, and future-proof eID solution. An open solution would enhancetransparency and increase the trust from the citizens.

Chapter 7

ConclusionsThis chapter summarizes the findings of this thesis work.

The goal of this work was to determine if OpenID Connect would be suitable as the baseof an eID solution and to present a design proposal for an eID solution based on OpenIDConnect. In order to accomplish this goal, a number of requirements was formulated.Then a design proposal demonstrating how OpenID Connect could be utilized and anevaluation of the design proposal against the requirements was conducted. This showsthat OpenID Connect could be used as the base for an eID solution and that it fulfills therequirements. OpenID Connect is well suited for the task and the fact that it is an openstandard that builds on other well established and accepted open standards is advanta-geously. The standard is well suited and have the prerequisites in order to function asthe base in an eID-solution.

The main alternatives to OpenID Connect are OAuth and SAML. In this case there isno need to consider OAuth, because OpenID Connect is an extension of OAuth and iscapable of solving the same problems. SAML is a valid alternative and is used in manyeID-solutions and for eIDAS. SAML and OpenID Connect are actually quite close in theoverall flow, but SAML has the advantage of being a more mature and widespread. Onthe other hand, SAML has the drawbacks descendant from old design choices. For in-stance, the User Agent is assumed to be a web browser, which result in restrictions re-garding development and usability. When OpenID Connect was specified, the problemswith SAML was most likely taken into account and the mistake of making the assump-tion that the User Agent has to be a web browser does not apply for OpenID Connect.

The proof of concept served as a small scale demonstration of the feasibility of the so-lution, but also showed that there is much work left to be done when it comes to secur-ing the solution. It would certainly be fully possible to develop an eID solution based onOpenID Connect, but the question still remains, if now is the time. At one hand it couldbe better to wait for it to be more accepted by the eID community and acknowledged byThe Swedish E-identification Board. On the other hand, in order for OpenID Connect tobecome more accepted, the boarder has to be pushed by someone starting to develop eIDsolutions based on OpenID Connect.

To summarize the OpenID Connect standard is well suited for an eID-solution, butthe extent of the suitability is highly depending on the implementation. In short an eID-solution based on OpenID Connect satisfying the requirements is feasible.

51

Chapter 8

Future WorkThis chapter reflects over the work left to be done.

The field of eID is going through rapid changes and will most probably be faced withnew challenges in the near future. It is therefore important to try to be as prepared aspossible and try to foresee the problems we will be faced with in the future. One wayto be better prepared, is to design alternatives to the already established eID solutions.This work has presented an alternative based on OpenID Connect. This solution is notfully fledge and it remains a number of questions that needs to be answered in order tofurther develop this design proposal to a functional solution. Problems including:

• How should the eID be issued to the End-User?

• How should the End-User be able to transfer his eID from one device to another?

• How should the availability be ensured?

52

Bibliography

[1] Finansiell ID-Teknik BID AB. Detta är BankID, 2017. URL https://www.bankid.com/om-bankid/detta-ar-bankid. [Accessed: 2017-02-23].

[2] Malin Wemnell. Statistik BankID –användning och innehav - fördjupning, Januari2017, February 2017. URL https://www.bankid.com/assets/bankid/stats/2017/statistik-2017-01.pdf. [Accessed: 2017-02-23].

[3] Malin Wemnell. Statistik BankID –användning och innehav - fördjupning, Årsstatis-tik 2016, January 2017. URL https://www.bankid.com/assets/bankid/stats/2016/statistik-2016-12.pdf. [Accessed: 2017-02-23].

[4] Finansiell ID-Teknik BID AB. Om Finansiell ID-Teknik, 2017. URL https://www.bankid.com/om-oss. [Accessed: 2017-02-23].

[5] The Swedish E-identification Board. Om oss, 2017. URL http://www.elegnamnden.se/omoss.4.5a85666214dbad743ff81e3.html. [Accessed:2017-02-23].

[6] The Swedish E-identification Board. E-legitimationsnämndens Tekniskaramverk. Framework ELN-0600-v1.5, The Swedish E-identification Board,March 2017. URL http://www.elegnamnden.se/download/18.5c281c7015abecc2e20acb7/1490600991333/ELN-0600_-_Tekniskt_ramverk_-_Svensk_e-legitimation.pdf. [Accessed: 2017-05-15].

[7] P. Madsen et al. SAML V2.0 Executive Overview. Overview, April 2005. URLhttps://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf. [Accessed: 2017-02-23].

[8] OpenID Connect Fondation. OpenID Connect FAQ and Q&As, 2017. URL http://openid.net/connect/faq/. [Accessed: 2017-02-23].

[9] Malin Wemnell. Statistik BankID –användning och innehav, Årsstatistik 2015, Jan-uary 2016. URL https://www.bankid.com/assets/bankid/stats/2015/statistik-2015-12.pdf. [Accessed: 2017-02-24].

[10] Carol Geyer. SAML Specifications, October 2007. URL http://saml.xml.org/saml-specifications. [Accessed: 2017-02-24].

[11] Daniel Eran Dilger. Smartphones: iPhone and the Big Fat Mobile Industry, Jan-uary 2007. URL http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/BEC05CE1-D5EB-4E48-B46C-7385D5AADCFE.html. [Accessed: 2017-02-24].

53

https://www.bankid.com/om-bankid/detta-ar-bankid

https://www.bankid.com/om-bankid/detta-ar-bankid

https://www.bankid.com/assets/bankid/stats/2017/statistik-2017-01.pdf




https://www.bankid.com/om-oss

https://www.bankid.com/om-oss

http://www.elegnamnden.se/omoss.4.5a85666214dbad743ff81e3.html

http://www.elegnamnden.se/omoss.4.5a85666214dbad743ff81e3.html

http://www.elegnamnden.se/download/18.5c281c7015abecc2e20acb7/1490600991333/ELN-0600_-_Tekniskt_ramverk_-_Svensk_e-legitimation.pdf



https://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf

https://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf

http://openid.net/connect/faq/

http://openid.net/connect/faq/



http://saml.xml.org/saml-specifications

http://saml.xml.org/saml-specifications

http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/BEC05CE1-D5EB-4E48-B46C-7385D5AADCFE.html

http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/BEC05CE1-D5EB-4E48-B46C-7385D5AADCFE.html

54 BIBLIOGRAPHY

[12] The Swedish E-identification Board. Deployment Profile for the SwedisheID Framework. Framework ELN-0602-v1.3, The Swedish E-identificationBoard, October 2015. URL http://www.elegnamnden.se/download/18.77dbcb041438070e039d6ef/1444137199011/ELN-0602+-+Bilaga+Tekniskt+ramverk+-+Deployment+Profile+for+the+Swedish+eID.pdf.[Accessed: 2017-02-24].

[13] Sumana Annam. Ideal solution for SSO across native mobile ap-plications, June 2014. URL http://blog.centrify.com/ideal-solution-for-sso-across-native-mobile-applications/.[Accessed: 2017-02-24].

[14] Oscar Jacobsson. "SAML is the Windows XP of Identity",June 2014. URL https://www.ayoy.se/blog/2014/06-19-saml-is-the-windows-xp-of-identity/. [Accessed: 2017-02-24].

[15] Charles Gibbons. Why the Future of Identity is OpenID Connectand not SAML, August 2014. URL http://blog.centrify.com/ideal-solution-for-sso-across-native-mobile-applications/. [Ac-cessed: 2017-02-24].

[16] Ken Peffers, Tuure Tuunanen, Marcus A. Rothenberger, and Samir Chatter-jee. A design science research methodology for information systems research.Journal of Management Information Systems, 24(3):45–77, 2007. doi: 10.2753/MIS0742-1222240302. URL http://www.tandfonline.com/doi/abs/10.2753/MIS0742-1222240302.

[17] S. Bradner. Ietf rfc 2119: Key words for use in rfcs to indicate requirement levels.Technical report, 1997.

[18] ISO/IEC 29115:2013. Information technology – Security techniques – Entity authen-tication assurance framework. Standard, International Organization for Standardiza-tion, Geneva, CH, March 2013.

[19] The Swedish E-identification Board. Tillitsramverk för Svensk e-legitimation.Framework, The Swedish E-identification Board, September 2015. URL http://www.elegnamnden.se/download/18.77dbcb041438070e039d237/1444138670074/ELN-0700+-+Tillitsramverk+f%C3%B6r+Svensk+e-legitimation.pdf.

[20] The Swedish E-identification Board. Kartläggning av internationella tillitsramverk,June 2012. URL https://www.kirei.se/xfiles/tillit-pm.pdf. [Accessed:2017-05-14].

[21] The Swedish E-identification Board. Ansökningsformulär för ansökan om att bli Ut-färdare av Svensk e-legitimation, October 2015. URL http://www.elegnamnden.se/download/18.54a3d27615036ac09f32c8d/1444810255097/ELN-0003+-++Ans%C3%B6kningsformul%C3%A4r+f%C3%B6r+utf%C3%A4rdare+av+Svensk+e-legitimation.docx. [Accessed: 2017-05-14].

http://www.elegnamnden.se/download/18.77dbcb041438070e039d6ef/1444137199011/ELN-0602+-+Bilaga+Tekniskt+ramverk+-+Deployment+Profile+for+the+Swedish+eID.pdf



http://blog.centrify.com/ideal-solution-for-sso-across-native-mobile-applications/


https://www.ayoy.se/blog/2014/06-19-saml-is-the-windows-xp-of-identity/

https://www.ayoy.se/blog/2014/06-19-saml-is-the-windows-xp-of-identity/



http://www.tandfonline.com/doi/abs/10.2753/MIS0742-1222240302

http://www.tandfonline.com/doi/abs/10.2753/MIS0742-1222240302

http://www.elegnamnden.se/download/18.77dbcb041438070e039d237/1444138670074/ELN-0700+-+Tillitsramverk+f%C3%B6r+Svensk+e-legitimation.pdf




https://www.kirei.se/xfiles/tillit-pm.pdf

http://www.elegnamnden.se/download/18.54a3d27615036ac09f32c8d/1444810255097/ELN-0003+-++Ans%C3%B6kningsformul%C3%A4r+f%C3%B6r+utf%C3%A4rdare+av+Svensk+e-legitimation.docx




BIBLIOGRAPHY 55

[22] W. Stallings, Lawrie Brown, M. Bauer, and M. Howard. Computer Security: Principlesand Practice. Pearson Prentice Hall, 2008. ISBN 9780135137116. URL https://books.google.co.in/books?id=S_4gOQAACAAJ.

[23] Stig Jönsson. E-legitimationsnämnden och Svensk e-legitimation(SOU 2010:104, 2010. URL http://www.regeringen.se/49bb35/contentassets/e031f49a8c7b48969b8ea4b45a2016d2/e-legitimationsnamnden-och-svensk-e-legitimation-hela-dokumentet-sou-2010104.[Accessed: 2017-05-14].

[24] eSam, The Swedish E-identification Board, and Swedish Civil Contingen-cies Agency. Juridisk vägledning för införande av e-legitimering och e-underskrifter, October 2015. URL http://esamverka.se/download/18.63a7ad9f15a3b727607db586/1488376229491/eSam+VL+e-legitimering+och+e-underskrift.pdf. [Accessed: 2017-05-15].

[25] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore. OpenID Con-nect Core 1.0 incorporating errata set 1. Specification, OpenID Foundation, Novem-ber 2014. URL http://openid.net/specs/openid-connect-core-1_0.html.

[26] Dick Hardt. The OAuth 2.0 Authorization Framework. RFC 6749, October 2012.URL https://rfc-editor.org/rfc/rfc6749.txt.

[27] Jeffrey Mogul, Larry M Masinter, Roy T. Fielding, Jim Gettys, Paul J. Leach, and TimBerners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616, June 1999. URLhttps://rfc-editor.org/rfc/rfc2616.txt.

[28] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore. OpenIDConnect Basic Client Implementer’s Guide 1.0 - draft 37. Specification,OpenID Foundation, August 2015. URL https://openid.net/specs/openid-connect-basic-1_0.html.

[29] Dominick Baier. Which OpenID Connect/OAuth 2.0 Flow is the right One?,January 2016. URL https://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/. [Accessed:2017-05-14].

[30] Nat Sakimura. Cut and pasted code attack in OAuth 2.0 [RFC6749],May 2016. URL https://nat.sakimura.org/2016/01/25/cut-and-pasted-code-attack-in-oauth-2-0-rfc6749/. [Accessed: 2017-05-07].

[31] Douglas Crockford. The application/json Media Type for JavaScript Object Notation(JSON). RFC 4627, July 2006. URL https://rfc-editor.org/rfc/rfc4627.txt.

[32] Tim Bray. The JavaScript Object Notation (JSON) Data Interchange Format. RFC7159, March 2014. URL https://rfc-editor.org/rfc/rfc7159.txt.

[33] ECMA. ECMA-404: The JSON Data Interchange Format. ECMA (European Associationfor Standardizing Information and Communication Systems), Geneva, Switzerland,

https://books.google.co.in/books?id=S_4gOQAACAAJ

https://books.google.co.in/books?id=S_4gOQAACAAJ

http://www.regeringen.se/49bb35/contentassets/e031f49a8c7b48969b8ea4b45a2016d2/e-legitimationsnamnden-och-svensk-e-legitimation-hela-dokumentet-sou-2010104



http://esamverka.se/download/18.63a7ad9f15a3b727607db586/1488376229491/eSam+VL+e-legitimering+och+e-underskrift.pdf



http://openid.net/specs/openid-connect-core-1_0.html

https://rfc-editor.org/rfc/rfc6749.txt


https://openid.net/specs/openid-connect-basic-1_0.html

https://openid.net/specs/openid-connect-basic-1_0.html

https://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

https://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

https://nat.sakimura.org/2016/01/25/cut-and-pasted-code-attack-in-oauth-2-0-rfc6749/

https://nat.sakimura.org/2016/01/25/cut-and-pasted-code-attack-in-oauth-2-0-rfc6749/




56 BIBLIOGRAPHY

October 2013. URL www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf.

[34] Michael Jones, John Bradley, and Nat Sakimura. JSON Web Token (JWT). RFC 7519,May 2015. URL https://rfc-editor.org/rfc/rfc7519.txt.

[35] Nat Sakimura, Michael Jones, and John Bradley. JSON Web Signature (JWS). RFC7515, May 2015. URL https://rfc-editor.org/rfc/rfc7515.txt.

[36] Joe Hildebrand and Michael Jones. JSON Web Encryption (JWE). RFC 7516, May2015. URL https://rfc-editor.org/rfc/rfc7516.txt.

[37] W. Diffie and M. Hellman. New directions in cryptography. IEEE Transactions onInformation Theory, 22(6):644–654, Nov 1976. ISSN 0018-9448. doi: 10.1109/TIT.1976.1055638.

[38] European Parliament, Council of the European Union. REGULATION (EU) No910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL, June 2014.URL http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG. [Accessed: 2017-02-27].

[39] J. Katz and Y. Lindell. Introduction to Modern Cryptography: Principles and Protocols.Chapman & Hall/CRC Cryptography and Network Security Series. Taylor & Fran-cis, 2007. ISBN 9781584885511. URL https://books.google.se/books?id=TTtVKHdOcDoC.

[40] C.R. Rachana. The Role of Digital Signatures in Digital Information Managment.International Monthly Refereed Journal of Research In Management & Technolog, 2:103–109,March 2013. URL https://www.abhinavjournal.com/images/Management_&_Technology/Mar13/13.pdf. [Accessed: 2017-05-30].

[41] Microsoft Corporation. What Are CA Certificates?, March 2003. URL https://technet.microsoft.com/en-us/library/cc778623(v=ws.10).aspx.[Accessed: 2017-05-22].

[42] Mozilla Corporation. Mozilla Root Store Policy Version 2.4.1, 2017. URL https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/. [Accessed: 2017-05-22].

[43] Dave Cooper. Internet X.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile. RFC 5280, May 2008. URL https://rfc-editor.org/rfc/rfc5280.txt.

[44] Stephen Wilson. A vulnerability assessment of roaming soft certificate pki solutions.SANS Institute InfoSec Reading Room, 2002.

[45] Apple Inc. iOS Security, iOS 10, March 2017. URL https://www.apple.com/business/docs/iOS_Security_Guide.pdf.

[46] Hardware-backed Keystore, March 2017. URL https://source.android.com/security/keystore/. [Accessed: 2017-05-06].

www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf




http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

https://books.google.se/books?id=TTtVKHdOcDoC

https://books.google.se/books?id=TTtVKHdOcDoC

https://www.abhinavjournal.com/images/Management_&_Technology/Mar13/13.pdf

https://www.abhinavjournal.com/images/Management_&_Technology/Mar13/13.pdf

https://technet.microsoft.com/en-us/library/cc778623(v=ws.10).aspx

https://technet.microsoft.com/en-us/library/cc778623(v=ws.10).aspx

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/





https://www.apple.com/business/docs/iOS_Security_Guide.pdf

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

https://source.android.com/security/keystore/

https://source.android.com/security/keystore/

BIBLIOGRAPHY 57

[47] Alan O. Freier, Philip Karlton, and Paul C. Kocher. The Secure Sockets Layer (SSL)Protocol Version 3.0. RFC 6101, August 2011. URL https://rfc-editor.org/rfc/rfc6101.txt.

[48] Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) Protocol Version1.2. RFC 5246, August 2008. URL https://rfc-editor.org/rfc/rfc5246.txt.

[49] Torsten Gigler, Michael Coates, Dave Wichers, Tyler Reguly, and Tony Hsu. Trans-port Layer Protection Cheat Sheet, April 2017. URL https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols. [Accessed: 2017-05-20].

[50] Tom Roader. Something You Know, Have, or Are, 2005. URL https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeople.html. [Accessed:2017-05-04], Lecturer: Professor Fred B. Schneider.

[51] S.T. Dispensa. Multi factor authentication, January 29 2013. URL https://www.google.com/patents/US8365258. US Patent 8,365,258.

[52] Ton van der Putte and Jeroen Keuning. Biometrical Fingerprint Recognition: Don’t getyour Fingers Burned, pages 289–303. Springer US, Boston, MA, 2000. ISBN 978-0-387-35528-3. doi: 10.1007/978-0-387-35528-3_17. URL http://dx.doi.org/10.1007/978-0-387-35528-3_17.

[53] M. Conti, N. Dragoni, and V. Lesyk. A survey of man in the middle attacks. IEEECommunications Surveys Tutorials, 18(3):2027–2051, thirdquarter 2016. ISSN 1553-877X.doi: 10.1109/COMST.2016.2548426.

[54] RSA. MAKING SENSE OF MAN-IN-THE-BROWSER ATTACKS. White Paper MITBWP 0611, June 2011.

[55] Entrust Inc. Defeating Man-in-the-Browser Malware. Technical report, March2014. URL https://www.entrust.com/wp-content/uploads/2014/03/WP_Entrust-MITB_March2014.pdf. [Accessed: 2017-06-02].

[56] Sreekanth Malladi, Jim Alves-Foss, and Robert B. Heckendorn. On Preventing Re-play Attacks on Security Protocols, 2002. URL http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA462295. [Accessed: 2017-06-02].

[57] Joan Goodchild. Social Engineering: The Basics, December 2012. URL http://www.csoonline.com/article/2124681/leadership-management/security-awareness-social-engineering-the-basics.html. [Accessed:2017-05-05].

[58] Finansiell ID-Teknik BID AB. Bedrägeriförsök, December 2016. URL https://www.bankid.com/om-oss/nyheter/bedrageriforsok. [Accessed: 2017-05-05].

[59] Fredrik Samuelson. Nytt larm om bank-ID – nu görs appen om, De-cember 2016. URL http://www.expressen.se/dinapengar/nytt-larm-om-bank-id--nu-gors-appen-om/. [Accessed: 2017-05-13].





https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols



https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeople.html

https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeople.html

https://www.google.com/patents/US8365258

https://www.google.com/patents/US8365258

http://dx.doi.org/10.1007/978-0-387-35528-3_17

http://dx.doi.org/10.1007/978-0-387-35528-3_17

https://www.entrust.com/wp-content/uploads/2014/03/WP_Entrust-MITB_March2014.pdf

https://www.entrust.com/wp-content/uploads/2014/03/WP_Entrust-MITB_March2014.pdf

http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA462295

http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA462295

http://www.csoonline.com/article/2124681/leadership-management/security-awareness-social-engineering-the-basics.html



https://www.bankid.com/om-oss/nyheter/bedrageriforsok

https://www.bankid.com/om-oss/nyheter/bedrageriforsok

http://www.expressen.se/dinapengar/nytt-larm-om-bank-id--nu-gors-appen-om/

http://www.expressen.se/dinapengar/nytt-larm-om-bank-id--nu-gors-appen-om/

58 BIBLIOGRAPHY

[60] The Swedish E-identification Board. Bli godkänd e-legitimationsutfärdare förkvalitetsmärket Svensk e-legitimation, 2017. URL http://www.elegnamnden.se/leverantor/bligodkandeidutfardareenligtsvenskelegitimation.4.5a85666214dbad743ffe6e6.html. [Accessed: 2017-05-04].

[61] The Swedish E-identification Board. Utländska e-legitimationer i svenskadigitala tjänster, 2017. URL http://www.elegnamnden.se/eidas.4.361dc8c15312eff6fdf6ef.html. [Accessed: 2017-05-15].

[62] The Swedish E-identification Board and Martin Lindström. ArchitechtureOverview, 2017. URL https://github.com/elegnamnden/eidas/wiki/Architechture-Overview. [Accessed: 2017-05-15].

[63] The Swedish E-identification Board. Behovsanalys eIDAS -utländska e-legitimationeri Sverige, August 2016. URL http://www.elegnamnden.se/download/18.361dc8c15312eff6fd29a84/1472724781219/Behovsanalys+eIDAS+2016-08-19.pdf. [Accessed: 2017-05-15].

[64] Richard Oehme. Analys av informationssäkerheten i Svensk e-legitimation. Mem-orandum M2014-1360, Swedish Civil Contingencies Agency, October 2014. URLhttps://www.msb.se/Upload/Forebyggande/Informationssakerhet/Rapporter/Analys%20av%20informationss%c3%a4kerheten%20i%20svensk%20e-legitimation.pdf.

[65] Yvonne Hermansson. Säkerhetsgranskning. Report H 21 835:610/14:2, FRA, theNational Defence Radio Establishment, December 2014.

[66] Oliver Terbu, Stefan Vogl, and Sebastian Zehetbauer. One mobile id to secure phys-ical and digital identity. In Gesellschaft für Informatik eV (GI) publishes this series in or-der to make available to a broad public recent findings in informatics (ie computer science andinforma-tion systems), to document conferences that are organized in co-operation with GI andto publish the annual GI Award dissertation., page 43.

[67] Sebastian Feld and Norbert Pohlmann. Security Analysis of OpenID, followed by a Ref-erence Implementation of an nPA-based OpenID Provider, pages 13–25. Vieweg+Teubner,Wiesbaden, 2011. ISBN 978-3-8348-9788-6. doi: 10.1007/978-3-8348-9788-6_2. URLhttp://dx.doi.org/10.1007/978-3-8348-9788-6_2.

[68] Frode Beckmann Nilsen. OpenID Connect Provider (preview), May 2017. URLhttps://confluence.bankidnorge.no/confluence/pages/viewpage.action?pageId=90636700. [Accessed: 2017-05-08].

[69] Ryan Paul. Compromising Twitter’s OAuth security system, Septem-ber 2010. URL https://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/. [Accessed: 2017-03-13].

[70] S. Pai, Y. Sharma, S. Kumar, R. M. Pai, and S. Singh. Formal verification of oauth 2.0using alloy framework. In 2011 International Conference on Communication Systems andNetwork Technologies, pages 655–659, June 2011. doi: 10.1109/CSNT.2011.141.

http://www.elegnamnden.se/leverantor/bligodkandeidutfardareenligtsvenskelegitimation.4.5a85666214dbad743ffe6e6.html



http://www.elegnamnden.se/eidas.4.361dc8c15312eff6fdf6ef.html

http://www.elegnamnden.se/eidas.4.361dc8c15312eff6fdf6ef.html

https://github.com/elegnamnden/eidas/wiki/Architechture-Overview

https://github.com/elegnamnden/eidas/wiki/Architechture-Overview

http://www.elegnamnden.se/download/18.361dc8c15312eff6fd29a84/1472724781219/Behovsanalys+eIDAS+2016-08-19.pdf



https://www.msb.se/Upload/Forebyggande/Informationssakerhet/Rapporter/Analys%20av%20informationss%c3%a4kerheten%20i%20svensk%20e-legitimation.pdf



http://dx.doi.org/10.1007/978-3-8348-9788-6_2

https://confluence.bankidnorge.no/confluence/pages/viewpage.action?pageId=90636700

https://confluence.bankidnorge.no/confluence/pages/viewpage.action?pageId=90636700

https://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/

https://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/

BIBLIOGRAPHY 59

[71] J. Hughes, S. Cantor, J. Hodges, F. Hirsch, P. Mishra, R. Philpott, and E. Maler.Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, March2005. URL https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf. [Accessed: 2017-02-27].

[72] MITREid Connect, May 2017. URL https://github.com/mitreid-connect.[Accessed: 2017-05-06].

[73] OpenID Connect Fondation. Certified OpenID Connect Implementations, 2017. URLhttp://openid.net/developers/certified/. [Accessed: 2017-05-06].

[74] Spring Security, 2017. URL https://projects.spring.io/spring-security/. [Accessed: 2017-05-06].

[75] Interface AuthenticationProvider, 2017. URL http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/authentication/AuthenticationProvider.html. [Accessed:2017-05-06].

[76] S. B. Roosa and S. Schultze. Trust darknet: Control and compromise in the internet’scertificate authority model. IEEE Internet Computing, 17(3):18–25, May 2013. ISSN1089-7801. doi: 10.1109/MIC.2013.27.

[77] Finansiell ID-Teknik BID AB. Frågor om beställning, 2017. URL https://support.bankid.com/sv/fragor-svar/fragor-om-bestallning. [Ac-cessed: 2017-05-22].

https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

https://github.com/mitreid-connect

http://openid.net/developers/certified/

https://projects.spring.io/spring-security/

https://projects.spring.io/spring-security/

http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/authentication/AuthenticationProvider.html



https://support.bankid.com/sv/fragor-svar/fragor-om-bestallning

https://support.bankid.com/sv/fragor-svar/fragor-om-bestallning

www.kth.se

Documents

Electronic Identification Based on OpenID Connect - KTHann/exjobb/tom_johansson.pdf · i Abstract Electronic identiﬁcation is used by an individual to prove who he or she is by