Patent Application
20240414163
The present invention relates to an access management system for controlling access to an electronic resource. Associated computer-implemented methods are also provided.
When a user wishes to register for a new service, such as an internet forum, a website, or a new product, the service provider invariably requires that the user registers a new account. Generally, this requires the user to provide a personal (valid) email address, a suitable username, and a password. Often, the user must also receive an authentication code via email. The user must then remember the username and password for subsequent access. Often, the user also needs to provide a valid mobile phone number, credit card details, and even a copy of their ID or proof of address. This is cumbersome for the user and the service provider, and is requires that the user expose their personal data. This is undesirable for privacy regulations, and also represents a liability for the service provider.
Alternatives have been provided to this “traditional” approach. Universal logins, such as the familiar “Login with Facebook” or “Login with Google” are offered by many websites nowadays. This partially solves the problem by invoking a trusted third party, and these systems are often designed with advanced privacy-preserving techniques (e.g. zero-knowledge, remote attestation). However, the systems still rely on a central authority to work, which comes with its own disadvantages. For example, if the Google authenticator portal is offline, a user cannot access the service in this manner even if the service is available. Also, this approach enforces a systemic reliance on these third parties, which then become a single point of failure, often for critical services and without proper regulatory oversight. Most importantly, these alternative systems:
These systems fail to address the question of why the service provider should always be in control of the identity of the user requesting a service. This is not the case for most everyday real-world services: we do not have to provide ID when buying food at a supermarket; when buying alcohol, we only have to provide ID as a proof of age—our other data is irrelevant, and is not stored. Generally, a service provider cares only about whether a user is paying for the service, and their personal information is incidental.
The present invention aims to address these issues.
Furthermore, it is well-known to users and service providers alike that the value of a certain service can fluctuate over time as a consequence of supply vs. demand. However, it is highly non-trivial for the service provider to adjust pricing in real time while giving reliable guarantees of service availability to paying customers. For example, if a customer pays upfront a yearly membership fee for accessing a certain resource, but then the price of the resource increases due to market fluctuations, the service provider is at a loss. Likewise, if the price drops, the customer is at a loss. One possible solution that has been adopted for certain services is that of using a prepaid account: the customer deposits a certain amount of funds, and those funds are depleted over time at a rate which is dependent on the market value of the resource. However, unlike normal deposits, for prepaid bill accounting systems, there is no way for a user to recoup leftover funds if they decide to cancel the subscription before it ends.
Certain aspects of the present invention aim to address this issue as well.
At a high level, the present invention addresses the problems outlined above by providing systems and methods in which, when a request is validated, a user's public key (or information identifying the public key) is placed on a list of authorized public keys, wherein users whose public keys are on the list are permitted to access the an electronic resource. Further aspects of the invention provide systems and methods which are modified to enable an auction capability which addresses the issues associated with the variations in cost of a resource. These are discussed later in this application.
An access management system for controlling access to an electronic resource, the electronic resource accessible at a resource address, and provided by a service provider having associated therewith an electronic provider address, the system comprising: a request management module, configured to determine whether a registration request received at the electronic provider address is a valid registration request, wherein: the registration request includes a public key or data identifying the public key, associated with a client device or user thereof from which the registration request is received; an authorized client management module configured to add the public key of the user, or data identifying the public key, to an authorized list, if the request management module determines that the registration request is a valid registration request, wherein: when a public key or data identifying the public key of the client device is on the authorized list, the client device or user thereof is permitted to access the electronic resource. Herein, the public key referred to above may be a public verification key which is used to identify the user through validation of a signature generated using a private signature key of the user (or client device). In some cases, the public key referred to here may be a public encryption key which is used to encrypt a session key (discussed in detail later on in this application). This is discussed in more detail later on.
Throughout this application, where we refer to a “client device”, this should be understood to mean “a client device or a user thereof”. Similarly, where we refer to a “public key ID”, this should be understood to mean “a public key or data identifying the public key”. These abbreviations are used to improve the clarity and conciseness of the follow disclosure.
In this way, no personal information related to a user of a client device, who wishes to access the electronic resource, is ever transmitted or stored. This enables a user to access an electronic resource, such as an online resource, without risk of their personal data being obtained by malicious actors.
In some cases, the electronic provider address may be a blockchain address. Specifically, the electronic provider address may be an address of a blockchain wallet, to which funds may be transferred, which is associated with the service provider. In particularly preferred case, the transaction would me made using a cryptocurrency with anonymity features, further adding to the security provided by the invention. An example of a cryptocurrency which may be used in implementations of the present invention is Monero. In some cases, particularly those cases which involve transferring funds using a blockchain, the registration request preferably includes a signature which is generated using a private signature key associated with the client device from which the registration request is received. This may be done so that the request management module or management software of the blockchain wallet is able to confirm that the user who sends the registration request to the electronic provider address is indeed who they claim to be. In these cases where the registration request is in the form of a blockchain transaction, the public verification key is preferably included in the request (i.e. the public verification key which is complementary to the private key which is used to generate the signature). It is this public verification key (or a related ID thereof) which may be added to the authorized list, if it is determined that the registration request is a valid request. This is convenient, because it means that unique identification can be stripped straight from the registration request when it is determined that it is valid, without requiring any personal information about the user. The user's personal information therefore remains entirely secure.
In some cases, the registration request may further include a public encryption key associated with the client device. In these cases, when data is encrypted using the public encryption key associated with the client device, it may be decrypted using a private decryption key to which only the client device in question has access.
We now consider how the validation process takes place. Specifically, the request management module may be configured to determine whether the registration request received at the electronic provider address meets a validation criterion, wherein: if the request management module determines that the request received at the electronic provider address meets the validation criterion, it is determined that the request is a valid request; and if the request management module determines that the request received at the electronic provider address does not meet the validation criterion, it is determined that the request is not a valid request. In some cases, the request management system may be configured to determine whether a quantity associated with the registration request received at the electronic provider address is greater than or equal to a predetermined value, wherein: if the request management system determines that the quantity associated with the registration request received at the electronic provider address is greater than or equal to the predetermined value, it is determined that the registration request is a valid registration request; and if the request management system determines that the quantity associated with the registration request received at the electronic provider address is less than the predetermined value, it is determined that the registration request is not a valid registration request. In these cases, the validation criterion is that the quantity associated with the registration request is greater than or equal to the predetermined value. Systems according to this example are useful in enabling commercial transactions, e.g. via a blockchain, as discussed above.
The access management system may not only be configured to process a single registration request. Specifically, the request management module may be configured to determine whether each request of a plurality of registration requests received at the electronic provider address is a valid registration request, each of the registration requests including a respective public key ID associated with the client device from which the registration request is received. Furthermore, the authorized client management module may be configured to add the respective public key ID of the client device associated with each of the valid requests to the authorized list. In some cases if a registration request of a client device is not granted, then that client device may be placed on a waiting list (e.g. in the event that a threshold requirement to be placed on the authorized list is lowered). In this way, the access management system is able to deal with a plurality of registration requests. The access management system may be configured to deal with the requests one at a time, or simultaneously in a single parallel operation.
The above disclosure relates to a registration process, whereby a client device is essentially registered or subscribed to an electronic resource. Examples of resources include streaming services such as Netflix or Spotify, online games such as World of Warcraft and Fortnite, online newspapers, and any other online content which is associated with a subscription.
Next, we consider how the client device actually comes to access the electronic resource, using an authorization module. Specifically, the access management system may further comprise an authorization module, which is preferably equipped to deal with access requests from client devices. Herein, an access request, is a request actually to access the electronic resource, rather than just registering to be able to access the resource. The authorization module (or alternatively, the request management module) may be configured to receive an access request from a client device, the access request, as discussed, indicating that the client device would like to access the electronic resource which is stored at the resource address. Such an access request may include the public key ID associated with the client device from which the access request is received. In addition, the access request may further include a public encryption key associated with the client device. Including the encryption key in the access request is advantageous in some circumstances because it minimizes the amount of metadata which needs to be transmitted in the initial registration request. The structure of the registration request is explained in more detail later on in the application with reference to
Access to the electronic resource is preferably granted by availing the client device of a session key which may be used to access the electronic resource. Of course, it is desirable not simply freely to broadcast the session key, in case such a signal is intercepted. Accordingly, the authorization module may be configured to grant the client device access to the electronic resource by encrypting a session key with a public encryption key associated with the client device, to generate an encrypted session key, and sending the encrypted session key to the client device, the encrypted session key being decryptable by a user using a private decryption key which is complementary to the public encryption key, and the decrypted session key being usable to access the electronic resource at the resource address. It will be noted that the encryption key may be retrievable from either the access request or the original registration request, in which case it is preferably stored to a memory of the access management system for later retrieval.
The session key may be a one-use session key, allowing the user to access the electronic resource a single time. For example, after the session key is used once, it may expire. In some cases in order to further heighten security, and also for increased control as to who is able to access the electronic resource, the session key may be a rotating session key. In other words, the session key may be updated on a regular (preferably periodic) basis. Specifically, the session key may be a rotating session key which changes to a new session key after a predetermined period of time; and wherein, when the session key changes, the authorization module is configured to encrypt the new session key with the encryption key of each client device whose public key ID is included in the authorized list in order to generate a new encrypted session key, and to send the new encrypted session key to the or each client device.
In certain cases, the validation criterion which determines which subset of client devices who have made registration requests are placed on the authorized list may be variable. Specifically, the request management module may be configured to change the validation criterion. Such a change may result in certain client devices (or specifically, their registration request) now meeting the criterion, when they didn't before, or certain client devices whose registration requests previously met the criterion no longer meeting the criterion. After the validation criterion has been changed, the request management module may be configured to determine whether the registration requests of the client devices whose public key IDs are included in the authorized list meet the updated validation criterion, and to identify those which do not, i.e. the no-longer valid registration requests. The request management module may then be configured to generate instructions configured to cause the authorized client management module to remove the public key IDs associated with the client devices whose registration requests are no longer valid from the authorized list. On the other hand, the request management module may also be configured to determine whether the registration request of client devices who have been placed in the waiting list (see earlier) meet the updated validation criterion. For those that do, the request management module may be configured to generate instructions configured to cause the authorized client management module to add the public key IDs associated with those client devices onto authorized list. In this manner, the present invention provides an access management system which is able to dynamically manage the client devices which are able to access a specific electronic resource while not requiring that individuals need to submit any personal information at all, nor to register with the service provider itself.
A second aspect of the invention provides a computer-implemented method of controlling access to an electronic resource, the electronic resource accessible at a resource address, and provided by a service provider having associated therewith an electronic provider address, the method comprising: determining whether a registration request received at the electronic provider address is a valid registration request, the request including a public key ID associated with a client device from which the registration request is received; if it is determined that the registration request is a valid registration request, adding the public key ID associated with the client device to an authorized list, wherein when a public key ID of the user is on the authorized list, the client device is permitted to access the electronic resource. The optional features set out above, with reference to the first aspect of the invention, also apply equally well to the second aspect of the invention.
A third aspect of the invention which is similar to the first addresses the situation in which a plurality of registration requests is received, and then a decision regarding the results of the registration requests is made “in bulk”. As we demonstrate, access management systems of the third aspect of the invention may be used to implement an auction function.
Specifically, a third aspect of the invention provides: an access management system for controlling access to an electronic resource, the electronic resource available at a resource address, and provided by a service provider having associated therewith an electronic provider address, the system comprising: a request management module configured to process a plurality of registration requests received at the electronic provider address, each of the registration requests including a respective public key ID associated with the client device from which the request is received, wherein processing the plurality of registration requests comprises: selecting only those registration requests of the plurality of requests which meet a predetermined validation criterion; and/or ranking the registration requests based on ranking data contained in the registration request, and selecting one or more of the registration requests based on a selection criterion; an authorized user management module configured to add the public key IDs associated with the client devices from which the selected registration requests were received to an authorized list, wherein: when a public key ID of a client device is on the authorized list, that client device is able to access the electronic resource. It will be noted that the optional features set out previously in this application in respect of the first aspect of the invention apply equally well to this third aspect of the invention, unless clearly incompatible, or where context dictates otherwise. In particular, the operation of the request management module (specifically with regard to determining how a validation criterion is met, and the authorization module may be as set out previously.
In some cases, the request management module, or other component, may be configured to change the validation criterion, the selection criterion, and/or the ranking data. Such a change may result in certain client devices (or specifically, their registration request) now meeting a criterion, when they didn't before, or certain client devices whose registration requests previously met a criterion no longer meeting the criterion. After the validation criterion has been changed, the request management module may be configured to determine whether the registration requests of the client devices whose public key IDs are included in the authorized list meet the updated criteria, and to identify those which do not, i.e. the no-longer valid registration requests. The request management module may then be configured to generate instructions configured to cause the authorized client management module to remove the public key IDs associated with the client devices whose registration requests are no longer valid from the authorized list. On the other hand, the request management module may also be configured to determine whether the registration request of client devices who have been placed in the waiting list (see earlier) meet the updated criterion. For those that do, the request management module may be configured to generate instructions configured to cause the authorized client management module to add the public key IDs associated with those client devices onto authorized list. In this manner, the present invention provides an access management system which is able to dynamically manage the client devices which are able to access a specific electronic resource while not requiring that individuals need to submit any personal information at all, nor to register with the service provider itself.
A fourth aspect of the invention provides a computer-implemented method for controlling access to an electronic resource, the electronic resource available at a resource address, and provided by a service provider having associated therewith an electronic provider address, the method comprising: processing a plurality of registration requests received at the electronic provider address, each of the registration requests including a respective public key ID associated with the client device from which the registration request is received, wherein processing the plurality of registration requests comprises: selecting only those registration requests of the plurality of registration requests which meet a predetermined validation criterion; and/or ranking the registration requests based on ranking data contained in the registration request, and selecting one or more of the registration requests based on a selection criterion; adding the public key IDs associated with the client devices from whom the selected registration requests were received to an authorized list, wherein when a public key ID of a client device is on the authorized list, that client device is able to access the electronic resource. Optional features set out above in respect of the first and third aspects of the invention apply equally well to the fourth aspect of the invention except where they are clearly incompatible, or context dictates otherwise.
Additional aspects of the invention provide: a computer program (or computer program product) comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the second and/or fourth aspect of the invention; a computer-readable medium having stored thereon the computer program (or computer program product) of the previous aspect of the invention.
The invention includes the combination of the aspects and preferred features described except where such a combination is clearly impermissible or expressly avoided.
Embodiments of the present invention will now be described with reference to the accompanying drawings, in which:
Aspects and embodiments of the present invention will now be discussed with reference to the accompanying figures. Further aspects and embodiments will be apparent to those skilled in the art. All documents mentioned in this text are incorporated herein by reference.
In at least one aspect, the present invention relates to an access management system which is able to ensure that user's can access an electronic resource without the requirement of supplying personal data to the service provider.
Before discussing its operation, we describe the structure of the access management system 100 in more detail. The access management system 100 may include a processor 102 and a memory 104. The processor 102 may include a request management module 105, an authorized client management module 106, and an authorization module 108. The memory 104 may include an authorized list 110, and registration data 112.
The signature 14 is preferably generated using a private signature key associated with the client device 200 or a user thereof. This means that the signature may be verified using a public verification key which is sent to e.g. the electronic provider address 400 or e.g. the request management module 105 of the access management system 100, in the registration request 10. The nature of the payload 12 is discussed shortly, with reference to
Upon receive the registration request, the request management module 105 may determine whether the registration request 10 is a valid request, in decision step S22. In the event that the registration request 10 is valid, the authorized client management module 106 may then add the public key 20 associated with the client device 200 from which the registration request 10 was received to the authorized list 110. The authorized list 110 preferably includes a list of client devices 200 who are permitted to access the electronic resource 300 based on the results of the determination in step S22. If it is determined in step S22 that the registration request 10 is not a valid request, the client device 200 from which the registration request 10 was received may not be registered, i.e. the public key ID will not be added to the authorized list 110. Then, in both cases (i.e. registered and not registered), the user may be notified of the result in step S26, at the client address 18 in the metadata 16 of the registration request 10.
The processes outlined above relate to the initial registration of a client device 200 with the electronic service provider via the access management module 100. Once a client device 200 is registered, the user thereof (or, for that matter, a user who is not registered) may then wish to access the electronic resource 300. In order to do so, an access request is generated and sent to the access management system 100.
We now consider how the client device 200 maybe authorized to access the electronic resource 300, and how access is actually granted. An exemplary process is shown in
For added security, the session key may change on a regular, preferably periodic basis. The session key may change every minute, or hourly, or may change a plurality of times per day. It may change daily, may change every 2, 3, 4, 5, or 6 days. The session key may change weekly, or monthly. The frequency with which the session key changes is preferably based on the intended application. Of course, if the session key changes, then it is necessary to keep the registered client devices 200 updated as well, in order to ensure that they remain able to access the electronic resource. This process is illustrated in
Finally, in step S76, the encrypted updated session key may be transmitted to the authorized client device 200. In some cases, as discussed elsewhere, rather than generating encrypted updated session keys using the respective encryption key 22 of each authorized client device 200, a broadcast encryption scheme may be used.
In some cases, it may be desirable to change the validation criterion. For example, in a commercial setting, this may be done in order to alter the price of accessing the electronic resource. The present invention provides a means of doing so.
The above disclosure relates to the first aspect of the invention, which focuses on registration and authorization aspects of the access management system 100. The final feature of the invention, described in the preceding paragraph, relates to changing a validation criterion, and in doing so, automatically changing which client devices 200 are able to access an electronic resource 300. A further aspect of the invention provides for a process in which rather than being decided on a one-by-one basis, an access management system 100 may receive a plurality of registration requests 10, but may only be able to accept a subset of these. The present invention thereby enables a kind of bidding, or auction functionality. It should be stressed here that the invention lies within the novel implementation of an auction process, rather than with the actual auction process itself.
In these cases, after the authorized list 110 has been generated, or updated, the process by which client devices 200 request access to the electronic resource 300 may be the same as shown in
As well as updating the authorized list 110 based on new incoming registration requests 10, the validation criterion or selection criteria may also be updated, essentially changing the threshold based on which client devices 200 are authorized. In some cases during the registration process of
The features disclosed in the foregoing description, or in the following claims, or in the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for obtaining the disclosed results, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.
While the invention has been described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art when given this disclosure. Accordingly, the exemplary embodiments of the invention set forth above are considered to be illustrative and not limiting. Various changes to the described embodiments may be made without departing from the spirit and scope of the invention.
For the avoidance of any doubt, any theoretical explanations provided herein are provided for the purposes of improving the understanding of a reader. The inventors do not wish to be bound by any of these theoretical explanations.
Any section headings used herein are for organizational purposes only and are not to be construed as limiting the subject matter described.
Throughout this specification, including the claims which follow, unless the context requires otherwise, the word “comprise” and “include”, and variations such as “comprises”, “comprising”, and “including” will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.
It must be noted that, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another embodiment includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by the use of the antecedent “about,” it will be understood that the particular value forms another embodiment. The term “about” in relation to a numerical value is optional and means for example +/−10%.
| Number | Date | Country | Kind |
|---|---|---|---|
| 21250009.4 | Nov 2021 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2022/083014 | 11/23/2022 | WO |
