Computer-implemented method for controlling access in a network

Abstract

Proposed is a computer-implemented method for controlling access in a network having at least two users, having the following steps: - a first identity corresponding to a first user (11) of the at least two users is created and stored in an encrypted form in an identity management system (15), - a second identity corresponding to a second user of the at least two users is created and stored in an encrypted form in the identity management system (15), - a first right of access to a first information or to a first software function or to a first product is assigned to the first identity, - the second user requests access to the information or software function or product from the first user (11) by sending a request to the identity management system (15), - the identity management system (15) checks the authentication of the second user on the basis of the second identity, - the identity management system sends the request to the first user (11), - the first user (11) rejects or approves the request by responding to the identity management system (15), - the identity management system (15) checks the authentication of the first user (11) on the basis of the first identity, - depending on the check, a secret information stored in an encrypted form is shared with the second user, which secret information allows the second user to access the information, software function or product, - the second user accesses the first information or the first software function or the product.

Description

[0001] Proposed are computer-implemented methods for controlling access in a network, and corresponding computer programs. State of the art

[0002] An overview of selected proposed identity management systems and the remaining technical challenges can be found in Paul Dunphy and Fabien A. P. Petitcolas, "A First Look at Identity Management Schemes on the Blockchain", IEEE Security & Privacy, Volume: 16, Issue: 4, July / August 2018.

[0003] The Hyperledger project provides tools, libraries, and reusable components for providing digital identities rooted in blockchain or other distributed ledgers, making them interoperable across management domains, applications, and any other silo. Examples include Indy, Ursa, Aries, and Transact, the latter enabling smart contracts. SUMMARY

[0004] Proposed is a computer-implemented method for controlling access in a network having at least two users, while a first identity corresponding to a first user of the at least two users is created and stored in an identity management system in encrypted form. The computer-implemented identity management system is a system comprising at least one processor unit, at least one memory unit, and at least one network interface connecting the system with the network, and is adapted to write and read digital data representing digital identities to and from the memory unit. In a preferred embodiment, it is also adapted to write, read, and alter information stored together with the digital identities.

[0005] - a second identity corresponding to a second user of the at least two users is created and stored in the identity management system (15) in encrypted form,

[0006] - a first right to access first information or to access a first software function or to access a first product is assigned to the first identity,

[0007] - the second user requests access to information or a software function or a product from the first user (11) by sending a request to the identity management system (15),

[0008] - the identity management system (15) checks the authentication of the second user based on the second identity,

[0009] - the identity management system sends a request to the first user (11),

[0010] - the first user (11) rejects or approves the request by responding to the identity management system (15),

[0011] - the identity management system (15) checks the authentication of the first user (11) based on the first identity,

[0012] - depending on the check, a secret information stored in encrypted form is shared with the second user, which allows the second user to access the information, software functionality or product,

[0013] - the second user accesses the first information or the first software functionality or product.

[0014] This method enables efficient and trustworthy access control in a network shared by users or their respective network nodes.

[0015] In a preferred embodiment, this method is used to protect an interaction between at least two users or their respective network nodes in a network, which are connected via the network. A first user is connected to the network via a first of the two network nodes. In a preferred embodiment, this first node can be implemented as a smart personal device, like a smartphone, a personal computer, a tablet or similar.

[0016] The first user creates a first identity corresponding to the first user in the network via a software application running on the first network node, which creation comprises the first user providing, in particular to the software application running on the first network node, first biometric information characterizing the first user. The first biometric information may, for example, comprise at least one of an iris sample, a fingerprint sample, a palm vein sample, a specific hand gesture or a voice sample of the first user.

[0017] The first biometric information is stored in encrypted form by a computer-implemented identity management system.

[0018] A second user accesses the network via a second network node and requests, via the network, the first user's consent to:

[0019] o the second user accessing a secret information of the first user, or

[0020] o the second user sending information to the first user, or

[0021] o the first identity corresponding to the first user being connected to a second identity corresponding to the second user, or

[0022] o the second user being granted access to control a software application assigned to the first identity,

[0023] and the request is sent via an identity management system.

[0024] The first user rejects or approves the request of the second user via the software application.

[0025] This system enables a decentralized and secure creation of digital identities, while the creation and management of a personal identity corresponding to a human user is strictly limited to the user and protected by personal identity characteristics. The access via the software application running on the personal smart device allows the system to create and manage digital identities in a user-friendly way, while still keeping the creation and management secure and trustworthy.

[0026] In a preferred embodiment, the management of such a digital identity comprises a method, wherein the first user authenticates to the identity management system by providing first biometric information via the software application, and wherein after the authentication the first user changes the first identity, or information stored with the first identity corresponding to the first user, via the software application running on the first network node. The change comprises adding or removing further biometric information corresponding to the first user, or adding or removing secret information, or adding or removing credentials. Additionally or alternatively, to reject or approve the request, the first user authenticates to the identity management system by providing first biometric information via the software application, or by providing further biometric information, or by providing secret information.

[0027] These embodiments allow an efficient and reliable digital identity management by the user, in particular to the software application on the first node.

[0028] In a preferred embodiment, the first identity is formed at least in part from at least one of a digital representation of:

[0029] - the first biometric information,

[0030] - the added further biometric information,

[0031] - the added secret information,

[0032] - the added credentials.

[0033] Additionally or alternatively, the first identity is formed at least initially based on the first biometric information and the consent of the first user to the creation of the first identity. This embodiment ensures that the digital identity is attributed and comprises the required basic information allowing a secure use of the digital identity information of the user: the consent of the user to its creation.

[0034] In a preferred embodiment of the invention, the rejection or approval of the request of the first user to the second user is stored by the software application as one of the logged consents. The software application can provide the first user with an overview of at least one of the logged and still pending consent requests, thereby allowing the first user to reject, grant or revoke any corresponding consent.

[0035] This allows for a particularly user-friendly management of digital identities.

[0036] In the following, embodiments of the invention are explained in detail. Corresponding figures show:

[0037] Figure 1 An exemplary system for creating, storing and managing digital identities in a network is shown.

[0038] Figure 2 An exemplary flowchart of an exemplary method for creating and managing digital identities in a network is shown.

[0039] Figure 3 An example of a user interacting in a network using their digital identity is shown. DETAILED DESCRIPTION

[0040] Digital identity management in a network is an important technical challenge. The term "identity" (short: ID) means a set of attributes related to an entity (ISO 29115). A digital ID is a digital representation in binary numbers of an identity. A human identity is a set of human attributes related to a human (e.g. a human body). Biology is the measurement and calculation of a human body (e.g. a digital representation in binary numbers of a body part) and can be an effective way to digitally identify one unique human being. Biology is data, and therefore biology can be stored and stolen. Keeping stored biology information secure is important to protect the privacy of the corresponding person.

[0041] Distributed ledger technology can be used to manage data and, in combination with security means, it can be used to manage data in a secure way. For example, a blockchain system can use a package of information carried within a digital block that contains a cryptographic hash of the previous block and a timestamp, which is verified by a decentralized consensus. Distributed ledger or blockchain technology can be used to create, store and manage digital IDs.

[0042] Figure 1 An exemplary system for creating, storing and managing digital identities in a network is shown. A user 11 interacts with a device 12 connected to a network (e.g. to the internet). In a preferred embodiment, the device 12 can be a computing device like a mobile computing device (smartphone or the like) having a user interface and a network interface.

[0043] To create a digital identity, the user 11 uses a software application running on the device 12 to provide first biometric information to the software application on the device 12. In a preferred embodiment, the first biometric information is provided to the software application by measuring or recording a biometric property, such as an image of a human iris, a fingerprint, facial features, a gesture, a voice sample, etc., using a sensor of the device 12.

[0044] The used software application of the device 12 interacts with a software application 13. The software 13 is software running on, for example, a server infrastructure. Via the software 13, information can be routed from the device 12 to other software applications in a secure manner. The software application 13 interacts with a software application 14 running on an identity management platform. The identity management platform is a platform in which digital identities and corresponding locally stored content are managed by using software applications running on hardware of the platform. The first biometric information provided from the user 11 to the device 12 is securely sent via the software application 13 running on the server infrastructure to the software application 14 running on the identity management platform.

[0045] The software application 14 of the identity management platform stores a digital representation of the first biometric information on a storage device of the identity management platform. The software application 14 interacts with a software application 15 of a distributed ledger system. Using the software application 15, the first biometric information is locally stored and a hash block of the information is stored in the distributed ledger. It is stored in an encrypted form and constitutes a seed of the newly created digital identity of the user 11.

[0046] If the user 11 wants to manage his digital identity, for example, to add or remove personal secrets, to add or remove further biometric information, to approve or reject a request for consent of another user, to request consent of another user, etc., he can do so by authenticating based on the first biometric information (or further biometric information or personal secrets added later on) and sending corresponding information or requests via the software application running on the device 12 and the software application 13 to the software application 14 running on the identity management platform.

[0047] Such a request for consent of another user can, for example, refer to the other user accessing secret information of the user 11, or the other user sending information to the user 11, or a connection of the identity corresponding to the user 11 with a second identity corresponding to the other user, or the other user being granted access to control a software application assigned to the identity corresponding to the user 11. In general, consent occurs when a person voluntarily agrees to something. Digital consent is a digital representation of consent in binary numbers.

[0048] Now, a digital identity can be formed by combining digital consent and biology into a distributed ledger identity or blockchain identity. This means that biology and digital consent form the core of the digital identity. The distributed ledger or blockchain can store the digital identity number against a hashed digital representation of the biology and consent. Each digital identity can contain only the necessary biology details and only for consented purposes. The biology can be stored into a chip (integrated circuit, packaged co-processor) together with a timestamp.

[0049] Consent for a particular purpose or request can be encapsulated with a "yes" (e.g. digitally "1") or "no" (e.g. digitally "0"), so they can be granted, denied and revoked.

[0050] This digital identity system enables identity tokens, which are special digital identities that can replace accounts (e.g. email + password) and allow users to manage access. Using this identity token, the network can act as a cross-consent identity network. Two consents are necessary to create any connection between identities. Thus, connections between digital identities are created via human digital consent and remain valid only as long as the human digital consent is not revoked at one end.

[0051] Products or things can have corresponding identities. However, it is proposed that these digital identities rely on and need to be assigned at least one digital identity corresponding to an actual human being as a base identity. Similarly, a company identity can be created to rely on and be assigned to a digital identity of an official representative (e.g. via an authorized consented power).

[0052] Figure 2 A schematic flow chart showing an exemplary method for creating and managing digital identities in a network is shown.

[0053] In a first step 21, a root string representing a digital identity is created. This step starts with an input from a user to a software application running on a user device. The software application requests first biology information from the user and first consent from the user. This information is used as attributes to create a digital identity, as a number or block in a distributed ledger or blockchain, i.e. a distributed identifier. The software application can request a name for this first identity. In a preferred embodiment, this name is private (i.e. not shared and only on this device). Only the owner of the identity can decide with whom to share which secret. The software application sends the distributed identifier to an identity management platform employing distributed ledger technology. The software application also stores the biology information on the device using local hardware.

[0054] The requested consent can refer to the consent to create a digital identity of the user, the biological information can be chosen among different options like measuring or recording an iris sample, a fingerprint or a palm vein sample, a specific gesture, a voice sample, etc.

[0055] Creating a root string representing the digital identity based on the first consent and the first biological information in this way is secure and meets privacy and data protection requirements. To this end, the first consent is digitalized by reducing it into a digital string. Then, the first biological information is processed, e.g. according to ISO / IEC JTC 1 / SC 37, and added to the digital string representing the first consent. This results in a root string of the digital identity, e.g. compliant with ISO29115. To ensure security, the hash string representing the digital identity is encrypted. In a preferred embodiment, the digital identity is encrypted by two algorithms, one being a classical algorithm (e.g. elliptic curve) and one being a post-quantum key generation, preventing future attacks. The encrypted string is stored as digital identity in a distributed ledger (e.g. blockchain) on a hardware memory of the identity management platform.

[0056] Using this method for creating and managing digital identities, a technical system is provided that meets data protection requirements for consent, like:

[0057] - Significant and separate (easy to understand, simple / clear language)

[0058] - Positive opt-in (no pre-ticked, no default on)

[0059] - Specific, different consent for different data

[0060] - Include reasons (why) and purposes (for what)

[0061] - Store information (how, when / timestamp, exact wording)

[0062] - Easy opt-out as opt-in.

[0063] Once a digital identity is created using the root string, it can be supplemented in a second step 22 by providing further information like further biological information or personal secrets, e.g. a password, or authority-dependent information like a university diploma, a driving license, a personal ID, a social security number, a medical record, etc. This information can be used as further attributes to be stored as digital identity and thereby make the digital identity more robust.

[0064] The information stored with or as part of the digital identity can then be used as a proof of legitimacy in step 23. It can be used for example to authenticate the information to other users in the network, or to authenticate to other users or network nodes, or to access other network nodes, or to log in to an application or service in the network.

[0065] To use the information or secrets stored with or as part of the digital identity, a software application running on the user device receives an input representing a request, for example:

[0066] - a request of the user to access an online service,

[0067] - a request of the online service for login authorization,

[0068] - a request of the online service for a proof of legitimacy (e.g. a certain age of eligibility, or the possession of a certain document like a driving license)

[0069] - a request of a federated identity service (e.g. OpenID),

[0070] - a request of an access service managed by the user (e.g. oAUTH).

[0071] The software application accesses the digital identity to check the consent for such an action, and to check if the necessary information is stored with or as part of the digital identity. If the consent and the information are stored and valid, the software application creates a token that includes only the required and consented secrets for that particular action. The token is thus a bundle of information that the user wants or agrees to share with the particular requester. If no consent information is stored for that action, the software application can solicit the user consent. If the requested or necessary information is not stored, the software application can ask the user to create and store it. Finally, the software application shares the token with the requester.

[0072] Thus, a piece of secret information and a piece of consent are bundled into a token to be used as a package of information that can satisfy a request for a proof of legitimacy or authorization information. The token is used to share the minimum required information.

[0073] In an alternative or subsequent step 24, the user can use his created digital identity to manage the consents. To this end, the software application on the user device receives and stores the answers from the user to each particular consent request: yes or no (e.g. stored as 1 or 0). The software application can create a backlog of requests and enable its user to answer at any possible time.

[0074] For example, such a request can be the question: "Do you agree that user A / service B / company C can send you a newsletter with conditions...". Such a question can be triggered by the user himself or by the party soliciting the consent (i.e. user A, service B or company C). ". Such a question can be triggered by the user himself or by the party soliciting the consent (i.e. user A, service B or company C).

[0075] In a preferred embodiment, the software application checks whether the consent question / conditions comply with predetermined data protection or privacy requirements, e.g. a limitation date or a revocation option.

[0076] In a preferred embodiment, the software application automatically suggests questions about relevant categories of the request to extend the given consent settings. It can also utilize reminders to support revocation, re-verification, re-consent to enable secret sharing. This functionality can be extended with existing machine learning algorithms to form an assistant to ask questions and keep the support manageable (reminders for expired consents, or time limits for already existing consents, etc.).

[0077] In a preferred embodiment, the software application can show the user a summary or overview of all or selected consents. The core functionality of such an overview or consent dashboard is to keep the consent management practical for the user, e.g. by using the following rules:

[0078] - all consents are created by answering a question with yes or no,

[0079] - therefore, consents are visualized as yes or no,

[0080] - all consents can be granted, denied, revoked, re-granted, revoked again, etc. with a single action.

[0081] In an alternative or subsequent step 25, digital identities can be connected, e.g. a newly created digital identity based on the newly created root string can be connected. For this, the software application on the user device solicits the consent to establish a one-to-one connection between the first identities. For this, the software application creates a distributed identifier, e.g. including an object or smart product owned by the user. This creation of a distributed identifier only takes place after the corresponding consent of the user to the software application. In a preferred embodiment, all distributed identifiers are listed (copied) as attributes in the user digital identity.

[0082] To connect existing root strings, for example, two existing root strings can be hashed to generate a third root string. This third root string can be copied as a secret of both original root strings in each consent dashboard. These two root strings can reject the existing third root string on both sides. Any number of secondary strings can be created via a consent of one root string. All these secondary strings are connected to this one root string via this consent.

[0083] All one-to-one connections, including the identity of an object or a smart product, are valid only if the basic digital identity consent at both ends is still valid.

[0084] One-to-one connections can be used to share secrets or create smart contracts, for example, by using two basic identities corresponding to human users to generate a distributed identifier of a smart contract and confirm an agreement between the two identities.

[0085] In Figure 3 , an example is shown in which a user uses their digital identity to interact in a network. A first digital identity 311 is created based on a root string created by merging information received by a first user 31, which includes a first consent and a first secret, such as biometric information. A second digital identity 321 is created based on a root string created by merging information received by a second user 32, which includes a first consent and a first secret, such as biometric information. A third digital identity 312 is created, for example for a product, in this example for a car belonging to user 31. Digital identity 312 is connected to and dependent on first digital identity 311. The creation of the third digital identity is only possible after the consent of user 32 via first digital identity 311. A fourth digital identity 322 is created, for example for a product, in this example for a garage belonging to user 32. Digital identity 322 is connected to and dependent on second digital identity 321. The creation of the fourth digital identity is only possible after the consent of user 32 via second digital identity 321.

[0086] The third digital identity corresponding to the car belonging to user 31 and the fourth digital identity corresponding to the garage belonging to user 32 may include consent to actions provided by the respective owners of the products. This consent may include agreement to certain conditions of a smart contract automatically negotiated between the products. For example, user 31 may agree to the car negotiating a smart contract with the garage at a maximum fee per parking time and a negotiation strategy or format, and user 32 may agree to the garage negotiating a smart contract with the car at a minimum fee per parking time and a negotiation strategy or format. Within these agreed conditions, the products can now negotiate the smart contract themselves, such as allowing the car to park in the garage (including opening the garage door) for a negotiated parking fee. In an alternative embodiment, consent to the negotiated conditions or consent to whether negotiation occurs at all may not be given in advance, but rather requested by the user through their product via the corresponding digital identity in the digital identity management system.

Claims

1. A computer implementation method for controlling access in a network with at least two users, characterized in that: - A first identity corresponding to the first user (11) of the at least two users is created and stored in the identity management system (15) in encrypted form, wherein the first identity is formed as a root string based at least initially on the first biological information and the consent of the first user (11) to create the first identity, which is formed by digitizing the first consent into a numeric string and adding the processed first biological information to the numeric string representing the first consent, and once the first identity is created using the root string, it is supplemented with further biological information or secret information corresponding to the first user (11); The first user (11) creates at least one distributed identifier for an object or smart product owned by the first user (11) via a corresponding agreement of the root string, and the at least one distributed identifier is connected to the root string via the corresponding agreement; - A second identity corresponding to the second user among the at least two users is created and stored in encrypted form in the identity management system (15). - The first right to access the first information, the first software function, or the first product is assigned to the first identity. - The second user requests access to information, software functions, or products from the first user (11) by sending a request to the identity management system (15). - The identity management system (15) verifies the authentication of the second user based on the second identity. - The identity management system sends a request to the first user (11). - The first user (11) rejects or approves the request by responding to the identity management system (15). - The identity management system (15) authenticates the first user (11) based on the first identity check. - Depending on the inspection, secret information stored in encrypted form may be shared with a second user, and this secret information may allow the second user to access the information, software functions, or products. - A second user accesses the first piece of information or the first software function or product.

2. The method according to claim 1, characterized in that, - The first user (11) connects to the network via the first of two network nodes (12). - A first user (11) creates a first identity in the network corresponding to the first user via a software application running on a first network node (12), wherein the creation includes the first user (11) providing first biological information characterizing the first user (11). - The identity management system (15) stores the first biological information in encrypted form.

3. The method according to claim 1 or 2, characterized in that, A first user (11) authenticates to an identity management system (15) by providing first biological information via a software application, and after the authentication, the first user (11) changes a first identity, or information stored with the first identity corresponding to the first user (11), via a software application running on a first network node (12), and the changes include: Add or remove further biological information corresponding to the first user (11), or Add or remove secret information.

4. The method according to claim 3, characterized in that, A primary identity is formed, in part, by at least one of the following numerical representations: First biological information, The added further biological information, The added secret information.

5. The method according to claim 1 or 2, characterized in that, In order to reject or approve the request, the first user (11) authenticates to the identity management system (15) by providing first biological information, further biological information, or secret information via a software application.

6. The method according to claim 1 or 2, characterized in that, The first biological information includes at least one of the following: iris sample, fingerprint sample, palm vein sample, specific gesture or voice sample of the first user (11).

7. The method according to claim 1 or 2, characterized in that, The first user's (11) rejection or approval of the second user's request is stored by the software application (12) as one of the recorded consents.

8. The method according to claim 1 or 2, characterized in that, Provide the first user (11) with an overview of at least one of the recorded and still pending consent requests, one of which is accessed by the first user (11) to refuse, grant or revoke the corresponding consent.

9. A computer program product adapted to perform the method according to any one of the preceding claims.

10. A storage device storing a computer program according to claim 9.

Images