Title

Computer-implemented method to secure interactions between at least two users in a network

Proposed is a computer-implemented method to secure interactions between at least two users in a network as well as corresponding computer programs.

Prior Art

An overview over selected proposed identity management systems as well as over remaining technical challenges can be found in“A First Look at Identity Management Schemes on the Blockchain” by Paul Dunphy and Fabien A.P. Petitcolas in: IEEE Security & Privacy ( Volume: 16 , Issue: 4 , July/August 2018).

The Hyperledger projects provide tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo. Examples include Indy, Ursa, Aries and Transact, whereas the latter enables smart contracts.

Invention Disclosure

Proposed is a computer-implemented method to secure an interaction between at least two users or their respective network nodes in a network, whereas the at least two network nodes are connected via the network. A first user connects to the network via a first of the two network nodes. In a preferred embodiment, this first node may be implemented as a smart personal device like a smartphone, personal computer, tablet or similar devices. The first user creates in the network a first identity corresponding to the first user via a software application running on the first network node, whereas the creation includes the first user providing first biometric information characterizing the first user, especially to the software application running on the first network node.

The first biometric information may for example include at least one of an iris sample, a fingerprint sample, a palm veins sample, a specific gesture, or a voice sample of the first user.

The first biometric information is stored in encrypted form by a computer-imple mented identity management system. The computer-implemented identity man agement system is a system comprising at least one processor unit, at least one memory unit as well as at least one network interface to connect the system with the network and is adapted to write and read digital data representing digital identities to the memory unit. In a preferred embodiment, it is also adapted to write, read and alter information stored together with the digital identity.

A second user accesses the network via a second network node and requests via the network a consent of the first user to

o the second user accessing secret information of the first user, or o the second user sending information to the first user, or

o the first identity corresponding to the first user being connected with a second identity corresponding to the second user, or

o the second user being granted access to control a software applica tion assigned to the first identity,

whereas the request is sent via the identity management system.

The first user denies or approves the request of the second user via the software application.

Such a system enables a decentralized and secure creation of digital identities whereas the creation and management of a personal identity corresponding to a human user is strictly limited to this user and secured by personal identity charac teristics. The access via a software application running on a personal smart de vice allows this system to create and manage the digital identity in a user-friendly way while still keeping the creation and management secure and trustworthy. In a preferred embodiment such a management of digital identities includes methods, where the first user authenticates to the identity management system by providing the first biometric information via the software application and whereas after the authentication, the first user alters the first identity or infor mation stored with the first identity corresponding to the first user via a software application running on the first network node. The altering includes adding or re moving further biometric information corresponding to the first user, or adding or removing secret information, or adding or removing a certificate. Additionally or alternatively, in order to deny or approve the request, the first user authenticates to the identity management system by again providing via the software applica tion the first biometric information, or by providing a further biometric information or by providing a secret information.

These embodiments allow for an efficient and reliable digital identity manage ment by the user, especially to the software application on the first node.

In preferred embodiments the first identity is formed at least partially by at least one of a digital representation of

the first biometric information,

an added further biometric information,

an added secret information,

an added certificate.

Additionally or alternatively, the first identity is at least initially formed based on the first biometric information and a consent of the first user to create the first identity. This embodiment ensures that the digital identity is characteristic and in cludes the required basic information to allow for a safe use of a user’s digital identity information: the user’s consent to its creation.

In preferred embodiments of the invention, the denial or approval by the first user of the request of the second user is stored by the software application as one of recorded consents. An overview over at least one of recorded and still open con sent requests may be provided to the first user by the software application, allow ing the first user to deny, grant or revoke any of the corresponding consents.

This allows for an especially user-friendly management of the digital identities. In a further preferred embodiment, an efficient and trustworthy access control is realized, comprising the steps:

The first identity corresponding to the first user is created and stored in en crypted form in the identity management system.

A second identity corresponding to a second user is created and stored in en crypted form in the identity management system.

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.

The second user requests an access to the information or the software func tion or the product from the first user by sending the request to the identity management system.

The identity management system checks the authentication of the second user based on the second identity.

The identity management system sends the request to the first user,

The first user denies or approves the request by responding to the identity management system.

The identity management system (15) checks the authentication of the first user (11) based on the first identity.

Dependent on the check, secret information stored in encrypted form is shared with the second user, whereas the secret information allows the sec ond user to access the information, the software function or the product.

The second user accesses the first information or the first software function or the product.

In the following, the embodiments of the invention are explained in detail. The corresponding drawings show:

Fig. 1 shows an exemplary system to create, store and manage digital identities in a network.

Fig. 2 shows a schematic flowchart of an exemplary method for creat ing and managing a digital identity in a network.

Fig. 3 shows an example for the interaction of users in a network using their digital identities. Detailed description and embodiments

Digital Identity Management in networks is an important technical challenge. The term identity (short: ID) means a set of attributes related to an entity (IS029115). A digital ID is a digital representation in binary numbers of an identity. A human identity is the set of human attributes related to a human being (e.g. the human body). Biometrics are human body measurements and calculations (e.g. digital representation in binary numbers of body parts) and can be an effective way to digitally identify one unique human being. Biometrics are data, therefore biomet rics can be stored - and stolen. Keeping stored biometric information secure is important to secure the privacy of the corresponding person.

Distributed ledger technology can be used to manage data and - combined with security means - it can be used to manage data in a secure way. For example, a Blockchain system may use an information package carried within a digital block that contains the cryptographic hash of the previous block and a timestamp, vali dated by a decentralized consensus. Distributed ledger or Blockchain technology can be used to create, store and manage a digital ID.

An exemplary system to create, store and manage digital identities in a network is shown in Fig. 1. A user 11 interacts with a device 12, which is connected to a network, e.g. connected to the internet. In a preferred embodiment, device 12 may be a computing device like a mobile computing device (smartphone etc.) with user interface and network interfaces.

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

The used software application of device 12 interacts with software application 13. Software 13 is a software running e.g. on a server infrastructure. Via the software 13 information can be routed in a secure manner from device 12 to other soft ware applications. Software application 13 interacts with software application 14 running on an identity management platform. Identity management platforms are platforms where digital identities and corresponding content stored locally is man aged by using software applications running on the hardware of the platform. The first biometric information provided from user 11 to device 12 is securely sent to the software application 14 running on the identity management platform via soft ware application 13 running on a server infrastructure.

Software application 14 of the identity management platform stores a digital rep resentation of the first biometric information on storage means of the identity management platform. Software application 14 interacts with software application 15 of a distributed ledger system. The first biometric information is stored locally and the hashed block of information in a distributed ledger using software appli cation 15. It is stored in encrypted form and constitutes the seed of a newly cre ated digital identity for user 11

If the user 11 wants to a manage his digital identity, e.g. add or remove personal secrets, add or remove further biometric information, approve or deny a request of consent by another user, request consent of another user etc., he may do this by authenticating based on the first biometric information (or subsequently added further biometric information or personal secrets) and sending the corresponding information or request via the software application running on device 12 and soft ware application 13 to software application 14 running on the identity manage ment platform.

Such a request for consent by another user may for example refer to the other user accessing secret information of user 11, or the other user sending infor mation to user 11, or the identity corresponding to user 11 being connected 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 user 11. Generally, consent occurs when one person voluntarily agrees to some thing. Digital consent is a digital representation in binary numbers of a consent. A digital identity can now be formed by merging digital consent and biometrics into one distributed ledger identity or Blockchain identity. That means that the bi ometrics and digital consents form the core of the digital identity. A distributed ledger or Blockchain can store digital identity numbers for hashed digital repre sentations of biometrics and consents. Each digital identity may only contain the necessary biometrics’ details and is used only for consented purposes. Biomet rics may be stored into a chip (integrated circuit, encapsulated co-processor) with a time stamp.

Consents for specific purposes or requests may be encapsulated with a yes (e.g. digitally“1”) or a no (e.g. digitally“0”), so they can be granted, denied and re voked.

Such a digital identity system enables identity tokens, which are special digital identities that can replace accounts (e.g. email + password) and allow user man aged access. Using such identity tokens, a network can be used as a cross-con- sent identity network. Two consents are necessary to create any connection be tween identities. Accordingly, connections between digital identities are created via human digital consent and stay valid only while the human digital consents are not revoked at one end.

Products or things can have corresponding identities. However, it is proposed that these digital identities are dependent on and need to be assigned to at least one digital identity corresponding to an actual human being as base identity. Sim ilarly, company identities can be created as dependent on and assigned to a digi tal identity of an official representative (e.g. via power of authority consent).

Fig. 2 shows a schematic flowchart of an exemplary method for creating and managing a digital identity in a network.

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 de vice. The software application requests a first biometric information from the user as well as 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 may request a name for this first identity. In a preferred embodiment, this name is private (i.e. not shared and only on the device). Only the owner of the identity may decide which secret to share with whom. The software application sends the distributed identifier to an identity management platform, which employs distributed ledger technology. The software application also stores the biometric information on the device using lo cal hardware.

The requested consent may refer to a consent to creating a digital identity for the user, the biometric information may be chosen among a selection of different op tions like measuring or recording an iris sample, fingerprint or palm veins sample, a specific gesture, a voice sample etc.

The creation of a root string representing a digital identity based on a first con sent and first biometric information in such a way is secure and fulfills privacy and data protection requirements. To this end, the first consent is digitized by reduc ing it to a digital string. Then the first biometric information is processed, e.g. in accordance with ISO/I EC JTC 1/SC 37, and added to the digital string represent ing the first consent. This results in a root string for the digital identity, e.g. com pliant with IS029115. To ensure security, the hashed string representing the digi tal identity is encrypted. In a preferred embodiment, the digital identity is en crypted by two algorithms, e.g. one classical algorithm (e.g. elliptic curve) and one generating post-quantum keys, preventing future attacks. The encrypted string is stored as digital identity in the distributed ledger, e.g. Blockchain, on a hardware memory of the identity management platform.

Using such a method for creating and managing a digital identity, a technical sys tem is provided which fulfills data protection requirements for consents like: prominent and separate (easy to understand, plain/clear language) positive opt-in (no pre-ticked, no default on)

specific, different consent for different data

contains the reason (why) and the use (what for)

storage information (how, when / time stamp, exact words)

opt-out as simple as opt-in Once, the digital identity is created using the root string, it may be supplemented in a second step 22 by providing further information like further biometric infor mation or personal secrets, for example passwords or authority-dependent infor mation like University diploma, driver licence, personal ID, social security num ber, medical records etc. This information may be used as further attributes to be stored as the digital identity and therefore making the digital identity stronger.

The information stored with or as part of the digital identity may then be used as legitimizing proof in step 23. It may for example be used to verify this 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 applications or services in the network.

To use information or secrets stored with or as part of the digital identity, the soft ware application running on the user device receives input representing a re quest, e.g.:

a request by the user to access an online service,

a request for authorization for login by an online service,

a request for legitimizing proof (e.g. a certain qualifying age or the possession of a certain document like a driver’s licence) by an online service

a request by a federated identity service, e.g. open ID,

a request by a user-managed access service, e.g. oAUTH.

The software application accesses the digital identity to check the consent for such an action and to check whether the necessary information is stored with or as part of the digital identity. If consent and information are stored and valid, the software application creates a token, which includes only the required and con sented secrets for this specific action. Therefore, the token is a bundle of infor mation the user want or agreed to share with the specific requester. If there is no consent information stored for this action, the software application may ask the user for consent. If the requested or necessary information is not stored, the soft ware application may ask the user to create and store it. Finally, the software ap plication shares the token with the requester. Therefore, one piece of secret information and one piece of consent are bundled into one token to be used as an information package able to fulfil a request for legitimizing proof or for authorizing information. This token is used to share the minimum needed information.

In an alternative or subsequent step 24, the user may manage consent using his created digital identity. To this end, the software application on the user device re ceives and stores an answer from the user to each specific consent request: yes or no (e.g. stored as 1 or 0). The software application can create a backlog of re quests and enable its user to answer at any possible time.

For example, such a request may be a question“Do you consent to user A / service B / company C sending you newsletters with the conditions...?”. Such a question could be triggered by the user himself or by the party asking for consent, i.e. user A, service B or company C.

In a preferred embodiment, the software application checks, whether the question / conditions of the consent are compliant with predetermined data protection or pri vacy requirements, e.g. limit date or revocation option.

In a preferred embodiment, the software application automatically suggests ques tions on related categories of requests to expand the given consent setup. It may also support with reminders in revoking, revalidating, re-consenting to enable se cret sharing. Such a functionality can be extended with existing machine learning algorithms to form an assistant to ask the questions and keep the support manage able (reminding about expired consents or time limits of already existing consents, etc.).

In a preferred embodiment, the software application can show a summary of or an overview over all or selected consents to the user. Core functionality of such an overview or consent dashboard is keeping the consent management practical for the user, e.g. by using the following rules: all consents are created answering a question with yes or no

accordingly the consents are visualized as yes or no all consents can be granted, denied, revoked, re-granted, revoked again etc. with a single action.

In an alternative or subsequent step 25, digital identities can be connected, e.g. newly created digital identity based on newly created root strings can be con nected. To this end, the software application on the user device asks for consent to establish one-to-one connections between first identities. For that, the software ap plication creates distributed identifiers, e.g. including distributed identifiers to object or smart products the user owns. This creation of distributed identifiers only hap pens after according consent by the user to the software application. In a preferred embodiment, all distributed identifiers are listed (replicated) as attributes in the user’s digital identity.

In order to connect existing root strings, for example a third root string can be gen erated hashing the two existing root strings. This third root string can be replicated as a secret of the original two root strings in each consent dashboard. These two root strings can deny on both sides the existing third root string. Any number of secondary strings can be created via consent of one root string. All these second ary strings are connected to the one root string via this consent.

All one-to-one connections including identities for objects or smart products are only valid while the base digital identity consents at both ends are still valid.

One-to-one connection can be used to share secrets or to create a smart contract, e.g. by using two base identities corresponding to human users to generate a dis tributed identifier for the smart contract and confirm the agreement between the two identities.

In Fig. 3, an example for the interaction of users in a network using their digital identities is shown. A first digital identity 311 is created based on a root string cre ated by merging information received by a first user 31, whereas the information in cludes a first consent and a first secret like a biometrical information. A second digi tal identity 321 is created based on a root string created by merging information re ceived by a second user 32, whereas the information includes a first consent and a first secret like a biometrical information. A third digital identity 312 is created for example for a product, in this example for a car belonging to the user 31. Digital identity 312 is connected to and dependent on the first digital identity 311. The cre ation of the third digital identity is possible only after the consent of user 32 pro vided via the first digital identity 311. A fourth digital identity 322 is created for ex ample for a product, in this example for a garage belonging to the user 32. Digital identity 322 is connected to and dependent on the second digital identity 321. The creation of the fourth digital identity is possible only after the consent of user 32 provided via the second digital identity 321.

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, can include consents to action provided by the respective owner of the products. Such con sents may include the consent to certain conditions of a smart contract automati cally negotiated between products. For example, user 31 may consent to the car negotiating a smart contract with a garage with a maximum fee per parking time as well as negotiation strategy or format and user 32 may consent to the garage nego tiating a smart contract with a car with a minimum fee per parking time as well as negotiation strategy or format. Within these consented conditions, the products may now negotiate a smart contract on their own, for example allowing the car to park in the garage (including the opening of the garage door) for a negotiated parking fee.

In alternative embodiments, the consent to the conditions for the negotiation or the consent to making negotiations at all may not be given in advance, but requested from the users by their products via the respective digital identities in the digital identity management system.