WO2017048177A1

WO2017048177A1 - Method and system for authenticating a user

Info

Publication number: WO2017048177A1
Application number: PCT/SE2016/050854
Authority: WO
Inventors: Philip HALLENBORG; Mindaugas KEZIONIS
Original assignee: Identitrade Ab
Priority date: 2015-09-14
Filing date: 2016-09-13
Publication date: 2017-03-23
Also published as: SE1551176A1

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. In particular, the invention relates to remote authentication of a user, via an electronic device operated by the user, specifically an electronic device being provided internet connectivity via a wireless network wherein an operator of said network can identify the electronic device securely in connection to such connectivity provision, such as is the case for an electronic device operated using a SIM (Subscriber Identity Module) card or a similar functionality.

In many circumstances a user needs to be remotely authenticated, in order for a remotely arranged party to verify the identity of a user contacting the remotely arranged party. In particular, this is the case in digital communication applications, especially online. For instance, within the fields of e-commerce, online transactions and banking, digital service provision and user account registration, a user contacting a central server over the internet 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 from less secure alternatives such as simply entering a user name and a password, via more elaborate techniques such as Public Key Infrastructure-based systems, to multi-factor authentication solutions involving SMS (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. In general, in order to provide adequate security and user convenience, complex or different authentication methods should also in many cases be provided. Especially for small user service providers, this can represent a significant implementation cost. Another problem is that it is difficult for individual users to keep track of various authentication tools, login credentials, etc., for use with different user service providers. 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. Examples include the so called OpenID initiative, in turn using the open authentication standard Oauth, using which an authenticating party can provide an access token, using which the proprietor 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 the authentication type to each particular authentication need, such as depending on the type of 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 providers. Also, many user service providers, such as online vendors, have a desire to obtain more 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 authentication service providers to authenticate users across borders, in which case access to agreements and 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 the present application, discloses a method in which a cookie, in other words a piece of information stored on the electronic device being used to access web content, is placed on a user operated device by a central party, identifying particular available user authentication service providers. One specific problem in relation to the method disclosed by said Swedish patent application 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 particular mobile 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 is characterised in that it comprises the steps of providing a central server, in communication with an authentication service provider, arranged to authenticate users based upon the user's control over an electronic device which is provided wireless internet connectivity via a network operated by the said authentication service provider in question, and at least one user service provider, arranged to provide user services to users via a respective user service web interface; b) providing to the electronic device wireless internet connectivity via the said network; c) causing the authentication service provider to authenticate the user based upon the user's control over the said electronic device and via said network, and upon authentication of the user, allowing the central server to place a first cookie on the electronic device, said first cookie identifying the authentication service provider in question; d) providing to the electronic device internet connectivity which is not via the said network; e) providing, for the user and using a web browser executed on or from the same electronic device, access to a user service web interface, and as a result providing the first cookie to the central server using the internet connectivity provided in step d); f) causing the central server to identify, based upon the first cookie, the authentication service provider; g) verifying, in the authentication service provider, that the user can be validly authenticated; and h) causing user authentication information to be provided 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, arranged to authenticate users based upon the user's control over an electronic device which is provided wireless internet connectivity via a network operated by the said authentication service provider in question, and further in communication with at least one user service provider, arranged to provide user services to users via a respective user service web interface, which system is characterised in that the central server is arranged to receive information regarding the availability of a particular authentication service provider to authenticate the user based upon the user's control over the said electronic 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 authentication service provider in question and either allowing the authentication service provider to place a second cookie on the electronic device comprising information identifying the user or the electronic device to the authentication service provider in question or to receive from the authentication service provider in question such information, in that the central server is further arranged to, at a later point in time and upon a request from said user service provider, receive the first cookie and, based upon the first cookie, identify the authentication service provider in question, and then either allowing the first authentication service provider to read the second cookie or providing the first authentication service provider with said information. In 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 and arranged 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 first aspect of the present invention;

Figure 3 is a flow chart depicting the various method steps of a method according to a second aspect of the present invention; and

Figures 4a-4d show various interfaces provided by a web browser on the display of a user electronic device.

All figures share reference numerals for the same parts. Figure 1 shows a system 100 according to the present invention for authenticating a user via 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.

In one aspect of the invention, the system 100 comprises a central server 101, comprising or in communication with a database 102; at least one, preferably at least two, preferably a 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. In another aspect of the invention, the system 100 only comprises the central server 101, the database 102 and any software provided by the central server 101 to connected authentication service providers 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 service providers 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 services to users remotely, such as online vendors; public service actors such as libraries, government institutions or the like; financial institutions, such as online banks; payment providers; online communities; communication services; or any other actor providing a service to users remotely in a way so that the identity of the user is needed in order to provide at least one of the services provided. It is preferred that users communicate with the service providers 150, 160 directly over a digital communications network 190 such as the internet. In the following, when the term "internet" is used, it is understood that any type of digital communications network may be used, as applicable, such as wired or wireless local 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. 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 party capable of providing authentication services to users remotely, and in particular being arranged to perform authentication of users. Examples include online vendors; public service actors such as libraries, government institutions or the like; financial institutions, such as online banks; payment providers; online communities; communication services; or any other actor the relationship of which to each user requires that the identity of the user in question is safely established by a user authentication function provided by the authentication provider 110, 120, 130. It is preferred that the authentication providers 110, 120, 130 communicate directly with each respective user. This communication can take place over the network 190, but for at least one of the authentication service providers 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 question and serving the user electronic device 170, 180 with communication services, using a base station 111, which is a part of the said mobile wireless network and which is preferably operated by the provider 110. It is preferred that the said mobile wireless network is one in which a subscriber identity, such as an IMSI (International Mobile Subscriber Identity), is needed for connection to the network, such as via the use of a SIM (Subscriber Identity Module) card installed in the electronic device communicating with the network in question, 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 5G networks. Preferably, the provider 110 is the network operator of the said network, and as such has firsthand access to the identity of the electronic device 170, 180 when connected to the said mobile wireless network. The base station 111 is a part of the said mobile wireless network. Furthermore, the said network operator typically provides the electronic device 170, 180 with connectivity to the network 190 in a conventional manner, such as via GPRS in the case of a GSM network. Herein, the expression "network operated by an authentication service provider" also encompasses networks operated by third parties that are in collaboration with the said authentication service provider for the purpose of performing authentications based upon control of a particular electronic device via the network in question.

5

As used herein, the term "authentication service" means a remotely provided service for authenticating a user, comprising establishing with a certain minimum level of security a correct identity of the user. Such a minimum level of security, such as a minimum level of assurance (LOA), is herein denoted "authentication level". Examples of such authenticate) tion levels are those definitions of which are provided by NIST (National Institution of Standards and Technology, USA), according to which there are at least four basic levels of assurance levels, ranging from low security procedures where it is only tested whether it is the same user accessing a service at different occasions ("Level 1") up to high security procedures where authentication is dependent upon the user's possession of a strongly 15 encrypted cryptographic key ("Level 4"). See www.nist.gov for further information. Herein, it is preferred that each authentication service provider 110, 120, 130 is unambiguously associated with one or several certain available well-defined authentication levels, the requirements of which the authentication service in question fulfills, and that each authentication service provider is associated with a certain respective minimum supported 20 authentication level. It is possible that a particular authentication service provider is associated with different minimum authentication levels in relation to different users. It is preferred that this information is stored in the database 102 and accessible from the central server 101. The information may, for instance, be supplied in an initial registration step of each authentication service provider 110, 120, 130, and may subsequently be 25 updated, for instance in reaction to new information in relation to specific users. It is also possible that available authentication levels in relation to a specific user are provided, by request 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).

30 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 one piece of user electronic device 170, 180, an authentication factor used by that authentication service provider 110 is of the kind "something you have", whereby the item held by the user to be authenticated is the said user electronic device 170, 180 in question. This means that the authentication provided by the authentication service provider 110 is based upon the control of the user over the electronic device 170, 180 which is connected to the said mobile wireless network. By for instance receiving an SMS (Short Message Service) message on the electronic device 170, 180, which is sent from the provider 110 via the base station 111, which SMS comprises a code, and entering that code via another channel, such as via a web interface, so that the entered code reaches the authentication service provider 110, the possession of the electronic device 170, 180 can be proven, and hence the identity of the user, which has previously been securely authenticated in connection to the signing up for the subscription to the said mobile wireless network.

It is realized that each one of entities 101, 110, 120, 130, 150, 160 may be implemented as a 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 is preferably arranged to communicate with the system 100 over the network 190. In figure 1, such devices are exemplified by a mobile phone 170 of so-called smartphone type and a portable computer 180. However, the electronic device can be any device capable of communicating with the system 100, in particular wirelessly, such as a desktop computer or a machine-to-machine interface. In this context, the term "wireless communication" means communication which is at least partly conducted over a wireless link. It is preferred that the device 170, 180 is of general-purpose type, and it is also preferred that the device comprises a respective display 171, 181 capable of providing an interactive graphical user interface to the user. According to the invention, the electronic device 170, 180 comprises a SIM (Subscriber Identity Module) card, or the corresponding (such as a corresponding software function), arranged to uniquely identify the electronic device 170, 180 to a mobile wireless network, such as the one operated by the provider 110, to which the device 170, 180 is connected. Such identification may, for instance, be via an IMSI or MSISDN code, or a MAC address. According to the invention, each electronic device 170, 180 is arranged to communicate via 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 the network 190 via at least one other wireless channel, such as over the mobile wireless network of another operator, such as an LTE roaming partner to the operator 110; a conventional 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. In the latter 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- eating a user. This first aspect is described herein in order for the reader to fully understand 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.

In a step 201, the method starts.

In a step 202, the central server 101 is provided, and is arranged to be in communication with at least two authentication service providers 110, 120, 130 and at least one user service provider 150, 160, that are also provided. It is realized that this step 202 can be performed in advance and only one time for several runs of the method. In a step 203, each authentication service provider 110, 120, 130 is associated with at least 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 available 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 respective available 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 authenticated 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 advance of 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, for instance, mean that the user successfully logs into a web page provided by the authentication service provider in question, or that the user in any other suitable manner provides proof, at a certain authentication level, of the identity of the user in question. For instance, 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 that can be provided from a user via an electronic device and that can be used by an authenticating 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.

In 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, further based upon an association between the electronic device, a SIM card comprised in the electronic device, or the like, and the user, which association has previously been stored by the authentication service provider 110 in question after an initial authentication 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 user provides a personal identification card to office staff of the authentication service provider. The authentication in step 204 by the provider 110 may be by sending an SMS as described above, or for instance by the mobile wireless network of the provider 110 automatically reading some information from the electronic device 170, 180, such as an IMSI 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 the authentication 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 holds information regarding the user, for instance user credential data or the knowledge of an IMSI or MSISDN code of the electronic device 170, 180, allowing the authentication service provider to authenticate the user at a particular authentication level. After the authentication in step 204, or an authentication in step 221 (see below), it is preferred that the authentication service provider has an active authentication session with respect to the authenticated user. This may mean that the user does not have to provide credential data, or does not have to prove control over the electronic device 170, 180 as described above, when being authenticated again within a predetermined time period during which the said session is active. The time period may be defined by the authentication 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 caused to be remotely configurable by individual users so that they can provide information regarding their respective capability to authenticate the users in question to the central server 101. Hence, the user in question may remotely instruct the authentication service provider in question, preferably over the internet and preferably in connection to or prior to the authentication step 204, such as via a user control provided as an integrated part of a web page displayed as a result of a successful login with the authentication service provider in question, or in connection to the signing up for a subscription with the provider 110, to, upon request from the central server 101 or automatically upon authentication of the user in question, provide information indicating that the authentication service provider in question is capable of authenticating the user at least at the said authentication level, and preferably also to provide, in a subsequent step 224, user information to the graphical user service interface (see below).

In 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 authenticated by the authentication service provider in question. In the case described below (such as in steps 221; steps 312-315; and steps 335-340), in which the authentication in step 204 takes place in connection to the electronic device 170, 180 being used to access a user service provider 150, 160, it may be the central server 101 that invokes the authentication service provider 110, 120, 130, why such notification may not be necessary. In this latter case, it is preferred that the authentication service provider 110, 120, 130 in question has previously notified the central server 101 about its ability to authenticate the user using a particular authentication level.

In a preferred step 207, which is preferably performed as an initial step in connection to setting up an association between the central server 101 and a certain authentication service 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. According to the said first aspect of the present invention, in a step 211, the central server 101 receives a request, from one of said one or several user service providers 150, 160, to authenticate 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 the user, with information indicating that the user wishes to be authenticated using a particular specified authentication service provider 110, 120 or 130, in turn providing an adequate authentication level for the present purposes. In another example, the user may be presented with a list of available authentication service providers with which the central server 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 user first initiates contact with the user service provider 150, 160, and it is the user service provider that in turn requests, possibly via an interface provided by the user service provider to the user, the central server 101 to authenticate the user. In general, and as will 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 by the 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. In a step 209, the user is provided with remote access to the user service provider 150, 160 via this first interface, displayed to the user on the display 171, 181 of the device 170, 180 used by the user, by the user service provider 150, 160. For instance, the device 170, 180 may comprise a web browser arranged to read and display the first interface provided by the user service provider 150, 160 web server. In a preferred step 210, which may be performed at any time prior to step 225 but preferably is performed before step 211, a particular user service transaction is identified, which transaction 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 to authenticate the user, in other words to provide an authentication service of the user. Preferably, the request comprises or implies a specific allowable authentication level, as dictated by the type of transaction and/or the particular user service provider 150, 160 and/or the particular user or user category. The allowable authentication level is the minimal authentication level that is allowed for authentication of the user under the current conditions. The database 102 may comprise information regarding what types of transactions, 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 authentication used for each authentication service provider 110, 120, 130 is caused to depend on at least one of the collection of parameters consisting of type of the electronic device; type and/or provider of a graphical user interface via which the user accesses the user service provider; the access of the authentication service provider in question to information identifying the particular user; geographical location of the electronic device; and/or the existence of an active authentication session with the authentication service provider in question. In the case of at least the authentication service provider 110, the parameters comprise the fact that the user controls the electronic device 170, 180 ("something you have" authentication factor) and that the authentication service provider 110 has previously securely authenticated the user, including the determination of the identity of the user and association to an identifier of the electronic device 170, 180 as such, as described above.

It 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 interface. Then, the service provider 150, 160 is not directly involved at the moment of the request, which is rather performed by for instance the device 170, 180 on behalf of the user service provider 150, 160. In a step 212 according to the said first aspect of the invention, it is determined, preferably 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. In a step 214, the central server is arranged to identify a selected one of said authentication service providers 110, 120, 130 which is associated with at least one level of authentication which is at least as high as the allowable authentication level, and which authentication service provider is capable of authenticating the said particular user at the allowable authentication level.

According to a preferred step 213, preceding step 214, the central server 101 is however arranged to first identify, for several authentication service providers 110, 120, 130, a respective offered sell price for performing user authentication at the allowable level of authentication. 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 perform the user authentication in question, preferably with knowledge of the particular user to be authenticated. Alternatively, the central server 101 has beforehand received price lists from several authentication service providers regarding various types of authentications.

Once the authentication service providers have responded to this request or the price list information 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 the respective allowable level, and to use this authentication service provider as the said selected authentication service provider in the following. According to one preferred embodiment, an auction over one or several bid rounds is performed among authentication service providers 110, 120, 130 being capable of providing 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.

It is also possible for the central server 101, via the user service provider 150, 160 such as via 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. In a preferred step 215, the central server 101 evaluates if at least one authentication service provider could be identified as the selected authentication service provider. For instance, none of the connected authentication service providers 110, 120, 130 may have been able to provide at least the allowable authentication level, or none may have been able to authenticate the particular user. If an authentication provider was identified in step 214, the method skips to step 217. Otherwise, it is preferred that the steps 217-224 are not performed, but the user service provider 150, 160 is instead caused to authenticate, in a step 216, the particular user for the particular transaction in question without involving any of said authentication service providers 110, 120, 130. Preferably, this means that the user service provider 150 performs its own, conventional, default proce- dure for authenticating the user.

In a preferred step 217, the user is then presented, via a graphical user interface, preferably the above mentioned first graphical user interface on the display 171, 181, with an option whether or not to authenticate using one of the authenticating service providers 110, 120, 130. Preferably, it is not specified at this point to the user which of the authentication service providers that was identified in step 214. If the user does not choose to allow such authentication, the method again skips to step 216 rather than performing steps 218-225. The option presented in step 217 may also comprise allowing the said authentication service provider to provide user information to the user service provider 150, 160 in question (see below). Preferably, the option presented in step 217 covers both the authentication and the user information provision, so that by, for instance, activating a user control embodying the option in step 217, the user acknowledges both that the authentication service provider may authenticate the user and provide user information to the user service provider in question. It is furthermore preferred that the option being presented in step 217 is comprised in the first interaction, relating to user authentication with regards to the transaction in question to be performed, between the user and the interactive graphical user interface provided to the user by the user service provider 150, 160. Hence, it is preferred that the communications between the user service provider 150, 160, the authentication service providers 110, 120, 130, and the central server 101 described above in relation to the previous steps are fully automatic, and do not require any user interaction. In other words, when for instance loading the checkout page from an online vendor being the user service provider 150, 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 the authentication service providers 110, 120, 130, or at least any one of said providers that the user has previously agreed to use, such as in a preferences setting supplied previously to the central server or by checking corresponding controls on the respective web page of each donor, to perform the user authentication for the purchase. In a particularly preferred embodiment, further detailed below in connection to figure 3, the user is presented with the option to allow a particular authentication service provider 110 to authenticate the user, and preferably also to provide user information regarding the user to the user service provider 150, 160 in question, which particular authentication service provider 110 is the operator of a mobile wireless network being able to authenticate the user based upon 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 data associated with the user in question is provided, in a step 219, directly to the selected authentication service provider, without the user credential data being supplied to the central server 101, or it is determined, in a step 220, that the selected authentication service provider already has an active authentication session for the user in question. Hence, in step 219 or 220, the central server 101 acts as a pure intermediary, binding together the user service provider 150, 160 with one of several available authentication service providers 110, 120, 130, without ever gaining actual knowledge of the specific credential information necessary for performing said authentication. Since the credential data 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 a preferred step 218, in which the above mentioned first graphical user interface is arranged to in turn activate a second user interface. This second user interface is then arranged to allow the user in question to communicate directly with the selected authentication service 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 interactive graphical 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 locally installed or remotely accessed application which is activated by the first graphical interface, and to which the active view of the display 171, 181 is transferred upon such activation. However, according to a preferred embodiment the second graphical user interface is 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 comprised in the first graphical user interface. For instance, the second graphical interface may be embodied as a particular graphical field in the first interface, or a popup dialog launched by and from the first interface. In these and similar examples, the second interface will typically comprise user controls activatable for recording or entering, and provid- ing, credential data specifically selected for authenticating the user in relation to the transaction to be performed. In a particularly preferred embodiment, the second interface is populated with contents by the selected authentication service provider itself, after initiation by the user service provider 150, 160. In case a relevant template was provided by the central server 101 to the selected authentication service provider in step 207, this template is preferably used as 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 fields for user name and password, as well as a field in which the authentication service provider can insert its logotype. Also, a link to a standardized set of terms and conditions can be provided as a part of the template, and so on. In general, it is preferred that the same template is provided to several authentication service providers, so that the user experience for the end user becomes as similar as possible when using different authentication service providers. Hence, in this case the selected authentication service provider provides the actual second graphical user interface to the user service provider 150, 160, or preferably 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 by specific software or hardware which is not part of the first graphical interface, but as initiated by the first graphical interface, such as activation of a fingerprint sensor on the device for reading the user's fingerprint and providing related data to the central server 101; activating a mobile telephony operator of the mobile phone of the user for sending an SMS (Short Message Sevice) to the mobile phone's telephone number (MSISDN), comprising an alphanumerical challenge to be manually provided to the user service provider by the user, or providing a request to the said mobile telephone to re-enter the SIM (Subscriber Identity Module) PIN code (the latter two options preferably being initiated by the mobile wireless network operating authentication service provider 110 directly vis-a-vis the user); activating a cryptographically based authentication procedure which is locally activatable on the electronic device; or the like. It is also possible, in case the selected authentication service provider 110 is the operator of a mobile wireless network to which the electronic device 170, 180 is connected, that an automatic readout of an identifier of the electronic device 170, 180 is performed by the network as described above, for securely identifying the electronic device 170, 180 and as a result authenticating the user. In this case, step 219 may be unnecessary, and the method 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 an active authentication session involving the selected authentication service provider and the user in question, in which case the second interface is not presented but the method instead skips to step 221. For instance, the central server 101 may collect information regarding such an active authentication session, or the first interface may receive such information 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 service provider authenticates the particular user. In case credential data was supplied in step 219, the authentication comprises the selected authentication service provider verifying the credential data. In case an active session was determined to exist in step 220, the authentication 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.

In a subsequent step 222, an authentication response is provided to the user service provider 150, 160. This authentication response may be that no authentication was possible, for instance since the user did not supply correct credential data to the authentication service provider, or that the authentication was validly performed based upon the supplied user credential data or the fact that an active authentication session existed. It is preferred that the authentication response is provided from the selected authentication service provider to the user service provider 150, 160 via the central server 101. According to a preferred embodiment, the user service provider 150, 160 is then provided with access, preferably from the selected authentication service provider and via the central server 101, to user information previously stored by the selected authentication service provider and therein associated with the particular user in question. According to an alternative embodiment, the said user information is provided directly from the authentication service providers (or several authentication service providers) to the user service 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, clothing sizes, contact lists, preferred configuration options, previous user behavior, etc., that is specific to the user in question. Such user metadata has preferably been provided by the user in question as a part of the interaction between the user and the selected authentica- tion service provider in step 204 or before, under the security provided by an active authentication session or in real life, for instance during the course of the ordering of a service the delivery of which requires user information to be provided by the user.

It is preferred that the said user information is used by the user service provider 150, 160 to 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 information which is required by the user service provider 150, 160 may be available from the authentication service provider for such auto population. According to one preferred embodiment, all available user information is supplied as a part of the above said authentication response. Alternatively, a separate interface is provided to the user service provider 150, 160 by the central server 101 for querying available user information. It is furthermore preferred that access to user information is only provided to the user service provider 150, 160 after an explicit approval from the user in question. Such approval may be delivered for more or less general purposes in an initial step in which the user registers with the user service provider 150, 160, the central server 101 or the authentication service provider 110, 120, 130, or at a later point. For instance, activating the said user control in step 217 may imply such approval. Step 205 may also cover such approval. According to the preferred embodiment illustrated in figure 2, the user is presented, in step 223, with an explicit option, for instance in the form of an activatable user 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.

In case the user opts in to automatically populate input fields in the interface, the population 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 user service provider 150, 160 in relation to the user in question. This may mean the ordering or purchasing of a good or a service, involving a transfer of funds; the publication or transmittal of information; the activation of a subscription; the modification of user information; or any other conventional user service.

In step 226, the method ends.

According to a preferred embodiment, both the selected authentication service provider and the user service provider 150, 160 are accessed by the particular user in question via a web browser provided on the electronic device 170, 180. The web browser used in various steps 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 a method according to a second aspect of the invention, which is illustrated in figure 3 and which will be described in the following. The following description of the method according to this second aspect of the invention will furthermore provide a more detailed de- 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.

In a step 302, which is similar to step 202, the central server 101; at least one, preferably several, preferably a plurality of, authentication service provider(s) 110, 120, 130; and at least one, preferably several, preferably a plurality of user service provider(s) 150, 160 are provided. 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 service providers 110, 120, 130 are arranged to authenticate users based upon the user's control over the electronic device 170, 180 of the user, as described above, which electronic device 170, 180 is provided wireless internet connectivity via a network operated by the said 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 to particular users via a respective user service web interface each. Furthermore, the said web interfaces are provided to the user via one and the same web browser (or different web browsers, as applicable according to the above) executed from (such as via a remotely provided web browsing service), or by, the electronic device 170, 180 controlled by the user in question. The user service web interface corresponds to the first user interface as discussed above in relation to figure 2.

In a step 303, wireless internet connectivity is provided to the electronic device 170, 180 via the said wireless network which is operated by the authentication service provider 110. Herein, "providing wireless internet connectivity" implies that the electronic device 170, 180 can be securely identified by the operator of the network in question as described above, preferably using a unique identity of a SIM card installed in the electronic device 170, 180, or similar. This identification takes place as an integrated part of the electronic device 170, 180 being provided such wireless connectivity, by the operator capturing identifying information of the device 170, 180 from communication messages to or from the device 170, 180; using a piece of software directly investigating electronic device 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 at least 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 device 170, 180 in a step 305, and, in a step 306, the requested web page is provided to the device 170, 180 and displayed thereon. It is realized that steps 305, 306 can take place in another way, which is conventional as such.

In a step 307, which must be performed at the latest before step 311, at least one of the authentication service providers 110, 120, 130 authenticates the user of the electronic device 170, 180, for instance by the user visiting a secure web page of the authentication service provider 110, 120, 130 in question and there performing an authentication based upon the control of the electronic device 170, 180; by physically visiting the authentication service provider 110, 120, 130 and providing a piece of identification; or in any other suitable 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 the authentication in step 307, whether the user whishes the authentication service provider 110, 120, 130 to either provide authentication services with respect to the user on behalf of general or specific user service providers 150, 160 and/or provide user information to such user service providers 150, 160, preferably specifically in connection to such authentication.

In a step 309, the user service provider 150, 160 visited in steps 305-306 determines a transaction which the user wishes to take part in, as a transaction part, using the user service provider 150, 160 in question, and in relation to which transaction the user is to be authenticated as such a transaction part.

In a step 310, a call is made, by the user service provider 150, 160, to the central server 101, requesting the central server 101 to authenticate the user in relation to the identified transaction. This call can, for instance, be in the form of a web page redirect to the central server 101, or by the use of a script on the web page provided in step 306. In one preferred embodiment, the web page provided in step 306 comprises content to be provided by the central server 101, such as an iframe with web page content provided by the central 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 authentication service provider 110, 120, 130 which has the capability to authenticate the user of the electronic device 170, 180, for instance based upon information regarding the user and/or the electronic device 170, 180 provided by the user service provider 150, 160 calling the central server 101; by the central server 101 receiving such information as a part of the communication with the web browser in which the central server-provided content is used; by the central server 101 reading a cookie placed on the electronic device 170, 180 in connection to the authentication in step 307, preferably via a call from the authentication service provider 110, 120, 130 in question to the central server 101 in connection to step 307 whereby the central server 101 places the cookie identifying, to the central server 101, the authentication service provider 110, 120, 130. The latter option is described in closer detail in the above referred to still not published Swedish patent applica- tion. The present invention is interested in the particular case in which the identified authentication service provider in this step is one which can authenticate the user based upon control of the electronic device 170, 180 and via communication in the above mentioned wireless network. In other words, in step 311, the authentication service provider 110 is identified. Several possible authentication service providers 110, 120, 130 may be identified, but in the following it is the provider 110 which is referred to as the one authenticating the user in steps 313-315, and so forth.

In a step 312, a call, such as a web redirect, is performed to the identified authentication service provider 110, identifying the user and/or the electronic device 170, 180. In a step 313, the authentication service provider 110 determines whether there is an active session or not with the authentication service provider 110, as described above and also below. In this context, that there is an "active session" means that there is an active authentication session with respect to the user involving the electronic device 170, 180 used. For instance, the user may have performed an authentication based upon control over 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 taken place via the mobile wireless network operated by the authentication service provider 110 in question.

If, in a step 314, it is determined that there is not such an active session, the user is authenticated in a step 315, by the said authentication service provider 110 based upon the user's control over the electronic device 170, 180 and via the said mobile wireless network 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 authentication service provider 110. It is realized that more than one authentication service providers 110, 120, 130 can authenticate the user in similar ways, in steps corresponding to steps 312-315, as long as at least one is one which may authenticate using the said network, as described above. In a step 316, the authentication service provider 110 provides, to the user service provider 150, 160, in a way which may be similar to the above or below described, authentication information regarding the just performed authentication. This authentication infor- mation can, for instance, simply acknowledge that the user has been securely authenticated.

According to the invention, in a step 318 which is performed upon the said authentication of the user by the authentication service provider 110, the central server 101 is allowed and caused to place an identifying cookie, in other words a first cookie, on the electronic device 170, 180, which cookie is arranged to identify the authentication service provider 110 in question to the central server 101. Preferably, this identifying cookie is also arranged to identify the authentication service provider 110 identified by the cookie as one which 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 the identifying cookie via the web browser used to access the particular user service web interface in steps 304-306. Preferably, the placement of the identifying cookie takes place by the said particular user service web interface comprising central server 101 content which 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 the placing of the identifying cookie in step 318, in a step 317 further allows the authentication service provider 110 to place an authentication cookie, in other words a second cookie, on the electronic device 170, 180. Such an authentication cookie is arranged to identify, to the authentication service provider 110, the user and/or the electronic device 170, 180 in question. The placing of the authentication cookie may take place in any suitable way, such as via a web direct to web content provided by the authentication service provider 110 and incorporated in a piece of central server 101 provided web content incorporated in the user service web interface, such as using an iframe incorporated in an iframe; via suitable scripts; or the like. What is important is that the authentication service provider 110 in question is caused, by the central server 101, to be allowed to place the authentication cookie on the electronic device 170, 180, preferably in the same web browser as used in steps 305-306. The authentication cookie may comprise information about a currently ongoing active authentication session for the user and/or the electronic device 170, 180 in question. The information comprised in the authentication cookie allows the authentication service provider 110 to specifically identify the user and/or the electronic device 170, 180.

In a second alternative embodiment, the central server 101, in connection to the placing of the identifying cookie in step 318, further receives from the authentication service provider 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 user and/or the electronic device 170, 180. Then, in step 317, the central server 101 associates the particular information with the identifying cookie and stores the particular information, 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 user which has taken place based upon control of the electronic device 170, 180 via the said wireless network, and the central server 101 has placed identifying information on the electronic device 170, 180 (the identifying cookie) regarding what authentication service provider has performed such authentication. Based upon the authentication cookie or the said particular information, it is possible for the authentication service provider 110 to determine the identity of the user and/or the electronic device 170, 180, hence making it possible for the authentication service provider 110 to determine whether it can authenticate the user or not, even when the said network operated by the authentication service provider 110 is not used for the communication at a later stage when such authentication is needed. This will be detailed in the following. It is preferred that all information in said identifying and authentication cookies and in the particular 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 which is not via the said network operated by the authentication service provider 110 in question. Such internet connectivity may be wireless mobile internet connectivity provided via a different operator; a WiFi connection; a wired internet connection; or the like. What is important is that, using the steps 304-316 it is not possible for the authentication service provider 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.

In a step 320, which is similar to step 304, the user, using a web browser executed on or from 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 interface which may or may not be the same user service web interface as used in steps 305-306. In other words, the authentication performed in steps 313-315 is an authentication of the user 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 step 320, and in relation to which the user is to be authenticated again, as will be described in the following.

In a step 321, which may be similar to step 309, a transaction is identified, wherein the user is to be a transaction part and in relation to which the user is to be authenticated as a transaction part for the purposes of the user service provider 150, 160 in question. In 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 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 described 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 the second user service web interface. However, according to a preferred embodiment, the providing of the identifying cookie to the central server 101 in step 324 takes place by the second user service web interface accessed in steps 322-323 comprising central server 101 content which is fetched from the central server 101, and by the central server 101 receiving, such as reading, the identifying cookie in connection to a call from the user service web interface requesting said central server 101 content. The central server 101 content may, for instance, be in the form of an iframe containing web content provided by the central server 101. It is preferred that all calls to the central server 101 and the authentication service provider 110 in steps 323-328 are performed without being visually visible to the user in the web browser in question on the electronic device 170, 180. For instance, a non-visible iframe may be used to redirect the web browser to the central server 101 in step 324.

It is preferred that the central server 101 in step 325 reads not only the identifying cookie placed 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 or cookies read, the authentication service provider 110 or all authentication service providers identified by such cookies. It is realized that one and the same identifying cookie could be used to identify several authentication service providers. In a step 334, in the said first alternative embodiment, the authentication service provider 110 is allowed to then read the authentication cookie placed in step 317, from the electronic device 170, 180, and then, in a step 335, to first determine whether or not the authentication service provider can authenticate the user in question at all, and then to determine whether the user and/or electronic device 170, 180 identified by the authentication cookie is still validly authenticated by the authentication service provider 110, such as by identifying the presence of an active authentication session for the user and/or electronic device 170, 180 in question. The non-existence of an authentication cookie could imply that no such authentication is possible. Preferably, the said causing of the authentication service provider 110 to read the authentication cookie is performed by a communication or call, such as a redirect, performed by the central server 101 and preferably via the web browser used to access the second user service web interface in steps 322-323. For instance, the said central server 101 web content could comprise a piece of authentication service provider 110 web content, such as an invisible iframe, causing the authentication cookie to be passed to the authentication service provider 110 when the central server 101 content is loaded.

In the said second alternative embodiment, in a step 327, the central server 101 instead reads 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 identified by the above described particular information is still validly authenticated by the authentication service provider 110. In this case, it is preferred that the particular information is stored by the central server 101 in a way which does not allow the central server 101 to identify the user, and preferably also not the electronic device 170, 180, based on the particular 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 device 170, 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 in question, by one or any of the authentication service provider(s) 110 identified in step 326, and whether the user wishes to allow user information to be transferred from such authentication service provider 110 to the user service provider 150, 160 in question in relation to the said transaction and its fulfillment. In case the user has previously agreed, in step 308, to always allow a particular 110 or any authentication service provider to provide authentication and/or user information, the option 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 of the following happens.

In 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 available in step 330, and the user may select at least "any of the identified authentication service providers" or a particular one of the presented authentication service providers. Then, as the user performs a selection resulting in a particular one authentication service provider 110, either by the user specifically selecting one or by the central server 101 selecting one based upon the user's selection of several possible authentication service providers, the authentication service provider 110 to use is identified in a step 332, and the identified authentication service provider 110 is called upon in a step 333. Thereafter, the step 334 is performed, possibly resulting in an error message to the user that the authentication service provider is not available to authenticate the user in question.

In the case of the second alternative embodiment, only authentication service provider(s) responding in the positive regarding their authentication availability for the user and/or the 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 provided with an option to be authenticated by a particular authentication service provider 110 identified 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 alternative will not result in the said error message, why this second alternative embodiment is the preferred one.

It is preferred that it is the user service provider 150, 160 providing the second user service interface accessed in steps 322-323 which is caused to allow the central server 101 to provide or not to provide said option in step 330. Preferably, this takes place by the central server 101 populating corresponding central server 101 content with a user control arranged to allow the user to be authenticated by the authentication service provider 110 identified in step 326. For instance, the central server 101 web content being displayed as part of the second user service web page returned in step 323 and finally populated in steps 329-330 could comprise one respective button for each available authentication service provider 110 identified in step 326 and for which authentication service provider it has been verified, in step 328, that the user can be validly authenticated.

In case the user does not select any authentication service provider, or selects "No" or the corresponding, in step 330, the user service provider 150, 160 may apply a prioprietary authentication of the user for the transaction in question, and the method skips to step 347.

It is noted that this verification step according to the first alternative embodiment takes place in steps 334-336.

It 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 step 335 it is determined, by the authentication service provider 110 called in step 333, whether or not an active authentication session exists for the user and/or the electronic device 170, 180 with the authentication service provider 110. If this is deemed to be the case, in a step 336, the user is considered authenticated. It is important to note that, in this case, the user is no longer connected to the wireless network operated by the authentication service provider 110, and the latter can therefore no longer automatically authenticate the user based upon control of the electronic device 170, 180. However, due to the identification of the active authentication session, an authentication can nevertheless be performed automatically, based upon the electronic device 170, 180 being associated with the authentication service provider 110 via the central server 101. A timer for the active authentication session is preferably less than 60 minutes, 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 disconnected from the network operated by the authentication service provider 110.

If 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 device 170, 180 and via the network operated by the authentication service provider 110. Typically, this would now involve the user being provided with some type of visual feedback regarding this authentication process and being required to provide credential data of some 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 provider 110 via the user service provider interface, such as via manual user input. However, it would also be possible for a software function of the electronic device 170, 180 to, in step 337, automatically investigate identifying information of the electronic device 170, 180, such as a MAC address or a SIM card IMSI or MSISDN code, and automatically communicating such identifying information to the authentication service provider over network 190. Such software may be locally installed beforehand on the electronic device 170, 180 and 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.

In case this authentication is positive, in a possible step 338, the user may be redirected to an authentication web interface allowing the user to authenticate manually with the authentication service provider 110, for instance by, in a step 339, provide user credential data to the user authentication service provider 110 allowing the latter to tie the user to a previously 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 authenticated in steps 336-340, user authentication information is provided from the authentication 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 the identified authentication service provider 110. Such an access token is arranged to allow the holder of the token to access, using the token, a certain subset of otherwise secret information from the identified authentication service provider, in particular user information (as defined above) for the user in question. Hence, using the first access token, the holder may query the identified authentication service provider 110 for at least some user information associated with the user in question and known to the provider 110. Such querying 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.

In the latter case, the central server 101 is then preferably, in turn, in a step 342 arranged to issue a second access token, preferably of similar functionality and type as the first access token, and send it to the user service provider 150, 160, possibly indirectly by sending 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 indirectly via 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. In the preferred embodiment in which the user has allowed such user information to be queried 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 to the central server 101, and used to request specified user information. Thereafter, the central server is arranged to, in a step 344, if allowed by the second access token, request user information corresponding to the information requested in step 343 from the identified authentication service provider 110.

In a step 345, the requested information, if known to the identified authentication service provider 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 http://oauth.ne†./2/.

Then, in a step 346, input fields for the corresponding user information in a user service provider web page are preferably automatically populated by the user service web interface in question, using the user information obtained from the central server 101 in step 345.

In 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 and shown on the display 181 of the device 180 and hence viewable to the user. Figure 4a illustrates the state of the web page displayed in step 329 during a run-through of the method according to said second alternative embodiment shown in figure 3. A number of user 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 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 is activatable to perform a transaction with the user as a transaction part using the user information 401 provided manually by the user by entering information into the corresponding fields in the web page 430. The other one 431 ("Checkout using ASP1") is automatically 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 the user service provider 150 to the central server 101 in step 324, for instance using an iframe the contents of which are provided by a web server of the central server 101. In case no available authentication service providers were found in step 326, or in case no authentication service providers could be verified in step 328, the button 431 would simply be missing in the interface 430. Hence, the existence of the button 431 in figure 4a indicates that there is at the moment at least one authentication service provider 110 available for authenticating the user based upon control of the electronic device 180 and via said wireless network operated by provider 110. The currently shown text "Checkout using ASP1" indicates that (at least) authentication service provider 110 named "ASP1" is available for authentication.

In 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 information to user service providers, such as to user service provider 150. According to one preferred embodiment, illustrated in figure 4b, by pressing the "Checkout 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 provider interface. Then, the state 460 of the web page illustrated in figure 4b will result, if no errors or problems are encountered. The user information (name, address and credit card) have been automatically populated using such information queried from the authentica- tion service provider 110 via the central server 101 in steps 343-354 and used to fill in the fields in the web page. The button "Checkout" 461 may be pressed in order to go ahead with the transaction in question using the currently displayed user information 401, possibly after editing of the user. According to one preferred embodiment, pressing of the button 431 even leads to the user being authorized by the authentication service provider 110, user information being fetched and the transaction finalized using the fetched user information, everything done automatically and without involving the user at all in all goes well. In this case, the state 450 shown in figure 4b would never be shown, but the user would instead be redirected to a page informing the user of the finalized transaction or the like.

In case the authentication in step 337 is unsuccessful, in step 338 the state 440 shown in figure 4c is shown, in which the user can provide, in step 339, credential data 442 for a reauthentication, 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 as an iframe, of the user service provider 150 web page which is populated by the authentication service provider 110 directly, such as using a set of user controls allowing the user to enter and send said credentials directly to the authentication service provider 110 for verification and authentication. After the user presses the "Submit" button 443, the state 460 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 proceeding to checkout in an online vendor web site. This way, user information can be provided to the user service provider 150, 160, via the mechanism in steps 332-345, and used for instance to provide enhanced purchasing support information to the user. This can be achieved by, for instance, a button representing the option to use the present method, if available 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. According to another preferred embodiment, the database 102 comprises a respective record for each user registered for use with the system 100, comprising a flag setting that the user always, or at least for a certain set of user service providers 150, wishes to accept the option presented in step 330, respectively. If the flag is set, step 330 is not performed, but instead the method skips directly to step 332. This may, for example, mean that the button "Checkout with ASP1" is not displayed, but that a normal "Checkout" button will always result in an automatic authentication and possibly also user information provision as 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 welcome page 470 of a user service web interface provided on the display 181 of the device 180 of the user John Doe, displaying user controls 472 for navigating the page. In this case, the user has agreed to always allow user service providers to gain access to the user name via the above described access tokens, as provided by the user's online community service provider. By pressing the button 471, the user agrees that the user service provider is entitled 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.

In fact, the button 471 will generate a redirect to the central server 101, which then receives any cookies previously stored in the web browser of the device 180 by central server 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 said cookies, redirects to the said online community service provider, which, in turn, issues and returns the above described first access token. To the user, this process is completely unnoticeable and virtually instantaneous, since the user in this exemplifying case already has an active authentication session with the said online community provider. All this under condition that at least one authentication service provider, based upon available information, can authenticate the user based upon control of the electronic device 180 and using said wireless network as described above. A method and a system according to the present invention provides a cost-efficient way for 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 allowable authentication level, such a user service provider 150, 160 gains access to a network of third party authentication service providers 110, 120, 130 that can provide required user authentication on behalf of the user service provider. Since each user authentication service provider can offer to sell such an authentication for a particular price, using good economies 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, a small-scale user service provider 101 is capable of reaching. It is even possible for such a small-scale user service provider to offer a wide and highly specialized set of authentication 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 of user service providers 150 in a very efficient manner, and also have the system 100 keep track of relevant user information such as credit card numbers, without jeopardizing personal information integrity, by simply agreeing to letting one or several trusted authentication service providers, such as the user's personal online banking facility, authenticate the user on behalf of other parties and to contribute with user information known to them.

Importantly, these advantages can be achieved without removing much flexibility for any of the stakeholders. The users can choose to use any registered authentication service provider, 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 providers, since much user information can be made available automatically, without the user having to type it in repeatedly at various sites. At the same time, user service providers can offer a more tailor made user experience with extra knowledge of the visiting user at an early point in the transaction process. These advantages are even more powerful in case several authentication service providers are used in parallel to together provide a more complete set of available user information.

In particular, these advantages can be achieved even in the case of authentication service providers using control of a particular electronic device ("something you have") as an authentication factor, via direct communication in a wireless mobile network, also in case such electronic device is no longer connected to such mobile network, for instance when coming home or entering an office building, and switching to a WiFi connection as a consequence.

Hence, the selected or identified authentication service provider described above is a mobile telephony operator to which the particular user is a subscriber. The user authentication provided by the authentication service provider comprises a mobile authentication step in which the user communicates with the selected authentication service provider using a mobile device comprising a SIM card associated with the particular user's subscription with the said authentication service provider. For instance, the credential data provided by the user to the authentication service provider may then comprise an alphanumeric code sent to the telephone number (MSISDN) of the mobile phone as an SMS, read by the user and input into an input box comprised in the graphical interface. The above described first graphical interface may be provided on the display of the said mobile telephone, such as by a web browser running on the mobile telephone. Such method provides a second authentication factor (something the user has, namely the mobile telephone).

It is particularly preferred that the mobile authentication step specifically comprises the verification of a certificate which has previously been provided on the said SIM card. This provides very good security.

It 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 then be independently applied from the factor based upon control of the electronic device.

It 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 wireless network, move to a WiFi connection, be authenticated again based upon the previous authentication in the mobile network, move to a different WiFi connection and again be authenticated there based upon the previous mobile network authentication, again move to a mobile wireless network and be authenticated again there, then move to a WiFi network and be authenticated based upon the last mobile network authentication, etc. Hence, from the user's perspective, a seamless experience is achieved, in particular as long as the electronic device reaches a mobile wireless network connection sufficiently frequently so as to maintain an active authentication session with the authentication service provider 110.

In particular, according to one preferred embodiment, the authentication service provider 110 periodically re-authenticates the user based upon the control of the electronic device when the latter is connected to the above described network of the provider 110, in a way which does not involve any interaction with the user, such as by automatically reading an IMSI code of the electronic device. This way, the chance of there being an active authentication 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 apparent to 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 have considerable 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. Moreover, one or several of the authentication service providers may be comprised by respective external central servers similar to the central server 101. Such external central servers will then, typically, be connected to a respective plurality of other authentication service providers. Then, such external central servers are treated as ordinary authentication service providers. So, for instance in the above described auction procedure, an external central server may provide a sell price for authentication of a user in a certain current situation and under certain conditions, using its own network of available authentication 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.

Claims

C L A I M S

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) providing a central server (101), in communication with an authentication service provider (110), arranged to authenticate 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 authentication service provider in question, and at least one user service provider (150,160), arranged to provide user services to users via a respective user service web interface;

b) providing to the electronic device wireless internet connectivity via the said network;

c) causing the authentication service provider to authenticate the user based upon the user's control over the said electronic device and via said network, and upon authentication of the user, allowing the central server to place a first cookie on the electronic device, said first cookie identifying the authentication service provider in question;

d) providing to the electronic device internet connectivity which is not via the said network;

e) providing, for the user and using a web browser executed on or from the same electronic device, access to a user service web interface, and as a result providing the first cookie to the central server using the internet connectivity provided in step d);

f) causing the central server to identify, based upon the first cookie, the authentication service provider;

g) verifying, in the authentication service provider, that the user can be validly authenticated; and

h) causing user authentication information to be provided to the user service provider.

2. Method according to claim 1, c h a r a c t e r i s e d i n that the authentication in step c) is an authentication of the user 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 step e), and in that the central server (101) is allowed to place the first cookie via the said web browser used to access the said particular 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 central server (101), in connection to the placing of the first cookie in step c), further allows the authentication service provider (110,120,130) to place a second cookie on the electronic device (170,180) identifying the user or the electronic device, and in that, in step g), the verifying comprises that the authentication service provider is allowed to read the second cookie 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 the placement of the first cookie in step c) takes place by the said particular user service web interface 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 read the second cookie is performed by a communication or call, such as a redirect, performed by the central server (101) and preferably via the web browser used to access the particular 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 the central server (101), in connection to the placing of the first cookie in step c), further receives from the authentication service provider (110,120,130) information regarding the user or the electronic device (170,180) allowing the authentication service provider to identify 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 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 user service interface accessed in step e) is caused to provide to the user an option to be authenticated 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 user service 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 of the 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 place by the user service web interface accessed in step e) comprising central server content which 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 central server (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 of the preceding claims, c h a r a c t e r i s e d i n that step h) comprises the authentication service provider (110) providing a first access 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 fist access token is provided to the central server (101), and that step h) further comprises the central server providing, to the user service provider (150,160), a second access token using which the user service provider can request the central server to provide information regarding the user, and in that, upon such request using the second access token, the central server queries the authentication service provider (110) for said user information 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 to authenticate 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 authentication service provider in question, and further in communication with at least one user service provider (150,160), arranged to provide user services to users via a respective user service web interface, c h a r a c t e r i s e d i n that the central server is arranged to receive information regarding the availability of a particular authentication service provider to authenticate the user based upon the user's control over the said electronic 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 authentication service provider in question and either allowing the authentication service provider to place a second cookie on the electronic device comprising information identifying the user or the electronic device to the authentication service provider in question or to receive from the authentication service provider in question such information, in that the central server is further arranged to, at a later point in time and upon a request from said user service provider, receive the first cookie and, based upon the first cookie, identify the authentication service provider in question, and then either allowing the first authentication service provider to read the second cookie or providing the first authentication service provider with said information.