WO2023138918A1

WO2023138918A1 - Method and apparatus for reputation rating

Info

Publication number: WO2023138918A1
Application number: PCT/EP2023/050127
Authority: WO
Inventors: Stefaan PONNET; Michele MINELLI; Dimitri Torfs; Hugo Embrechts
Original assignee: Sony Group Corporation; Sony Europe B.V.
Priority date: 2022-01-18
Filing date: 2023-01-04
Publication date: 2023-07-27

Abstract

It is provided a method for reputation rating. The method comprises receiving data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity. The method further comprises receiving data indicating an actual conduct of the transaction. The method further comprises determining a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct. The method further comprises storing the determined reputation score in a distributed ledger database.

Description

METHOD AND APPARATUS FOR REPUTATION RATING

Field

The present disclosure pertains to a reputation rating. Examples of the present disclosure relate to a method and an apparatus for reputation rating.

Background

Transaction systems require to prove trustworthiness of possible transaction partners. For instance, users of a transaction platform may search for reputable other users they may enter into a transaction with. Hence, there may be a demand for improved reputation rating.

Summary

This demand is met by apparatuses and methods in accordance with the independent claims. Advantageous embodiments are addressed by the dependent claims.

According to a first aspect, the present disclosure relates to a method for reputation rating. The method comprises receiving data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity. The method further comprises receiving data indicating an actual conduct of the transaction. The method further comprises determining a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct. The method further comprises storing the determined reputation score in a distributed ledger database.

According to a second aspect, the present disclosure relates to an apparatus for reputation rating. The apparatus comprises interface circuitry configured to receive data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity. The interface circuitry is further configured to receive data indicating an actual conduct of the transaction. The apparatus further comprises processing circuitry configured to determine a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct. The processing circuitry is further configured to store the determined reputation score in a distributed ledger database.

According to a third aspect, the present disclosure relates a non-transitory machine-readable medium having stored thereon a program having a program code for performing the method described herein, when the program is executed on a processor or a programmable hardware.

According to a fourth aspect, the present disclosure relates to a program having a program code for performing the method described herein, when the program is executed on a processor or a programmable hardware.

Brief description of the Figures

Some examples of apparatuses and/or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

Fig. 1 illustrates a flowchart of an example of a method for reputation rating;

Fig. 2 illustrates an example of an apparatus for reputation rating; and

Fig. 3 illustrates another example of an apparatus for reputation rating.

Detailed Description

Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

Throughout the description of the figures same or similar reference numerals refer to same or similar elements and/or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and/or areas in the figures may also be exaggerated for clarification.

When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e., only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and/or B" may be used. This applies equivalently to combinations of more than two elements.

If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and/or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and/or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and/or a group thereof.

Fig- 1 illustrates a flowchart of an example of a method 100 for reputation rating.

A system executing the method 100 may, for instance, be integrated into a trust or reputation management system of a computer network. The trust or reputation management system may comprise one or more processors for executing the method 100. Reputation rating may be understood as a computer-based mechanism for associating a reputation score (reputation capital), i.e., a quantitative measure for reputation, with a digital identity of the computer network. The reputation score may be valid for a certain ecosystem of the computer network, such as a transaction platform on which several digital identities are able to interact with each other, e.g., an online community or a digital marketplace. Alternatively, the reputation score may be valid for several transaction platforms of the computer network and/or several computer networks.

The method 100 comprises receiving 110 data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity. As used herein, the term “digital identity” refers to a digital representation of an entity in a computer network. The entity may be, e.g., a person, a company, an organization, etc. having access to the computer network via a network node (technical endpoint). The digital identity may indicate one or more identifier being shared via the computer network to give the entity access to a service of the computer network, such as the above-mentioned transaction platform, without the involvement of a human operator.

The first and the second digital identity may be self-sovereign identities (SSIs) managed in an SSI framework. This may be advantageous to ensure confidentiality and authenticity for digital identities involved in the transaction. The SSI framework, firstly, provides verifiable credentials, i.e., a digitally signed collection of attributes of an SSI. The attributes may, for instance, comprise the above-mentioned reputation score of the SSI attested by the transaction platform. Verification of a credential is realized by public-key cryptography which may be anchored on a distributed ledger system. Secondly, the SSI framework provides decentralized identifiers (DIDs) which allow self-certified identifiers of SSIs to be used for end- to-end encrypted communication between the SSIs. The entity represented by an SSI, thirdly, is in control of its DID, i.e., the entity has access to a digital wallet which comprises software managing private keys for the public-key cryptography. The SSI framework, fourthly, requires technical endpoints (digital agent or digital hub) which serve as custodian for the DIDs and as connection points (network nodes) for communication between SSIs. The SSI framework may ensure that an entity entering into a transaction with another entity via its digital identity is what it claims to be and is identifiable within a certain data ecosystem.

Receiving 110 the data may comprise using a communication channel to a sender of the data. A system executing the method 100 may comprise an interface to the communication channel. The communication channel may be any technical infrastructure for transmitting signals - encoding the data - from the sender to a system executing the method 100. For instance, the communication channel may be a wired or wireless connection between network nodes of a computer network or between distinct parts of one computer system. The sender may be, e.g., a network node used to access the communication channel via the first and/or the second digital identity, a server hosting a transaction platform for executing the transaction, or a mediator between the aforementioned. In some examples, the data may be encrypted by the sender based on a private key of the sender and/or a public key of the recipi- ent before transmitting the encrypted data via the communication channel. In the latter case, receiving 110 the data may comprise decrypting the data based on a public key of the sender and/or a private key of the recipient. This may be advantageous for establishing data privacy for the first and second digital identity. In some examples, the data may be digitally signed by the sender such that the sender is identifiable by its digital signature. In this case, receiving 110 the data may comprise verifying the digital signature of the sender to ensure data authenticity.

As mentioned above, the data indicates a desired conduct of a transaction. The transaction may be understood as mutual transfer of data between the first and the second digital identity. For instance, the transaction may be a transfer of first data of the first digital identity to the second digital identity and a transfer of second data of the second digital identity to the first digital identity. In other examples, the transaction may comprise a one-directional transfer of data from one digital identity to the other or several transfers of data between the digital identities. The transaction may correspond to operations executed in at least one database. A set of operations which form one data transfer may be atomic such that the data transfer is indivisible and irreducible.

The transaction may correspond to a transfer of ownership of a certain electronic or digital asset or a grant of a right to use the digital asset. The digital asset may be any data being of value for the entities represented by the first and second digital identity, e.g., programmable or digital money, an access key to an online service or information valuable for data analytics. For instance, the transaction may be an exchange of information for digital money between a data seller (e.g., a digital identity of a private person) and a data buyer (e.g., a digital identity of a company aiming to use the data for data analytics).

The desired conduct of the transaction may define a set of rules to be followed by the participants of the transaction, i.e., the first and the second digital identity. Thus, the desired conduct may define liabilities or obligations of the transaction. The liabilities or obligations may be binding for digital identities involved in the transaction within a certain data ecosystem. The desired conduct of the transaction may be defined by a transaction platform providing a service for administering and/or executing the transaction. The desired conduct may indicate at least one condition of the transaction to be fulfilled by the at least one of the first digital identity and the second digital identity. In the above- mentioned example, the data seller and the data buyer may have agreed on conditions of the transaction before entering into the transaction. More specifically, the data seller and the data buyer may have agreed on that the data seller is obliged to transfer certain data (e.g., personal information of the entity represented by the data seller) of a certain degree of noise/disclosure in exchange of a certain amount of digital money in a certain (digital) currency from the data buyer. Moreover, the desired conduct may define a certain time interval within the transfer shall be completed. In another instance, the data seller may have offered a data subscription to the data buyer, i.e., the data seller is obliged to transfer several portions of data, e.g., captured regularly by a sensor being operated by the entity of the data seller, to the data buyer.

In some examples, the condition of the transaction may be defined based on a historical reputation score of the first digital identity and the second digital identity. For example, a historical reputation score of the data buyer indicating that in past transactions the data buyer showed a substantially “good” behavior, i.e., the data buyer mainly complied with the rules of the past transactions, the condition of the present transaction may include discounts, e.g., depending on the historical reputation score, for acquiring the data from the data seller.

In some examples, the desired conduct of the transaction indicates a sequence of conditions to be fulfilled by the first digital identity and the second digital identity. In other words, the completion of one action or atomic transfer of the transaction may be a condition for a subsequent action defined in the desired conduct, yielding a chronological or functional order in which transfers shall be executed. The sequence of conditions may be considered a “flow” of several steps of the transaction.

The data indicating the desired conduct of the transaction may indicate a score value achievable by the at least one of the first digital identity and the second digital identity for fulfilling the at least one condition of the transaction. The score value may be any real number representing a gain or loss of reputation when fulfilling or not fulfilling the condition, respectively. The score value may be determined by peers governing the transaction platform. In some examples, the data indicating the desired conduct of the transaction is received from a server hosting a transaction platform for the transaction. In this manner, peers governing the transaction platform may determine the desired conduct for transactions administered by the transaction platform. In other words, the transaction platform specifies the rules by which users of the transaction platforms need to abide. The desired conduct may be publicly shared among users of the transaction platform or additionally among users of other transaction platforms.

The desired conduct of the transaction may be defined by a so-called smart contract. In some examples, the transaction may be automatically executable by the smart contract. Smart contracts are self-executing machine-readable instructions that are stored in a distributed ledger database. When deployed, the smart contract is assigned a unique address to allow communication to and from the smart contract through messages. The smart contract is deployed by storing the smart contract as an event in the distributed ledger database. Messages to the smart contract may be posted as events on the blockchain. The smart contract may have the ability to read or write to its internal storage storing data, read the storage of a received message, send messages to other smart contracts to trigger execution of the code in other distributed applications. When the smart contract is executed on a virtual machine running on the peers securing the distributed ledger database, the resulting data may be saved in the internal storage of the smart contract. The updated smart contract may be stored as an event, e.g., on a new block of a blockchain. Thus, the smart contract and changes to data, i.e., state of the smart contract, are represented as a series of events on the blockchain. Similar to the cryptocurrency blockchain, each block in the blockchain may be generated based on a consensus protocol, e.g., by mining the blockchain.

For defining the desired conduct, for example, in a smart contract that governs a sale of a digital asset, the smart contract may include machine-readable instructions to process data in a received message such as an offer from a data buyer. When the data seller sends a counteroffer to the smart contract, the smart contract may update its internal storage to include the counter-offer event, such as the digital identity of the data buyer, the counter-offer price etc. The updated smart contract may be recorded as an event on a new block on the blockchain. The smart contract may allow automatic administration and enforcement of some or all of the obligations and liabilities of participants involved in the transaction, i.e., the first and the second digital identity. The smart contract may optionally obtain updates on conditions that may affect the obligations and liabilities of the parties to the smart contract, i.e., the smart contract may record the actual conduct of the first and the second digital identity. In some examples, the method 100 may comprise executing the smart contract.

It is to be noted, that more than two parties (digital identities) may be involved into the transaction. For instance, the first digital identity may be a data seller, the second digital identity may be data buyer (consumer), and a third digital identity may be a data analyst processing data from the data seller before transferring the processed data to the data buyer. There may be n > 2 parties involved into the transaction.

Referring back to Fig. 1 : The method 100 further comprises receiving 120 data indicating an actual conduct of the transaction. The actual conduct corresponds to an actual course or progress of the transaction. For instance, the actual conduct may indicate which conditions defined in the desired conduct are fulfilled, not fulfilled but still achievable, or not fulfilled. If the transaction is administered by a smart contract, the smart contract may comprise a software routine which regularly checks the state of the transaction and updates the actual conduct of the transaction accordingly.

An example of data indicating the desired conduct of the transaction is described by the following List 1 : participants: network address of data buyer (e.g., first digital identity); network address of data seller (e.g., second digital identity); network address of transaction platform (e.g., third digital identity) signatures: identifier of the data buyer, identifier of the data seller, identifier of the transaction platform; the signature may be generated when the participants sign the transaction with their respective private key; confirming and authorizing of the desired conduct

- value: amount of programmable money to transfer from data buyer to data seller

- time 1 : deadline for transferring the value to the data seller score value 1 : reputation gain achievable by the data buyer for transferring the value to the data seller score value 2: reputation gain achievable by the data buyer for meeting the deadline of time 1 flow 1 : only if value is transferred, countervalue is due countervalue: kind, source, amount of data or access key to data source to transfer from data seller to data buyer

- time 2: deadline for transferring the countervalue to the data buyer score value 3 : reputation gain achievable by the data seller for transferring the countervalue to the data buyer score value 4: reputation gain achievable by the data seller for meeting the deadline of time 2 score value 5: reputation loss of data seller if countervalue is due and data seller does not meet the deadline of time 2 flow 2: only if value and countervalue are transferred, transaction fee is due

- transaction fee: “gas units” to be transferred from the data buyer to the transaction platform and or “gas units” to be transferred from the data seller to the transaction platform; units of gas represent computational power to be provided by the data seller and/or the data buyer for data mining of the transaction platform

- time 3 : deadline for transferring the transaction fee score value 6: reputation loss of data buyer and/or data seller if transaction fee is due and data buyer and/or data seller do not meet the deadline of time 3

List 1

An example of data indicating the actual conduct is described by the following List 2: current time: time when the data indicating the actual conduct was generated completed transfers: timestamp 1 : time when value of List 1 was transferred from the data buyer to the data seller; timestamp 2: time when countervalue of List 1 was transferred from the data seller to the data buyer outstanding transfers: transfer of transaction fee of List 1

List 2 The method 100 further comprises determining 130 a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct. The reputation score may be considered a quantitative measure for how well the first and the second digital identity have complied to rules defined by the desired conduct of the transaction. The reputation score may be a real number which indicates the reputation of the first digital identity and/or the second digital identity. For each digital identity involved in the transaction, a respective reputation score may be determined.

Determining 130 the reputation score may be executed by an algorithm of a reputation management system. In some examples, determining 130 the reputation score comprises determining whether the at least one condition is fulfilled by the at least one of the first digital identity and the second digital identity. If it is determined that the at least one condition is fulfilled, determining 130 the reputation score of the at least one of the first digital identity and the second digital identity may be based on the score value.

In the example given by the List 1 and List 2, the reputation score may be determined by comparing the actual conduct of List 2 with the desired conduct of List 1. Processing circuitry which executes the step determining 130 the reputation score of method 100 may process the information given by the desired conduct and the actual conduct to calculate the reputation score. For instance, the actual conduct of List 2 indicates that the value and countervalue transfer are completed, i.e., the condition of score value 1 (transferring the value to the data seller) and the condition of score value 3 (transferring the countervalue to the data buyer) are fulfilled. The processing circuitry may derive from a computational comparison between timestamp 1 and time 1 and between timestamp 2 and time 2 whether the conditions of score value 2, score value 4, and score value 5 are fulfilled. The processing circuitry may further determine that transaction fee is due based on the completed transfers of List 2 - which is a first condition of score value 6. The processing circuitry may compare the “current time” with the time 3 to determine whether the second condition of score value 6 (deadline is not met) is fulfilled.

The processing circuitry may determine a first reputation score for the data seller (first digital identity) and a second reputation score for the data buyer (second digital identity). The processing circuitry may determine the first and second reputation score by mathematically combining gain or loss of effective score values. A score value is deemed effective when it is tied to fulfilled conditions.

It is to be noted, that determining 130 the reputation score may comprise determining several distinct reputation scores (a series of reputation scores). Each of the reputation scores may correspond to a certain aspect of desirable behavior. For example, a first reputation score may express a number of transaction parties the associated digital identity dealt with. More precisely: a high first reputation score may indicate that the associated digital identity successfully completed prior transactions with a high number of transaction parties, whereas a low first reputation score may indicate the associated digital identity interacts mostly with limited number of parties. Depending on a digital market environment, one or the other may be desirable: often changing transaction partners may be deemed, e.g., a sign for unsatisfied transaction parties which seldomly reenter into new transactions with the concerned digital identity.

Assuming that the first digital identity and the second digital identity may have been involved in a plurality of transactions, it may be useful to determine an overall reputation of the first and second digital identity. Determining 130 the reputation score may be repeated for each of the plurality of transactions, yielding a respective reputation score for each transaction. The reputation score of a digital identity may be updated regularly to consider preferably all relevant transactions of said digital identity. A reputation score determined for prior transactions of the first and second digital identity may be referred to as historical reputation score. Thus, determining 130 the reputation score may be based on the historical reputation score of at least one of the first digital identity and the second digital identity. The historical reputation score may be based on at least one prior transaction of the at least one of the first digital identity and the second digital identity.

In some examples, the reputation score is determined by applying a weighting function to the score values achieved by the first and/or second digital identity in the transaction and prior transactions. This may be beneficial for providing a more significant reputation rating, in particular when the first and second digital identity are involved in a plurality of transactions which may be executed on several transaction platforms and/or with differing desired conducts. The weighting function may ensure comparability of score values achieved by a digital identity in several transactions. The weighting function may, for instance, require at least one of the following weighting factors as input variables: a volume of the transaction (e.g., amount of programmable money transferred in the transaction), a number of transaction partners of the transaction, a number of prior transactions of the at least one of the first digital identity and the second digital identity, and a number of transaction partners of the prior transactions. The preceding list of weighting factors shall be considered non-exhaustive.

In contrast to conventional reputation rating, the method 100 may enable an objective rating of reputation of a digital identity in a certain data ecosystem. This is realized in form of a reputation score, a measure for reputation which is independent of subjective and inconsistent ratings of users of the data ecosystem. The method 100 may determine the reputation score based on a predefined logic which may be public for users of the data ecosystem. Said logic may form a basis for comprehensibly rating a behavior exhibited by a digital identity in transactions with other digital identities. In this manner, the method 100 may build trust in transactions executed in the data ecosystem.

Referring back to Fig. 1 : The method 100 further comprises storing 140 the determined reputation score in a distributed ledger database. A distributed ledger database refers to a database supported by any distributed ledger technology (DLT), e.g., blockchain technology. DLT provides a technical infrastructure and protocols for simultaneous access, validation, and record of the database across multiple network nodes (devices) of a peer-to-peer computer network. This may lead to immutability of the stored reputation score. For instance, storing 140 the determined reputation score may comprise generating a block of a blockchain and writing the reputation score into the block. The block may be shared with participants of a digital market. Participants may run an own node of the blockchain, thereby owning a copy of blocks and their state. Some participants may, alternatively, not run an own node but have access to at least one node, so the blocks are visible to preferably all participants.

Storing 140 the determined reputation score in the distributed ledger database may comprise associating the determined reputation score with at least one of the first digital identity and the second digital identity, e.g., linking the reputation score to a digital identifier of the digi- tai identity. The reputation score and the digital identifier may be written into the same block of a blockchain.

In some examples, the data indicating the desired conduct and/or the data indicating the actual conduct of the transaction are received from the distributed ledger database or another distributed ledger database. This may establish visibility of data underlying the determination of the reputation score and may, therefore, raise credibility of a reputation management system executing the method 100.

In summary, the method 100 may enable objective reputation rating based on a behavior of participants (digital identities) in transactions executed in a data ecosystem. A reputation score may be determined for each participant. The reputation score may be a measurable property of reputation of a participant, unlike a conventional star-rating system. The reputation score may be derived by applying a set of rules (as defined in the desired conduct) to the behavior of the participant in a transaction. The participants may be rewarded with a higher reputation score for complying with the desired conduct. Their compliance may be derived from a comparison of an actual conduct (behavior) of the transaction and the desired conduct. Since they may benefit from the higher reputation score, the method 100 may provide an incentive for the participants to stick to the set of rules they agreed on.

Conditions of a transaction between participants may be defined by the set of rules which may be public in the data ecosystem. A smart contract may be used to define and, optionally, enforce the rules (desired flow of the transaction). A blockchain or other DLT may be used to immutably monitor the behavior (e.g., payments) of the participants. Thus, the method 100 may prevent participants to side-step the reputation rating process.

The reputation score of a participant may automatically increase when said participant successfully completes a deal flow. The reputation score may, e.g., represent the total amount of points (score value) that a participant received over all deals (transactions) the participant is or has been involved in within the data ecosystem. The reputation score may be weighted, e.g., according to the total amount of deals done or to a ratio of score value and the total amount of deals done. The reputation score may be stored on a blockchain and coupled to (a digital identifier of) the associated participant. Registering transactions in a distributed ledger database, as it is done by a smart contract, may imply that users of the distributed ledger database are able to retrieve details about the transactions with a higher level of disclosure than needed or desired for building trust between potential transaction partners. The method 100 may provide a mechanism allowing a user to show and prove its reputation without disclosing the complete transaction history of said user. A possible implementation of that mechanism is the use of a trusted execution environment (TEE).

For instance, at least one of receiving 110 the data indicating the desired conduct of the transaction, receiving 120 the data indicating the actual conduct of the transaction and determining 130 the reputation score is executed in a TEE. In other words, the system executing the method 100 may comprise the TEE and execute parts of the method 100 within the TEE.

The TEE is a secure area or secure enclave integrated in an untrusted environment of a computer system. The TEE may protect code and data loaded inside TEE with respect to confidentiality and integrity. The TEE may therefore be inaccessible from inspection and modification by an execution of untrusted code in the untrusted environment. The TEE may establish an isolated execution environment that runs in parallel with an operating system of the untrusted environment. The TEE may defend sensitive code and data against software attacks from the potentially compromised operating system of the device. The TEE may use hybrid hardware and software mechanisms to protect the sensitive code and data. The TEE may not be accessible by privileged processes like an operating system or a Hypervisor of the untrusted execution environment. The TEE may guarantee security of sensitive information, (i.e., content of the TEE can prove that it is not available for unauthorized processes), authenticity, (i.e., the TEE can prove that it is the intended recipient of data sent to the TEE), and reliability, (i.e., the TEE can prove that code of the TEE is not tampered with and executed as intended). For instance, authenticity of the TEE may be verified by public-key encryption; reliability of the TEE may be verified based on local and/or remote attestation. Remote attestation may allow changes to the TEE to be detected by, e.g., an authorized party or, in case the source code of the TEE is stored publicly, by any system having access to the publicly stored source code. The TEE may generate a certificate (fingerprint) stating which software is currently running and present this certificate to a remote party to prove that unaltered software is executing. The remote party may, therefore, compute a fingerprint based on the source code and compare it to the certificate.

One example of how to realize the isolation of the TEE is to use a so-called hardware root of trust. The hardware root of trust relates to a set of private keys that are embedded into a semiconductor chip during manufacturing. Usually, the keys are unique for each hardware component of the TEE, such that a key extracted from one hardware component cannot be used to compromise other hardware components of the TEE, for example, using physically unclonable functions. The private keys cannot be changed, even after software resets. Corresponding public keys reside in a manufacturer database, together with a hash of a public key belonging to a trusted party. The latter-mentioned public key is used to digitally sign trusted firmware of the TEE and control access to the TEE. The hashed public key is then compared to the one embedded in the TEE. If the hashes match, the public key is used to verify a digital signature of the trusted firmware.

Alternatively, to the example given above, the TEE may use any other technology to establish an execution environment for code and data which is protected against modifications or inspections that are unintended or unauthorized by an operator of the TEE. The usage of the TEE may be advantageous since an operating system of a conventional computer system may comprise insecure software making exfiltration of confidential data easy for attackers.

The data received by the TEE may be encrypted data and the encrypted data may solely be decryptable inside the TEE. By using the TEE, the method 100 may, on the one hand, protect sensitive portions of data in the transaction while it may, on the other hand, immutably and visibly log non-sensitive portions of data in the transaction which are relevant for rating the reputation of digital identities involved in the transaction. For instance, sensitive data, such as identifiers of the digital identities or the amount of programmable money transferred, may be encrypted based on a public key of the TEE. Thus, the sensitive data may only be decrypted within the TEE. Optionally, the sensitive data may be stored in a distributed ledger database but in an encrypted manner and unreadable for outside observers.

The method 100 may provide a “privacy preserving reputation management system” for decentralized (digital) marketplaces. The method 100 may be executed in a secure enclave (TEE) such that coin balances (digital money), deal state (actual conduct) and reputation balances (score values) of transactions are stored as encrypted values in a distributed ledger database such as blockchain. The encryption may allow sensitive data to be solely decrypted within the secure enclave. The secure enclave may then execute calculations on the decrypted values, e.g., according to a logic defined by the desired conduct. An output of the calculations including the reputation score may be stored in a distributed ledger database. The reputation score may be accessible and readable by users of the distributed ledger database of which some are not involved in the transactions. Part of an output of the calculations may be encrypted before leaving the secure enclave, keeping sensitive data encrypted in the distributed ledger database.

A possible application field of the proposed technique are data ecosystems where distributed ledger databases are used to capture steps and payments of transactions in an open computer network. The method 100 may provide an incentive to data sellers and data buyers of these data ecosystems to participate in a race for best reputation and to behave according to accepted norms and values of a digital marketplace (transaction platform) of the data ecosystems.

The above-mentioned transaction between the first digital identity and the second digital identity may be a first transaction of a plurality of transactions. The first transaction may be administered by a first transaction platform. In some examples of the present disclosure, the method 100 is not limited to an execution of the steps 110 to 140 for one transaction between the first digital identity and the second digital identity. The steps 110 to 140 may rather be applied similarly to at least one further transaction between the first and the second digital identity. The steps 110 to 140 may be applied similarly to at least one transaction between the first/the second digital identity and at least one third identity and/or to at least one transaction between at least two fourth identities. The steps 110 to 140 may be applied similarly to several transactions administered on at least two transaction platforms in a shared data ecosystem. In this way, the method 100 may allow a shared reputation management across several transaction platforms and for several transactions between differing digital identities. An example of a shared reputation management is explained with reference to Fig. 3.

If the method 100 is used for several transactions between the first and the second digital identities, the method 100 may be extended in the following way: The method 100 may comprise receiving data indicating a desired conduct of a second transaction between the first digital identity and the second digital identity from a server hosting a second transaction platform for the second transaction. The method 100 may comprise receiving data indicating an actual conduct of the second transaction, updating the reputation score of the at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction. The method 100 may further comprise storing the updated reputation score in the distributed ledger database.

If the method 100 is used for transactions between differing digital identities, the method 100 may be extended in the following way: The determined reputation score may be for the first digital identity and the method 100 may further comprise receiving data indicating a desired conduct of a second transaction between the first digital identity and at least one third digital identity from the server hosting the (first) transaction platform or a server hosting a second transaction platform for the second transaction. The method 100 may further comprise receiving data indicating an actual conduct of the second transaction and updating the reputation score of the first digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction. The method 100 may further comprise storing the updated reputation score in the distributed ledger database.

Fig- 2 illustrates an example of an apparatus 200 for reputation rating. The apparatus 200 comprises interface circuitry 210. The interface circuitry 210 is configured to receive data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity. The interface circuitry 210 is further configured to receive data indicating an actual conduct of the transaction

The apparatus 200 further comprises processing circuitry 220 configured to determine a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct. The processing circuitry 220 is further configured to store the determined reputation score in a distributed ledger database. The interface circuitry 210 is communicatively coupled to the processing circuitry 220.

For example, the processing circuitry 220 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which or all of which may be shared, a digital signal processor (DSP) hardware, an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The processing circuitry 220 may optionally be coupled to, e.g., read only memory (ROM) for storing software, random access memory (RAM) and/or non-volatile memory.

More details and aspects of the apparatus 200 are explained in connection with the proposed technique or one or more examples described above, e.g., with reference to Fig. 1. The apparatus 200 may comprise one or more additional optional features corresponding to one or more aspects of the proposed technique, or one or more examples described above. The apparatus 200 may be configured to execute a method for reputation rating, such as the method 100.

The apparatus 200 may enable objective reputation rating for digital identities interacting on transaction platforms. The apparatus 200 may immutably store a quantitative, thus, comparable measure for reputation of a digital identity. Reputation may be apparent to the transaction platforms. Thus, the apparatus 200 may build trust in transactions executed on the transaction platforms.

Fig- 3 illustrates another example of an apparatus 300 for reputation rating. The apparatus 300 is connected to a data ecosystem 310. The data ecosystem 310 provides a framework for communication from a first transaction platform 321 (marketplace of domain A) and a second platform 322 (marketplace of domain B) to the apparatus 300 via a computer network. At least one further transaction platform 323 is connected to the data ecosystem 310. The transaction platforms 321, 322, 323 may be hosted by a server or by several servers.

Each of the transaction platforms 321, 322, 323 may comprise computer software and hardware that allow a digital identity (market participant), e.g., an SSI linked to an entity, to enter into a transaction with another digital identity on said transaction platform. The transaction platforms 321, 322, 323 may be web portals offering micro services and may be run by companies. A digital identity may need to be registered on a transaction platform to have access to the transaction services of the transaction platform.

Fig. 3 illustrates several digital identities 330, e.g., a first digital identity 331, (at least one) a second digital identity 332, and (at least one) a third digital identity 333. The digital identi- ties interact with each other via the first transaction platform 321 and/or the second transaction platform 322. To enter into a transaction (e.g., for a transfer of digital assets), the first digital identity 331 may search for a suitable transaction partner (another digital identity) via the first transaction platform 321, e.g., based on a reputation score of possible transaction partners. The first transaction platform 321 may make suggestions about possible transaction partners to the first digital identity 331 which may select the second digital identity 332 as transaction partner. The first digital identity 331 and the second digital identity 332 may enter into negotiations (e.g., in form of offer and counteroffer) on the transaction via the transaction platform. For instance, the transaction platform may provide a smart contract which receives messages signed by the first digital identity 331 or the second digital identity 332. The messages may indicate conditions of the transaction (such as payments) the first digital identity 331 or the second digital identity 332 demands. The messages may be encrypted such that they are solely readable by the respective other digital identity. Some basic, unchangeable conditions of the transaction (such as types of digital goods that can be transferred in the transaction) may be determined by the first transaction platform 321. The conditions may be encoded by rules readable by a code of the smart contract. The rules may be customized for each of the transaction platforms.

If the first digital identity 331 and the second digital identity 332 agree on the conditions, they may confirm the transaction to conclude the smart contract with the respective other digital identity. The smart contract generates data indicating the desired conduct of the transaction based on the conditions of the first transaction platform 321 and the conditions the digital identities agreed on.

The first transaction platform 321 may, then, encrypt the data indicating the desired conduct of the transaction based on a public key provided by the apparatus 300. The public key may be provided by a blockchain-based public-key infrastructure 301 of the apparatus 300. The apparatus 300 may be part of a TEE to secure an intended operation of the apparatus 300. The first transaction platform 321 may send the encrypted data to the apparatus 300. The apparatus 300 is configured to receive the data indicating the desired conduct of the transaction between the first digital identity 321 and the second digital identity 322.

The smart contract of the first transaction platform 321 may monitor a (transaction) behavior of the first digital identity 331 and the second digital identity 332. For instance, the first digital identity 331 and the second digital identity 332 may transfer digital assets as aimed by the transaction via the smart contract, i.e., the smart contract acts as a mediator between the digital identities. The smart contract may record the transfers (e.g., time, sender, recipient, and transferred digital good) associated with the transaction in a distributed ledger database. The smart contract may automatically execute the transfer if possible. For instance, ERC-20 compatible payment tokens may be implemented in the data ecosystem 310; minting and burning of the payment tokens may be administered by the data ecosystem 310. Confidential details of the transfers (i.e., sensitive data) may be encrypted such that they are solely decryptable by the involved digital identities and inside the TEE. Based on the monitored behavior, the first transaction platform 321 may generate data indicating an actual conduct of the transaction and send the data to the apparatus 300.

The apparatus 300 is further configured to receive the data indicating the actual conduct of the transaction. Based on a comparison of the actual conduct and the desired conduct, the apparatus 300 may determine (or update) a first reputation score for the first digital identity 331 and a second reputation score for the second digital identity 332. The apparatus 300 may access a data storage to retrieve a historical reputation score of the digital identities and determine the first and the second reputation score based on the respective historical reputation score.

The apparatus 300 may further be configured to store the determined reputation score in a distributed ledger database. The distributed ledger database may be administered, e.g., by the apparatus 300, by the first transaction platform 321, or jointly by several transaction platforms. The reputation score may be readable, e.g., by the affected first transaction platform 321, by several transaction platforms, or additionally by digital identities registered on the transaction platforms. The reputation score may be tied to the associated digital identity in a reliable way, e.g., based on an attested SSI credential for which the TEE is the attester (issuer).

The first digital identity 331 may further enter into a second transaction with a third digital identity 333 via the second transaction platform 322. The apparatus 300 may then similarly pass through the steps described above for the second transaction. Apparatuses and methods for reputation rating as disclosed herein, such as method 100, apparatus 200 or 300, may allow a determination of an objective measure for reputation earned by a digital identity for its behavior in transactions with other digital identities. The reputation score may be derived by comparing a desired conduct and an actual conduct of transactions. The apparatuses and methods may additionally enable privacy preservation: Even though transaction partners may have to share certain identifiable data such that a rules engine may rate the reputation, their privacy may be preserved by using secure algorithm execution (encryption implemented in a TEE). Only digital identities involved in a transaction may be able to decrypt data disclosing details (secrets) of said transaction, but the derived reputation score and the rules by which the reputation score was accrued may be public information, visible to market participants of a certain digital market.

The apparatuses and methods may enable enforcement of rules defined for a transaction. The apparatuses and methods may provide an unattended system for establishing gamification which incents market participants to strive for a high reputation score. A transaction platform may define rules of how the reputation score is determined and force market participants to stick to these rules by monitoring their behavior. A blockchain may serve as a trusted record of the behavior. The market participants may risk getting cut in remuneration if they fail to follow the rules. By introducing programmable money into a data ecosystem, a “good” behavior (thus, following the rules) may be linked to a transfer of programmable money. Since smart contracts may be used to arrange all the transactions between market participants, there may be no need for a middleman to orchestrate, curate, or cleanse any data.

The following examples pertain to further embodiments:

(1) A method for reputation rating, comprising receiving data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity, receiving data indicating an actual conduct of the transaction, determining a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct, and storing the determined reputation score in a distributed ledger database. (2) The method of (1), wherein the desired conduct of the transaction indicates at least one condition of the transaction to be fulfilled by the at least one of the first digital identity and the second digital identity.

(3) The method of (1), wherein the desired conduct of the transaction indicates a sequence of conditions to be fulfilled by the first digital identity and the second digital identity.

(4) The method of (2) or (3), wherein the data indicating the desired conduct of the transaction further indicate a score value achievable by the at least one of the first digital identity and the second digital identity for fulfilling the at least one condition of the transaction.

(5) The method of (4), wherein determining the reputation score comprises determining whether the at least one condition is fulfilled by the at least one of the first digital identity and the second digital identity, and, if it is determined that the at least one condition is fulfilled, determining the reputation score of the at least one of the first digital identity and the second digital identity based on the score value.

(6) The method of any one of (1) to (5), wherein the reputation score is determined based on at least one of a volume of the transaction, a number of transaction partners of the transaction, a number of prior transactions of the at least one of the first digital identity and the second digital identity, and a number of transaction partners of the prior transactions.

(7) The method of any one of (1) to (6), wherein the reputation score is determined based on a historical reputation score of the at least one of the first digital identity and the second digital identity.

(8) The method of (7), wherein the historical reputation score is based on at least one prior transaction of the at least one of the first digital identity and the second digital identity.

(9) The method of any one of (1) to (8), wherein storing the determined reputation score on the distributed ledger database comprises associating the determined reputation score with the at least one of the first digital identity and the second digital identity. (10) The method of any one of (1) to (9), wherein at least one of receiving the data indicating the desired conduct of the transaction, receiving the data indicating the actual conduct of the transaction and determining the reputation score is executed in a trusted execution environment.

(11) The method of (10), wherein data received by the trusted execution environment is encrypted data, and wherein the encrypted data is solely decryptable inside the trusted execution environment.

(12) The method of any one of (1) to (11), wherein at least one of the data indicating the desired conduct of the transaction and the data indicating the actual conduct of the transaction are received from the distributed ledger database or another distributed ledger database.

(13) The method of any one of (1) to (12), wherein the data indicating the desired conduct of the transaction is received from a server hosting a transaction platform for the transaction.

(14) The method of (13), further comprising receiving data indicating a desired conduct of a second transaction between the first digital identity and the second digital identity from a server hosting a second transaction platform for the second transaction, receiving data indicating an actual conduct of the second transaction, updating the reputation score of the at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction, and storing the updated reputation score in the distributed ledger database.

(15) The method of (13) or (14), wherein the reputation score is for the first digital identity. The method further comprises receiving data indicating a desired conduct of a second transaction between the first digital identity and at least one third digital identity from a server hosting a second transaction platform for the second transaction, receiving data indicating an actual conduct of the second transaction, updating the reputation score of the first digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction, and storing the updated reputation score in the distributed ledger database.

(16) The method of any one of (13) to (15), wherein the reputation score is for the first digital identity. The method further comprises receiving data indicating a desired conduct of a second transaction between the first digital identity and at least one third digital identity from the server hosting the transaction platform, receiving data indicating an actual conduct of the second transaction, updating the reputation score of the first digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction, and storing the updated reputation score in the distributed ledger database.

(17) An apparatus for reputation rating, comprising interface circuitry configured to receive data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity and receive data indicating an actual conduct of the transaction. The apparatus further comprises processing circuitry configured to determine a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct and store the determined reputation score in a distributed ledger database.

(18) A non-transitory machine-readable medium having stored thereon a program having a program code for performing the method of any one of (1) to (16), when the program is executed on a processor or a programmable hardware.

(19) A program having a program code for performing the method of any one of (1) to (16), when the program is executed on a processor or a programmable hardware.

The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor, or other programmable hardware component. Thus, steps, operations, or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and/or contain machine-executable, processorexecutable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

It is further understood that the disclosure of several steps, processes, operations, or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process, or operation may include and/or be broken up into several sub-steps, -functions, -processes or -operations.

If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

Claims What is claimed is:

1. A method for reputation rating, comprising: receiving data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity; receiving data indicating an actual conduct of the transaction; determining a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct; and storing the determined reputation score in a distributed ledger database.

2. The method of claim 1, wherein the desired conduct of the transaction indicates at least one condition of the transaction to be fulfilled by the at least one of the first digital identity and the second digital identity.

3. The method of claim 1, wherein the desired conduct of the transaction indicates a sequence of conditions to be fulfilled by the first digital identity and the second digital identity.

4. The method of claim 2, wherein the data indicating the desired conduct of the transaction further indicate a score value achievable by the at least one of the first digital identity and the second digital identity for fulfilling the at least one condition of the transaction.

5. The method of claim 4, wherein determining the reputation score comprises: determining whether the at least one condition is fulfilled by the at least one of the first digital identity and the second digital identity; and if it is determined that the at least one condition is fulfilled, determining the reputation score of the at least one of the first digital identity and the second digital identity based on the score value.

6. The method of claim 1, wherein the reputation score is determined based on at least one of a volume of the transaction, a number of transaction partners of the transaction, a number of prior transactions of the at least one of the first digital identity and the second digital identity, and a number of transaction partners of the prior transactions.

7. The method of claim 1, wherein the reputation score is determined based on a historical reputation score of the at least one of the first digital identity and the second digital identity.

8. The method of claim 7, wherein the historical reputation score is based on at least one prior transaction of the at least one of the first digital identity and the second digital identity.

9. The method of claim 1, wherein storing the determined reputation score on the distributed ledger database comprises associating the determined reputation score with the at least one of the first digital identity and the second digital identity.

10. The method of claim 1, wherein at least one of receiving the data indicating the desired conduct of the transaction, receiving the data indicating the actual conduct of the transaction and determining the reputation score is executed in a trusted execution environment.

11. The method of claim 10, wherein data received by the trusted execution environment is encrypted data, and wherein the encrypted data is solely decryptable inside the trusted execution environment.

12. The method of claim 1, wherein at least one of the data indicating the desired conduct of the transaction and the data indicating the actual conduct of the transaction are received from the distributed ledger database or another distributed ledger database.

13. The method of claim 1, wherein the data indicating the desired conduct of the transaction is received from a server hosting a transaction platform for the transaction.

14. The method of claim 13 further comprising: receiving data indicating a desired conduct of a second transaction between the first digital identity and the second digital identity from a server hosting a second transaction platform for the second transaction; receiving data indicating an actual conduct of the second transaction; updating the reputation score of the at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction; and storing the updated reputation score in the distributed ledger database.

15. The method of claim 13, wherein the reputation score is for the first digital identity, the method further comprising: receiving data indicating a desired conduct of a second transaction between the first digital identity and at least one third digital identity from a server hosting a second transaction platform for the second transaction; receiving data indicating an actual conduct of the second transaction; updating the reputation score of the first digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction; and storing the updated reputation score in the distributed ledger database.

16. The method of claim 13, wherein the reputation score is for the first digital identity, the method further comprising: receiving data indicating a desired conduct of a second transaction between the first digital identity and at least one third digital identity from the server hosting the transaction platform; receiving data indicating an actual conduct of the second transaction; updating the reputation score of the first digital identity based on a comparison of the actual conduct and the desired conduct of the second transaction; and storing the updated reputation score in the distributed ledger database.

17. An apparatus for reputation rating, comprising: interface circuitry configured to: receive data indicating a desired conduct of a transaction between a first digital identity and at least one second digital identity; receive data indicating an actual conduct of the transaction; and processing circuitry configured to: determine a reputation score for at least one of the first digital identity and the second digital identity based on a comparison of the actual conduct and the desired conduct; and store the determined reputation score in a distributed ledger database.

18. A non-transitory machine-readable medium having stored thereon a program having a program code for performing the method of any one of claims 1 to 16, when the program is executed on a processor or a programmable hardware.

19. A program having a program code for performing the method of any one of claims 1 to 16, when the program is executed on a processor or a programmable hardware.