Method for issuing an access authorisation for an individual and verification method

Abstract

The invention relates to a method for issuing an access authorisation datum for an individual having a public key and a given attribute, implemented in an access authorisation server capable of communicating with an identification server and a client device. The access authorisation server has a rule and a secret cryptographic datum, the secret cryptographic datum being specific to a group of individuals having an attribute that is consistent with the rule. The method comprises in particular a step of obtaining an attribute of the individual and a step of determining that the attribute of the individual is consistent with the rule. If the attribute of the individual is consistent with the rule then the method comprises a step of generating an access authorisation datum for the individual, based on the secret cryptographic datum and the public key of the individual, and a step of issuing the access authorisation datum to the client device. The invention also relates to a method for verifying an access authorisation of an individual.

Description

Description Title of the invention: Method for issuing an access authorization for an individual and verification method

[0001] The invention relates to a method and device for issuing access authorization data for an individual and an associated method and device for verifying an access authorization of an individual.

[0002] Access to content, services, applications, resources, or servers of a service provider is very often controlled. In particular, access to the service provider may be authorized for one or more categories of persons based on the person's own characteristics or abilities. In other words, if the person possesses one or more specific characteristics or abilities, they are granted access. Otherwise, the person is denied access.

[0003] Access control to the service provider can be implemented in a rudimentary manner. For example, before entering a specific website, the person must simply declare that they are of legal age, enter their date of birth, or click a button such as "I am over 18 years old." This access control is therefore subject to verification based solely on the person's declaration. This control is very often anonymous and may be based on incorrect information.

[0004] Conversely, access control to the service provider can be implemented in a very sophisticated manner. For example, before logging into a service provider's website, the individual must register with the service provider and provide personal information such as their first name, last name, age, address, and provide banking or identity card information. They then receive a username and password that allow subsequent access to the service provider's website. In this case, access is not anonymous, and each connection to the website can be traced.

[0005] Another solution is to use a digital identity. This reduces the disclosure of the person's identity information and achieves the goal of proving that the person possesses one or more specific characteristics or abilities.

[0006] However, these solutions are not satisfactory for several reasons. Access control to a service provider based on characteristics specific to the individual is carried out either based on declarative information that may be erroneous or following registration with this service provider with the provision to the latter of information relating to the individual. Thus, the solutions currently available- available do not allow access to the service provider that is reliable with regard to the characteristics of the person, anonymous and untraceable.

[0007] The aim of the invention is to remedy these drawbacks and to enable, on the one hand, the delivery of access authorization data for an individual based on at least one of his attributes by an access authorization server so that the latter can then provide proof to a service provider that he has at least one attribute that satisfies the service provider.

[0008] On the other hand, the invention allows verification of an individual's access authorization, the verification being carried out anonymously and without traceability of the different accesses.

[0009] Thus, the subject of the invention is a method for issuing access authorization data for an individual having a public key and at least one given attribute, the method being implemented in an access authorization server capable of communicating with an identification server and a client device, the access authorization server having at least one given rule and a secret cryptographic data, the secret cryptographic data being specific for a group of individuals having at least one attribute conforming to said at least one given rule. The method comprising the following steps: • obtaining the individual’s public key; • obtaining said at least one attribute of the individual from the identification server; • determination of conformity of said at least one attribute of the individual obtained to said at least one given rule; • if said at least one attribute of the individual complies with said at least one given rule, generation of access authorization data for the individual from the secret cryptographic data and the public key of the individual obtained; • delivery of the generated access authorization data to the client device.

[0010] The method according to the invention allows the delivery of access authorization information to an individual if the latter possesses one or more attributes conforming to one or more rules. The access authorization information will subsequently allow the individual to prove to a service provider that he possesses one or more attributes, in a reliable and anonymous manner.

[0011] The access authorization server may further comprise public cryptographic data associated with said secret cryptographic data, the method may then further comprise a step of transmitting the public cryptographic data to the client device.

[0012] The method may further comprise a step of verifying possession of a private key of the individual by the client device associated with the public key of the individual obtained, prior to the delivery of the access authorization data.

[0013] The method may further comprise a step of obtaining a request identifier for access authorization data and a step of transmitting the request identifier for access authorization data to the identification server.

[0014] The request identifier for access authorization data may in this case include an identifier of the individual.

[0015] Alternatively, the method may further comprise a step of obtaining an identifier of the individual from the identification server or the client device.

[0016] The invention also relates to a method for verifying an access authorization of an individual having access authorization data, the access authorization data having been issued in accordance with the method described above. The method is implemented in an access authorization server capable of communicating with a service provider, the service provider implementing an access control based on at least one attribute of the individual. The access authorization server has a public cryptographic data, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule, said public cryptographic data being associated with a secret cryptographic data, said secret cryptographic data having been used to generate the access authorization data. The method comprises the following steps: • receipt of proof of access authorization information, the proof of access authorization information having been generated using the individual's access authorization data; • verification of the access authorization proof information received using the public cryptographic data; • if the access authorization proof information is verified, sending to the service provider information validating the access authorization proof information, without verifying the conformity of at least one attribute of the individual to said at least one rule given during the verification of the access authorization.

[0017] Public cryptographic data may be received from the service provider or a client device.

[0018] Proof of access authorization information may be received from the service provider or a client device.

[0019] The access authorization server may further be able to communicate with a client device. The method may then further comprise the following steps: • receipt of a verification request ID from the service provider; • generation of connection information from the verification request identifier received; • transmission to the service provider of the generated connection information • creation of a communication channel between the access authorization server and the client device using the connection information; • receiving the access authorization proof information from the client device via the created communication channel.

[0020] The access authorization server may further be capable of communicating with a client device. The method may then further comprise the following steps: • generation of verification data; • transmission of the generated verification data to the client device; • the access authorization proof information received being further generated from the verification data.

[0021] The access authorization server may be able to communicate with an evidence database, and the method may then further comprise a step of transmitting to said evidence database the received access authorization proof information.

[0022] The access authorization server may further comprise data identifying the group of individuals having at least one attribute conforming to said at least one given rule, and the step of sending to the service provider information validating the access authorization proof information may then further comprise sending the data identifying the group of individuals.

[0023] The invention also relates to a device configured to implement at least one of the methods described above.

[0024] We will now describe examples of embodiments of the present invention with reference to the appended figures where the same references designate identical or functionally similar elements from one figure to another:

[0025] [Fig-1] illustrates an example of a system in which a method of issuing access authorization data for an individual in accordance with the invention and a method of verifying an access authorization of an individual in accordance with the invention can be implemented.

[0026] [Fig.2] illustrates an embodiment of the method for issuing access authorization data for an individual in accordance with the invention.

[0027] [Fig.3] illustrates a first example of a system in which an access authorization server implements an embodiment of the method for issuing access authorization data for an individual in accordance with the invention.

[0028] [Fig.4] illustrates a second example system in which a server access authorization implements another embodiment of the method for issuing access authorization data for an individual in accordance with the invention.

[0029] [Fig.5] illustrates an embodiment of the method for verifying an individual's access authorization in accordance with the invention.

[0030] [Fig.6] illustrates a first example of a system in which an access authorization server implements an embodiment of the method for verifying an access authorization of an individual in accordance with the invention.

[0031] [Fig.7] illustrates a second example system in which an access authorization server implements another embodiment of the method for verifying an access authorization of an individual in accordance with the invention.

[0032] [Fig.8] illustrates a first example of a system in which a control server implements an embodiment of a method for determining the identity of the individual having requested verification of an access authorization.

[0033] [Fig.9] illustrates a second example system in which a control server implements an embodiment of a method for determining the identity of the individual having requested verification of an access authorization.

[0034] The present invention relates, according to a first aspect, to a secure and reliable manner of issuing access authorization data for an individual having a public key and at least one given attribute subsequently allowing anonymous and untraceable access of the individual to a service provider having access control based on attributes of the individual.

[0035] Access control based on one or more attributes of the individual authorizes access to the individual only if the individual is able to provide proof that one or more of their attributes comply with one or more rules. Such access control makes it possible to filter the individual's access to content, services, applications, resources or servers of a service provider. The issuance of access authorization data is based on at least one given attribute of the individual.

[0036] The access authorization data is generated for an individual so as to subsequently allow the latter anonymous access, therefore without having to disclose his identity and attributes. The access authorization data has a role of anonymous digital attestation certifying that the individual has at least one attribute conforming to a given rule. In particular, the invention relates to a method for issuing access authorization data for an individual having a public key and at least one given attribute, implemented in an access authorization server.

[0037] The present invention relates according to a second aspect to a secure and reliable manner of carrying out an access authorization verification of an individual wishing to access a service provider implementing access control based on at least one attribute of the individual. The verification is carried out by means of access authorization proof information generated from the access authorization data previously generated for the individual. Such an access authorization verification makes it possible to ensure that the individual actually has at least one attribute that complies with at least one given rule and therefore that he is legitimate to access the service provider. However, the verification is carried out without having to actually verify the compliance of the individual's attribute(s) with one or more given rules, compliance having been previously achieved by the issuance of the access authorization data.

[0038] Thus, it is made possible to verify an access authorization of an individual to a service provider by means of access authorization proof information generated from the individual's access authorization data, anonymously and without being able to trace the individual's connections. In particular, the invention relates to a method for verifying an access authorization of an individual having access authorization data implemented in an access authorization server.

[0039] An attribute of an individual is a characteristic of an individual, such as age, region of residence, country of residence, etc., or a capability of the individual, such as possession of a driver's license or a work permit. The attribute may also include the fact that an individual has an access account with an organization, such as a public organization, a bank, etc.

[0040] According to the invention, access authorization data is issued to an individual if an attribute of the latter complies with a given rule or if attributes of the individual comply with given rules respectively. A rule is intended to define an access criterion. For example, a rule relating to the attribute "age" may be "being over 18 years old", a rule relating to the individual's abilities may be "having a driving license".

[0041] With reference to [Fig. 1], an example of a system is described in which a method for issuing access authorization data for an individual in accordance with the invention and a method for verifying an access authorization of an individual in accordance with the invention can be implemented.

[0042] The system comprises an individual INDIV, at least one client device available to the individual DEV, an access authorization server SERV-AUTO, a service provider FRS-SERV and an identification server IDP. It may further comprise an identity support CAP of the individual INDIV and a control device CONTROL.

[0043] An individual INDIV is a user who wishes to access content, an application, a service, a server, etc. of a service provider using a client device DEV. He has an ID identifier U , at least one given attribute ATT, a key public pk u and a secret key sk uassociated. To prove that he has the attribute or attributes necessary to connect to the service provider, he will first obtain access authorization data that can be stored in a secure area of ​​the client device. Then, he will generate proof information to prove that he has access authorization for a connection to the service provider, without however disclosing to the latter his identity and his ATT attributes. In other words, he will generate proof information that must be verified to certify to the service provider that he has the attribute or attributes allowing him to connect to the latter without however the service provider having access to the identity and ATT attributes of the individual.

[0044] The client device DEV may be any type of device, such as a mobile phone, a tablet, a computer, etc., comprising a hardware and software platform on which software is executed, this software being either directly executable or interpreted on a virtual machine. The client device DEV comprises in particular a human-machine communication interface for displaying data and receiving data from the individual INDIV. This human-machine communication interface comprises for example a screen and a keyboard, or a touch screen. The client device DEV may comprise an Internet browser running on the human-machine communication interface. The client device is capable of communicating with the access authorization server SERV-AUTO, the service provider FRS-SERV and the identification server IDP. It can also communicate with the identity support CAP.For this purpose, the DEV client device is provided with communication means (wired or wireless). For example, the DEV client device may include network-type connectivity, either via a wired connection or via a wireless connection (for example, compliant with the Bluetooth standard, the NFC standard, the WIFI standard or the PC / SC standard) for communication with the CAP identity support and may include network communication means compliant with any of the Ethernet standards, and / or compliant with any of the IEEE 802.11 (Wifi) standards, and / or compliant with one or more mobile telephony standards (2G, 3G, 4G, etc.) for communication with the SERV-AUTO access authorization server, the FRS-SERV service provider and the IDP identification server.

[0045] The CAP identity support is a means of storing information specific to the individual INDIV. It may include in particular an identifier of the individual ID U, the latter's ATT attribute(s) and / or a private key sk u and a public key pk u of the individual. This could be, for example, an electronic identity card, an electronic passport or a bank card. It includes means of connectivity, in particular means of wireless communication (for example, compliant with the standard Bluetooth, NFC standard or PC / SC standard) in order to be able to communicate with a DEV client device. The CAP identity support may further comprise a function for establishing a secure communication channel enabling the creation of a secure communication channel between the CAP identity support and the DEV client device. The establishment of a secure communication channel relies on the use of security protocols. The DEV client device may also further comprise a function for establishing a secure communication channel enabling the creation of a secure channel between the DEV client device and the CAP identity support. The establishment of a secure communication channel relies on the use of security protocols.

[0046] According to an embodiment in which the system does not include a CAP identity support, the identifier of the individual ID U, the latter's ATT attribute(s) and / or a private key sk u and a public key pk u of the individual INDIV can be stored in the client device DEV, in particular in a secure memory space.

[0047] The IDP identification server comprises a hardware and software platform on which software runs. It can be used to authenticate an individual, in particular based on the latter's ID. U , and it can provide, in particular to the access authorization server, the ATT attribute(s) of the individual INDIV of which it has regular knowledge. In particular, the identification server IDP stores for a set of individuals, their identifier ID Uand one or more ATT attributes of these individuals. An IDP identification server is, for example, a government identity provider, a bank or a secure data space. The IDP identification server may include a function for establishing a secure communication channel allowing the creation of a secure channel between the IDP identification server and the DEV client device or between the IDP identification server and the SERV-AUTO access authorization server. The establishment of a secure communication channel relies on the use of security protocols. Connection to the IDP identification server requires strict authentication. For this, different technologies can be used such as OpenID, SAML, ISO 18013 or IS02020.

[0048] The ERS-SERV service provider is, for example, an application service provider or an online application provider. In other words, it may be a hosted application provider that provides software, content, or IT services to its customers via an Internet network, for example. Access to these applications is achieved, in particular, through a web browser and using a standard protocol such as the http protocol. Thus, the ERS-SERV service provider includes a hardware and software platform on which applications run in order to provide software, services, or content. Depending on the case, the service provider may want to or has an obligation to ensure that the individual who wishes to access these services, applications or content belongs to a certain category of persons, for example that the individual is an adult. In other words, in this case, the service provider implements access control based on at least one attribute of the individual. To do this, the service provider communicates with the SERV-AUTO access authorization server.

[0049] The SERV-AUTO access authorization server provides a service that delivers access authorization data to an individual and verifies an access authorization of an individual to prove the legitimacy of an individual to access a service, content, application, etc. of a service provider. The access authorization server is capable of implementing all or part of the method for delivering access authorization data for an individual or the method for verifying an access authorization of an individual in accordance with the invention. All or part of the method for delivering access authorization data for an individual and / or all or part of the method for verifying an access authorization of an individual may be implemented in software form and / or in the form of devices).The embodiments of the SERV-AUTO access authorization server described below are such that the SERV-AUTO access authorization server is capable of implementing all or part of the process for issuing access authorization information for an individual and the method for verifying an access authorization of an individual. However, according to other embodiments, the method for issuing access authorization data for an individual and the method for verifying an access authorization of an individual may be implemented in separate servers.

[0050] The SERV-AUTO access authorization server is capable of communicating with the FRS-SERV service provider and the IDP identification server using connectivity means provided by the SERV-AUTO access authorization server. The connectivity means of the SERV-AUTO access authorization server may comprise network communication means compliant with any one of the Ethernet standards, and / or compliant with any one of the IEEE 802.11 (Wifi) standards, and / or compliant with one or more mobile telephony standards (2G, 3G, 4G, etc.). It can further communicate with the DEV client device and the CONTROL control server.

[0051] The SERV-AUTO access authorization server further comprises means for executing a calculation algorithm and exchanging cryptographic keys.

[0052] A CONTROL control server may be implemented to reveal the identity of the individual who submitted access authorization proof information to the service provider. However, this server is implemented in particular in embodiments in which it is necessary to be able to find the identity of the individual who submitted access authorization proof information to the service provider.

[0053] [Fig.2] illustrates an embodiment of the method for issuing access authorization data for an individual INDIV having a public key pk u and at least one given attribute ATT in accordance with the invention. The dotted steps in the figure are optional.

[0054] The method is implemented in a SERV-AUTO access authorization server capable of communicating with an IDP identification server and a DEV client device.

[0055] The SERV-AUTO access authorization server comprises at least one given rule. It further comprises a pair of cryptographic data specific to a group of individuals having at least one attribute conforming to said at least one given rule. The pair of cryptographic data comprises a secret cryptographic data and a public cryptographic data. A group of individuals comprises a set of individuals having obtained access authorization information because the attribute(s) of these individuals conform to said at least one given rule.

[0056] The method may begin with a step of obtaining a request identifier for access authorization data (step 210). This step may result from the generation of the request identifier by the client device DEV and the access authorization service SERV-AUTO.

[0057] The request identifier for an access authorization data is for example a session identifier established between the client device and the access authorization server or an authentication code.

[0058] According to one embodiment, the request identifier for access authorization data is obtained by the generation of an identifier by the client device and the access authorization server following, for example, the exchange of messages for the creation of a communication channel.

[0059] According to a particular embodiment, the request identifier for access authorization data may comprise an identifier of the individual ID U .

[0060] The individual's ID Uis for example a personal identifier of that individual. This could be an identifier assigned by a specific organization (e.g., a government identity provider, a bank, etc.). Thus, the individual's identifier ID U may be an identification number or personal data such as a name, telephone number and / or date of birth.

[0061] Step 210 is followed by a step of obtaining the public key of the individual pk u (step 220). According to a particular embodiment, step 220 may also comprise obtaining an identifier of the individual ID U associated with the individual's public key pk u .

[0062] Step 220 may be followed by a step 230 of transmitting the request identifier for access authorization data to the IDP identification server (optional step). This step may allow the IDP identification server to initiate a authentication process with the individual, in particular by means of the DEV client device (via or not the access authorization server).

[0063] The method continues with a step 240 of obtaining at least one attribute ATT of the individual INDIV. The step 240 of obtaining at least one attribute ATT is carried out by receiving said at least one attribute of the individual INDIV transmitted directly or indirectly by the identification server IDP to the access authorization server SERV-AUTO. The attribute(s) of an individual are determined by the identification server IDP for example after authentication of the individual with the identification server IDP or from the identifier of the individual ID U .

[0064] According to a particular embodiment, the method may also comprise a step of obtaining an identifier of the individual ID Ufrom the IDP identification server, in particular in the case where the individual's ID U was not transmitted by the client device. The individual ID U is then associated with the individual's public key received.

[0065] Step 240 is followed by a step 250 of determining compliance of said at least one ATT attribute of the individual obtained with said at least one given rule of the access authorization server.

[0066] In a particular example, the individual's attribute includes the data that the individual is in possession of a driver's license and the rule defines a criterion relating to the possession of the driver's license. In this example, the individual's attribute complies with the rule since the attribute complies with the criterion.

[0067] Step 250 is followed by a step 260 of testing relating to the conformity of said at least one attribute ATT of the individual to said at least one given rule. If the test is negative, step 260 is followed by a step 270 of ending the method and no access authorization data is generated and delivered to the individual. If, on the contrary, the test of step 260 is positive, then step 260 is followed by a step 280 of generating access authorization data for the individual from the secret cryptographic data and the public key of the individual pk u obtained.

[0068] In the embodiment in which the access authorization server has obtained the individual's identifier ID U , the access authorization data for the individual is further generated from the individual's ID U .

[0069] Step 280 is then followed by a step 290 of delivering the generated access authorization data to the client device DEV. This step comprises, for example, sending the generated access authorization data to the client device.

[0070] The delivery method may further comprise a step of transmitting the public cryptographic data to the client device DEV.

[0071] According to one embodiment, prior to the step of issuing the generated access authorization data, the method may further comprise a step of verifying fication of possession of the private key sk u by the individual, in particular by the individual's client device, associated with the individual's public key pk uobtained and used for the generation of the access authorization data. This step allows the access authorization server to ensure that the generated access authorization data is delivered to the individual possessing the public key used for the generation of the access authorization data.

[0072] According to a particular embodiment in which the access authorization server has obtained the identifier of the individual ID U , the method further comprises a step of storing in a database of individuals BD-INDIV, the identifier of the individual ID U and the public key pk u of this individual. The database of individuals can be stored on a server separate from the access authorization server.

[0073] According to another particular embodiment of the method for issuing access authorization data for an individual, the identifier of the individual ID Uis not provided to the access authorization server.

[0074] [Fig.3] illustrates a first example of a system comprising an access authorization server SERV-AUTO which implements a particular embodiment of the method for issuing access authorization data for an individual having a public key pk u and at least one given attribute ATT in accordance with the invention.

[0075] The system illustrated in [Fig.3] includes, in addition to the SERV-AUTO access authorization server, a DEV client device and an IDP identification server.

[0076] The SERV-AUTO access authorization server comprises at least one given rule. It further comprises a pair of cryptographic data specific to a group of individuals having at least one attribute conforming to said at least one given rule. The pair of cryptographic data comprises a secret cryptographic data and a public cryptographic data. A group of individuals comprises a set of individuals having obtained access authorization information because the attribute(s) of these individuals conform to said at least one given rule.

[0077] The client device DEV is, for example, a mobile phone. The individual INDIV may also be provided with an identity support CAP including in particular the public key pk u of the individual. The CAP identity support may also include an identifier of the individual ID U associated with the public key pk uof the individual. The DEV client device includes means of communication with the CAP identity support.

[0078] According to another embodiment, the public key pk u of the individual can be stored on the DEV client device.

[0079] According to the illustrated system, the access authorization server obtains a request identifier of an access authorization data (step 310). This step may comprise the exchange of messages between the access authorization server SERV-AUTO and the client device DEV allowing the generation and obtaining of a request identifier for access authorization data. This step results in the access authorization server SERV-AUTO obtaining a request identifier for access authorization data in accordance with step 210 previously described in the support of [Fig.2],

[0080] According to a particular embodiment, the request identifier for access authorization data further comprises an identifier of the individual ID U .

[0081] In step 310, the access authorization server SERV-AUTO obtains the public key of the individual pk u (in accordance with step 220 described previously in support of [Fig.2]). In particular, the client device can send the public key of the individual pk u to the SERV-AUTO access authorization server.

[0082] According to a particular embodiment, during step 310, the access authorization server SERV-AUTO can also obtain the identifier of the individual ID U .

[0083] Step 310 may be followed by a step of transmission by the access authorization server SERV-AUTO of the request identifier for access authorization data to the identification server IDP (step 320 which complies with step 210 previously described in the support of [Fig.2]).

[0084] According to another embodiment, step 320 is a step of creating a secure communication channel between the access authorization server SERV-AUTO and the identification server IDP.

[0085] According to the illustrated embodiment, step 320 is followed by an authentication phase by the individual with the IDP identification server, for example by means of the client device.

[0086] For this, according to a first embodiment illustrated in [Fig. 3], the identification server IDP communicates with the client device DEV so that the individual authenticates himself (step 330). This is possible in particular when the request identifier for access authorization data received by the identification server IDP includes the identifier of the individual ID U .

[0087] According to another embodiment, the authentication of the individual can be carried out via the access authorization server, the latter then having a proxy role.

[0088] According to yet another embodiment, the individual authenticates himself with the identification server IDP by means of his client device DEV prior to step 310 then the client device transmits to the access authorization server, the identifier of the individual ID U authenticated.

[0089] Following authentication of the individual with the IDP identification server, the latter transmits to the access authorization server SERV-AUTO at least one ATT attribute of the individual (step 340). Thus, the access authorization service SERV-AUTO obtains at least one ATT attribute of the individual from the identification server IDP in accordance with step 240 previously described in support of [Fig.2].

[0090] According to a particular embodiment, the IDP identification server transmits to the SERV-AUTO access authorization server at least one ATT attribute of the individual via the DEV client device.

[0091] According to a particular embodiment, the access authorization server can further obtain from the identification server an identifier of the individual ID U .

[0092] Step 340 is followed by a step 350 during which the access authorization server SERV-AUTO will determine the conformity of said at least one attribute ATT of the individual obtained to said at least one given rule in accordance with step 250 described in the support of [Fig. 2]. If said at least one attribute ATT of the individual conforms to said at least one given rule, the access authorization server SERV-AUTO generates access authorization data for the individual from the secret cryptographic data and the public key of the individual pk u obtained, in accordance with steps 260 and 280 previously described in support of [Fig.2].

[0093] In the embodiment in which the access authorization server has obtained the individual's identifier ID U , the access authorization data for the individual is further generated from the individual's ID U .

[0094] Step 350 is followed by a step 360 of delivery by the access authorization server SERV-AUTO of the access authorization data generated to the client device DEV in accordance with step 290 previously described in the support of [Fig.2]. For this, the access authorization server SERV-AUTO sends a message to the client device DEV containing the access authorization data generated.

[0095] According to a particular embodiment, the step of issuing the access authorization data is preceded by a step of verifying possession of the private key sk u by the individual, in particular by the individual's client device, associated with the individual's public key pk u obtained. This step allows the access authorization server to verify, before communicating the access authorization data to the client device, that the latter has the individual's secret key.

[0096] In the particular embodiment in which the access authorization server has obtained the individual's identifier ID U , the access authorization server may further comprise a step of storing in a database of individuals BD-INDIV, the identifier of the individual ID U and the public key of this individual pk u . Other additional information relating to the individual may also be stored in the BD-INDIV individual database. The BD-INDIV individual database may be stored on a server separate from the access authorization server.

[0097] [Fig.4] illustrates a second example of a system comprising a SERV-AUTO access authorization server which implements another embodiment of the method for issuing access authorization data for an individual. in accordance with the invention and described in support of [Eig.2].

[0098] Only the steps that differ from those of the first example system described in the support of [Fig. 3] will be described in detail below. For the rest, reference is made to the first example described in the support of [Fig. 3].

[0099] The access authorization server includes at least one given rule.

[0100] In this example system, the individual understands a key pair, namely a private key sk u and a public key pk u stored for example on a client device DEV or in an identity medium CAP and the control server CONTROL includes a secret disclosure key sk o and a public disclosure key pk o

[0101] The public disclosure key pk o from the control server CONTROL is transmitted to the access authorization server SERV-AUTO (step 400).

[0102] Following receipt of the public disclosure key pk ocoming from the control server CONTROL, the access authorization server SERV-AUTO will generate a specific cryptographic data pair for a group of individuals having at least one attribute conforming to said at least one given rule. The cryptographic data pair comprises a public cryptographic data Gpk and a secret cryptographic data sk m .

[0103] In the example embodiment illustrated in [Eig.4], the public cryptographic data Gpk comprises at least one public master key pk m and the public disclosure key pk o received from the CONTROL control server.

[0104] According to another embodiment in which the system does not include a control server CONTROL, the access authorization server includes a specific cryptographic data pair for a group of individuals having at least one attribute conforming to said at least one given rule. The cryptographic data pair includes, on the one hand, a public cryptographic data Gpk composed of a public master key pk m and on the other hand, a secret cryptographic data sk m .

[0105] The public cryptographic data Gpk can then be transmitted to the DEV client device.

[0106] According to the illustrated system, the access authorization server obtains a request identifier for an access authorization data item (step 410) in accordance with step 210 previously described in support of [Eig.2].

[0107] According to a particular embodiment, the request identifier for access authorization data (step 410) can be determined by the client device in particular from the secret key sk u of the individual and the received public cryptographic data Gpk. It can further be determined from the individual's identifier ID U The request identifier of an access authorization data is then transmitted by the client device and received by the access authorization server.

[0108] In step 410, the access authorization server SERV-AUTO obtains the key public of the individual pk u (in accordance with step 220 described previously in support of [Fig.2]). In particular, the client device can send the public key of the individual pk u to the SERV-AUTO access authorization server.

[0109] Step 410 is then followed by steps 320 to 340 previously described.

[0110] At the end of step 340, the access authorization server SERV-AUTO will determine the conformity of said at least one ATT attribute of the individual obtained to said at least one given rule in accordance with step 240 described previously in support of [Fig.2]. If said at least one ATT attribute of the individual conforms to said at least one given rule, the access authorization server SERV-AUTO generates access authorization data for the individual gsk u from the secret cryptographic data sk m and the public key of the individual pk u obtained, in accordance with steps 260 and 280 previously described in support of [Fig.2].

[0111] Step 450 is followed by a step 46O.a of issuing the access authorization data gsk u generated, to the DEV client device.

[0112] In the embodiment in which the access authorization server has received the individual's identifier ID U step 450 may also be followed by a step 46O.b of storage by the access authorization server, in a database of individuals BD-INDIV of the identifier of the individual ID U and the public individual key pk u of that individual. Other additional information relating to the individual may also be stored in the BD-INDIV individual database. The BD-INDIV individual database may be stored on a server separate from the access authorization server.

[0113] [Fig.5] illustrates an embodiment of a method for verifying an access authorization of an individual having an access authorization data item implemented in a SERV-AUTO access authorization server in accordance with the invention. The access authorization data item was issued in accordance with the method for issuing an access authorization data item previously described.

[0114] The SERV-AUTO access authorization server is capable of communicating with a FRS-SERV service provider implementing access control based on at least one attribute of the individual.

[0115] The SERV-AUTO access authorization server comprises public cryptographic data, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule. The public cryptographic data is associated with secret cryptographic data, said secret cryptographic data having been used to generate the individual's access authorization data.

[0116] According to a particular embodiment, the public cryptographic data may be received by the access authorization server and come from the service provider. FRS-SERV. According to another embodiment in which the access authorization server SERV-AUTO is able to communicate with a DEV client device of the individual, the public cryptographic data can be received by the access authorization server and come from the DEV client device.

[0117] The SERV-AUTO access authorization server implementing the method for verifying an access authorization may be the same server as that implementing the method for issuing access authorization information or a separate server.

[0118] The method of verifying an access authorization may follow the method of issuing access authorization data previously described in support of [Fig.2] and the following figures.

[0119] The purpose of the access authorization verification method is to verify that the individual has access authorization to access a service provider implementing access control based on at least one attribute of the individual, without verifying the conformity of the individual's attribute(s) to one or more rules given during the access authorization verification. Furthermore, the verification also does not use an identifier of the individual.

[0120] Thus, this method allows access control of an individual to a service provider implementing access control based on at least one attribute of the individual while guaranteeing anonymous and untraceable access of the individual.

[0121] Non-traceability means not being able to identify different accesses from the same individual to the service provider. In other words, the system and the service provider cannot determine whether two separate accesses belong to the same individual (or not).

[0122] According to this method, the individual must provide proof that one or more of his attributes comply with one or more rules, the rules defining the criteria for the access control of the service provider. For this, the proof is an access authorization proof information generated by the client device using the access authorization data previously issued to it.

[0123] Furthermore, according to the verification method according to the invention, the ATT attribute(s) of the individual are not communicated to the service provider. However, if the access authorization proof information is validated by the verification method, the service provider implementing access control based on at least one attribute of the individual only knows that the rule(s) relating to one or more ATT attributes of the individual are respected.

[0124] As illustrated in [Fig.5], the method of verifying an access authorization of an individual having access authorization data begins with a step of receiving access authorization proof information (step 510). The proof information access authorization information was generated using the individual's access authorization data, including by the individual's client device. The access authorization proof information may reach the access authorization server from the service provider or the individual's client device.

[0125] This step may be preceded by a step of generating verification data c by the access authorization server, a step of transmitting the generated verification data to the client device DEV. In this case, the access authorization proof information received may also be generated from the verification data.

[0126] Step 510 is followed by a step 520 of verifying the access authorization proof information received using the public cryptographic data.

[0127] Step 520 is followed by a step 530 of testing the verification of the access authorization proof information. If the access authorization proof information could not be verified, then step 530 is followed by step 540 during which the access authorization server can indicate to the service provider that the access authorization proof information is invalid.

[0128] If, on the contrary, the access authorization proof information could be verified, in other words the access authorization proof information is valid, then step 530 is followed by a step 550 of sending to the ERS-SERV service provider information validating the access authorization proof information. Thus, during the verification of the access authorization, the access authorization server does not carry out a verification of the conformity of the attribute(s) of the individual to one or more given rules. Furthermore, the access authorization server does not use an identifier of the individual to carry out the verification of the access authorization.

[0129] According to a particular embodiment, the access authorization server further comprises data identifying the group of individuals having at least one attribute conforming to said at least one given IdToken rule. According to this embodiment, the step of sending to the FRS-SERV service provider information for validating the access authorization proof information further comprises sending the data identifying the group of IdToken individuals.

[0130] [Fig.6] illustrates a first example of a system comprising a SERV-AUTO access authorization server which implements a particular embodiment of the method for verifying an individual's access authorization in accordance with the invention.

[0131] The individual has access authorization data previously issued in accordance with the method for issuing access authorization data described in particular in the support of [Fig.2].

[0132] The SERV-AUTO access authorization server includes a crypto- public graph, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule. The public cryptographic data is associated with a secret cryptographic data, said specific secret cryptographic data having been used to generate the individual's access authorization data.

[0133] According to a particular embodiment, the public cryptographic data is stored in the access authorization server. According to another embodiment, the public cryptographic data is received by the access authorization server of the service provider FRS-SERV. According to yet another embodiment, the public cryptographic data is received by the access authorization server of the client device DEV.

[0134] The system illustrated in [Fig. 6] comprises, in addition to the access authorization server SERV-AUTO, a service provider FRS-SERV, an identification server IDP or a server comprising a database BD-PREUVES and one or more client devices DEVI, DEV2 of an individual INDIV. [Fig. 6] illustrates a particular system in which the individual INDIV has a first client device DEV 1 and a second client device DEV2 which may be, for example, a laptop and a mobile phone. In the illustrated system, the access authorization data of the individual is, for example, stored in the second client device DEV2. However, according to another embodiment of the system, the first client device DEV 1 and the second client device DEV2 are the same client device.

[0135] When the individual INDIV wishes to access, for example, content, an application or a service, etc. of a service provider implementing access control based on at least one attribute of the individual, he can use an internet browser to achieve such access (step 610).

[0136] The service provider must then verify that the individual has one or more attributes allowing access. To do this, the FRS-SERV service provider can communicate, in particular securely using a secure communication channel created for example using the OpenID CIBA protocol, with the SERV-AUTO access authorization server in order to verify that the individual has access authorization to the service provider (step 620).

[0137] A verification request identifier SessionID is then received by the access authorization server SERV-AUTO during step 620. The reception of the verification request identifier may be preceded by a step of generation of the verification request identifier by the service provider and the access authorization server.

[0138] The access authorization server can then generate login information from the received verification request identifier and transmit the login information connection generated to the service provider.

[0139] According to the embodiment illustrated in [Fig.6], the service provider transmits to the client device, for example to the first client device DEV1, the connection information that it has received (step 630).

[0140] The connection information can be, for example, a QR Code which will be displayed on the display screen of the first client device DEV1.

[0141] According to an exemplary embodiment, the individual scans the QR Code displayed on the first client device DEV1 using the second client device DEV2 (step 640). A communication channel between the access authorization server and the client device, in particular the second client device DEV2, is then created using the connection information.

[0142] The second client device DEV2 then generates proof of access authorization information, the proof of access authorization information being generated by means of the individual's access authorization data stored for example in the second client device DEV2.

[0143] The access authorization server SERV-AUTO will then receive the access authorization proof information generated as previously described in step 510 on the support of [Fig.5].

[0144] The access authorization server receives the proof information from the individual's second client device as illustrated in [Fig.6] (step 650) via the created communication channel.

[0145] According to another embodiment in which no communication channel between the access authorization server SERV-AUTO and the client device DEV is created, the client device, for example the first client device DEV 1, can transmit the access authorization proof information to the access authorization server via the service provider. In this embodiment, the access authorization proof information is generated on one of the client devices DEV1 or DEV2 by means of the individual's access authorization data stored for example on the second client device DEV2.

[0146] According to a particular embodiment, the access authorization server can send the received access authorization proof information to the identification server IDP or to an evidence database BD-PREUVES in order to store the received access authorization proof information (step 650.a). In addition to the evidence information, the access authorization server can also send the verification request identifier SessionID and / or the date and time of receipt of the access authorization proof information in order to be stored. Additional data used for example for generating the access authorization proof information can also be stored in the database of evidence.

[0147] The access authorization server verifies the received access authorization proof information using the public cryptographic data as previously described in step 510.

[0148] If the access authorization proof information is verified, then the access authorization server sends to the FRS-SERV service provider information validating the access authorization proof information (step 660) as previously described with regard to step 530 of [Fig. 5]. When verifying the access authorization of the individual, the access authorization server does not verify the conformity of the attribute(s) of the individual to one or more given rules. Furthermore, the access authorization server does not use the identifier of the individual.

[0149] According to a particular embodiment, the access authorization server further comprises data identifying the group of individuals having at least one attribute conforming to said at least one given IdToken rule. According to this embodiment, the step of sending to the FRS-SERV service provider information for validating the access authorization proof information further comprises sending the data identifying the group of IdToken individuals.

[0150] Following receipt of the validation information of the access authorization proof information by the service provider, the latter allows access to the service provider (step 670).

[0151] According to a particular embodiment, the access authorization server can receive the public cryptographic data from the FRS-SERV service provider or the DEV client device in order to carry out the verification of the access authorization proof information.

[0152] [Fig.7] illustrates a second example of a system comprising an access authorization server SERV-AUTO which implements another embodiment of the method for verifying an access authorization of an individual having access authorization data in accordance with the invention. The access authorization data gsk u of this example was generated according to the embodiment of the delivery method described in the support of [Fig.4].

[0153] Only the steps that differ from those of the first example system described in [Fig. 6] will be described in detail below. For the rest, reference is made to the first example described in support of [Fig. 6].

[0154] In this exemplary embodiment, the access authorization server includes a public cryptographic data Gpk. The public cryptographic data is specific for a group of individuals having at least one attribute conforming to at least one given rule. The public cryptographic data is associated with a secret cryptographic data sk m . The said secret cryptographic data was used for generate the access authorization data as described in the embodiment illustrated in [Fig.4].

[0155] The public cryptographic data Gpk includes at least one public master key pk m . The public cryptographic data Gpk may further include a public disclosure key pk o .

[0156] According to a particular embodiment, the public cryptographic data is stored in the access authorization server. According to another embodiment, the public cryptographic data is received by the access authorization server of the service provider FRS-SERV. According to yet another embodiment, the public cryptographic data is received by the access authorization server of the client device DEV.

[0157] As illustrated in [Fig.7], the access authorization proof information o is generated by the client device using a signature algorithm having as parameter the access authorization data gsk u and a verification data c to be signed generated by the access authorization server and transmitted to the client device. The verification data is for example a random or semi-random number.

[0158] In the illustrated embodiment, the access authorization proof information is generated on one of the client devices DEV1 or DEV2 by means of the access authorization data gsk u the individual stored for example on the second client device DEV2.

[0159] The access authorization proof information is then verified by the access authorization server by means of a signature verification algorithm having as parameters, the access authorization proof information o, the verification data c and the public cryptographic data Gpk (step 750).

[0160] According to a particular embodiment, the access authorization server can send the access authorization proof information o received to the identification server IDP or to an evidence database BD-PREUVES in order to store the access authorization proof information o received (step 75O.a). In addition to the evidence information, the access authorization server can also send the verification request identifier SessionID, the date and time of receipt of the access authorization proof information o in order to be stored. Additional data used for example for generating the access authorization proof information can also be stored in the evidence database, such as the verification data c.

[0161] [Fig.8] illustrates a first example of a system in which a CONTROL control server determines the identity of the individual who requested verification of an access authorization.

[0162] The CONTROL control server can in fact implement a de- Termination of an individual's identifier from access authorization proof information provided to the service provider and stored in a BD-PREUVES evidence database. The BD-PREUVES evidence database stores the various access authorization proof information submitted by individuals to the service provider to show that they are legitimate to access the service provider. In addition, for each stored proof information o, the verification request identifier SessionID and the verification data c are associated. The date and time of receipt of the access authorization proof information by the access authorization server can also be stored for each stored proof information.

[0163] The BD-PREUVES evidence database can be stored on the IDP identification server.

[0164] The system further comprises a database of individuals BD-INDIV storing the identifier ID U individuals who have requested access authorization data from the access authorization server. Each individual's identifier is associated with the public key pk u of the latter.

[0165] The method for determining an individual's identifier implemented in the CONTROL control server aims to lift the anonymity of the individual who has requested verification of an access authorization.

[0166] The method for determining an individual's identifier begins with a step of receiving a request for determining an individual's identifier (step 810) and a step of receiving a SessionID verification request identifier from the FRS-SERV service provider (step 820). The SessionID verification request identifier identifies a session between the FRS-SERV service provider and the SERV-AUTO access authorization server so that the latter verifies information proving an individual's access authorization.

[0167] From the verification request identifier SessionID, the control server performs a search in the evidence database BD-PREUVES in order to identify the stored access authorization proof information o and the associated verification data c (step 830).

[0168] Step 830 is followed by a step 840 of determining the identifier of the individual from the access authorization proof information o and the verification data c. To do this, the control server first determines the public key of the individual pk u . Then, from the determined public key pk u , the control server performs a search in the BD-INDIV individual database for the individual ID identifier U having the public key pk u determined.

[0169] Step 840 is followed by step 850 of sending the individual's identifier ID U determined.

[0170] [Fig.9] illustrates a second example of a system in which a control server determines the identity of the individual who requested verification of an access authorization.

[0171] Only the steps that differ from those of the first example system described in [Fig. 8] will be described in detail below. For the rest, reference is made to the first example described in support of [Fig. 8].

[0172] According to this embodiment, the control server CONTROL comprises a secret disclosure key sk o and a public disclosure key pk o Furthermore, the access authorization server is as described in [Fig.4] and [Fig.7] and comprises a public cryptographic data Gpk. The public cryptographic data Gpk is specific for a group of individuals having at least one attribute conforming to at least one given rule. Said public cryptographic data is associated with a secret cryptographic data sk m . The public cryptographic data Gpk includes a public master key pk m and a public disclosure key pk o, the public disclosure key being the public key of the CONTROL control server.

[0173] The BD-INDIV individual database stores the ID identifier U individuals having requested access authorization data from the access authorization server according to the embodiment described in support of [Eig.4]. For each ID identifier U of individual is associated the public key pk u of the latter.

[0174] In addition, the BD-PREUVES evidence database includes the various access authorization evidence information o submitted by individuals to the service provider to show that they are legitimate to access the service provider as described in support of [Eig.7]. In the BD-PREUVES evidence database, for each stored evidence information o, the verification request identifier SessionID and the verification data c are associated. The date and time of receipt of the access authorization evidence information by the access authorization server may also be stored for each stored evidence information.

[0175] The method for determining an individual's identifier implemented in the CONTROL control server aims to lift the anonymity of the individual who has requested verification of an access authorization.

[0176] The method for determining the identifier of an individual begins with steps 810 and 820 previously described in support of [Eig.8]. In addition, the method continues at step 925 by the control server obtaining the public cryptographic data Gpk, originating from the access authorization server SERV-AUTO. The method continues at step 830 previously described in support of [Eig.8].

[0177] According to this embodiment, at the end of steps 820, 925 and 830, the control server CONTROL has obtained the public cryptographic data Gpk, the data of verification c, and the access authorization proof information o. From the secret disclosure key sk o and from the data and information obtained, the control server CONTROL determines the public key of the individual pk u who generated the access authorization proof information o.

[0178] The method then continues at step 840 previously described in support of [Fig.8] during which, from the determined public key pk u , the CONTROL control server will search the BD-INDIV individual database for the individual ID U having the public key pk u determined.

[0179] Step 840 is followed by step 850 of sending the individual's identifier ID U determined.

Claims

Claims

1. Method for issuing access authorization data for an individual having a public key (pk u ) and at least one given attribute (ATT), the method being implemented in an access authorization server (SERV-AUTO) capable of communicating with an identification server (IDP) and a client device (DEV), the access authorization server (SERV-AUTO) having at least one given rule and a secret cryptographic data item, the secret cryptographic data item being specific for a group of individuals having at least one attribute conforming to said at least one given rule, the method comprising the following steps: • obtaining the individual's public key (pk u ) (step 220); • obtaining said at least one attribute (ATT) of the individual from the identification server (IDP) (step 240); • determination of conformity of said at least one attribute (ATT) of the individual obtained to said at least one given rule (step 250); • if said at least one attribute (ATT) of the individual complies with said at least one given rule, generation of access authorization data for the individual from the secret cryptographic data and the public key of the individual (pk u ) obtained (steps 260, 280); • delivery of the generated access authorization data to the client device (DEV) (step 290).

2. Method according to the preceding claim, characterized in that the access authorization server further comprises public cryptographic data associated with said secret cryptographic data, and in that the method further comprises a step of transmitting the public cryptographic data to the client device (DEV).

3. Method according to any one of the preceding claims, characterized in that the method further comprises a step of verifying the possession of a private key of the individual (sk u ) by the client device associated with the individual's public key (pk u ) obtained, prior to the issue of the access authorization data.

4. Method according to any one of the preceding claims, characterized in that the method further comprises a step of obtaining a request identifier for access authorization data (step 210) and a step of transmitting the request identifier for access authorization data to the identification server (IDP) (step 230).

5. Method according to the preceding claim, characterized in that the request identifier for access authorization data comprises an identifier of the individual (ID U ).

6. Method according to any one of claims 1 to 4, characterized in that the method further comprises a step of obtaining an identifier of the individual (ID U ) from the identification server (IDP) or the client device (DEV).

7. A method for verifying an access authorization of an individual having access authorization data, the access authorization data having been issued in accordance with the method according to any one of claims 1 to 6, the method being implemented in an access authorization server (SERV-AUTO) capable of communicating with a service provider (FRS-SERV), the service provider implementing access control based on at least one attribute of the individual, the access authorization server (SERV-AUTO) having public cryptographic data, the public cryptographic data being specific for a group of individuals having at least one attribute conforming to at least one given rule, said public cryptographic data being associated with secret cryptographic data, said secret cryptographic data having been used to generate the access authorization data, the method comprising the following steps: • receiving access authorization proof information, the access authorization proof information having been generated by means of the individual's access authorization data (step 510); • verification of the access authorization proof information received using the public cryptographic data (step if the access authorization proof information is verified, sending to the service provider (FRS-SERV) information validating the access authorization proof information, without verifying the conformity of at least one attribute of the individual to said at least one rule given during the verification of the access authorization (steps 530, 550).

8. Method according to the preceding claim, characterized in that the public cryptographic data is received from the service provider (FRS-SERV) or from a client device (DEV).

9. Method according to claim 7 or 8, characterized in that the access authorization proof information is received from the service provider (FRS-SERV) or from a client device (DEV).

10. Method according to claim 7 or 8, characterized in that the access authorization server is further capable of communicating with a client device (DEV), and in that the method further comprises the following steps: receiving a verification request identifier (SessionID) from the service provider (FRS-SERV); generating connection information from the received verification request identifier; transmitting to the service provider (FRS-SERV) the generated connection information; creating a communication channel between the access authorization server (SERV-AUTO) and the client device (DEV) by means of the connection information; receiving the access authorization proof information from the client device (DEV) via the created communication channel.

11. Method according to any one of claims 7 to 10, characterized in that the access authorization server is further capable of communicating with a client device (DEV), and in that the method further comprises the following steps: • generation of verification data (c); transmitting the generated verification data to the client device (DEV); the received access authorization proof information being further generated from the verification data.

12. Method according to any one of claims 7 to 11, characterized in that the access authorization server (SERV-AUTO) is capable of communicating with an evidence database (BD-PREUVES), and in that the method further comprises a step of transmitting to said evidence database (BD-PREUVES) the access authorization proof information received.

13. Method according to any one of claims 7 to 12, characterized in that the access authorization server further comprises data identifying the group of individuals having at least one attribute conforming to said at least one given rule (IdToken), and in that the step of sending to the service provider (FRS-SERV) information validating the access authorization proof information further comprises sending the data identifying the group of individuals (IdToken).

14. A device configured to implement the method according to any one of claims 1 to 6 or the method according to any one of claims 7 to 13.

Images