SE1551176A1

SE1551176A1 - Method and system for authenticating a user

Info

Publication number: SE1551176A1
Application number: SE1551176A
Authority: SE
Inventors: Hallenborg Philip; Kezionis Mindaugas
Original assignee: Identitrade Ab
Priority date: 2015-09-14
Filing date: 2015-09-14
Publication date: 2017-03-15
Also published as: WO2017048177A1

Abstract

Method for authenticating a user, comprising the steps of. a) providing a central server (101), an authentication service provider (110) for authenticating users based upon control over an electronic device (170,180) which is. provided wireless internet connectivity via a network operated by the authentication service provider, and a user service provider (150,160);. b) providing to the device wireless internet connectivity via said network; c) authenticating the user and the central server placing a first cookie on the electronic device identifying the authentication service provider; d) providing to the device internet connectivity which is not via said network; e) providing, on the device, access to a user service web interface, and providing the first cookie to the central server; f) the central server identifying the authentication service provider; g) verifying that the user can be validly authenticated; and h) providing the user authentication information to the user service provider.The invention also relates to a system.

Description

Method and system for authenticating a user The present invention relates to a method and a system for authenticating a user. lnparticular, the invention relates to remote authentication of a user, via an electronicdevice operated by the user, specifically an electronic device being provided internetconnectivity via a wireless network wherein an operator of said network can identify theelectronic device securely in connection to such connectivity provision, such as is the casefor an electronic device operated using a SIM (Subscriber Identity Module) card or a similarfunctionality. ln many circumstances a user needs to be remotely authenticated, in order for a remotelyarranged party to verify the identity of a user contacting the remotely arranged party. lnparticular, this is the case in digital communication applications, especially online. Forinstance, within the fields of e-commerce, online transactions and banking, digital serviceprovision and user account registration, a user contacting a central server over the inter- net needs to be authenticated by providing some type of proof of his or her identity.

There are many conventional technologies for providing such authentication, ranging fromless secure alternatives such as simply entering a user name and a password, via moreelaborate techniques such as Public Key Infrastructure-based systems, to multi-factorauthentication solutions involving SI\/IS (Short Message Service) messages sent to a mobile phone controlled by the user, or even biometric measurement data, and so on.

There is a problem in that it is costly for a user service provider to provide such authenti-cation procedures. ln general, in order to provide adequate security and user conven-ience, complex or different authentication methods should also in many cases be provid-ed. Especially for small user service providers, this can represent a significant implementa- tion cost.

Another problem is that it is difficult for individual users to keep track of various authenti- cation tools, login credentials, etc., for use with different user service providers.

Application text 2015-09-14 150088SE One known solution to these problems is to allow a third party, such as a large, well-known company, to authenticate a user on behalf of the user service provider. Examplesinclude the so called OpenlD initiative, in turn using the open authentication standardOauth, using which an authenticating party can provide an access token, using which theproprietor of said access token can obtain access to a defined subset of services provided by the authenticating party. Another example is Facebook (registered trademark) Connect.

However, such conventional methods often impose specific requirements on the user,such as first signing up for an account with a particular authentication service provider.For service providers, there is a desire for increased flexibility and possibility to tailor theauthentication type to each particular authentication need, such as depending on the typeof service provided or the type of electronic device used by the user. Also, there is a desire for an authentication service which can be acquired at a lower cost.

A related problem is that it is desired for users not to have to enter personal information,such as billing address, repeatedly when ordering transactions with various service pro-viders. Also, many user service providers, such as online vendors, have a desire to obtainmore detailed user information as early as possible during the ordering procedure of a transaction, such as a purchase.

Another problem is to provide a simple and efficient way of allowing authenticationservice providers to authenticate users across borders, in which case access to agreementsand the operation under different legislations may impose significant cost to small-scale user service providers.

Swedish patent application 1450928-5, which has not been published at the filing of thepresent application, discloses a method in which a cookie, in other words a piece ofinformation stored on the electronic device being used to access web content, is placedon a user operated device by a central party, identifying particular available user authenti-cation service providers.

Application text 2015-09-14 150088SE One specific problem in relation to the method disclosed by said Swedish patent applica-tion is for the mobile device user to be able to pass from a mobile wireless network,wherein an authentication can be based upon the possession or control of a particularmobile device, to another type of internet connection of the same device, such as a WiFi connection, and still be able to easily and securely be authenticated.

The present invention solves the above described problems.

Hence, the invention relates to a method for authenticating a user, which method ischaracterised in that it comprises the steps of providing a central server, in communica-tion with an authentication service provider, arranged to authenticate users based uponthe user's control over an electronic device which is provided wireless internet connectivi-ty via a network operated by the said authentication service provider in question, and atleast one user service provider, arra nged to provide user services to users via a respectiveuser service web interface; b) providing to the electronic device wireless internet connec-tivity via the said network; c) causing the authentication service provider to authenticatethe user based upon the user's control over the said electronic device and via said net-work, and upon authentication of the user, allowing the central server to place a firstcookie on the electronic device, said first cookie identifying the authentication serviceprovider in question; d) providing to the electronic device internet connectivity which isnot via the said network; e) providing, for the user and using a web browser executed onor from the same electronic device, access to a user service web interface, and as a resultproviding the first cookie to the central server using the internet connectivity provided instep d); f) causing the central server to identify, based upon the first cookie, the authenti-cation service provider; g) verifying, in the authentication service provider, that the usercan be validly authenticated; and h) causing user authentication information to be provid- ed to the user service provider.

Furthermore, the invention relates to a system for authenticating a user, which system comprises a central server, in communication with an authentication service provider, Application text 2015-09-14 150088SE arranged to authenticate users based upon the user's control over an electronic devicewhich is provided wireless internet connectivity via a network operated by the said au-thentication service provider in question, and further in communication with at least oneuser service provider, arranged to provide user services to users via a respective userservice web interface, which system is characterised in that the central server is arrangedto receive information regarding the availability of a particular authentication serviceprovider to authenticate the user based upon the user's control over the said electronicdevice and via said network, and in response to the receipt of such information, place afirst cookie on the electronic device, said first cookie identifying the authentication serviceprovider in question and either allowing the authentication service provider to place asecond cookie on the electronic device comprising information identifying the user or theelectronic device to the authentication service provider in question or to receive from theauthentication service provider in question such information, in that the central server isfurther arranged to, at a later point in time and upon a request from said user serviceprovider, receive the first cookie and, based upon the first cookie, identify the authentica-tion service provider in question, and then either allowing the first authentication serviceprovider to read the second cookie or providing the first authentication service provider with said information. ln the following, the invention will be described in closer detail, partly with reference to the enclosed drawings, in which: Figure 1 is an overview diagram of a system according to the present invention andarranged to perform a method according to the invention; Figure 2 is a flow chart depicting the various method steps of a method according to a firstaspect of the present invention; Figure 3 is a flow chart depicting the various method steps of a method according to asecond aspect of the present invention; and Figures 4a-4d show various interfaces provided by a web browser on the display of a userelectronic device.

All figures share reference numerals for the same parts.

Application text 2015-09-14 150088SE Figure 1 shows a system 100 according to the present invention for authenticating a uservia an electronic device 170, 180. The system 100 is furthermore arranged to perform the methods described herein according to various aspects of the present invention. ln one aspect of the invention, the system 100 comprises a central server 101, comprisingor in communication with a database 102; at least one, preferably at least two, preferablya plurality of user service providers 150, 160; and at least one, preferably at least two,preferably a plurality of authentication service providers 110, 120, 130. ln another aspectof the invention, the system 100 only comprises the central server 101, the database 102and any software provided by the central server 101 to connected authentication serviceproviders 110, 120, 130 and user service providers 150, 160, which are as such thus not part of the system 100.

The database 102 comprises information regarding registered authentication serviceproviders 110, 120, 130, user service providers 150, 160 and users, such as required minimum allowed authentication levels for various conditions.

The user service providers 150, 160 may be any type of party capable of providing servicesto users remotely, such as online vendors; public service actors such as libraries, govern-ment institutions or the like; financial institutions, such as online banks; payment provid-ers; online communities; communication services; or any other actor providing a service tousers remotely in a way so that the identity of the user is needed in order to provide atleast one of the services provided. lt is preferred that users communicate with the serviceproviders 150, 160 directly over a digital communications network 190 such as the inter-net. ln the following, when the term ”internet” is used, it is understood that any type ofdigital communications network may be used, as applicable, such as wired or wirelesslocal area or wide area networks. Specifically, all entities 101, 110, 120, 130, 150, 160, 170, 180 are interconnected, directly or indirectly, by this network 190.

Application text 2015-09-14 150088SE In figure 1, broken lines denote wireless communication while full lines denote wired communication.

The authentication service providers 110, 120, 130 may, furthermore, be any type of partycapable of providing authentication services to users remotely, and in particular beingarranged to perform authentication of users. Examples include online vendors; publicservice actors such as libraries, government institutions or the like; financial institutions,such as online banks; payment providers; online communities; communication services; orany other actor the relationship of which to each user requires that the identity of theuser in question is safely established by a user authentication function provided by theauthentication provider 110, 120, 130. It is preferred that the authentication providers110, 120, 130 communicate directly with each respective user. This communication cantake place over the network 190, but for at least one of the authentication service provid-ers 110, the communication between the provider 110 and the user electronic device 170,180 is performed via a mobile wireless network operated by the provider 110 in questionand serving the user electronic device 170, 180 with communication services, using a basestation 111, which is a part of the said mobile wireless network and which is preferablyoperated by the provider 110. It is preferred that the said mobile wireless network is onein which a subscriber identity, such as an IMSI (International Mobile Subscriber Identity), isneeded for connection to the network, such as via the use of a SIM (Subscriber IdentityModule) card installed in the electronic device communicating with the network in ques-tion, or a software function corresponding to the identifying function of a SIM card.Examples of such networks comprise telephony networks such as GSM, 3G, LTE and 5Gnetworks. Preferably, the provider 110 is the network operator ofthe said network, and assuch has firsthand access to the identity of the electronic device 170, 180 when connectedto the said mobile wireless network. The base station 111 is a part of the said mobilewireless network. Furthermore, the said network operator typically provides the electron-ic device 170, 180 with connectivity to the network 190 in a conventional manner, such as via GPRS in the case of a GSM network.

Application text 2015-09-14 150088SE Herein, the expression ”network operated by an authentication service provider" alsoencompasses networks operated by third parties that are in collaboration with the saidauthentication service provider for the purpose of performing authentications based upon control of a particular electronic device via the network in question.

As used herein, the term ”authentication service” means a remotely provided service forauthenticating a user, comprising establishing with a certain minimum level of security acorrect identity of the user. Such a minimum level of security, such as a minimum level of |H assurance (LOA), is herein denoted ”authentication leve . Examples of such authentica-tion levels are those definitions of which are provided by NIST (National Institution ofStandards and Technology, USA), according to which there are at least four basic levels ofassurance levels, ranging from low security procedures where it is only tested whether it isthe same user accessing a service at different occasions (”Level 1") up to high securityprocedures where authentication is dependent upon the user's possession of a stronglyencrypted cryptographic key (”Level 4"). See wwwhistgov for further information. Here-in, it is preferred that each authentication service provider 110, 120, 130 is unambiguouslyassociated with one or several certain available well-defined authentication levels, therequirements of which the authentication service in question fulfills, and that each au-thentication service provider is associated with a certain respective minimum supportedauthentication level. lt is possible that a particular authentication service provider isassociated with different minimum authentication levels in relation to different users. lt ispreferred that this information is stored in the database 102 and accessible from thecentral server 101. The information may, for instance, be supplied in an initial registrationstep of each authentication service provider 110, 120, 130, and may subsequently beupdated, for instance in reaction to new information in relation to specific users. lt is alsopossible that available authentication levels in relation to a specific user are provided, byrequest from the central server 10 to one or several authentication service providers that have been identified as being available for authenticating the user in question (see below).

Specifically, for at least one authentication service provider 110, which is an operator of a mobile wireless network comprising the base station 111 in communication with at least Application text 2015-09-14 150088SE one piece of user electronic device 170, 180, an authentication factor used by that au-thentication service provider 110 is of the kind ”something you have", whereby the itemheld by the user to be authenticated is the said user electronic device 170, 180 in ques-tion. This means that the authentication provided by the authentication service provider110 is based upon the control of the user over the electronic device 170, 180 which isconnected to the said mobile wireless network. By for instance receiving an SI\/IS (ShortMessage Service) message on the electronic device 170, 180, which is sent from theprovider 110 via the base station 111, which SMS comprises a code, and entering thatcode via another channel, such as via a web interface, so that the entered code reachesthe authentication service provider 110, the possession of the electronic device 170, 180can be proven, and hence the identity of the user, which has previously been securelyauthenticated in connection to the signing up for the subscription to the said mobile wireless network. lt is realized that each one of entities 101, 110, 120, 130, 150, 160 may be implemented asa respective standalone, internet connected server; a distributed or virtual set of servers;or in any other configuration, as long as the respective entity in question provides a well- defined interface for communications to and from the entity.

Each user communicating with the system 100 uses an electronic device 170, 180, which ispreferably arranged to communicate with the system 100 over the network 190. ln figure1, such devices are exemplified by a mobile phone 170 of so-called smartphone type and aportable computer 180. However, the electronic device can be any device capable ofcommunicating with the system 100, in particular wirelessly, such as a desktop computeror a machine-to-machine interface. ln this context, the term ”wireless communication”means communication which is at least partly conducted over a wireless link. lt is pre-ferred that the device 170, 180 is of general-purpose type, and it is also preferred that thedevice comprises a respective display 171, 181 capable of providing an interactive graph-ical user interface to the user. According to the invention, the electronic device 170, 180comprises a SIM (Subscriber Identity I\/|odule) card, or the corresponding (such as acorresponding software function), arranged to uniquely identify the electronic device 170, Application text 2015-09-14 150088SE 180 to a mobile wireless network, such as the one operated by the provider 110, to whichthe device 170, 180 is connected. Such identification may, for instance, be via an |I\/|S| or I\/ISISDN code, or a MAC address.

According to the invention, each electronic device 170, 180 is arranged to communicatevia at least one wired or wireless communication path provided via said base station 111.Apart therefrom, each electronic device 170, 180 is also able to communicate with thenetwork 190 via at least one other wireless channel, such as over the mobile wirelessnetwork of another operator, such as an LTE roaming partner to the operator 110; aconventional wireless internet connection which is not a mobile telephony connection,such as a WiFi connection via a WiFi access point 191, or using a conventional wired internet connection (exemplified using a full line from device 180 in figure 1).

The user is preferably a human being, but in some aspects the user may be a machine-implemented communication part in a machine-to-machine implemented system. ln thelatter case, the electronic device 170, 180 may be comprised in or constitute the machine in question.

Figure 2 shows a method according to a first aspect of the present invention for authenti-cating a user. This first aspect is described herein in order for the reader to fully under-stand the context of the present invention. Everything which is described in connection to the first aspect is also relevant to the second aspect, as applicable. ln a step 201, the method starts. ln a step 202, the central server 101 is provided, and is arranged to be in communicationwith at least two authentication service providers 110, 120, 130 and at least one userservice provider 150, 160, that are also provided. lt is realized that this step 202 can be performed in advance and only one time for several runs of the method.

Application text 2015-09-14 150088SE lO ln a step 203, each authentication service provider 110, 120, 130 is associated with atleast one respective available level of authentication. Each particular provider 110, 120,130 may be associated with several available such levels, in which case one of the availa-ble levels for a certain provider 110, 120, 130 is considered to be the lowest, or least safe,level. For instance, adding another identification factor, such as a physical token owned by the user, or adding encryption, would make the authentication level safer.

As indicated above, for at least one authentication servicer provider 110, the respectiveavailable authentication level comprises a ”something you have” authentication factor,based upon the control over the electronic device 170, 180 used by the user to be authen-ticated to connect to the central server 101 and the user service provider 150, 160. The”thing the user has” is the electronic device 170, 180 itself, which is identified by the above mentioned operator of the mobile network.

According to a preferred embodiment, in a step 204, which can be performed in advanceof the existence of a need for the user service provider 150, 160 to authenticate the user,the user is authenticated by a certain authentication service provider. This may, forinstance, mean that the user successfully logs into a web page provided by the authentica-tion service provider in question, or that the user in any other suitable manner providesproof, at a certain authentication level, of the identity of the user in question. For in-stance, such authentication in step 204 may comprise that the user provides some type of user credential data to the authentication service provider.

Herein, ”credential data” is to be understood as all types of user-specific information thatcan be provided from a user via an electronic device and that can be used by an authenti-cating party to identify or prove the identity of the user in question, such as user name -password combinations; PIN codes; cryptographic keys; hash values; biometric data, such as fingerprint data; and so on. ln particular, in step 204, at least one authentication service provider 110 authenticates the user based upon control, and hence possession, of the electronic device 170, 180, Application text 2015-09-14 150088SE ll further based upon an association between the electronic device, a SIM card comprised inthe electronic device, or the like, and the user, which association has previously beenstored by the authentication service provider 110 in question after an initial authentica-tion of the user as such, for instance in connection to the purchase of the subscription.Such initial authentication may for instance be a real-life authentication, in which the userprovides a personal identification card to office staff of the authentication service provid-er. The authentication in step 204 by the provider 110 may be by sending an SI\/IS asdescribed above, or for instance by the mobile wireless network of the provider 110automatically reading some information from the electronic device 170, 180, such as anIMSI number provided by a SIM card in the electronic device 170, 180, or a MAC address of the electronic device 170, 180.

The authentication in step 204 may furthermore be performed in connection to theauthentication service provider in question providing some type of service to the user,such as providing an authentication service on the initiative of the central server 101 as described below.

Hence, at the latest after step 204, the authentication service provider in question holdsinformation regarding the user, for instance user credential data or the knowledge of anIMSI or I\/ISISDN code of the electronic device 170, 180, allowing the authenticationservice provider to authenticate the user at a particular authentication level. After theauthentication in step 204, or an authentication in step 221 (see below), it is preferredthat the authentication service provider has an active authentication session with respectto the authenticated user. This may mean that the user does not have to provide creden-tial data, or does not have to prove control over the electronic device 170, 180 as de-scribed above, when being authenticated again within a predetermined time periodduring which the said session is active. The time period may be defined by the authentica- tion service provider.

Preferably, at the latest in a step 205, the authentication service provider in question, more preferably several, or all, of the authentication service providers 110, 120, 130, are Application text 2015-09-14 150088SE 12 caused to be remotely configurable by individual users so that they can provide infor-mation regarding their respective capability to authenticate the users in question to thecentral server 101. Hence, the user in question may remotely instruct the authenticationservice provider in question, preferably over the internet and preferably in connection toor prior to the authentication step 204, such as via a user control provided as an integrat-ed part of a web page displayed as a result of a successful login with the authenticationservice provider in question, or in connection to the signing up for a subscription with theprovider 110, to, upon request from the central server 101 or automatically upon authen-tication of the user in question, provide information indicating that the authenticationservice provider in question is capable of authenticating the user at least at the saidauthentication level, and preferably also to provide, in a subsequent step 224, user information to the graphical user service interface (see below). ln particular, in a step 206, the, several or all authentication service providers 110, 120,130 is or are arranged to notify the central server 101 when a user has been authenticatedby the authentication service provider in question. ln the case described below (such as insteps 221; steps 312-315; and steps 335-340), in which the authentication in step 204takes place in connection to the electronic device 170, 180 being used to access a userservice provider 150, 160, it may be the central server 101 that invokes the authenticationservice provider 110, 120, 130, why such notification may not be necessary. ln this lattercase, it is preferred that the authentication service provider 110, 120, 130 in question haspreviously notified the central server 101 about its ability to authenticate the user using a particular authentication level. ln a preferred step 207, which is preferably performed as an initial step in connection tosetting up an association between the central server 101 and a certain authenticationservice provider 110, 120, 130, but which may be performed at any time before step 218,a respective template for a second interactive graphical user interface is provided to the or those authentication service providers that will use such templates, see below.

Application text 2015-09-14 150088SE 13 According to the said first aspect of the present invention, in a step 211, the central server101 receives a request, from one of said one or several user service providers 150, 160, toauthenticate a particular user accessing the user service provider 150, 160 in question via the electronic device 170 or 180. This request can be provided in different ways.

As an example, the central server 101 may be directly provided, for instance from theuser, with information indicating that the user wishes to be authenticated using a particu-lar specified authentication service provider 110, 120 or 130, in turn providing an ade-quate authentication level for the present purposes. ln another example, the user may bepresented with a list of available authentication service providers with which the centralserver 101 is in communication and that can deliver an adequate authentication level,from which list the user can select a certain authentication service provider to use for a later authentication step 220.

However, figure 2 illustrates an alternative, preferred way, according to which the userfirst initiates contact with the user service provider 150, 160, and it is the user serviceprovider that in turn requests, possibly via an interface provided by the user serviceprovider to the user, the central server 101 to authenticate the user. ln general, and aswill be explained in the following, the central server 101 may make the decision automati-cally as to what specific authentication service provider 110, 120, 130 that will be used to authenticate the user.

Hence, in a preferred step 208, a first interactive graphical user interface is provided bythe user service provider 150, 160. For instance, the user service provider 150, 160 com-prises a web server providing a web page which is the first interface. ln a step 209, theuser is provided with remote access to the user service provider 150, 160 via this firstinterface, displayed to the user on the display 171, 181 ofthe device 170, 180 used by theuser, by the user service provider 150, 160. For instance, the device 170, 180 may com-prise a web browser arranged to read and display the first interface provided by the user service provider 150, 160 web server.

Application text 2015-09-14 150088SE 14 ln a preferred step 210, which may be performed at any time prior to step 225 but prefer-ably is performed before step 211, a particular user service transaction is identified, whichtransaction is to be performed by the user service provider 150, 160 for, to or on behalf of the user, and which requires the user to be authenticated before being performed.

Then, in step 211, the user service provider 150, 160 requests the central server 101 toauthenticate the user, in other words to provide an authentication service of the user.Preferably, the request comprises or imp|ies a specific allowable authentication level, asdictated by the type of transaction and/or the particular user service provider 150, 160and/or the particular user or user category. The allowable authentication level is theminimal authentication level that is allowed for authentication of the user under thecurrent conditions. The database 102 may comprise information regarding what types oftransactions, particular user service providers and particular users and/or user categories that require what minimum authentication levels.

According to a preferred embodiment, the minimum allowable level of authenticationused for each authentication service provider 110, 120, 130 is caused to depend on atleast one of the collection of parameters consisting of type of the electronic device; typeand/or provider of a graphical user interface via which the user accesses the user serviceprovider; the access of the authentication service provider in question to informationidentifying the particular user; geographical location of the electronic device; and/or theexistence of an active authentication session with the authentication service provider inquestion. ln the case of at least the authentication service provider 110, the parameterscomprise the fact that the user controls the electronic device 170, 180 (”something youhave” authentication factor) and that the authentication service provider 110 has previ-ously securely authenticated the user, including the determination of the identity of theuser and association to an identifier ofthe electronic device 170, 180 as such, as described above. lt is realized, as is illustrated in figure 3 (below), that the request in step 211 may also be performed in an indirect way by the service provider 150, 160, via the first graphical Application text 2015-09-14 150088SE interface. Then, the service provider 150, 160 is not directly involved at the moment of therequest, which is rather performed by for instance the device 170, 180 on behalf of the user service provider 150, 160. ln a step 212 according to the said first aspect of the invention, it is determined, prefera-bly by the central server 101 and preferably based upon the said available authentication-related information, an allowable authentication level to use for the said request, which level is required to authenticate the user under the current conditions. ln a step 214, the central server is arranged to identify a selected one of said authentica-tion service providers 110, 120, 130 which is associated with at least one level of authenti-cation which is at least as high as the allowable authentication level, and which authenti-cation service provider is capable of authenticating the said particular user at the allowa- ble authentication level.

According to a preferred step 213, preceding step 214, the central server 101 is howeverarranged to first identify, for several authentication service providers 110, 120, 130, arespective offered sell price for performing user authentication at the allowable level ofauthentication. For instance, the central server 101 may be arranged to request a respec-tive sell price at which each respective authentication service provider is willing to per-form the user authentication in question, preferably with knowledge of the particular userto be authenticated. Alternatively, the central server 101 has beforehand received pricelists from several authentication service providers regarding various types of authentica- tions.

Once the authentication service providers have responded to this request or the price listinformation has been analyzed, the central server 101 is arranged to identify at least one,preferably exactly one, authentication service provider offering a lowest sell price at therespective allowable level, and to use this authentication service provider as the said selected authentication service provider in the following.

Application text 2015-09-14 150088SE 16 According to one preferred embodiment, an auction over one or several bid rounds isperformed among authentication service providers 110, 120, 130 being capable of provid-ing at least the allowable authentication level, the final winner of which auction is the selected authentication service provider to use for the authentication in question. lt is also possible for the central server 101, via the user service provider 150, 160 such asvia the first graphical user interface, to allow the user to select what authentication service provider to use among a set of lowest-bidding authentication service providers. ln a preferred step 215, the central server 101 evaluates if at least one authenticationservice provider could be identified as the selected authentication service provider. Forinstance, none of the connected authentication service providers 110, 120, 130 may havebeen able to provide at least the allowable authentication level, or none may have beenable to authenticate the particular user. lf an authentication provider was identified instep 214, the method skips to step 217. Otherwise, it is preferred that the steps 217-224are not performed, but the user service provider 150, 160 is instead caused to authenti-cate, in a step 216, the particular user for the particular transaction in question withoutinvolving any of said authentication service providers 110, 120, 130. Preferably, thismeans that the user service provider 150 performs its own, conventional, default proce- dure for authenticating the user. ln a preferred step 217, the user is then presented, via a graphical user interface, prefera-bly the above mentioned first graphical user interface on the display 171, 181, with anoption whether or not to authenticate using one of the authenticating service providers110, 120, 130. Preferably, it is not specified at this point to the user which of the authenti-cation service providers that was identified in step 214. lf the user does not choose toallow such authentication, the method again skips to step 216 rather than performingsteps 218-225. The option presented in step 217 may also comprise allowing the saidauthentication service provider to provide user information to the user service provider150, 160 in question (see below). Preferably, the option presented in step 217 covers boththe authentication and the user information provision, so that by, for instance, activating a Application text 2015-09-14 150088SE 17 user control embodying the option in step 217, the user acknowledges both that theauthentication service provider may authenticate the user and provide user information to the user service provider in question. lt is furthermore preferred that the option being presented in step 217 is comprised in thefirst interaction, relating to user authentication with regards to the transaction in questionto be performed, between the user and the interactive graphical user interface providedto the user by the user service provider 150, 160. Hence, it is preferred that the communi-cations between the user service provider 150, 160, the authentication service providers110, 120, 130, and the central server 101 described above in relation to the previous stepsare fully automatic, and do not require any user interaction. ln other words, when forinstance loading the checkout page from an online vendor being the user service provider150, 160 in question, a user control may be automatically included in the page which,when activated by the user, acknowledges that the user wishes to allow any one of theauthentication service providers 110, 120, 130, or at least any one of said providers thatthe user has previously agreed to use, such as in a preferences setting supplied previouslyto the central server or by checking corresponding controls on the respective web page ofeach donor, to perform the user authentication for the purchase. ln a particularly pre-ferred embodiment, further detailed below in connection to figure 3, the user is presentedwith the option to allow a particular authentication service provider 110 to authenticatethe user, and preferably also to provide user information regarding the user to the userservice provider 150, 160 in question, which particular authentication service provider 110is the operator of a mobile wireless network being able to authenticate the user basedupon control of the electronic device 170, 180 used to access the user service provider 150, 160, as described above.

According to the said first aspect of the invention, thereafter either user credential dataassociated with the user in question is provided, in a step 219, directly to the selectedauthentication service provider, without the user credential data being supplied to thecentral server 101, or it is determined, in a step 220, that the selected authenticationservice provider already has an active authentication session for the user in question.

Application text 2015-09-14 150088SE 18 Hence, in step 219 or 220, the central server 101 acts as a pure intermediary, bindingtogether the user service provider 150, 160 with one of several available authenticationservice providers 110, 120, 130, without ever gaining actual knowledge of the specificcredential information necessary for performing said authentication. Since the credentialdata is not provided to the central server 101, it is neither stored therein, nor in the database 102.

According to a preferred embodiment, the provision in step 219 is made possible by apreferred step 218, in which the above mentioned first graphical user interface is arrangedto in turn activate a second user interface. This second user interface is then arranged toallow the user in question to communicate directly with the selected authenticationservice provider, thereby to supply said user credential data to the selected authentication service provider without it passing via the central server 101.

According to one preferred embodiment, the second user interface is an interactivegraphical user interface provided to the user on the display 171, 181 of the electronic device 170, 180, and via which the user can enter the credential data.

For instance, in this case the second graphical interface may be in the form of a locallyinstalled or remotely accessed application which is activated by the first graphical inter-face, and to which the active view of the display 171, 181 is transferred upon such activa-tion. However, according to a preferred embodiment the second graphical user interfaceis provided as an integrated graphical sub interface of the first graphical user interface,such as within a specific subpart, such as an iframe, provided within a web page com-prised in the first graphical user interface. For instance, the second graphical interfacemay be embodied as a particular graphical field in the first interface, or a popup dialoglaunched by and from the first interface. ln these and similar examples, the second inter-face will typically comprise user controls activatable for recording or entering, and provid-ing, credential data specifically selected for authenticating the user in relation to thetransaction to be performed.

Application text 2015-09-14 150088SE 19 ln a particularly preferred embodiment, the second interface is populated with contentsby the selected authentication service provider itself, after initiation by the user serviceprovider 150, 160. ln case a relevant template was provided by the central server 101 tothe selected authentication service provider in step 207, this template is preferably usedas a basis for the population of the second interface with such user controls. For instance,a template for entering a user name and a password may comprise labels, user input fieldsfor user name and password, as well as a field in which the authentication service providercan insert its logotype. Also, a link to a standardized set of terms and conditions can beprovided as a part of the template, and so on. ln general, it is preferred that the sametemplate is provided to several authentication service providers, so that the user experi-ence for the end user becomes as similar as possible when using different authenticationservice providers. Hence, in this case the selected authentication service provider providesthe actual second graphical user interface to the user service provider 150, 160, or prefer-ably directly to the device 170, 180, for provision to the user in question as a part of the first graphical user interface, based upon said template.

According to another preferred embodiment, the second interface may be provided byspecific software or hardware which is not part of the first graphical interface, but asinitiated by the first graphical interface, such as activation of a fingerprint sensor on thedevice for reading the user's fingerprint and providing related data to the central server101; activating a mobile telephony operator of the mobile phone of the user for sendingan SI\/IS (Short Message Sevice) to the mobile phone's telephone number (I\/ISISDN),comprising an alphanumerical challenge to be manually provided to the user serviceprovider by the user, or providing a request to the said mobile telephone to re-enter theSIM (Subscriber Identity I\/|odule) PIN code (the latter two options preferably being initiat-ed by the mobile wireless network operating authentication service provider 110 directlyvis-à-vis the user); activating a cryptographically based authentication procedure which is locally activatable on the electronic device; or the like.

Application text 2015-09-14 150088SE lt is also possible, in case the selected authentication service provider 110 is the operatorof a mobile wireless network to which the electronic device 170, 180 is connected, that anautomatic readout of an identifier of the electronic device 170, 180 is performed by thenetwork as described above, for securely identifying the electronic device 170, 180 and asa result authenticating the user. ln this case, step 219 may be unnecessary, and themethod may immediately skip from step 217 to step 221. This is described in closer detail in connection to steps 336-340, below.

As mentioned above, in the alternative step 220, it is determined that there is already anactive authentication session involving the selected authentication service provider andthe user in question, in which case the second interface is not presented but the methodinstead skips to step 221. For instance, the central server 101 may collect informationregarding such an active authentication session, or the first interface may receive suchinformation upon a request to the selected authentication service provider to provide the second interface.

Then, in a step 221 according to the present invention, the selected authentication serviceprovider authenticates the particular user. ln case credential data was supplied in step219, the authentication comprises the selected authentication service provider verifyingthe credential data. ln case an active session was determined to exist in step 220, theauthentication comprises the selected authentication service provider verifying the said active authentication session, in which case steps 220 and 221 may be one and the same. ln a subsequent step 222, an authentication response is provided to the user serviceprovider 150, 160. This authentication response may be that no authentication waspossible, for instance since the user did not supply correct credential data to the authenti-cation service provider, or that the authentication was validly performed based upon thesupplied user credential data or the fact that an active authentication session existed. lt ispreferred that the authentication response is provided from the selected authentication service provider to the user service provider 150, 160 via the central server 101.

Application text 2015-09-14 150088SE 21 According to a preferred embodiment, the user service provider 150, 160 is then providedwith access, preferably from the selected authentication service provider and via thecentral server 101, to user information previously stored by the selected authenticationservice provider and therein associated with the particular user in question. According toan alternative embodiment, the said user information is provided directly from the au-thentication service providers (or several authentication service providers) to the userservice provider 150, 160, by the central server 101 providing a direct communication channel between the user service provider and the authentication service provider.

Herein, the term ”user information” means any user metadata information, such as name,delivery and invoicing addresses, telephone numbers, credit card information, clothingsizes, contact lists, preferred configuration options, previous user behavior, etc., that isspecific to the user in question. Such user metadata has preferably been provided by theuser in question as a part ofthe interaction between the user and the selected authentica-tion service provider in step 204 or before, under the security provided by an activeauthentication session or in real life, for instance during the course of the ordering of a service the delivery ofwhich requires user information to be provided by the user. lt is preferred that the said user information is used by the user service provider 150, 160to automatically populate corresponding user input fields in a graphical user interface,such as the first graphical interface, provided to the user by the user service provider 150,160 and via the electronic device 170, 180. Hence, all or only a subset of the user infor-mation which is required by the user service provider 150, 160 may be available from theauthentication service provider for such auto population. According to one preferredembodiment, all available user information is supplied as a part of the above said authen-tication response. Alternatively, a separate interface is provided to the user service provider 150, 160 by the central server 101 for querying available user information.

Application text 2015-09-14 150088SE 22 lt is furthermore preferred that access to user information is only provided to the userservice provider 150, 160 after an explicit approval from the user in question. Such ap-proval may be delivered for more or less general purposes in an initial step in which theuser registers with the user service provider 150, 160, the central server 101 or theauthentication service provider 110, 120, 130, or at a later point. For instance, activatingthe said user control in step 217 may imply such approval. Step 205 may also cover suchapproval. According to the preferred embodiment illustrated in figure 2, the user ispresented, in step 223, with an explicit option, for instance in the form of an activatableuser control, in the said first graphical interface, to automatically populate input fields using available user data, or to populate only certain specified such input fields. ln case the user opts in to automatically populate input fields in the interface, the popula-tion is performed in a preferred step 224. Non-automatically populated input fields are filled in by the user manually.

Thereafter, in a step 225, the transaction identified in step 210 is performed by the userservice provider 150, 160 in relation to the user in question. This may mean the orderingor purchasing of a good or a service, involving a transfer of funds; the publication ortransmittal of information; the activation of a subscription; the modification of user information; or any other conventional user service. ln step 226, the method ends.

According to a preferred embodiment, both the selected authentication service providerand the user service provider 150, 160 are accessed by the particular user in question via aweb browser provided on the electronic device 170, 180. The web browser used in varioussteps may be one and the same, or a different one, as long as the relevant information(such as cookies) is available for said browsers, as applicable. This is also the case in amethod according to a second aspect of the invention, which is illustrated in figure 3 andwhich will be described in the following. The following description of the method accord-ing to this second aspect of the invention will furthermore provide a more detailed de- Application text 2015-09-14 150088SE 23 scription of certain preferred aspects of the above described method according to the first aspect of the invention.

Hence, in a step 301 the method starts. ln a step 302, which is similar to step 202, the central server 101; at least one, preferablyseveral, preferably a plurality of, authentication service provider(s) 110, 120, 130; and atleast one, preferably several, preferably a plurality of user service provider(s) 150, 160 areprovided. The central server 101 is in communication with both the authentication service provider(s) 110, 120, 130 and the user service provider(s) 150, 160.

According to this second aspect of the present invention, the authentication serviceproviders 110, 120, 130 are arranged to authenticate users based upon the user's controlover the electronic device 170, 180 of the user, as described above, which electronicdevice 170, 180 is provided wireless internet connectivity via a network operated by thesaid authentication service provider in question. This has been exemplified above with provider 110, operating a wireless network comprising base station 111.

Furthermore, the user service providers 150, 160 are arranged to provide user services toparticular users via a respective user service web interface each. Furthermore, the saidweb interfaces are provided to the user via one and the same web browser (or differentweb browsers, as applicable according to the above) executed from (such as via a remote-ly provided web browsing service), or by, the electronic device 170, 180 controlled by theuser in question. The user service web interface corresponds to the first user interface as discussed above in relation to figure 2. ln a step 303, wireless internet connectivity is provided to the electronic device 170, 180via the said wireless network which is operated by the authentication service provider110. Herein, ”providing wireless internet connectivity" implies that the electronic device170, 180 can be securely identified by the operator of the network in question as de-scribed above, preferably using a unique identity of a SIM card installed in the electronic Application text 2015-09-14 150088SE 24 device 170, 180, or similar. This identification takes place as an integrated part of theelectronic device 170, 180 being provided such wireless connectivity, by the operatorcapturing identifying information of the device 170, 180 from communication messages toor from the device 170, 180; using a piece of software directly investigating electronicdevice 170, 180 hardware or software and reporting to the operator found information; or in any other suitable way as described above.

Steps 304-316 may correspond to step 204, or to steps 208-222.

Hence, in a preferred step 304, a respective user service web interface is provided by atleast one of said user service providers 150, 160, for instance made available in the form of a corresponding web site by a web server of the said provider 150, 160.

A web page of the interface is requested by the said web browser of the electronic device170, 180 in a step 305, and, in a step 306, the requested web page is provided to thedevice 170, 180 and displayed thereon. lt is realized that steps 305, 306 can take place in another way, which is conventional as such. ln a step 307, which must be performed at the latest before step 311, at least one of theauthentication service providers 110, 120, 130 authenticates the user of the electronicdevice 170, 180, for instance by the user visiting a secure web page of the authenticationservice provider 110, 120, 130 in question and there performing an authentication basedupon the control of the electronic device 170, 180; by physically visiting the authenticationservice provider 110, 120, 130 and providing a piece of identification; or in any othersuitable way providing a secure authentication of the user, specifically connected to the electronic device 170, 180 in question.

Preferably, in a step 308, an option is provided to the user, preferably in connection to theauthentication in step 307, whether the user whishes the authentication service provider110, 120, 130 to either provide authentication services with respect to the user on behalfof general or specific user service providers 150, 160 and/or provide user information to Application text 2015-09-14 150088SE such user service providers 150, 160, preferably specifically in connection to such authen- tication. ln a step 309, the user service provider 150, 160 visited in steps 305-306 determines atransaction which the user wishes to take part in, as a transaction part, using the userservice provider 150, 160 in question, and in relation to which transaction the user is to be authenticated as such a transaction part. ln a step 310, a call is made, by the user service provider 150, 160, to the central server101, requesting the central server 101 to authenticate the user in relation to the identifiedtransaction. This call can, for instance, be in the form of a web page redirect to the centralserver 101, or by the use of a script on the web page provided in step 306. ln one pre-ferred embodiment, the web page provided in step 306 comprises content to be providedby the central server 101, such as an iframe with web page content provided by thecentral server 101, resulting in the central server 101 being called upon to provide such contents. The contents as such may be invisible to the user.

The central server 101, when called upon, in a step 311 identifies at least one authentica-tion service provider 110, 120, 130 which has the capability to authenticate the user oftheelectronic device 170, 180, for instance based upon information regarding the user and/orthe electronic device 170, 180 provided by the user service provider 150, 160 calling thecentral server 101; by the central server 101 receiving such information as a part of thecommunication with the web browser in which the central server-provided content isused; by the central server 101 reading a cookie placed on the electronic device 170, 180in connection to the authentication in step 307, preferably via a call from the authentica-tion service provider 110, 120, 130 in question to the central server 101 in connection tostep 307 whereby the central server 101 places the cookie identifying, to the centralserver 101, the authentication service provider 110, 120, 130. The latter option is de-scribed in closer detail in the above referred to still not published Swedish patent applica- tion.

Application text 2015-09-14 150088SE 26 The present invention is interested in the particular case in which the identified authenti-cation service provider in this step is one which can authenticate the user based uponcontrol of the electronic device 170, 180 and via communication in the above mentionedwireless network. ln other words, in step 311, the authentication service provider 110 isidentified. Several possible authentication service providers 110, 120, 130 may be identi-fied, but in the following it is the provider 110 which is referred to as the one authenticat- ing the user in steps 313-315, and so forth. ln a step 312, a call, such as a web redirect, is performed to the identified authenticationservice provider 110, identifying the user and/or the electronic device 170, 180. ln a step313, the authentication service provider 110 determines whether there is an activesession or not with the authentication service provider 110, as described above and alsobelow. ln this context, that there is an ”active session” means that there is an activeauthentication session with respect to the user involving the electronic device 170, 180used. For instance, the user may have performed an authentication based upon controlover the electronic device 170, 180 within a certain time period preceding step 313.Preferably, the active session is based upon a previous authentication which has takenplace via the mobile wireless network operated by the authentication service provider 110 in question. lf, in a step 314, it is determined that there is not such an active session, the user isauthenticated in a step 315, by the said authentication service provider 110 based uponthe user's control over the electronic device 170, 180 and via the said mobile wirelessnetwork operated by the authentication service provider 110, as described above. Such authentication may or may not involve an interaction with the user.

Hence, after step 314 or 315, the user has been authenticated by the authenticationservice provider 110. lt is realized that more than one authentication service providers110, 120, 130 can authenticate the user in similar ways, in steps corresponding to steps312-315, as long as at least one is one which may authenticate using the said network, asdescribed above.

Application text 2015-09-14 150088SE 27 ln a step 316, the authentication service provider 110 provides, to the user service provid-er 150, 160, in a way which may be similar to the above or below described, authentica-tion information regarding the just performed authentication. This authentication infor-mation can, for instance, simply acknowledge that the user has been securely authenti- cated.

According to the invention, in a step 318 which is performed upon the said authenticationof the user by the authentication service provider 110, the central server 101 is allowedand caused to place an identifying cookie, in other words a first cookie, on the electronicdevice 170, 180, which cookie is arranged to identify the authentication service provider110 in question to the central server 101. Preferably, this identifying cookie is also ar-ranged to identify the authentication service provider 110 identified by the cookie as onewhich has authenticated the user based upon control over the electronic device 170, 180 on which the cookie is placed.

According to a preferred embodiment, the central server 101 is allowed to place theidentifying cookie via the web browser used to access the particular user service webinterface in steps 304-306. Preferably, the placement of the identifying cookie takes placeby the said particular user service web interface comprising central server 101 contentwhich is fetched from the central server 101, thereby allowing the central server 101 to place the identifying cookie.

According to a first alternative embodiment, the central server 101, in connection to theplacing of the identifying cookie in step 318, in a step 317 further allows the authentica-tion service provider 110 to place an authentication cookie, in other words a secondcookie, on the electronic device 170, 180. Such an authentication cookie is arranged toidentify, to the authentication service provider 110, the user and/or the electronic device170, 180 in question. The placing of the authentication cookie may take place in anysuitable way, such as via a web direct to web content provided by the authenticationservice provider 110 and incorporated in a piece of central server 101 provided web Application text 2015-09-14 150088SE 28 content incorporated in the user service web interface, such as using an iframe incorpo-rated in an iframe; via suitable scripts; or the like. What is important is that the authenti-cation service provider 110 in question is caused, by the central server 101, to be allowedto place the authentication cookie on the electronic device 170, 180, preferably in thesame web browser as used in steps 305-306. The authentication cookie may compriseinformation about a currently ongoing active authentication session for the user and/orthe electronic device 170, 180 in question. The information comprised in the authentica-tion cookie allows the authentication service provider 110 to specifically identify the user and/or the electronic device 170, 180. ln a second alternative embodiment, the central server 101, in connection to the placingof the identifying cookie in step 318, further receives from the authentication serviceprovider 110 particular information regarding the user and/or the electronic device 170,180 allowing the authentication service provider 110 to, at a later point, identify the userand/or the electronic device 170, 180. Then, in step 317, the central server 101 associatesthe particular information with the identifying cookie and stores the particular infor-mation, such as in database 102. Alternatively, the central server 101 stores the particular information as a part of the identifying cookie.

Hence, after the performance of steps 317 and 318, there is an authentication of the userwhich has taken place based upon control of the electronic device 170, 180 via the saidwireless network, and the central server 101 has placed identifying information on theelectronic device 170, 180 (the identifying cookie) regarding what authentication serviceprovider has performed such authentication. Based upon the authentication cookie or thesaid particular information, it is possible for the authentication service provider 110 todetermine the identity of the user and/or the electronic device 170, 180, hence making itpossible for the authentication service provider 110 to determine whether it can authenti-cate the user or not, even when the said network operated by the authentication serviceprovider 110 is not used for the communication at a later stage when such authentication is needed. This will be detailed in the following.

Application text 2015-09-14 150088SE 29 lt is preferred that all information in said identifying and authentication cookies and in theparticular information is coded and/or encrypted, so that only the central server or the authentication service provider 110, as applicable, can interpret the information.

Then, in a step 319, the electronic device 170, 180 is provided internet connectivity whichis not via the said network operated by the authentication service provider 110 in ques-tion. Such internet connectivity may be wireless mobile internet connectivity provided viaa different operator; a WiFi connection; a wired internet connection; or the like. What isimportant is that, using the steps 304-316 it is not possible for the authentication serviceprovider 110, preferably not for any of the authentication service providers 110, 120, 130,to authenticate the user based upon control of the electronic device 170, 180 and via a network operated by the respective used authentication service provider 110, 120, 130.

Steps 320-346 may correspond to steps 209-224. ln a step 320, which is similar to step 304, the user, using a web browser executed on orfrom the same electronic device 170, 180 as used in steps 317, 318, is provided access,further using the internet connection provided in step 319, to a user service web interfacewhich may or may not be the same user service web interface as used in steps 305-306. lnother words, the authentication performed in steps 313-315 is an authentication of theuser performed in connection to the user accessing a particular user service web interface,which may or may not be the same user service web interface as the one accessed in step320, and in relation to which the user is to be authenticated again, as will be described in the following. ln a step 321, which may be similar to step 309, a transaction is identified, wherein theuser is to be a transaction part and in relation to which the user is to be authenticated as a transaction part for the purposes ofthe user service provider 150, 160 in question. ln a step 322, which may be similar to step 305, a corresponding user service provider web page is requested by the electronic device 170, 180 for the user service provider 150, 160 Application text 2015-09-14 150088SE in question, and as a result, in a step 323 which may be similar to step 306, a second user service web page is returned to the electronic device 170, 180.

As a result of the access provided to the web interface in steps 320-323, the above de-scribed identifying cookie is provided to the central server 101, in particular in steps 324-325 in which the central server 101 is called upon by the electronic device 170, 180 in question and allowed to read the identifying cookie in question.

Such call can, again, take place in any suitable way, such as using a script comprised in thesecond user service web interface. However, according to a preferred embodiment, theproviding ofthe identifying cookie to the central server 101 in step 324 takes place by thesecond user service web interface accessed in steps 322-323 comprising central server 101content which is fetched from the central server 101, and by the central server 101receiving, such as reading, the identifying cookie in connection to a call from the userservice web interface requesting said central server 101 content. The central server 101content may, for instance, be in the form of an iframe containing web content provided bythe central server 101. lt is preferred that all calls to the central server 101 and the au-thentication service provider 110 in steps 323-328 are performed without being visuallyvisible to the user in the web browser in question on the electronic device 170, 180. Forinstance, a non-visible iframe may be used to redirect the web browser to the central server 101 in step 324. lt is preferred that the central server 101 in step 325 reads not only the identifying cookieplaced by the authentication service provider 110 as described above, but any identifying cookies placed this way.

Then, in a step 326, the central server 101 identifies, based upon the identifying cookie orcookies read, the authentication service provider 110 or all authentication service provid-ers identified by such cookies. lt is realized that one and the same identifying cookie could be used to identify several authentication service providers.

Application text 2015-09-14 150088SE 31 ln a step 334, in the said first alternative embodiment, the authentication service provider110 is allowed to then read the authentication cookie placed in step 317, from the elec-tronic device 170, 180, and then, in a step 335, to first determine whether or not theauthentication service provider can authenticate the user in question at all, and then todetermine whether the user and/or electronic device 170, 180 identified by the authenti-cation cookie is still validly authenticated by the authentication service provider 110, suchas by identifying the presence of an active authentication session for the user and/orelectronic device 170, 180 in question. The non-existence of an authentication cookiecould imply that no such authentication is possible. Preferably, the said causing of theauthentication service provider 110 to read the authentication cookie is performed by acommunication or call, such as a redirect, performed by the central server 101 and prefer-ably via the web browser used to access the second user service web interface in steps322-323. For instance, the said central server 101 web content could comprise a piece ofauthentication service provider 110 web content, such as an invisible iframe, causing theauthentication cookie to be passed to the authentication service provider 110 when the central server 101 content is loaded. ln the said second alternative embodiment, in a step 327, the central server 101 insteadreads the particular information stored in step 317, and, in step 328, queries the authenti-cation service provider 110 whether the user and/or electronic device 170, 180 identifiedby the above described particular information is still validly authenticated by the authenti-cation service provider 110. ln this case, it is preferred that the particular information isstored by the central server 101 in a way which does not allow the central server 101 toidentify the user, and preferably also not the electronic device 170, 180, based on theparticular information, but that this is only possible for the relevant authentication service provider 110 in question. For instance, the information may be coded or encrypted.

Then, in a step 329, the second user service web page is displayed on the electronic device170, 180. As a part of the second user service web page, in a step 330, an option is dis-played to the user whether the user wishes to be authenticated, for the transaction inquestion, by one or any of the authentication service provider(s) 110 identified in step Application text 2015-09-14 150088SE 32 326, and whether the user wishes to allow user information to be transferred from suchauthentication service provider 110 to the user service provider 150, 160 in question in relation to the said transaction and its fulfillment. ln case the user has previously agreed, in step 308, to always allow a particular 110 or anyauthentication service provider to provide authentication and/or user information, theoption presented in step 330 may, under some circumstances, not be displayed, and instead an ”OK” from the user is assumed to be present.

However, it is preferred that one ofthe following happens. ln the case of the said first alternative embodiment, it is preferred that all, or at least one,of the authentication service provider(s) identified in step 326 are presented as availablein step 330, and the user may select at least ”any of the identified authentication serviceproviders" or a particular one of the presented authentication service providers. Then, asthe user performs a selection resulting in a particular one authentication service provider110, either by the user specifically selecting one or by the central server 101 selecting onebased upon the user's selection of several possible authentication service providers, theauthentication service provider 110 to use is identified in a step 332, and the identifiedauthentication service provider 110 is called upon in a step 333. Thereafter, the step 334is performed, possibly resulting in an error message to the user that the authentication service provider is not available to authenticate the user in question. ln the case of the second alternative embodiment, only authentication service provider(s)responding in the positive regarding their authentication availability for the user and/orthe electronic device 170, 180 in question are displayed as available options in step 330,and the step 334 is never performed. Hence, in this case the user will only be providedwith an option to be authenticated by a particular authentication service provider 110identified in step 326 in case the authentication service provider 110 has confirmed that an authentication is indeed possible under the current circumstances. As a result, this Application text 2015-09-14 150088SE 33 alternative will not result in the said error message, why this second alternative embodi- ment is the preferred one. lt is preferred that it is the user service provider 150, 160 providing the second userservice interface accessed in steps 322-323 which is caused to allow the central server 101to provide or not to provide said option in step 330. Preferably, this takes place by thecentral server 101 populating corresponding central server 101 content with a usercontrol arranged to allow the user to be authenticated by the authentication serviceprovider 110 identified in step 326. For instance, the central server 101 web content beingdisplayed as part of the second user service web page returned in step 323 and finallypopulated in steps 329-330 could comprise one respective button for each availableauthentication service provider 110 identified in step 326 and for which authenticationservice provider it has been verified, in step 328, that the user can be validly authenticat- ed. ln case the user does not select any authentication service provider, or selects ”No” or thecorresponding, in step 330, the user service provider 150, 160 may apply a prioprietaryauthentication of the user for the transaction in question, and the method skips to step 347. lt is noted that this verification step according to the first alternative embodiment takes place in steps 334-336. lt is further noted that, in case no authentication service providers were identified in step 326, the option in step 330 may not be displayed at all.

Hence, irrespectively of if the first or second alternative embodiments are used, in a step335 it is determined, by the authentication service provider 110 called in step 333, wheth-er or not an active authentication session exists for the user and/or the electronic device 170, 180 with the authentication service provider 110.

Application text 2015-09-14 150088SE 34 lf this is deemed to be the case, in a step 336, the user is considered authenticated. lt isimportant to note that, in this case, the user is no longer connected to the wireless net-work operated by the authentication service provider 110, and the |atter can therefore nolonger automatically authenticate the user based upon control of the electronic device170, 180. However, due to the identification of the active authentication session, anauthentication can nevertheless be performed automatically, based upon the electronicdevice 170, 180 being associated with the authentication service provider 110 via thecentral server 101. A timer for the active authentication session is preferably less than 60minutes, meaning that it will only be possible to authenticate a user automatically using a”Yes” in step 336 at the most 60 minutes after the electronic device 170, 180 is discon- nected from the network operated by the authentication service provider 110. lf the step 336 results in a ”No”, the authentication service provider 110, in a step 337,preferably tries to authenticate the user again, based upon control of the electronic device170, 180 and via the network operated by the authentication service provider 110. Typi-cally, this would now involve the user being provided with some type of visual feedbackregarding this authentication process and being required to provide credential data ofsome sort. For instance, an SMS message could be sent to the electronic device 170, 180,comprising credential information which is fed back to the authentication service provider110 via the user service provider interface, such as via manual user input. However, itwould also be possible for a software function of the electronic device 170, 180 to, in step337, automatically investigate identifying information of the electronic device 170, 180,such as a MAC address or a SIM card |l\/|S| or MSISDN code, and automatically communi-cating such identifying information to the authentication service provider over network190. Such software may be locally installed beforehand on the electronic device 170, 180and automatically invoked by the user service provider 150, 160 interface in step 337. This way, also step 337 could be performed in a way which is transparent to the user. ln case this authentication is positive, in a possible step 338, the user may be redirected toan authentication web interface allowing the user to authenticate manually with theauthentication service provider 110, for instance by, in a step 339, provide user credential Application text 2015-09-14 150088SE data to the user authentication service provider 110 allowing the latter to tie the user to apreviously registered secure user account or the like, and that way securely authenticate the user in question, in a step 340.

Thereafter, in a preferred set of steps 341-345 performed in case the user was authenti-cated in steps 336-340, user authentication information is provided from the authentica- tion service provider 110 in question to the user service provider 150, 160.

Thus, in a step 341 after the said authentication, a first access token is provided from theidentified authentication service provider 110. Such an access token is arranged to allowthe holder of the token to access, using the token, a certain subset of otherwise secretinformation from the identified authentication service provider, in particular user infor-mation (as defined above) for the user in question. Hence, using the first access token, theholder may query the identified authentication service provider 110 for at least some userinformation associated with the user in question and known to the provider 110. Suchquerying takes place via a specified interface provided by the authentication service provider 110. Suitable examples of such access tokens comprise OAuth2 access tokens.

The user service provider 150, 160 may be provided directly with the first access token.However, it is preferred that it is the central server 101 that is provided with the first access token. ln the latter case, the central server 101 is then preferably, in turn, in a step 342 arrangedto issue a second access token, preferably of similar functionality and type as the firstaccess token, and send it to the user service provider 150, 160, possibly indirectly bysending it to the user service web interface as operating on or from the device 170, 180.Using the second access token, the user service provider 150, 160, again possibly indirectlyvia the user service web interface, can obtain access, by querying to the central server 101 using a specified interface, to at least some user information.

Application text 2015-09-14 150088SE 36 ln the preferred embodiment in which the user has allowed such user information to bequeried from the identified authentication service provider 110, via the central server 101,in a step 343 the second access token is presented by the user service provider 150, 160 tothe central server 101, and used to request specified user information. Thereafter, thecentral server is arra nged to, in a step 344, if allowed by the second access token, requestuser information corresponding to the information requested in step 343 from the identi- fied authentication service provider 110. ln a step 345, the requested information, if known to the identified authentication serviceprovider 110 and allowed by the first access token, is returned to the central server 101, which in turn is arranged to provide the information to the user service provider 150, 160.

The issuing, provision and use of the first and second access tokens are conventional as such, and possible implementations are for instance described in the OAuth2 documenta- tion available from httpzjfoauthfietﬂf.

Then, in a step 346, input fields for the corresponding user information in a user serviceprovider web page are preferably automatically populated by the user service web inter-face in question, using the user information obtained from the central server 101 in step 345. ln a step 348, the method ends.

An example of a user service provider web page 430 of the above discussed type is illus-trated in figure 4a, as provided, for exemplifying reasons, by user service provider 150 andshown on the display 181 of the device 180 and hence viewable to the user. Figure 4aillustrates the state of the web page displayed in step 329 during a run-through of themethod according to said second alternative embodiment shown in figure 3. A number ofuser controls 401 allow the user to enter user information for transmittal to the user service provider 150 upon pressing the ”Checkout” button 461 and for use in finalizing a Application text 2015-09-14 150088SE 37 transaction, namely to buy the two items currently in the user's virtual shopping cart (as illustrated in figure 4a).

However, there are two ”Checkout” buttons. One 461 of these is always available, and isactivatable to perform a transaction with the user as a transaction part using the userinformation 401 provided manually by the user by entering information into the corre-sponding fields in the web page 430. The other one 431 (”Checkout using ASP1") is auto-matically populated by web page content (that is, the control button with the text”Checkout using ASP1") provided by the central server 101 upon the call made from theuser service provider 150 to the central server 101 in step 324, for instance using aniframe the contents of which are provided by a web server of the central server 101. lncase no available authentication service providers were found in step 326, or in case noauthentication service providers could be verified in step 328, the button 431 wouldsimply be missing in the interface 430. Hence, the existence of the button 431 in figure 4aindicates that there is at the moment at least one authentication service provider 110available for authenticating the user based upon control of the electronic device 180 andvia said wireless network operated by provider 110. The currently shown text ”Checkoutusing ASP1" indicates that (at least) authentication service provider 110 named ”ASP1” is available for authentication. ln this exemplifying case, the user has beforehand agreed, in step 308, to both allow ASP1(authentication service provider 110) to authenticate the user and to provide user infor- mation to user service providers, such as to user service provider 150.

According to one preferred embodiment, illustrated in figure 4b, by pressing the ”Check-out using ASP1" button 431, the authentication and user information fetching steps 332-346 are all performed automatically in the background upon pressing of the button”Checkout using ASP1" 431, not involving any user interaction in the user service providerinterface. Then, the state 460 of the web page illustrated in figure 4b will result, if noerrors or problems are encountered. The user information (name, address and credit card)have been automatically populated using such information queried from the authentica- Application text 2015-09-14 150088SE 38 tion service provider 110 via the central server 101 in steps 343-354 and used to fill in thefields in the web page. The button ”Checkout” 461 may be pressed in order to go aheadwith the transaction in question using the currently displayed user information 401,possibly after editing of the user. According to one preferred embodiment, pressing of thebutton 431 even leads to the user being authorized by the authentication service provider110, user information being fetched and the transaction finalized using the fetched userinformation, everything done automatically and without involving the user at all in all goeswell. ln this case, the state 450 shown in figure 4b would never be shown, but the userwould instead be redirected to a page informing the user of the finalized transaction or the like. ln case the authentication in step 337 is unsuccessful, in step 338 the state 440 shown infigure 4c is shown, in which the user can provide, in step 339, credential data 442 for areauthentication, in step 340 of the user by the authentication service provider 110.Preferably, and as shown in figure 4c, this is performed using a sub interface 444, such asan iframe, of the user service provider 150 web page which is populated by the authenti-cation service provider 110 directly, such as using a set of user controls allowing the userto enter and send said credentials directly to the authentication service provider 110 forverification and authentication. After the user presses the ”Submit” button 443, the state460 shown in figure 4b may be shown as the next step in the user experience, if the authentication goes well.

According to a preferred variant of the above described, the step 328, or at least step 326,is performed already before the transaction has been defined, such as before proceedingto checkout in an online vendor web site. This way, user information can be provided tothe user service provider 150, 160, via the mechanism in steps 332-345, and used forinstance to provide enhanced purchasing support information to the user. This can beachieved by, for instance, a button representing the option to use the present method, ifavailable for the user in question and the electronic device 170, 180 in question, being displayed at the welcoming page of the user service web interface.

Application text 2015-09-14 150088SE 39 According to another preferred embodiment, the database 102 comprises a respectiverecord for each user registered for use with the system 100, comprising a flag setting thatthe user always, or at least for a certain set of user service providers 150, wishes to acceptthe option presented in step 330, respectively. lf the flag is set, step 330 is not performed,but instead the method skips directly to step 332. This may, for example, mean that thebutton ”Checkout with ASP1" is not displayed, but that a normal ”Checkout” button willalways result in an automatic authentication and possibly also user information provisionas described above, whenever and as soon as at least one authentication service provider 110, 120, 130 is available for valid user authentication as described above.

Figure 4d illustrates an example of these two latter variations, in the form of the welcomepage 470 of a user service web interface provided on the display 181 of the device 180 ofthe user John Doe, displaying user controls 472 for navigating the page. ln this case, theuser has agreed to always allow user service providers to gain access to the user name viathe above described access tokens, as provided by the user's online community serviceprovider. By pressing the button 471, the user agrees that the user service provider isentitled to request also other available user information from the central server 101 and,when proceeding to checkout, available user information will be used to auto populate any input fields as described above. ln fact, the button 471 will generate a redirect to the central server 101, which thenreceives any cookies previously stored in the web browser of the device 180 by centralserver authentication content by the action of authentication service providers, and then,after proper verification of the settings in the database 102 and the contents of the saidcookies, redirects to the said online community service provider, which, in turn, issues andreturns the above described first access token. To the user, this process is completelyunnoticeable and virtually instantaneous, since the user in this exemplifying case alreadyhas an active authentication session with the said online community provider. All thisunder condition that at least one authentication service provider, based upon availableinformation, can authenticate the user based upon control of the electronic device 180and using said wireless network as described above.

Application text 2015-09-14 150088SE A method and a system according to the present invention provides a cost-efficient wayfor a user service provider 150, 160 to be able to offer secure authentication of its users.By registering with the central server 101 and specifying at least one minimum allowableauthentication level, such a user service provider 150, 160 gains access to a network ofthird party authentication service providers 110, 120, 130 that can provide required userauthentication on behalf of the user service provider. Since each user authenticationservice provider can offer to sell such an authentication for a particular price, using goodeconomies of scale, the central server 101 can provide complex and advanced user au-thentication at a very cost-efficient total cost per authentication than, for instance, asmall-scale user service provider 101 is capable of reaching. lt is even possible for such asmall-scale user service provider to offer a wide and highly specialized set of authentica- tion service functionality without its total costs for authentication increasing significantly.

On the other side, users of the system 100 can authenticate themselves to a wide range ofuser service providers 150 in a very efficient manner, and also have the system 100 keeptrack of relevant user information such as credit card numbers, without jeopardizingpersonal information integrity, by simply agreeing to letting one or several trusted authen-tication service providers, such as the user's personal online banking facility, authenticatethe user on behalf of other parties and to contribute with user information known to them. lmportantly, these advantages can be achieved without removing much flexibility for anyof the stakeholders. The users can choose to use any registered authentication serviceprovider, and the user service providers do not have to follow authentication standards or protocols offered by the individual authentication service providers.

Furthermore, users will experience better efficacy when dealing with user service provid-ers, since much user information can be made available automatically, without the userhaving to type it in repeatedly at various sites. At the same time, user service providerscan offer a more tailor made user experience with extra knowledge of the visiting user at Application text 2015-09-14 150088SE 41 an early point in the transaction process. These advantages are even more powerful incase several authentication service providers are used in parallel to together provide a more complete set of available user information. ln particular, these advantages can be achieved even in the case of authentication serviceproviders using control of a particular electronic device (”something you have") as anauthentication factor, via direct communication in a wireless mobile network, also in casesuch electronic device is no longer connected to such mobile network, for instance whencoming home or entering an office building, and switching to a WiFi connection as a COHSQQUQHCE.

Hence, the selected or identified authentication service provider described above is amobile telephony operator to which the particular user is a subscriber. The user authenti-cation provided by the authentication service provider comprises a mobile authenticationstep in which the user communicates with the selected authentication service providerusing a mobile device comprising a SIM card associated with the particular user's subscrip-tion with the said authentication service provider. For instance, the credential data pro-vided by the user to the authentication service provider may then comprise an alphanu-meric code sent to the telephone number (MSISDN) of the mobile phone as an SMS, readby the user and input into an input box comprised in the graphical interface. The abovedescribed first graphical interface may be provided on the display of the said mobiletelephone, such as by a web browser running on the mobile telephone. Such methodprovides a second authentication factor (something the user has, namely the mobile telephone). lt is particularly preferred that the mobile authentication step specifically comprises theverification of a certificate which has previously been provided on the said SIM card. This provides very good security. lt is realized that the authentication performed in steps 335-340 may comprise additional authentication factors, such as entering a PIN number, which additional factors would Application text 2015-09-14 150088SE 42 then be independently applied from the factor based upon control of the electronic device. lt is realized that the methods described in connection to figures 2 and 3 can be repeated.Hence, the user may be authenticated as a mobile subscriber to the mobile wirelessnetwork, move to a WiFi connection, be authenticated again based upon the previousauthentication in the mobile network, move to a different WiFi connection and again beauthenticated there based upon the previous mobile network authentication, again moveto a mobile wireless network and be authenticated again there, then move to a WiFinetwork and be authenticated based upon the last mobile network authentication, etc.Hence, from the user's perspective, a seamless experience is achieved, in particular aslong as the electronic device reaches a mobile wireless network connection sufficientlyfrequently so as to maintain an active authentication session with the authentication service provider 110. ln particular, according to one preferred embodiment, the authentication service provider110 periodically re-authenticates the user based upon the control of the electronic devicewhen the latter is connected to the above described network of the provider 110, in a waywhich does not involve any interaction with the user, such as by automatically reading anIMSI code of the electronic device. This way, the chance of there being an active authenti-cation session once the electronic device moves into a WiFi connection, or the like, will be large.

Above, a number of preferred embodiments have been described. However, it is apparentto the skilled person that many modifications can be made to the described embodiments without departing from the basic idea of the invention.

For instance, the above described first and second aspects of the present invention haveconsiderable overlap. However, it is realized that all features from one of these can be freely applied to the other, and vice versa, when so is practically applicable.

Application text 2015-09-14 150088SE 43 Moreover, one or several of the authentication service providers may be comprised byrespective external central servers similar to the central server 101. Such external centralservers will then, typically, be connected to a respective plurality of other authenticationservice providers. Then, such external central servers are treated as ordinary authentica-tion service providers. So, for instance in the above described auction procedure, anexternal central server may provide a sell price for authentication of a user in a certaincurrent situation and under certain conditions, using its own network of available authen-tication service providers. Such a setup may for instance be advantageous to facilitate geographic coverage of the system 100 in several countries or regions.

Hence, the invention is not to be considered limited to the described embodiments, but may be varied within the scope of the enclosed claims.

Application text 2015-09-14 150088SE

Claims

1. Method for authenticating a user, c h a r a c t e r i s e d i n that the method comprises the steps of a)

2. providing a central server (101), in communication with an authentication serviceprovider (110), arranged to authenticate users based upon the user's control over anelectronic device (170,180) which is provided wireless internet connectivity via anetwork operated by the said authentication service provider in question, and atleast one user service provider (150,160), arranged to provide user services to usersvia a respective user service web interface; providing to the electronic device wireless internet connectivity via the said net-work; causing the authentication service provider to authenticate the user based upon theuser's control over the said electronic device and via said network, and upon au-thentication of the user, allowing the central server to place a first cookie on theelectronic device, said first cookie identifying the authentication service provider inquestion; providing to the electronic device internet connectivity which is not via the saidnetwork; providing, for the user and using a web browser executed on or from the sameelectronic device, access to a user service web interface, and as a result providingthe first cookie to the central server using the internet connectivity provided in stepdl; causing the central server to identify, based upon the first cookie, the authenticationservice provider; verifying, in the authentication service provider, that the user can be validly authen-ticated; and causing user authentication information to be provided to the user service provider. I\/|ethod according to claim 1, c h a r a c t e r i s e d i n that the authenti- cation in step c) is an authentication of the user performed in connection to the user Application text 2015-09-14 150088SE accessing a particular user service web interface, which may or may not be the same userservice web interface as the one accessed in step e), and in that the central server (101) isallowed to place the first cookie via the said web browser used to access the said particu-lar user service web interface.

3. Method according to claim 2, c h a r a c t e r i s e d i n that the centralserver (101), in connection to the placing of the first cookie in step c), further allows theauthentication service provider (110,120,130) to place a second cookie on the electronicdevice (170,180) identifying the user or the electronic device, and in that, in step g), theverifying comprises that the authentication service provider is allowed to read the secondcookie and then determines whether the user or electronic device identified by the second cookie is still validly authenticated by the authentication service provider.

4. Method according to claim 2 or 3, c h a r a c t e r i s e d i n that theplacement of the first cookie in step c) takes place by the said particular user service webinterface comprising central server (101) content which is fetched from the central server, thereby allowing the central server to place the first cookie.

5. Method according to claim 3 and further according to claim 4, c h a r a c -t e r i s e d i n that the said causing of the authentication service provider to readthe second cookie is performed by a communication or call, such as a redirect, performedby the central server (101) and preferably via the web browser used to access the particu- lar user service web interface.

6. Method according to claim 1 or 2, c h a r a c t e r i s e d i n that thecentral server (101), in connection to the placing of the first cookie in step c), furtherreceives from the authentication service provider (110,120,130) information regarding theuser or the electronic device (170,180) allowing the authentication service provider toidentify the user or the electronic device, in that the central server then associates the said information with, or stores the said information as a part of, the first cookie, and in that, in step g), the verifying comprises that the central server queries the authentication Application text 2015-09-14 150088SE 46 service provider whether the user or electronic device identified by the said information is still validly authenticated by the authentication service provider.

7. Method according to claim 6, c h a r a c t e r i s e d i n that the userservice interface accessed in step e) is caused to provide to the user an option to beauthenticated by the authentication service provider identified in step f) only in case the verifying in step g) is positive.

8. Method according to claim 7, c h a r a c t e r i s e d i n that the userservice provider (150,160) providing the user service interface accessed in step e) is caused to allow the central server to provide or not to provide said option.

9. Method according to any one ofthe preceding claims, c h a r a c t e r i s e d i n that the providing of the first cookie to the central server (101) in step e) takes placeby the user service web interface accessed in step e) comprising central server contentwhich is fetched from the central server, and by the central server receiving the first cookie in connection to a call from the user service web interface requesting said content.

10. Method according to claim 9, c h a r a c t e r i s e d i n that the centralserver (101) populates the central server content with a user control arranged to allow the user to be authenticated by the authentication service provider (110) identified in step f).

11. Method according to any one ofthe preceding claims, c h a r a c t e r i s e di n that step h) comprises the authentication service provider (110) providing a firstaccess token, using which information regarding the user can be accessed from the authentication service provider.

12. Method according to claim 11, c h a r a c t e r i s e d i n that the fistaccess token is provided to the central server (101), and that step h) further comprises thecentral server providing, to the user service provider (150,160), a second access tokenusing which the user service provider can request the central server to provide infor- mation regarding the user, and in that, upon such request using the second access token, Application text 2015-09-14 150088SE 47 the central server queries the authentication service provider (110) for said user infor- mation and provides the user information to the user service provider.

13. System (100) for authenticating a user, which system comprises a central server(101), in communication with an authentication service provider (110), arranged toauthenticate users based upon the user's control over an electronic device (170,180)which is provided wireless internet connectivity via a network operated by the said au-thentication service provider in question, and further in communication with at least oneuser service provider (150,160), arranged to provide user services to users via a respectiveuser service web interface, c h a r a c t e r i s e d i n that the central server isarranged to receive information regarding the availability of a particular authenticationservice provider to authenticate the user based upon the user's control over the saidelectronic device and via said network, and in response to the receipt of such information,place a first cookie on the electronic device, said first cookie identifying the authenticationservice provider in question and either allowing the authentication service provider toplace a second cookie on the electronic device comprising information identifying the useror the electronic device to the authentication service provider in question or to receivefrom the authentication service provider in question such information, in that the centralserver is further arranged to, at a later point in time and upon a request from said userservice provider, receive the first cookie and, based upon the first cookie, identify theauthentication service provider in question, and then either allowing the first authentica- tion service provider to read the second cookie or providing the first authentication service provider with said information. Application text 2015-09-14 150088SE