BE1024035B1 - MOBILE AUTHENTICATION SYSTEM - Google Patents

Abstract

This invention relates to a system for providing authenticated access to internet-supported services, which is remarkable in that it forms a unified identity management system (2) centered on the user (3) to create a unified identity means (23) intended for users (3) within a certain area, so that this user is able to use the same account to make himself known and to authenticate this for various applications (31, 32, 33, 34; 61), possibly from different application holders (63), in particular where a mobile authentication is used.

Description

Mobile authentication system

The present invention relates in the first instance to a mobile authentication system.

Mobile devices are ubiquitous and they are carried everywhere and always with them. This means that mobile devices are good candidates for engaging in a 2-factor authentication mechanism. After all, the user does not have to carry an extra device.

States where a user is in possession of a multiplicity of passwords in order to have access to a wide range of so-called websites are well known to pose a problem for the user, because it becomes somewhat difficult for the user to to remember all those passwords in order to be used correctly against a desired website. To remedy this, a number of management systems were developed that provide access to a multitude of computers via the internet through a single authentication process.

Such a system is known in which a so-called single-sign-on user account known as SSO is described, as well as a set of secure access websites linked to said SSO user account, various user identification ID and password combinations that are linked to said set of secure websites. A computer program that is installed on a local computer is configured to immediately fill in the so-called log-in and password intended for the access-protected websites.

A further system is also known in which a twisted platform module referenced with TPN is described which cooperates with a so-called PROXY SSO unit and with access applications to the web to generate, store and search for passwords in so-called SSO credentials. Here again the same problem is raised that the user is confronted with an ever-increasing number of passwords each time he wants to gain access to a new website or reactivate a certain website.

With the ever-increasing number of electronic transactions and all sorts of transactions in the context of the internet, the secure use of appropriate identification during the transactions on the internet has become a crucial problem that gave rise to the establishment of internet models for the identity management of the internet. user who is usually registered with a specific username and password linked to a certain domain, intended to make the theft or even any unauthorized use of the identification of a third party from site to site more difficult. Such models, referred to here as application-oriented identity models, are characterized by strong support for domain management, but show scaling and flexibility limitations as soon as they are confronted with broader identity requirements of internet scenarios.

Known authentication systems are rather application-based, which have the disadvantage of holding strong limitations, both for users and for agents or service providers of the intended applications. The latter remain locked up in one authentication method or technology to which they are limited. In addition, they have an increasing total cost of ownership of TCO, for maintaining a so-called help desk, etc. The latter also have to contend with the quality of the user data, such as problems of double use, false data, or data that is no longer current. In addition, they have little or even no mutual interaction among the applications, no cross marketing or cost known as TCO. They must also provide maintenance for privacy compliance.

As far as the users are concerned, they are then somewhere forced to use specific authentication means specific to the application. In addition, they encounter difficulties in maintaining their credentials. Neither can they enjoy a multiple mutual authentication / application interaction. Finally, they show increasing concern about the control and management of their identity, their credentials and their privacy.

In the particular case of a mobile device, this also has a keyboard and screen that may be different from the keyboard and screen on which the main application runs. The separate screen can show context about what should be happening on the main screen. It inspires confidence by assuring the user that the main screen does indeed do what it claims and that it is not a fraudulent application.

The separate keyboard ensures safe input for the knowledge factor. Therefore, users should not use the keyboard of the other, possibly untrusted, device on which the main application runs.

The current generation of mobile devices have an excellent camera on board that is capable of fast QR codes and, moreover, they often have a permanent Internet connection. Both can be used to create a very smooth and secure user experience. Scanning a QR code ensures fast and error-free synchronization of the main application and the mobile application.

In other 2-factor authentication methods, the possession factor is often implemented by a so-called “safe element” - such as a smart card for example - that can only be unlocked by the knowledge factor, often a PIN code. The possession factor in the mobile authentication method according to the invention, on the other hand, is fully implemented in software because such secure elements are not widely distributed in current mobile devices.

The object of this invention is to eliminate the aforementioned drawbacks, respectively. solve problems in a more sophisticated way based on an innovative combination of a number of elements, resulting in a more powerful system thanks to which fairly practical and ingenious applications in the use of the internet possibilities are achieved thanks to a user-oriented identity management system.

Thus, according to this invention, a system is proposed as defined in the appended claims, in particular in the main claim, wherein in summary the linked mobile authentication method according to the invention implements a 2-factor authentication. It is based on both a knowledge and possession factor. It uses QR codes and a 2-phase commit mechanism to create a safe, stable and smooth user experience.

A secure element cannot be copied within reasonable, affordable limits. The linked possession factor according to the invention, on the other hand, can be copied by hostile code running on the mobile device or by unsafe backup procedures. To compensate for the loss of this protection, the linked authentication mechanism according to the invention is constructed so that it can detect if 2 copies of the same mobile registration are active and take action if this were the case.

The user experience used here consists of 2 major steps, including scanning a so-called QR tag and confirming the context by entering a PIN code.

The process in which the user links his mobile device to user account is called the registration process. Thus the registration consists of the following steps: - the user is logged in or was created by another trusted process - the user installs the linklD application on his mobile device □

- the system shows a QR code to the user D - the user scans the QR code - the user verifies the context now displayed by his mobile device

- the user chooses and confirms his PIN codeD - the system links the mobile device to the user account.

With regard to the subsequent authentication, the system attempts to identify and authenticate the person trying to gain access during the authentication process as follows: - the user tries to gain access to an application! - the system shows a QR code to the unknown user! - the user scans the QR code! - the user verifies the context now displayed by his mobile device - the user enters his PIN code - the system gives the user access to the application.

The proposed solution according to the invention based in particular on an algorithm consists of a mobile application and a server application. The user has a mobile device with the mobile application on it and is in contact with the server application via another screen, such as the browser on his PC for example.

Both the mobile application and the server application have a persistent state. The state of both applications changes during the interaction between the mobile application and the server application. These interactions and their influence on the state of both applications are set out below.

With the aforementioned persistent state, the state of the mobile application is fairly simple. It contains 2 things:

The registration ID, this is a DUID that is created during registration. It is the link between the registered mobile device and the user account on the server application; and The OTP, this is a UUID that serves as a one-time password to log this mobile device into the server application. It can only be used once.

The state of the server application consists of registrations and sessions. A registration contains the following fields for the aforementioned RegistratielD. This refers to a aforementioned registered mobile device; a PIN, this is a 4-digit number. It is selected by the user during registration; OTP1 as the first candidate OTP as it may be stored in the mobile application; OTP2 as a second candidate OTP as it may be stored in the mobile application;

Counter, is a value that counts the number of consecutive failed authentication attempts due to an incorrect PIN;

Blocked, which indicates whether a registration is blocked and therefore cannot be used for authentication;

Activated, this field indicating whether a registration has been completed in full;

Device name, which is a legible name of the registered device. This name is displayed during the management of a user account;

Current session, which is the SessielD of the current authentication or registration session for this mobile registration.

The session of the server application contains: QRhash, which is a value that is the so-called hash of the QR tag that was generated for this session;

SessielD, which is a reference to this session that is used during client / server communication and in the registration data;

Status, which is a field that tells whether the session was successfully terminated. Start time This tells when the session was started; it is used to expire old sessions;

Registration ID which links the session to a specific registration.

The registration starts with a user who has already been authenticated by the server application through a sufficiently trusted process. This authentication allows the user to start the registration process on the server application. The following sections show what happens on the client and server side. Figure 1 shows a diagram of the complete registration process.

A QR code is generated by the server. This QR code is an encoded URL that is defined as follows: URL = <urlhandler>: // reg / <version> / <RegistratielD> / <context> QR = encode (URL).

The URL handler is a string that ensures that this URL will be opened by the mobile so-called linkID application according to the invention in case the QR was scanned by a general QR scanner.

The literal reg string tells the mobile application that it is about a registration process instead of an authentication process.

The version shows the version of the authentication protocol so that the client can respond appropriately if a QR code of another protocol is scanned.

The Registration ID is a random number in the UUID format that will serve as identification of this registered device during further registration or subsequent authentication.

The context is a text that will be displayed after scanning the QR code so that the user can verify that the tag he just scanned indeed matches what he is currently seeing on the main application.

The server state is adjusted by adding a session that looks like the following in Table 1:

Table 1

At the same time, the server adds a registration as shown in the following table 2

Table 2 where QRhash = securehash (URL). □ This secure hash function is a so-called hashing function known as SHA1. The SessielD is a random UUID.

The QR tag is now displayed to the user within the previously authenticated context. Registration data is submitted as follows:

The user's mobile application scans the QR code, decodes and processes the URL. Alternatively, the QR code can be scanned by a generic QR scanner or, if shown in a web page, clicked by the user. The specific URL trader in the QR code will launch the linkID mobile application.

Because of the literal reg string in the URL, the mobile application starts the registration procedure. The mobile application shows the context to the user and asks the user to select and confirm a knowledge factor - usually a PIN.

The mobile application retrieves the ReglD from the URL that will serve as identification for this registered device in subsequent contacts with the server.

The mobile application then connects to the server at a registered SSL-secured URL and sends. following information: ReglD, the chosen PIN and the readable name of the device.

The server checks whether the registration (ReglD) exists, is not yet activated and whether the current session is still valid. If everything is fine, an OTP (a random number in UUID form) is created and stored in the registration. The PIN code is also stored in the registration as shown in the following table 3:

Table 3

The server responds with the OTP to the mobile application. After receiving the OTP, the mobile application adjusts its state as shown in the following table 4:

Table 4

The registration is confirmed as follows: the mobile application now sends the QRhash and the ReglD to the server. The server validates whether this hash matches the hash of the current session of registration. The server also checks whether the session has expired. If everything is OK, the server adjusts the registration as shown in the following table 5:

Table 5 as well as the session as shown in the following table 6:

Table 6

Regarding authentication, she starts with a user who is not known by the server application.

This unknown user starts the authentication process on the server. The following sections show what happens sequentially in the mobile application and the server application. Figure 2 shows a diagram of the entire authentication process.

The server generates a QR code in much the same way as during registration according to: URL = <urlhandler>: // auth / <version> / <seed> / <context> QR = encode (URL).

The seed is a random string to make the URL and QR different for each session. The server state is adjusted by adding a session. The session looks as shown in the following table 7:

Table 7 where QRhash is generated in the same way as during registration. The QR tag is now shown to the user.

The submission of authentication data then takes place as follows: the user's mobile application scans the QR code, decodes and processes the URL. Like during registration, the QR code can be scanned by a generic QR scanner or the URL can be opened by clicking on the tag. Because of the literal auth string in the URL, the mobile application will start the authentication procedure. The mobile application shows the context to the user and asks them to enter their knowledge factor, usually a PIN.

The mobile application then connects to the server at a registered SSL-secured URL and sends: ReglD, PIN, QRhash and the OTP, whereby ReglD and OTP are taken from the local state of the mobile application.

The server checks whether the session (QRhash) exists and is still valid. The server checks whether the registration (ReglD) is activated and not blocked. If blocked, the server will stop the authentication process.

The server checks whether the OTP matches one of the OTP values stored in the registration. If none of the OTP values matches the submitted value, the registration is marked as blocked. This prevents any future authentication attempt until the blockage is lifted by a sufficiently trusted procedure.

The server also checks whether the PIN code matches the PIN code stored in the registration. If the submitted PIN does not match the stored PIN code, the server increases the counter. If the counter exceeds a predetermined threshold, the registration is marked as blocked. The counter is reset to 0 with every successful authentication attempt.

When all checks are over, the server generates a new OTP (OTP ") and stores it in the non-matching OTP field of the registration. The resulting server state for registration is then as shown in the following table 8:

Table 8 and those for the session as shown in the following table 9:

Table 9

The OTP and SessielD values are sent back to the mobile application.

After receiving the OTP ’and SessielD values, the mobile application adjusts its state as shown in the following table 10:

Table 10

To confirm authentication, the mobile application then sends a final message to the server within the same session. The non-matching OTP value of the previous interaction is deleted. The server state now looks like the following table 11:

Table 11

Only now does the server mark the session as authenticated as shown in the following table 12:

Table 12

The algorithm used for the system according to the invention is designed to have two important side effects. The first side effect is that if the state of the mobile application were successfully copied and used, then the next time the original state is used the registration will be blocked by the server. This is because the original state will contain an OTP that is no longer on the server. The server blocks registrations for which an invalid OTP has been submitted.

A second side effect is that the mobile application can never be synchronized with the server due to network problems or problems with the mobile device. In other words, no matter how, where or when the mobile application loses contact with the server during authentication, the mobile application will work again after the temporary connection issues are resolved. The reason for this is that the OTP is being replaced by a 2-phase commit; the OTPs are only shifted after the mobile application has certainly saved the new OTP.

Below are some scenarios in which the so-called linkID mobile authentication according to the invention can be used. Each scenario is based on a user who has already registered.

For an authentication on a web site, the user follows the following system steps 1. a user goes to a web site 2. the user clicks on logon 3. the web site shows a QR code 4. the user scans the QR code with his linkID mobile application 5. the user recognizes the context on his mobile application "log in to site X" 6. the user enters his PIN code in the linkID mobile application 7. the web site reads the successful session status and allows the user to access the protected part of the website.

For a payment on a web site, the user follows the following System steps: 1. a user goes to a web site and puts an order together 2. the user clicks on payment 3. the web site shows a QR code 4. the user scans the QR code with his linkID mobile application 5. the user recognizes the context on his mobile application “Pay X Euro on site Y” 6. the user enters his PIN code in the linkID mobile application 7. the web site reads the successful session status and uses it the user's stored payment data to pay for the order.

For a payment in a physical store, the user follows the following System steps: 1. a user goes to a store cash register 2. the cashier clicks on payment in the cash register system 3. the cash register system shows a QR code 4. the user scans the QR code with his linkID mobile application 5. the user recognizes the context on his mobile application “X euro payment in store Y” 6. the user enters his PIN code in the linkID mobile application 7. the cash register system reads the successful session status and uses the stored payment data from the user to pay the order.

For an access control to an event, the user follows the following System steps: 1. a user goes to the access control 2. the control system shows a QR code 3. the user scans the QR code with his linkID mobile application 4. the user recognizes the context for his mobile application "enter at event X" 5. the user enters his PIN code in the linkID mobile application 6. the control system reads the successful session status and verifies in his database whether this user is indeed entitled to enter.

Also according to the present invention is proposed a system as defined in the appended higher-level system claims based on a combination of validation means such as agreements established between the service provider of this system and owners or operators of relevant internet sites in their capacity as suppliers - such as banks , shopping sites and so-called utility companies - which are intended to provide the user with the possibility of access when he visits an internet site that is connected to the central management system concerned designated as "LinkID", which is subject to a connection to the management system referred to .

The characteristic of user-centered electronic identification is that the user is given the opportunity to use one ID that can be both transparent and flexible, instead of having to use multiple pairs of username / passwords to access the desired websites. register. This, after all, offers the great advantage that these operations therefore become much smoother and the risk of oblivion or error is reduced to a minimum. User-oriented electronic ID models are rather focused on the user himself, and not on a directory. However, this requires identified transactions between users on the one hand and so-called website agents who on the other hand use verifiable data, thus providing better traceable transactions. This user centered model is based on the concern to provide users with a means of control over the way their identity data is passed on to service providers or agents, while these also allow users to interact flexibly with a wide variety of services.

Against the aforementioned disadvantages of the prior art, the so-called linked identity management system according to the invention that is centered on the user does not offer any of the above-described limitations of the application-centered models of management systems. Instead, this opens up new service options for application holders or operators and provides user-friendly access to more valuable applications for users.

For the agents or application providers, this means that they can use various, both current and future authentication methods or technologies at a significantly lower TCO cost. They also do not provide for any investment in infrastructure or equipment. Furthermore, they enjoy an increased quality of user data, in particular elimination of double use, updated correction of data and the like. Moreover, there is a complete mutual interaction of the attributes with each other, including cross marketing and cross selling with the advantage that a larger number of users are on line with more efficacy. The confidentiality requirements are perfectly maintained and complied with. There is also scalability available, as well as a built-in help desk and auditing.

As far as users are concerned, they have easier and also more reliable access to on-line applications including payment transactions that use authentication means of their choice. Moreover, they have reliable and simple multi-authentication / application interactions. Finally, they still enjoy full control and management of their identity, credentials and confidentiality.

According to an advantageous embodiment of the invention, various authentication means can be used, such as a card reader or a mobile telephone, to provide access to the aforementioned internet site connected to the management system according to the invention. With this, this system provides an extremely reliable service that offers flexible and strong authentication with multiple means, as well as the validation of data and transactions intended for signing or payments. These service resources that are based exclusively on standard resources fit in with all flexibility with existing and future online applications.

According to an additional embodiment of the invention, a number of management means are provided with so-called attributes which are intended to determine the profile of the user, such as address, date of birth and gender, management means thereof being provided in the system according to the invention to implement said attributes. and storing during the course of routine use of the invention. Thanks to the thus proposed system according to the invention, the problem is solved consisting of the improvement method for the security of SSO user accounts.

Thus a user can link a number of attributes as a part of his / her user profile. This attribute can be any information element about the user. Access control is often carried out by connecting the aforementioned attributes communicated by a user or having them weighed against a set of rules determined by the service provider or agent. In this respect, the aforementioned attributes can be determined arbitrarily, provided, however, that they are appropriately understood and interpreted and interpreted both by the user and the service provider or agent during a transaction.

The system according to the invention thus forms a standard supported management system for managing a standard supported user-directed electronic identity and credential.

The identity-linked system according to the invention is a reliable and secured user-oriented management system of its electronic identity and credential means, whereby the users are placed in full control of their identity and privacy while at the same time also providing the possibility for application operators, major brand holders and member companies to build deeper, more relevant, and ultimately more cost-effective relationships with the users of their services.

The system according to the invention furthermore also opens the door to frequent applications as well as cross-selling and marketing with increased revenue. After all, the same account can be used for all activities, ranging from ordinary membership to a forum activity and purchases or accessions.

This invention also relates to a device intended for carrying out the relevant method as set forth above, consisting of the basic embodiment for carrying out the Link-ID method.

Further features and specifics are determined in the relevant sub-claims. Further details and details are further elucidated in the description below, which is illustrated with the aid of the accompanying drawings.

Figure 1 shows a diagram of the complete registration process in a first main embodiment of the management system of the invention.

Figure 2 shows a diagram of the complete authentication process in the aforementioned basic main embodiment of the management system of the invention.

Figure 3 shows a block diagram of a conventional application-oriented identity model management system from the prior art.

Figure 4 shows a block diagram of a current user-oriented identity model according to a further main embodiment of the management system of the invention.

Figure 5 shows a block diagram of a variant of an identity model from the prior art. Figure 6 shows a block diagram of a variant of user-oriented identity model management system according to the invention.

Figure 7 is a schematic representation of the identity components employed in the management system of the invention.

Figure 8 is a schematic representation of the parties involved in the management system according to the invention.

Figure 9 is a flow chart as a schematic representation of the operation of the management system according to the invention.

Figure 10 shows a block diagram of a conventional application-oriented identity model according to a special application example of the invention.

Figure 11 is a schematic representation of an exemplary embodiment of the method according to the invention.

Figure 12 shows a block diagram of an application-oriented identity model according to an additional application example of the invention.

In general, the aforementioned further embodiment of the invention relates to self-directed authentication systems that are distinguished from known systems 1 in that the latter are based on application basis with the disadvantage of retaining strong limitations, both for users 3 and for agents or service providers of the intended applications, as shown in Figure 3. This shows the state in which a user 3 has one specific identity 13, 14, 15 for each on-line application a, b, c operated or not operated by the same holder, the identities 13, 14, 15, respectively, given in certain cases also being different. Three identity fields 13, 14, 15 can therefore be considered here.

In contrast, the linked identity management system 2 according to the invention centered on the user 3 shown in Figure 4 does not offer any of the above-described limitations of the application centered models of management system 1. Instead, this opens up new service options for the application holders or operators and offers user-friendly access to more valuable applications for users 3.

The management system 2 according to the invention forms a united identity management system, which is centered on the user 3 and whose purpose is to create a united identity means 23 intended for users within a certain region or industry. With this, that user is able to use the same account in order to make himself known and to authenticate this for various applications a, b, c, whereby these applications can start from different application holders. This is shown schematically in Figure 4 with reference to the schematic representation of the current state shown in Figure 3.

In the additional example shown in Figure 5, applications 31 and 32 are operated by the same holder AA, whereby they can then have the same identity in common. Herein, the user 30 has one specific identity 35, 36, 37 for each on-line application 31, 32, 33, 34, whether or not operated by the same holder AA, resp. BB, wherein the identities 35, 36, 37, respectively, can be mutually different. Whatever the case may be, with this example a minimum of three identity fields 35, 36 and 37 can be considered.

The user-centered management means L according to the invention offers a simplification of the existing system by offering a united identity field 40 which can thus be used for the aforementioned applications 31, 32, 33, 34 simultaneously which moreover can also be operated by several aforementioned application holders AA, resp. BB as shown in Figure 4.

Thus, the main embodiment of the invention can be defined as a management system L of the identity fields 40 of a user 3 identified by one globally unified identity 40 which he must insert in order to have access to his desired applications 31, 32, 33, 34 operated by agents AA, BB, which is remarkable in that this management system 2 is aimed at the user 3 whereby the latter can access all the aforementioned applications 31, 32, 33, 34 t * which are mutually different and this via a single identity field 40 that uniquely identifies said user.

The advantage of this is clear that a globally united identity field 40 is thus obtained thanks to the system 2 according to the invention. Identity components 51, 52, 53, 54 occurring here intervene in the unified identity 40 created by this system 2 and consist of four different components which are all connected via the core element L according to the invention, which is schematically shown in Figure 7.

The first component consists of so-called attributes 52, existing. in pieces of data assigned to the physical person who has the relevant identity in his capacity as user 3, such as name, age, gender, location, etc. A further component consists of subscriptions 51 that determine in which applications 31, 32, 33, 34 the relevant identity 40 can be used. These accessions 51 form the link between an application and an identity. These also regulate the legal and confidentiality satisfaction between a user and an application that the latter wishes to target.

Furthermore, there is the component of the authentication means 53 which is intended to be registered and used by a user 3 to authenticate himself. One particular identity 40 may have registered several authentication means here and examples are the duo user name with password, identity card, a traditional credit card, a mobile phone, and so on.

Finally, the history component 54 in which the user 3 can keep a track of all actions around his identity 40.

The management system 2 can guarantee the uniqueness of the user 3 by means of his devices 53, on the understanding that the core L will not allow a physical device to be used for two different accounts, which makes the identities in this management system 2 particularly strong.

Attributes 52 form the substance of the identity 40 of the user 3, and make the user what he is ultimately. The essence of attributes consists in their repeated use between different applications 31, 32, 33, 34, whereby the user can check at any time which application gives access to which attribute.

Attributes 52 have certain data types, such as, for example, Boolean or so-called string characters, and can be linked to single or also multiple values. The attributes can also be assembled to form new data types, such as, for example, a street combined with a city together form the address. It should be noted that attributes are not hard coded but can be added by the operator at the request of its customers, i.e. the application holders.

In the general structure of the system 2 there is the peculiar core element L thereof, which occupies a central position herein, communicating with various parties which are determined as follows, as shown in Figure 8. End users 3 are formed by physical persons who account and want to use applications 61 which are linked to the core L of the management system 2. The end users interact with the system core L by means of an interface 62, for example a web interface, whereby integration is also possible with non-web systems.

A further party is formed by the applications 61 which are intended to fulfill functions consisting of certain services offered to the aforementioned end users 3. In order to be able to identify their users 3, they then use the aforementioned core L. To communicate with the core L, they use web services 62.

In addition, application holders or operators 63 who own and operate the aforementioned applications. It is they who are the effective customers of a so-called core operator 64. They interact with the core L through a web application that provides statistics and accounting about the applications they own.

Furthermore, there are also operators 65 who manage the system software in so-called data centers and who sell the various system functions and services to the aforementioned application holders 63. They work together with the aforementioned application holders to connect their applications 61 to the management system L.

Finally, there are also the device deliverers who deliver the necessary authentication means 53 to the users 3. These can have their device 53 carried by the management system 2, of which it is understood that this is formed by the so-called LinkID system.

Attribute values can be provided by the user 3 himself, by an application 61, by a device 53, a remote system such as a database, a web service, LDAP, or also starting from a calculation of other attributes. An attribute can be read in by an application 61 when the following conditions are met, in particular that the operator gives the application access to the attribute, the user 3 allows the application 61 to use the attribute and finally that the attribute has an value. A further advantageous feature of attributes is that they can be referred to as being anonymous. In that case, applications 61 cannot read the specific value of an attribute from a specific user, but they are able to receive statistics about it. For example, when location was designated as anonymous for an application, this application cannot read the location of a certain person X, but it can receive a statistic "20% of your users live in a city Y" , which is a particularly useful information for the application holder 63, and is therefore an asset of this management system L.

Here, different functions can be fulfilled by the system 2 according to the invention vis-à-vis the applications, in particular first an authentication function: when an application invokes this function, the user is authenticated by the system 2 when one of his configured devices 53 is used. provided this is successful, the application will be notified and will give access to the user 3.

There is also the attribute function: an application can request the attributes 52 of the user and use the values thereof in its business operations. Attributes can only be read here on condition that the user 3 has given his explicit permission for this.

There is also the data function in which an application 31 can push attributes 52 to the profile of the user 3. In that case these attributes can be used by other applications 32, 33, 34, provided that this is permitted by the user and the delivery application.

For the end user, the benefits of using the management system 2 are a remarkable reinforcement of his accounts, the functions are the attributes and also a stronger control over his identity 40, both from a management, confidentiality and security point of view.

Under that application, in particular its holder 63, the benefits are primarily device independence, stronger identities with higher quality profiles, simplified registration and user management, simplified legal and confidentiality compliance. This also allows a new use of the partner of the user of the application. Moreover, this also allows a reduction of the access threshold to the application. This also supports marketing schemes by reading in and providing attributes to or from partner applications.

In the authentication process, an authentication flow 71 takes place which propagates in the direction of arrow F via an authentication path visualized in Figure 9 in the form of a so-called authentication pipeline 70. To be authenticated, the user 3 evolves through different stages of the flow 71, wherein delivers certain guarantees to the agent or customer application at every stage. The successive steps of the authentication process are set out below.

In a first step referred to as device selection A, the user 3 is offered to select the authentication means 53 that he wishes to use for authentication purposes. In this way, the user can select this means 53 that he has on hand or that fits him best at that time and place. However, this means selection A can be limited at the request of the application, for example, only stronger means of authentication for high value operations. The authentication then takes place B as required by the respective device 53.

The next step which is this of the agreements C is a general legal conformity confirmed by asking the user 3 to express his agreement against a user agreement C. This step only occurs when a new version of the user agreement is available.

Furthermore, the management system 2 asks the user 3 whether he agrees with the relevant application 61 using certain attributes 52. This is thus the confirmation step D of the attributes determined by the aforementioned operator 65. The core L asks this only once , so that this step D will not occur in later authentication events, unless the application attribute requirements have since been changed.

Finally, there is the comparison step E where the core L compares the user-defined attributes with the attributes requested by the respective application 61. Some attributes may be indicated as requested. However, in case the user does not yet have these attributes, the management system L will first ask the user 3 to provide the attributes.

The authentication stream 70 described above can be included in various protocols. Without other notification, this is the SAML version 2.0 protocol for this management system

With regard to the authentication means 53, several of these are dynamically supported by the management system 2. These elements 53 are not hard coded in the management system 2 so that new authentication elements 53 can be added without the need for a new software for the management system 2. For each authentication element 53, the management system 2 knows the location of the registration / update / deletion and authentication workflow 70. These workflows are jointly determined by the management system operator 65 and the device provider 64. These workflows 70 differ for each device 53 since there are differences in both technology and delivery procedures.

The software that implements these workflows can be hosted and edited by the management system operator 65 or by the Equipment Holder 64. This choice depends on a number of factors such as safety, costs and experience. Either way, the management system can use workflows from remote elements, which can be developed and maintained separately.

For a number of highly regulated authentication elements, the operator 65 of the management system 2 does not require much cooperation from the element provider. A good example of this is the large PKI-based electronic identity card.

By way of example, a number of technical choices are made below with regard to tools and resources used, which should not, however, be regarded as limiting in the context of this application. The management system 2 designated as LinkID is implemented in JAVA EE 5 and is independent of both the operating system and the database.

This management system uses only open standards to ensure maximum compatibility with customer applications, in particular SOAP, WS-Security, Liberty Alliance; SAML, X.509, et al. A JAVA SDK is being developed together with the management system to facilitate integration between applications and the management system. However, this does not mean that applications written in other languages are discarded. Since all communication runs on open standards, it is easy to extend the SDK to other languages, whereby it can only be seen as a reference implementation.

The management system according to the invention was built on an extremely flexible architecture to make this independent of technology. All technology-dependent components are plug-ins and can be expanded. The following features have been developed in this way and can therefore be expanded: under authentication means 53, mobile authentication, EMV cards, OTP tokens, etc. Regarding authentication protocols: Cardspace, OpenlD, Windows live ID protocol, Shibolleth.

The implementation of a signature service is also advantageously provided. When this service is used, an application 61 can request the management system 2 to have a user sign a particular document or transaction using his authentication elements 53. In this way, an application can use the management system 2 to strongly seal transactions on a technology independent manner in perfect compliance with legal compliance.

When several LinkID instances are in production in various regions or industries, possibly under processing by different operators, the management system 2 will have the ability to evolve users 3 between these instances. Users connected to one management system 2 will be able to use applications that are connected to another LinkID instance.

The following is an overview of the benefits generated by the LinkID management system 2. This system allows the agent or service provider to do more with the users. In this respect, application providers have a need for management systems that involve a larger number of users, with more applications and ultimately more revenue. This management system provides reliable authentication that covers all of these requirements by offering their users an identification management that they can trust.

This is done by acquiring deeper and broader levels of commitment because of its user base, by increasing trust and control. Also membership levels with easy management and transactions in one click intended for a migration to first rank services are eligible. In addition, traffic and usage are increasing, as users find it easier and more productive to manage their usage through a single ID that they can better monitor and trust.

An example of system arrangement is described on the basis of the relevant figure 10 in which an identity service is represented, with a single identity number 80, which is validated by the system 2 according to the invention. This system service extends the internal identity management of the service provider to external partners. This service allows users to move freely between the agent or service provider and its partner applications, and also allows easy sharing of personal and marketing data.

This service identity number eliminates the need for certain users to take advantage of their partnership between service providers. This also allows exposure of service providers applications and customer data to external parties.

Application examples that can provide the distribution of benefits or profits are so-called co-branded services from the physical world, or the ability to share compensation or loyalty systems between applications.

The system offers some important features in the event that customers are outside the service provider area, in particular in terms of user convenience: no more need to be re-registered in terms of confidentiality check, the customer can decide which data can be read in by external parties on field of standard interfaces for partner applications; and further in the field of simple and reliable authentication, where the customer can choose among the appropriate or reliable devices without the slightest integration problem for the partner application. Existing external authentication means 53, such as already used ELDs or pairs of user name / passwords 82 or, respectively, can be reused 83.

Said identity system is thus the integration point for external applications as clearly shown in Figure 10 where this identity number system 80 occupies a central position in the graph around which everything revolves and thus functions as a sort of central processing unit for the foregoing. However, this could even be used for new or existing applications.

Strong authentication can then be seen as the advantage of the system according to the invention, whereby access to an account of a management system 2 can be protected using multiple authentication means 53 which differ in complexity and reliability. This offers a large number of benefits.

First of all, an on-line application can require strong authentication in the event of an emergency, for example when it is based on an operation value. However, if strong security is not strictly required, more simple authentication methods can be used, i.e. the reliability level of the authentication means 53 can be adapted to the desired application 31, 32, ...; 61.

Furthermore, users 3 can use an authentication method as a backup for a further method: in case one method would be unavailable, the user can fall back on another method thanks to this feature.

Moreover, the L authentication system is fully usable: it can support any proposed authentication mechanism and can therefore offer this to its account holders as an authentication method.

Authentication methods are, for example, a mobile phone in which various technologies are available, in particular SMS, software on the phone or PKI on the so-called SIM card; with password 82, wherein the management system 2 also supports normal username / password combinations, and this either as a stand-alone database or also linked to an existing user base; furthermore also an electronic identity card, in which the management system 2 already supports the so-called PKI electronic identity cards, this is now the Belgian electronic identity card; and finally a so-called digipass 86 in which the management system 2 already supports implemented digipass solutions. This digipass means 86 is available for users to authenticate all applications or a limited number of applications, depending on the policy followed by the operator of the base installed with digipass. There are two ways to obtain an account for user registration. Either they can create their own account themselves, or an account is automatically converted or mirrored from an existing identity system.

In both cases, the account of the management system 2 will grow over time. The customer, the agent or service provider and his partners will enter data into the bill. New authentication means 53 are also included en route because they become available or that they are claimed for a specific application 61.

The end result is then a particularly rich bill that can be used in any business condition as long as all information about the user 3 is present and he can be identified to the extent that the new application requires. The bill can then be expanded into new applications without delay due to technical interfacing issues or user registration hinders.

In short, the management system according to the invention is an effective way to capture the information value of the customer base and efficiently reuse it.

In the following, an additional extension of the functionality of the LinkID management system according to the invention is designated with L explained existing in the development of an additional ingenuity designated as the "red button". It is essentially an activation means of a particular application as a specially elaborated format which is described below in the light of an application example for a television broadcast.

In this format, a LinkID application is installed on a user's mobile device, which can be any mobile device capable of running third-party applications. Examples of this are an Iphone, an Ipad, android devices, etc ...

The aforementioned application has a distinctive logo and brand that identifies an identity provider. In the TV world, the latter can be a channel, a cable / network, a media group, or an advertiser, and the like.

When this logo appears in a LinkID or "L" -advised television broadcast or advertisement, the user can activate this logo by pressing this on his mobile device.

The L application starts and downloads interactive content related to the aforementioned advertisement or TV broadcast from an L server, which then decides which content to broadcast, supported at the time the interactive content was requested.

This content includes ordinary multimedia information material, but also actions that the user can take. Part of these actions and content may be exclusive and specific to the user of the L application and, in other words, could not be obtained by surfing the channel, the television station or the advertising website, for example.

A typical example of exclusive promotion consists of a discount that is offered to the viewer.

The exclusive content or privileges can be used immediately via the L-mobile application, or can also be used later also via the L-mobile application, or via a website, or another point of sale known as POS.

To install the aforementioned mobile application, the relevant L format requires the installation of a telephone application on the user's telephone.

A marketing campaign should convince users to download the application for free from their mobile store.

When the LinkID application is started for the first time, the user can create an account, including a chosen account name, and may optionally choose a PIN code, all via the mobile L application. The mobile device is linked to the newly created account, so that every action carried out via the mobile device is charged.

The content is synchronized as follows: when the user presses the intended logo on his mobile device, specific content is displayed for the user taking into account that the application holder must be aware of the content that appears when a user presses the intended logo on on its mobile device, the Link-ID application must be synchronized with the television content. Since there is a collaboration between the producers of the television broadcast or advertisers and the management system 2, it is approximately known when these will start.

The synchronization is obtained with the approached television program and at least one of the following techniques: the core L is automatically informed by the broadcaster, the television station or the advertiser when the programs or advertisements activated with the core start; the core L itself detects the start of a television broadcast or advertisement that is activated with the core L via a scratch of the screen; and / or the core L is configured manually by an operator.

In the event that there are several television broadcasts or advertisements activated with the core L simultaneously, the core L will simply ask the user to choose what content he wants to see, or which channel he was watching.

The follow-up of the content takes place as follows: when a user has activated a Link-ID application by pressing the provided selection means during an activated or equipped television broadcast or advertisement, he has the possibility to visualize a certain content or certain to carry out actions.

In addition, the core will indicate the user's bill that he has pressed the relevant means of selection or button in a particular broadcast or advertisement. The user can then transfer to a website of a producer or advertiser if he uses his PC or mobile device and he can then continue to log in using his mobile application.

The website can then request the user's bill and check whether he has entered the current system campaign. If this is the case, the website may grant special rights to the user.

At the same time, all required personal details of the user are shared with the producer / advertiser. If privacy laws and regulations require this, this data sharing can be carried out in such a way that the user must explicitly confirm this.

The user can also claim his advantages at a POS point of sale on condition that the POS software is connected on-line. To identify himself, the user can communicate his core system, usemame - chosen by him at registration - to the POS operator, or he can have a system mobile application generate a barcode and the like.

The POS software can then scan this barcode or TAG and use it further to identify the user in the system server.

Application examples of the system button are in the following possible states, in particular by pressing the system button during an advertisement thanks to what the user can enjoy an exclusive discount on the advertiser's webshop.

Furthermore, by pressing the button several times, the user can take advantage if he views all concurrent advertisements of a certain product. This means also allows you to cast a vote during a television broadcast in the context of this, during a polling, for example. Finally, pressing the system button during a television broadcast may provide additional content known as a bonus, or additional background information about the item concerned.

In the context of a still further extension of the functionality of the management system according to the invention, a further development of the possibilities of the attributes is also set out below and presented in Fig. 12.

I K

Wholesaler Deal Community case

The following explanation should be considered as a starter and input for setting up a "Wholesaler Deal" service based on the L solution proposed above, where reference is made to the reference "Mobile Wholesalers, the community operator who facilitates" deals ".

The following is a concise overview of the possible configuration, use cases, development as well as working method and planning to arrive at the establishment, implementation and use of the Wholesaler Deal service. We use the L 4 step plan as indicated. 1. Wholesaler Deal configuration

For the sake of clarity, in the principle diagram represented in Figure 10 only the most important functional connections are shown.

Wholesaler Deal web site

This is the Wholesaler Deal community web site where users can register, look up deals and offers as well as buy or acquire.

As soon as a voucher is purchased on this site, this is passed on to the L promo web service. Crédits earned during this purchase, or other promotions on this site, are also passed on to the L promo web service.

Partner shop (POS)

This is a local dealer in a Point of Sales (POS), so a physical store. This trader can claim and grant vouchers and crédits via the linkID promo web site, linkID promo web service, eg. linked to the cash register system, or via a mobile merchant app.

Partner web site

This is a web shop that participates in Wholesaler Deal. This can claim and grant vouchers and crédits via the L promo web service or the L promo web site. the Mobile Wholesalers web site is also considered as a partner participating in Wholesaler deal. linkID is the identity provider that is responsible for authentication and identification of users in all other components, management of attributes, user registration, profile / attribute sharing, logging, auditing, ...

linkID Promo attribute provider IF

This is the interface between promotions and deals and the L attribute system. The attributes that can be derived from the "deals" situation of the user are, for example: "creditworthiness" in terms of deals or crédits and loyalty levels. linkID Promo model

This L program implements various forms of promotions based on giving and taking. It keeps track of which parties can give and which parties can take, and how much. It also keeps track of how many "crédits" of which promotions someone has.

The L promo model is a model for virtual cash. Numbers of certain currencies are recorded per user. The currencies then include vouchers, points ..... The linkID promo model also knows which currencies, t.w. vouchers or points apply in which applications, as well as which applications these currencies can allocate or consume and whether user interaction or confirmation is required.

In the linkID Promo model, credit systems can be expressed such as universal crédits and local crédits, but also vouchers for all kinds of deals.

linkID Promo transaction WWW

This website has a dual function, namely Website where merchants / merchants in a POS can grant crédits if a user has earned them or claim if the user has used them. This web site can also be used during a transaction on a webshop. The webshop then redirects the user to this promo site where the "payment" is made using crédits.

linkID Promo transaction WS

This web service allows merchants, web shops and the Wholesaler Deal to grant or claim web site promotions from other systems. linkID Promo mobile merchant app

This is a mobile device app that can be used by the trader instead of. the promo transaction web site for claiming and awarding promotions. linkID mobile app

The linkID mobile app has several functions: a 2-factor authentication for linkID, selection and use of vouchers, and finally also an interface to the Wholesaler Deal web site.

The 2 factor authentication means that the user can authenticate with the aid of his smart Phone in a very secure way at all connected online partners as well as at the Wholesaler Deal web site.

The application is also used when claiming vouchers, where the user selects the vouchers that he wants to offer to the merchant. The app is then a native GUI for the end-user aspects of the linkID Promo WS, namely the use of vouchers.

Optionally, the app can also be used to purchase vouchers, the app then functions as a native GUI for the Wholesaler Deal web site.

Mobile Wholesaler web site and API

Mobile Wholesaler offers an API so that Mobile Wholesaler users can easily be deployed in the Wholesaler Deal community.

Mainly the username / password of the Mobile Wholesaler site is reused. In addition, the reuse of some personal data can also promote migration. This offers the possibility for Mobile Wholesalers users to log in to the Wholesaler Deal site via their Mobile Wholesalers UN / PW.

However, new users of Wholesaler Deal must re-register and authenticate each time to the Mobile Wholesalers site. If the "integration or interoperability" between -Mobile Wholesalers and linkID is further elaborated as indicated in the linkID / Mobile Wholesalers set up document, then new users of Wholesaler Deal with their Wholesaler Deal ID can also log in to the Mobile Wholesaler site, using of multiple authentication means as indicated above.

Payment Service Provider (PSP)

The PSP is the party that makes the payment. If possible, this person also uses the Groothandela, ar Deal ID of the user to quickly retrieve previous payment details and, in the ideal case, to enable a one-click payment. 2. Use Cases

A few typical use cases for the Wholesaler Deal system are described here as an example. It is indicated for each of these use cases which parts play which role. These use cases only show a few options for using the Wholesaler Deal service. Further options include sharing "crédits" between users, use of promotions between affiliated partners, ... The basic use cases for the Wholesaler Deal service are further recorded and specified as indicated in Method (steps 1 and 2).

Use Case “Buying a restaurant voucher”

On the Wholesaler Deal web site a voucher for a dinner is offered at an attractive price.

The Wholesaler Deal user logs in. For this, he is sent to the linkID service that authenticates him using a mobile device, SMS, elD or password. After authentication, the user is sent back to the Wholesaler Deal web site. The Wholesaler Deal site can recognize the user on the basis of the information provided.

The Wholesaler Deal user clicks on the "buy now" option next to the voucher.

The user is redirected to the Payment Service Provider to make the payment. The PSP also receives the link ID of the user. On the basis of this identity, the PSP retrieves previous payment data and offers the user the opportunity to confirm the payment with 1 click.

The user is sent back to the Wholesaler Deal site with a payment confirmation. The Wholesaler Deal site contacts the Promo backend via the Promo transaction WS, and in this way adds 1 restaurant voucher to the user's account.

The user goes to the restaurant and enjoys the dinner. At the payment he says that he is paying with a voucher. The user takes his mobile device and starts the Promo app. In the promo app he looks up the voucher and clicks on "offer". A reference appears on the LIN.K Wholesaler Deal Community smartphone. The user shows this reference to the restaurant employee. The employee opens the Promo transaction web site, the Promo mobile merchant app or the Promo transaction WS, via his POS, and sees all "pending, active" restaurant vouchers, these will generally only be a few, from all persons who want to pay with the voucher in that restaurant at that time. He searches for the voucher with the same reference as the one shown by the customer. He clicks on "accept" with the correct voucher.

In this use case, the user of course also has other options besides his mobile to offer the voucher, eg. print out.

Use case “Online discount through crédits”

When purchasing products from Wholesaler Deal partners, the user can earn crédits. He can also earn this with purchases on the Wholesaler Deal site itself.

The web shop A that grants the credit establishes the identity of the user via linkID.

The web shop A contacts the Promo backend via the Promo transaction WS and adds the crédits to the user's account.

The user goes to web shop B and selects a product there. When paying for the product, the buyer is given the option to pay in part or in full through crédits.

Web shop B sends the user to the Promo transaction web site. This site recognizes the user and only requests confirmation from the user for the use of X crédits.

After confirmation, the Promo transaction web site sends the user back to web shop B. The outstanding balance is further settled via a payment process at the PSP, which ideally also only takes 1 click.

Claims (40)

CONCLUSIONS 1 System comprising a unified identity management system (2) centered on the user (3) to create a unified identity means (23) intended for users (3) within a certain area, thereby empowering that user to have the same account to self-identify and authenticate for various applications (31, 32, 33, 34; 61) where appropriate from different application holders (63), characterized in that the authentication process implements a 2-factor authentication based on is on both a knowledge and possession factor, using specific codes and a 2-phase mechanism to create a user experience, the linked authentication mechanism being built so that it can detect if 2 copies of the same mobile registration are active and take action if this is the case, wherein said applied user experience consists of 2 main steps including the scan n of a so-called QR tag and confirming the context by entering a PIN code. System according to claim 1, characterized in that a mobile authentication is used. A system according to any one of the preceding claims, characterized in that the user couples his mobile device to a user account according to a registration process whereby he can be registered, the registration consisting of the following steps: - the user is logged in or was created by another person trusted process - the user installs the linklD application on his mobile deviceD - the system shows a QR code to the userD - the user scans the QR code - the user verifies the context now displayed by his mobile device - the user chooses and confirms its PIN code - the system links the mobile device to the user account, where a QR code is an encrypted URL generated by the server, with subsequent authentication, where the system identifies the person trying to access during the authentication process and authenticates as follows: - the user tries to gain access and until an application D - the system shows a QR code to the unknown user D - the user scans the QR code D - the user verifies the context now displayed by his mobile device - the user enters his PlN code - the system gives the user access to the application. System according to one of the preceding claims, characterized in that the process is based on an algorithm consisting of a mobile application and a server application, wherein the user has his mobile device with the mobile application thereon and is in contact with the server application via a another screen, where both the mobile application and the server application have a persistent state and the state of both applications changes during the interaction between the mobile application and the server application. System according to the preceding claim, characterized in that said interactions and their influence on the state of both applications are determined by the fact that with said persistent state,. wherein the state of the mobile application contains the following two items: the registration D, which is created during registration and forms the link between the registered mobile device and the user account on the server application; and the OTP, which serves as a one-time password to register this mobile device to the server application, which is used only once, and wherein the state of the server application exists in registrations and sessions, in which a record contains a number of fields , in particular the following: the aforementioned RegistratielD, which refers to a aforementioned registered mobile device; a PIN as an n-digit number chosen by the user during registration; OTP1 as the first candidate OTP as it may be stored in the mobile application; OTP2 as a further candidate OTP as it may be stored in the mobile application; 'Counter' as a value that counts the number of consecutive failed authentication attempts due to an incorrect PIN; "Blocked" indicating whether a registration is blocked and therefore cannot be used for authentication; "Activated" where this field indicates whether a registration has been fully completed; □ “Device Name”, which is a legible name of the registered device, where this name is displayed during the management of a user account; "Current Session", which is the SessielD of the current authentication or registration session for this mobile registration, where the server application session includes: "QRhash", which is a value that is the so-called hash of the QR tag generated for this session; "SessielD", which is a reference to this session that is used during client / server communication and in the registration data; "Status", which is a field that tells whether the session was successfully terminated; Start time which tells when the session was started, and is used to expire old sessions; "RegistrationD" which links the session to a specific registration; i.h.b. wherein the registration begins with a user already authenticated by the server application through a sufficiently trusted process, and wherein this authentication allows the user to start the registration process on the server application. i 'I System according to the preceding claim, characterized in that the Registration data is submitted in which the user's mobile application scans the QR code, decodes and processes the URL, or that the QR code is scanned by a generic QR scanner or, if displayed in a web page, clicked by the user, where the specific URL trader in the QR code starts the linkID mobile application, where the mobile application starts the registration procedure, and the mobile application shows the context to the user and asks him for a knowledge factor, in particular a PIN, to choose and confirm; after which the registration is confirmed. A system according to any one of the preceding claims, characterized in that the authentication starts with a user who is not known by the server application, said unknown user starting the authentication process on the server, the authentication process in the mobile application and the server application running because the server generates a QR code in the same way as during registration, with the submission of authentication data as follows, that the user's mobile application scans the QR code, decodes and processes the URL, whereby the QR code can be scanned by a generic QR scanner or the URL can be opened by clicking on the tag, where the mobile application starts the authentication procedure, and the mobile application shows the context to the user and asks him for his knowledge factor, in particular a PIN, to be entered, where the mobile application then connects to the server at a specified secure URL and the server checks whether the session exists and is still valid, the server checks whether the registration is activated and not blocked, and if blocked then the server stops the authentication process, whereby the server further checks whether the OTP corresponds to one of the OTP values stored in the registration, whereby if none of the OTP values matches the submitted value, the registration is then marked as blocked, and to confirmation of authentication, the mobile application then sends a final message to the server within the same session. A system according to any one of the preceding claims, characterized in that if the state of the mobile application is successfully copied and used, then the next time the original state is used the registration is blocked by the server, the server blocking registrations for which an invalid OTP has been submitted. 9. System as claimed in any of the foregoing claims, i.h.b. 2 and 3 to 8, in which a linkID mobile authentication is used, characterized in that the successive steps of the authentication process that a user follows for an authentication on a web site are the following, in which the user has already registered: - a user goes to a web site - the user clicks on log in - the web site shows a QR code 1 1 - the user scans the QR code with his linkID mobile application - the user recognizes the context on his mobile application "log in to site X" - the user enters his PIN code in the linkID mobile application - the web site reads the successful session status and allows the user to access the protected part of the web site. 10. System as claimed in any of the foregoing claims, i.h.b. 2 and 3 to 8, using a linkID mobile authentication, characterized in that the successive steps of the authentication process that a user follows for a payment on a web site are the following: - a user goes to a web site and places an order together. - the user clicks on payment - the web site shows a QR code - the user scans the QR code with his linkID mobile application - the user recognizes the context on his mobile application "Pay X euros on site Y" - the user enters his PIN code in the linkID mobile application,> - the web site reads the successful session status and uses the stored payment data of the user to pay for the order. 11. System as claimed in any of the foregoing claims, i.h.b. 2 and 3 to 8 using a linkID mobile authentication, characterized in that the successive steps of the authentication process that a user follows for a payment in a physical store are the following: - a user goes to a store counter - the cashier clicks on payment in the cash register system - the cash register system shows a QR code - the user scans the QR code with his linkID mobile application - the user recognizes the context on his mobile application “Pay X euros in store Y” - the user enters his PIN code in the linkID mobile application - the cash register system reads the successful session status and uses the stored payment data of the user to pay for the order. 12. System as claimed in any of the foregoing claims, i.h.b. 2 and 3 to 8 using a linkID mobile authentication, characterized in that the successive steps of the authentication process that a user follows for an access control to an event site are the following: - a user goes to the access control - the control system shows a QR code - the user scans the QR code with his linkID mobile application - the user recognizes the context on his mobile application "enter event X" - the user enters his PIN code in the linkID mobile application i! - the control system reads the successful session status and verifies in its database whether this user is indeed entitled to enter. 13. System for providing authenticated access to internet-supported services, i.h.b. according to claim 1, optionally 2 to 12, characterized in that it forms a united identity management system (2) centered on the user (3) to create a united identity means (23) intended for users (3) within a certain area, so that this user is in a position to use the same account to make himself known and. to authenticate this for various applications (31, 32, 33, 34; 61) if necessary from different application holders (63). System according to the preceding claim, characterized in that the user-centered management means (2) is based on a combination of validation means of agreements established between a particular service provider and owners of the internet sites involved in their capacity as suppliers, to the user (3) give access to an internet site that he visits that is subject to the management system (L) referred to if he is connected to the management system (L) concerned. System according to one of the two preceding claims, characterized in that the management system (2) is aimed at the user (3), the latter being able to access all of the aforementioned applications (31, 32, 33, 34) that are mutually different and this via a single identity field (40) that uniquely identifies said user (3), said centered linked identity management system (2) providing a unified identity field (40) of the user (3) being used for said applications (31, 32, 33, 34) at the same time and which is operated by several application holders (AA, BB). The system according to any of claims 13 to 15, characterized in that the globally united identity field (40) is introduced by the user (3), identified by said one globally united identity (40), to have access to his desired applications (31, 32, 33, 34) that are operated by agents (AA, BB). The system according to any of claims 13 to 16, characterized in that the unified identity (40) created by this system (2) consists of four different components (51, 52, 53, 54) that are all connected via the core element (L), wherein the first of the aforementioned identity constituents (51, 52, 53, 54) consists of so-called attributes (52), consisting of pieces of data assigned to the physical person who possesses the relevant identity in his capacity as user ( 3); wherein a further component consists of accessions (51) which determine in which applications (31, 32, 33, 34) the relevant identity (40) can be used and which (51) form the link between an application (31, 32, 33) , 34) and an identity (40), which regulate certain legal and confidentiality rules between a user (3) and an application (31, 32, 33, 34) that the latter wishes to address; wherein a still further component consists of authentication means (53) to be registered and used by the user (3) to authenticate itself, wherein one particular identity (40) has registered multiple authentication means (53) and finally the history component (54) wherein the user (3) has a trace of all actions around his identity (40). System according to the preceding claim, characterized in that the various authentication means (53) are used to provide access to said internet site connected to the management system (L). System according to one of claims 13 to 18, characterized in that a number of management means are provided with attributes (52) intended to determine the profile of the user (3), wherein management means thereof are provided in the management system (L) for taking out and storing said attributes (52) during the course of the process (70). A system according to the preceding claim, characterized in that the system (L) forms a standard supported management system for managing a standard supported user-directed electronic identity (40). The system according to any of claims 13 to 20, characterized in that the management system (2) brings about the uniqueness of the user (3) by means of his devices (53), wherein the core (L) prevents a physical device from being used is charged for two different accounts the identities (40) in this management system (2). System according to one of the preceding claims 13 to 21, characterized in that said attributes (52), which form the substance of the identity (40) of the user (3), are used repeatedly between different applications (31, 32, 33, 34), wherein the user (3) can check at any time which application (31, 32, 33, 34) gives access to which attribute (52). System according to one of the preceding claims 13 to 22, characterized in that said attributes (52) have certain data types, and are linked to single, if appropriate also multiple, values. The system according to any of claims 13 to 23, characterized in that said attributes (52) are assembled to form new data types. The system according to any of claims 13 to 24, characterized in that said attributes (52) are added by the operator (65) at the request of its customers, i.e. the application holders (63). The system according to any of claims 13 to 25, characterized in that in the structure of the system (2) the core element (L) thereof occupies a central position herein, wherein it communicates with various parties that are defined as end users (3) formed by physical persons who have an account and wish to use applications (61) that are linked to the core (L) of the management system (2), the end users (3) interacting with the system core (L) by by means of an interface (62), wherein a further party is formed by the applications (61) intended to perform functions consisting of certain services offered to said end users (3), making use of said core (L) ) to identify their users (3), and from web services (62) to communicate with the core (L), a still further party being formed by application holders or operators (63) that said applications (61) own and operate, and the effective customers are from a core operator (64), interacting with the core (L) through a web application that provides information about the applications they own, with an ever-increasing party being formed is by the operators (65) who manage the system software in data centers and sell the various system functions and services to the aforementioned application holders (63), thereby cooperating with the aforementioned application holders to connect their applications (61) to the management system (L) and - finally there are the device deliverers that deliver the necessary authentication means (53) to the users (3) who have their device (53) carried by the management system (2). A system according to any one of claims 13 to 26, characterized in that the system (2) performs different functions in relation to the applications (61), in particular first an authentication function, wherein in the event that an application invokes this function, the user (3) ) is authenticated by the system (2) when using one of its configured devices (53), and if this is successful, the application is notified and is currently giving access to the user (3); furthermore an attribute function, wherein an application requests the attributes (52) of the user (3) and uses the values thereof in its business operations, the attributes being read only on condition that the user (3) gives his explicit permission to do so; furthermore the data function, in which an application (31) pushes attributes (52) to the profile of the user (3), whereby these attributes are then used by other applications (32, 33, 34), provided that this is permitted by the user and the delivery application. 1 28. System for providing authenticated access to internet-supported services, i.h.b. according to one of the preceding claims in which a linkID mobile authentication is used, more i.h.b. 2 to 12, characterized in that in the authentication process an authentication flow (71) takes place which travels along an authentication path (F), wherein to be authenticated, the user (3) evolves through different stages of the flow (71), wherein delivers certain guarantees to the agent or customer application at every stage. System according to the preceding claim, characterized in that the successive steps of. the authentication process are the following: in a first step of device selection (A) the user (3) is offered to select the authentication means (53) that he wishes to use for authentication purposes, the user choosing this means (53) and wherein this means selection (A) is limited at the request of the application, then the authentication takes place (B) as required by the relevant device (53). System according to the preceding claim, characterized in that the next step is that of the agreements (C) in which a legal conformity is enforced by asking the user (3) to express his agreement against a user agreement (C), only when a new version of the user agreement is available. System according to the preceding claim, characterized in that the next step is that of the confirmation step (D) of the attributes (52) determined by said operator (65), wherein the management system (2) asks the user (3) whether it agrees with the relevant application (61) using certain attributes (52), the core (L) requesting this only once, so that in later authentication events this step (D) does not occur, except if the application attributes requirements have since been changed. System according to one of claims 29 to 31, characterized in that the last step is that of the comparison step (E) where the core (L) compares the user-defined attributes with the attributes requested by the relevant application (61), wherein some attributes are indicated as requested, where in case the user (3) does not have these attributes, the management system (L) first asks the user (3) to provide the attributes. The system according to any of claims 29 to 32, characterized in that the attribute values are provided by the user himself (3), by an application (61), by a device (53), a remote system such as a database, or also starting from a calculation of other attributes (52). The system according to any of claims 29 to 33, characterized in that an attribute is read in by an application (61) when the following conditions are met, in particular that the operator (65) gives the application access to the attribute, the user (3) authorizes the application (61) to use the attribute and finally that the attribute has a value. The system according to any of claims 29 to 34, characterized in that several authentication means (53) are dynamically supported by the management system (2), wherein new authentication elements (53) can be added without the need for a new software for the management system (2). The system according to any of claims 29 to 35, characterized in that for each authentication element (53) the management system (2) knows the location of the registration / update / deletion and authentication workflow (70), which are determined together by the management system operator (65) and the device provider (64). The system according to any of claims 29 to 36, characterized in that the implementation is provided with a signature service, wherein an application (61) can request the management system (2) to let a user (3) have a specific document or transaction sign with the use of its authentication elements (53). A system according to any one of claims 29 to 37, characterized in that when several L instances are in production in various areas, possibly under processing by different operators, the management system (2) allows users (3) to evolve between these instances, wherein users connected to one management system (2) are able to use applications connected to another L instance. The system according to any of claims 29 to 38, characterized in that the authentication system (L) is fully usable. The system according to any of claims 29 to 39, characterized in that an additional extension of the functionality of the management system (L) consists in an activation means of a particular application as a specially elaborated format in which an L application is installed on a mobile device of the user capable of running third-party applications, the aforementioned application having a distinctive sign identifying an identity provider, where when this character appears in an "L" -activated element, the user can activate this character by pressing this on his mobile device, which launches the L application and downloads interactive content related to the aforementioned element.