CN116303803A - Blockchain-based service agreement authorization method, system and medium - Google Patents

Abstract

Disclosed is a service protocol authorization method based on a blockchain, comprising the following steps: a service capability registration operation in which a service capability is registered to the blockchain and a service token is obtained; signing operation of the intermediate party, wherein the service agreement signing transaction of the intermediate party is recorded to the blockchain, and a token of the intermediate party is obtained; and a user signing operation, wherein a service agreement signing transaction of the user is recorded to the blockchain, and a token of the user is obtained. Corresponding systems, devices, and media are also disclosed.

Description

Blockchain-based service agreement authorization method, system and medium

technical field

This application relates to user block chains, and in particular to service agreement authorization methods, systems and media.

Background technique

On the one hand, with the improvement of privacy protection awareness and the improvement of privacy laws and regulations, the authorization and confirmation of users' private data (or personal data, personal information, private information, user data, etc., hereinafter sometimes referred to as "privacy") The requirements for other operations have also become higher.

On the other hand, business scenarios are becoming more and more complex. For example, in some cases, entities that store users' private data (hereinafter sometimes referred to as "private data providers", "data service providers", "service providers" or simply "data providers") and consumers of private data The entities that provide services to users (hereinafter sometimes referred to as "private data consumers", "private data merchants", or "merchant" for short) may be different. For example, entity A (such as a platform entity) may store a large amount of user privacy data, while entity B (such as a small entity) may need to use private data that it does not store in order to provide services to users. At this time, entity B may It is necessary to request private data from entity A under the authorization of the user, so the interaction between the user, the data provider (entity A), and the merchant (entity B) is required. In more complicated cases, there may be one or more channel parties between the data provider and the merchant.

Under current privacy protection requirements and business scenarios, reliable and real-time solutions are required for operations such as authorization, confirmation of rights, anti-tampering, and auditing.

Therefore, there is a need for a solution that can improve user privacy and right confirmation.

Contents of the invention

In order to overcome the defects of the prior art, one or more embodiments of this specification improve user privacy confirmation from multiple perspectives by applying blockchain (especially trusted chain) to user privacy confirmation.

One or more embodiments of this specification achieve the above-mentioned purpose through the following technical solutions.

In one aspect, a blockchain-based service agreement authorization method is provided, the method comprising: a service capability registration operation, wherein the gateway registers the service capability of the service provider to the blockchain and obtains a service token, wherein The service capability is associated with the service agreement; the intermediate party signs the operation, wherein the intermediate party uses the service token or the token of the upper intermediate party to obtain the service agreement from the blockchain and signs the service agreement, the intermediate party The service agreement signing transaction of the gateway or the upper-level intermediary is recorded in the block chain, and the token of the intermediary is obtained; The chain obtains the service agreement and signs the service agreement, and the user's service agreement signing transaction is recorded to the blockchain by the intermediate party, and the user's token is obtained.

Preferably, the service capability registration operation includes: the gateway receives a service registration request from the service provider, the service registration request includes a service code for identifying the service capability and the service agreement; based on the service registration request, by The gateway registers the service capability with the blockchain, wherein the blockchain performs a legality check on the gateway ID of the gateway, and completes the mapping between the gateway ID and the service code; The service token of the block chain, and transmit the service token to the service provider.

Preferably, there are multi-level intermediate parties, and the intermediate party signing operation includes the highest level intermediate party signing operation towards the gateway and the lower level intermediate party signing operation towards the higher level intermediate party, and the user signing operation includes the user signing with the lowest level intermediate party operate.

Preferably, the signing operation of the highest-level intermediary to the gateway includes: requesting the service token from the highest-level intermediary to the gateway; obtaining the service agreement from the blockchain based on the service token by the highest-level intermediary; The intermediate direction of the hierarchy signs the service agreement with the gateway, and the gateway transmits the service agreement signing transaction to the blockchain; the blockchain executes the consensus algorithm to record the service agreement signing transaction, and the blockchain check Verify the legality of the highest-level intermediary ID and the service token, and complete the mapping between the highest-level intermediary ID and the service token; generate the token of the highest-level intermediary by the blockchain and transmit it to the gateway; and communicating, by the gateway, the top-level intermediary's token to the top-level intermediary.

Preferably, the signing operation of the lower-level intermediate party to the higher-level intermediate party includes: the lower-level intermediate party requests the higher-level intermediate party's token from the higher-level intermediate party; the lower-level intermediate party based on the The token obtains the service agreement from the blockchain; the lower-level intermediate party signs the service agreement with the higher-level intermediate party, and the higher-level intermediate party transmits the service agreement signing transaction to the blockchain ; The block chain executes the consensus algorithm to record the service agreement signing transaction, wherein the block chain checks the legitimacy of the lower-level intermediary ID and the token of the higher-level intermediary, and completes the low-level The mapping between the ID of the first-level intermediary and the token of the higher-level intermediary; the token of the lower-level intermediary is generated by the blockchain; the token of the lower-level intermediary is transmitted by the blockchain to the higher-level intermediary; and the lower-level intermediary's token is transmitted by the higher-level intermediary to the lower-level intermediary.

Preferably, the user signing operation includes: the user requests the intermediary for a token of the intermediary, wherein the intermediary is the lowest-level intermediary; the user obtains the service agreement from the blockchain based on the token; The user signs the service agreement to the intermediate party, and the intermediate party transmits the service agreement signing transaction to the blockchain; the blockchain executes the consensus algorithm to record the service agreement signing transaction, in which the district The block chain verifies the legitimacy of the user subject and the token of the intermediary, and completes the mapping between the user subject and the token of the intermediary; the block chain generates the user's token; the block chain transferring the user's token to the intermediary; and transferring the user's token to the user by the intermediary.

Preferably, the method further includes: a right confirmation call operation, wherein the intermediary uses the user's token to request the block chain right confirmation through the gateway, and obtains service data from the service provider based on the right confirmation result.

Preferably, the right confirmation call operation includes: the intermediary uses the user's token to send a service request to the gateway; based on the service request, the gateway sends a right confirmation request to the block chain; the block chain calls The rights confirmation consensus executes rights confirmation, in which the blockchain uses the user's token to obtain the user's user principal, the intermediary's intermediary ID, the gateway's gateway ID, and the service based on the mapping completed in the signing operation. code to check whether the user's user subject, the intermediary ID of the intermediary party, the gateway ID of the gateway, and the service code match the corresponding items in the right confirmation request; The service provider invokes the service capability and forwards the associated service data to the intermediary; and the intermediary uses the service data to provide services to the user.

Preferably, the method further includes: the gateway records the service capability invocation transaction into the block chain.

Preferably, the blockchain is a chain of trust, and the gateway is a trusted gateway.

Preferably, the hash value of the service agreement signing transaction is published on the public domain.

Preferably, the service agreement is a privacy agreement.

In another aspect, a system for authorization of service agreements based on blockchain is provided, the system includes: a service capability registration device, wherein the gateway registers the service capability of the service provider to the blockchain and obtains the service Token, wherein the service capability is associated with the service agreement; the intermediate party signing device, wherein the intermediate party uses the service token or the token of the upper intermediate party to obtain the service agreement from the block chain and sign the service agreement , the service agreement signing transaction of the intermediate party is recorded in the block chain by the gateway or the upper-level intermediate party, and the token of the intermediate party is obtained; and the user signing device, wherein the user utilizes the token of the intermediate party Obtain the service agreement from the block chain and sign the service agreement, the user's service agreement signing transaction is recorded in the block chain by the intermediate party, and the user's token is obtained.

In yet another aspect, a device for authorization of a service agreement based on blockchain is provided, including: a processor; and a memory coupled to the processor, the memory stores processor-executable instructions, and the instructions are stored in When executed by the processor, the processor is caused to perform the method as described above.

In yet another aspect, there is provided a non-transitory processor-readable storage medium comprising processor-executable instructions which, when executed by the processor, cause the processor to perform the method as described above.

Compared with the prior art, one or more embodiments of this specification can achieve one or more of the following technical effects:

The link call is confirmed and opened in real time;

Based on the chain of trust, it has the ability to access the public domain;

Solved the problem of multi-level credit authorization of services, and finally ensured that multi-level private data calls are credible and transitive;

User data will not be retained on the channel side, reducing the risk of privacy leakage;

The commercial secrets of the channel party are protected.

Description of drawings

The above summary of the invention and the following specific implementation methods will be better understood when read in conjunction with the accompanying drawings. It should be noted that the drawings are merely examples of the claimed invention. In the drawings, the same reference numerals represent the same or similar elements.

Fig. 1 shows a schematic diagram of the overall operation of a system for service agreement authorization according to an embodiment of the present specification.

FIG. 2 shows a schematic diagram of an example process for service registration according to an embodiment of the specification.

Fig. 3 shows a schematic diagram of an example process for a subscription operation of a channel-direction gateway according to an embodiment of the present specification.

Fig. 4 shows a schematic diagram of an example process for a merchant to sign a contract with a channel party according to an embodiment of the present specification.

Fig. 5 shows a schematic diagram of an example process for a user to sign a contract with a merchant according to an embodiment of the present specification.

Fig. 6 shows a schematic diagram of an example process for confirming a call according to an embodiment of the present specification.

Fig. 7 shows a schematic flow chart of an example service agreement authorization method based on blockchain according to an embodiment of the present specification.

Fig. 8 shows a schematic flowchart of a system for performing example service agreement authorization based on blockchain according to an embodiment of the present specification.

Fig. 9 shows a schematic block diagram of an apparatus for implementing a method according to one or more embodiments of this specification.

Detailed ways

The content of the following specific embodiments is sufficient for any person skilled in the art to understand and implement the technical content of one or more embodiments of this specification, and according to the description, claims and drawings disclosed in this specification, those skilled in the art Objects and advantages associated with one or more embodiments of the present specification can be readily understood.

As mentioned in the background technology section, with the improvement of privacy protection requirements and the complexity of business scenarios, reliable and real-time solutions are required for operations such as authorization, confirmation, anti-tampering, and auditing of private data.

Some privacy protection schemes have been provided. In most solutions, the data provider and the merchant sign an agreement and perform post-mortem audits to process user privacy data. Some schemes provide more automated processing. For example, in one solution, the data provider provides an API interface, and through the API interface signature verification mechanism, the merchant can use its signature and/or key to request data from the data provider.

However, these solutions still have problems, such as:

First, the user's right confirmation agreement is kept in the merchant's private domain, which is inconvenient for external access and right confirmation inspection. At the same time, there is also the possibility that the merchant tampers with the user's privacy agreement.

Second, it is impossible to perform privacy confirmation in real time, and can only check whether there is any abuse of private data through offline inspection after the event.

Third, at most it solves the problem of B2B (that is, data provider and merchant) right confirmation, but does not solve the problem of B2B2C (that is, data provider and merchant and user) right confirmation.

Fourth, it is difficult to be used in complex scenarios, such as scenarios where there are multi-level contracts (for example, when there are channel parties).

Some embodiments of this specification solve some or all of the above-mentioned problems by applying blockchain to privacy confirmation calls.

Referring to FIG. 1 , it shows a schematic diagram of the overall operation of a system 100 for service agreement authorization according to an embodiment of the present specification.

As shown in FIG. 1 , the system 100 may include a service provider 102 , an intermediary, and a user 106 . An intermediary party may include a merchant 104 and zero or more channel parties (eg, channel party I 108-1 and channel party II 108-2 in FIG. 1). An example where there are two channel parties is shown in the example of FIG. 1 . Intermediaries that are closer to the service provider are called higher-level intermediaries, while intermediaries that are closer to the user are called lower-level intermediaries.

However, it should be understood that there may be one or more channel parties, or the system 100 may include no channel parties. When the system 100 does not include a channel party, the merchant 104 directly interacts with the service provider 102 .

As shown in FIG. 1 , system 100 may include gateway 110 . Gateway 110 will play a key role in privacy assurance, as will be described in detail below. Preferably, the gateway 110 is a trusted gateway.

In order to provide services to the user under the user's authorization (for example, calling the user's private data), two processes are required, namely, the signing process and the rights confirmation calling process. Through the signing process, all parties in the trust chain sign the service agreement in turn and put the signed transaction on the chain; through the confirmation call, it is confirmed that the intermediary (here is the lowest-level intermediary, that is, the merchant) has the right to call relevant data to provide services.

During the authorization signing process, there may be multiple signing consensuses, namely:

Service registration, which involves the contract agreement between the service provider and the gateway;

The signing of the intermediary party includes the signing of the channel party and the signing of the merchant. The signing of the channel party involves the signing agreement between the channel party and the service provider or the superior channel party, and the signing of the merchant involves the signing agreement between the merchant and the channel party; and

User signing, which involves the signing consensus between the user and the merchant.

In the absence of a channel party, the merchant and the service provider directly sign a consensus, namely:

Service registration, which involves the contract agreement between the service provider and the gateway;

Merchant's contract, which involves the signing agreement between the merchant and the service provider; and

User signing, which involves the signing consensus between the user and the merchant.

In the right confirmation process, there may be a right confirmation consensus, which involves the right confirmation call through the gateway based on the signing consensus.

The process of each of the above operations will be described in more detail below.

Depending on the scenario, there may be more or fewer entities, and other types of entities may also exist.

System 100 will utilize blockchain 120 . Preferably, the blockchain 120 is a trusted chain. The trusted chain can be, for example, a public chain or a consortium chain.

Preferably, the blockchain 120 can implement smart contracts. Smart contracts, for example, may include relevant execution logic and conditions, for example, for operations such as verification, authentication, mapping and/or confirmation of rights, as described below.

A blockchain can typically include multiple blockchain nodes. Hereinafter, operations performed by blockchain nodes are sometimes simply referred to as operations performed by blockchains.

In the embodiment of this specification, through signing consensus, various trusted key-value pairs can be uploaded to the chain:

·Gateway ID: service code

· Service Token: Gateway ID

Channel Party ID: Service Token

Channel Party Token: Channel Party ID

· Merchant ID: channel party token

Merchant Token: Merchant ID

User subject: Merchant token

User Token: User Principal

In Fig. 1, two channel parties are shown, so there is also a trusted key-value pair between the lower-level channel party (channel party II 108-2) and the upper-level channel party (channel party I 108-1), where omitted. In this article, trusted key-value pairs may also be referred to as trusted pairs.

It can be seen that through the above method, the chain signing consensus transmission can be realized, so as to ensure that each entity cannot modify the content of the privacy agreement and the signing status.

Through the above-mentioned gateway and blockchain, privacy confirmation can be realized.

In the following, we will introduce each level of signing consensus on-chain process and privacy confirmation call process step by step.

Referring to FIG. 2 , it shows a schematic diagram of an example process of service registration according to an embodiment of this specification.

As shown in Figure 2, the service registration process involves gateways, service providers, and blockchains. The service provider may, for example, provide calls to private data through an Application Programming Interface (API). Specifically, the service provider registers with the gateway service. The core elements of the message transmitted during the service registration process (such as the message transmitted in operation 1.1) are as follows:

Service capabilities can be represented using service codes, for example. Service capabilities can be used, for example, for account risk assessment, anti-cheating in marketing activities, corporate credit assessment, etc. Additional service capabilities may be designed as required.

The user subject may refer to the method used to declare and identify the user, such as the user's identification number, mobile phone number, user name and/or other identification information (such as registered email address, etc.). Through the user subject, when the user signs up, the user can know the dimension based on which the private data query is performed.

Typically, a privacy agreement indicates that the user agrees to a statement of privacy used by the merchant. In some alternative examples, the privacy agreement may include a link to the full text of the privacy agreement that the user is signing up to authorize. Usually, this privacy agreement will be displayed to the user when the user registers or when the user requests to use the service. The privacy agreement will be signed step by step on the blockchain, thereby constituting authorization and constraints on the parties signed on the blockchain.

In addition, the authorization contract may also include other relevant information, such as one or more of the validity period of the privacy agreement, authorization scope, and authorization fee.

Referring to FIG. 2 , it shows a schematic diagram of a service capability registration operation according to an embodiment of this specification. A service capability registry is sometimes referred to simply as a service registry. Preferably, one service provider can provide multiple service capabilities, and/or multiple service providers can register service capabilities with the same gateway.

As shown in FIG. 2 , in operation 1, the service provider may transmit a service registration request to the gateway, so as to initiate a service registration process. For example, the service registration request may include a service code and a service agreement. Preferably, the service registration request can also generally include a user principal.

Optionally, the service registration request may also include other relevant information, such as user rights, service description, service price, service usage restrictions, and the like.

Based on the service registration request, the service capability can be registered to the block chain by the gateway.

Specifically, in operation 1.1, after receiving the service registration request, the gateway may request to record the service registration transaction in the blockchain. As shown in FIG. 1, the request may include, for example, a gateway ID and a service code. Preferably, the request may also include information such as a user subject. The gateway ID refers to an identifier used by the gateway in the system to identify the source of the request.

In operation 1.1.1, the blockchain (specifically, the nodes on the blockchain) may execute a consensus algorithm to record the service registration transaction. Among them, the blockchain can perform legality verification on the gateway ID. After the legality check is passed, the blockchain can complete the mapping between the gateway ID and the service code, thereby generating a trusted key-value pair {gateway ID: service code}. Using this key-value pair, you can easily query the corresponding service code from the gateway ID.

After the legality check is passed, the blockchain can also generate a service token corresponding to the service code. After the service token is generated, another trusted key-value pair {service token: gateway ID} can be generated. Using this key-value pair, you can easily query the corresponding gateway ID from the service token.

At operation 1.1.2, the blockchain may transmit the service token to the gateway. Optionally, the gateway can store the service token locally for later use. In some examples, the return process of the service token usually requires operations such as encryption and signature to ensure the security and reliability of the service token. Preferably, other security measures, such as access control, auditing, etc., may be implemented in the return process of the service token, so as to ensure the security and reliability of the service capability.

In operation 1.1.2.1, after receiving the service token, the gateway determines that the service registration is successful, and may transmit the service token to the service provider. The service provider may store the received service token locally or in other locations, such as cloud storage.

In the following, the content of the signing operation of the intermediate party will be introduced. As mentioned above, the middle party may include zero, one or more channel parties and merchants. For the sake of clarity and conciseness, the following will focus on the contracting operation from the channel party (the highest level channel party, or the merchant if there is no channel party) to the gateway, and from the merchant (the lowest level intermediate party) to the channel party (the lowest level channel party) The signing operation of the user and the signing operation of the user to the merchant (the lowest-level intermediary party), other situations (such as a lower-level channel to a higher-level channel party) can be understood by referring to the introduction below.

Referring to FIG. 3 , it shows a schematic diagram of an example process for a subscription operation of a channel-direction gateway according to an embodiment of the present specification.

Specifically, channel parties can sign up for services based on service tokens. The core elements of the message transmitted by the channel party when signing the consensus (for example, as shown in operation 2.1.3.1) are as follows:

请求服务令牌，渠道方可向网关发起签约请求。例如，该签约请求可包括所选择的服务能力的服务代码。在一些实施例中，可信网关可存储由该数据服务提供方提供的一个或多个服务能力的信息，以供渠道方从中选择。在另一些实施例中，可信网关还可存储由其他数据服务提供方提供的服务能力的信息以供商户选择。网关可基于该服务代码来检索对应的服务令牌，如在前文的服务注册过程中所生成的。优选地，该签约请求还可包括渠道方ID。As shown in FIG. 3 , in operation 2, the channel requests a service token (service_token) from the gateway. pass

To request a service token, the channel party can initiate a signing request to the gateway. For example, the subscription request may include a service code for the selected service capability. In some embodiments, the trusted gateway can store information about one or more service capabilities provided by the data service provider for the channel party to choose from. In other embodiments, the trusted gateway can also store information about service capabilities provided by other data service providers for merchants to choose. Based on the service code, the gateway can retrieve the corresponding service token, as generated during the service registration process above. Preferably, the signing request may also include channel party ID.

In operation 2.1, the gateway may return the service token of the service code to the channel party. Preferably, the trusted gateway can verify the channel party ID to ensure that only authorized channel parties can obtain service tokens to request the service capability. If the verification is passed, the trusted gateway may generate or retrieve a service token corresponding to the service code requested by the channel party, and return it to the channel party.

In operation 2.1.1, after receiving the service token, the channel party can use the service token to request the privacy agreement from the blockchain. The channel party may initiate a request to the blockchain for the privacy protocol, which may include the service token. The request may also include other information such as Channel Party ID and the like.

In operation 2.1.2, the blockchain may transmit the privacy agreement to the channel party. Preferably, before transmitting the privacy agreement, the block chain can first verify the legitimacy of the service token, and only transmit the privacy agreement after the verification is passed.

In operation 2.1.3, the channel party can sign a privacy agreement with the gateway. Before signing the privacy agreement, the channel party can first review the terms of the privacy agreement, as well as other information (for example, validity period, scope of authorization, authorization fee, automatic renewal, compensation for breach of contract, dispute resolution, etc.). For example, a channel party can use its private key to sign a privacy agreement, thereby generating a corresponding signed message. The signed information may include, for example, the channel party's public key, privacy protocol information (such as its hash value), digital signature itself, and the like. After the signed information is generated, the channel can transmit the signed information to the trusted gateway.

In operation 2.1.3.1, the gateway can transmit the privacy agreement signing transaction of the channel party to the blockchain. Specifically, the gateway can package information such as signed information, service tokens, and channel party IDs into transactions, and transmit the transactions to nodes in the blockchain network.

In operation 2.1.3.1.1, the blockchain may execute a consensus algorithm to record the service agreement signing transaction. Among them, the blockchain can verify the legitimacy of channel party IDs and service tokens. After the verification is passed, the blockchain can complete the mapping between the channel party ID and the service token, thereby generating a trusted key-value pair {channel party ID: service token}. Using this key-value pair, the corresponding service token can be easily queried from the channel party ID.

After passing the legality check, the blockchain can also generate a channel party token (ds_token) corresponding to the channel party ID. After the channel party token is generated, another trusted key-value pair {channel party token: channel party ID} can be generated. Using this key-value pair, the corresponding channel party ID can be easily queried from the channel party token.

At operation 2.1.3.1.2, the blockchain may transmit the channel party token to the gateway. Optionally, the gateway can store the service token locally for later use.

At operation 2.1.31.2.1, the Gateway may transmit the Channel Party Token to the Channel Party. Channel parties may store channel party tokens (eg, locally or elsewhere) for subsequent use.

So far, the signing operation between the channel party and the trusted gateway is completed.

Referring to FIG. 4 , it shows a schematic diagram of an example process for a merchant to sign a contract with a channel party according to an embodiment of the present specification. The specific process of signing a contract between a merchant and a channel party is similar to the process of signing a contract between a channel party and a gateway described above in conjunction with Figure 3, in which the operations and information originally related to the channel party in Figure 3 are replaced by operations and information related to the merchant. In Figure 3, the operations and information originally related to the gateway are replaced by the operations and information related to the channel party.

Specifically, merchants can sign up for services based on channel party tokens. The core elements of the message transmitted by the merchant when signing the consensus are as follows:

As shown in Figure 4, in operation 3, the merchant requests the channel party token (ds_token) from the channel party. By requesting the channel party token, the merchant can initiate a signing request to the channel party. Preferably, the subscription request may include a service code of the selected service capability. The channel party may provide multiple service capabilities of one or more service providers, and the subscription request may include selection of the service code of the service capability to be contracted. For example, the service code may correspond to the above service capabilities provided by the service provider. Preferably, the signing request may also include the merchant ID of the merchant.

In operation 3.1, the channel party may return the channel party's channel party token (ds_token) to the merchant. Preferably, the channel side can verify the merchant ID to ensure that only authorized merchants can request the channel side token. If the verification is passed, the channel party can return its own channel party token to the merchant.

In operation 3.1.1, after receiving the channel party token, the merchant can use the channel party token to obtain the privacy agreement from the blockchain. A merchant can initiate a request to the blockchain for a privacy protocol, which can include a channel party token. Preferably, the request may also include other information, such as merchant ID and so on.

At operation 3.1.2, the blockchain may transmit the privacy agreement to the merchant. Preferably, before transmitting the privacy agreement, the block chain can first verify the legitimacy of the channel party token, and transmit the privacy agreement after the verification is passed.

In operation 3.1.3, the merchant can sign a privacy agreement with the channel party. Before signing a privacy agreement, merchants can first review the terms of the privacy agreement, as well as other information (for example, validity period, scope of authorization, authorization fee, automatic renewal, compensation for breach of contract, dispute resolution, etc.). For example, a merchant can use its private key to sign a privacy agreement, thereby generating a corresponding signed message. The signed information may include, for example, the merchant's public key, privacy protocol information (such as its hash value), the digital signature itself, and the like. After generating the signed information, the merchant can transmit the signed information to the channel party.

In operation 3.1.3.1, the channel can record the signing transaction of the merchant's privacy agreement to the blockchain. Specifically, the channel side can package the signed information, service token, merchant ID and other information into a transaction, and transmit the transaction to the nodes in the blockchain network.

At operation 3.1.3.1.1, the blockchain may execute a consensus algorithm to record the service agreement signing transaction. Among them, the blockchain can verify the legitimacy of merchant ID, channel party ID and channel party token. After the verification is passed, the blockchain can complete the mapping of the merchant ID and the channel party token, thereby generating a trusted key-value pair {merchant ID: channel party token}. Using this key-value pair, you can easily query the corresponding channel party token from the merchant ID.

After the legality check is passed, the blockchain can also generate a merchant token (ds_token) corresponding to the merchant ID. After the merchant token is generated, another trusted key-value pair {merchant token: merchant ID} can be generated. Using this key-value pair, the corresponding merchant ID can be easily queried from the merchant token.

At operation 3.1.3.1.2, the blockchain may transmit the merchant token to the channel party.

In operation 3.1.31.2.1, the Channel Party may transmit the Merchant Token to the Merchant. The merchant may store the merchant token (eg, locally or elsewhere) for subsequent use.

So far, the signing operation between the merchant and the channel party is completed.

Referring to FIG. 5 , it shows a schematic diagram of an example process for a user to sign a contract with a merchant according to an embodiment of the present specification. The specific process of signing a contract between a user and a merchant is similar to the signing process described above in conjunction with Figure 3 and Figure 4, only the participants are different.

Specifically, users may sign up for services based on merchant tokens. The core elements of the message transmitted when the user signs the consensus are as follows:

As shown in FIG. 5, in operation 4, the user requests a merchant token (b_token) from the merchant. By requesting the merchant token, the user can initiate a signing request to the merchant. For example, when the user registers with the merchant, or at other times when the user wishes to use the data provided by the data service provider to provide services to the merchant, the user can sign a privacy agreement with the merchant. Preferably, the subscription request may also include the user subject of the user.

At operation 4.1, the merchant may return the merchant's merchant token (b_token) to the user. Preferably, the merchant can verify the user principal to ensure that only authorized users can request the merchant token. If the verification passes, the merchant can return its merchant token to the user.

At operation 4.1.1, after receiving the merchant token, the user may use the merchant token to obtain the privacy agreement from the blockchain. A user can initiate a request to the blockchain for a privacy protocol, which can include a merchant token. Preferably, the request may also include other information, such as a user subject and the like.

At operation 4.1.2, the blockchain may communicate the privacy agreement to the user. Preferably, before transmitting the privacy agreement, the blockchain can first verify the legitimacy of the merchant's token, and then transmit the privacy agreement after the verification is passed.

In operation 4.1.3, the user may sign a privacy agreement with the merchant. Before signing a privacy agreement, users can first review the terms of the privacy agreement, as well as other information (for example, validity period, scope of authorization, authorization fee, automatic renewal, compensation for breach of contract, dispute resolution, etc.). For example, a user may use their private key to sign a privacy agreement, thereby generating a corresponding signed message. The signed information may include, for example, the user's public key, privacy protocol information (such as its hash value), the digital signature itself, and the like. After generating the signed information, the user may transmit the signed information to the merchant.

In operation 4.1.3.1, the merchant can record the transaction of signing the privacy agreement of the user to the blockchain. Specifically, merchants can package information such as signed information, service tokens, and user subjects into transactions, and transmit the transactions to nodes in the blockchain network.

In operation 4.1.3.1.1, the blockchain may execute a consensus algorithm to record the service agreement signing transaction. Among them, the blockchain can verify the legitimacy of the user subject, merchant ID and merchant token. After the verification is passed, the blockchain can complete the mapping between the user subject and the merchant token, thereby generating a trusted key-value pair {user subject: merchant token}. Using this key-value pair, the corresponding merchant token can be easily queried from the user subject.

After passing the legality verification, the blockchain can also generate a user token (c_token) corresponding to the user subject. After the user token is generated, another trusted key-value pair {user token: user principal} can be generated. Using this key-value pair, you can easily query the corresponding user principal from the user token.

So far, the sequence of key-value pairs passed in a chain has been realized, so that based on the user token, the user principal (for example, based on {user token: user principal} key-value pair), merchant token (for example, based on {user principal: Merchant Token} key-value pair), Merchant ID (for example, based on {Merchant Token: Merchant ID} key-value pair), Channel Party Token (for example, based on {Merchant ID: Channel Party Token} key-value pair), Channel Party ID (e.g. based on {channel party token: channel party ID} key-value pair), service token (e.g. based on { channel party ID: service token} key-value pair), gateway ID (e.g. based on { service token: gateway ID} key-value pair), service code (for example, based on {gateway ID: service code} key-value pair).

At operation 4.1.3.1.2, the blockchain may transmit the user token to the merchant.

At operation 4.1.31.2.1, the merchant may transmit the user token to the user. A user may store a user token (eg, locally or elsewhere) for subsequent use.

So far, the signing operation between the user and the merchant is completed.

Through the above operations, the data service provider-intermediary (one or more channel parties and merchants)-user chain signing consensus is completed, so that merchants can use the data services provided by the data service provider to provide users with Serve.

Referring to FIG. 6 , it shows a schematic diagram of an example process for right confirmation calling according to an embodiment of the present specification.

In operation 5, the user may request the merchant to use the service. For example, a user may send a service request to a merchant through channels provided by the merchant (including but not limited to websites, applications, applets, etc.). Typically, the service request may include a user principal and a service code, wherein the user principal identifies the user requesting the service, and the service code identifies the requested service capability. Preferably, the service request may also include a user token. Preferably, the service request may also include additional information such as service period and/or service fee.

At operation 5.1, the merchant may transmit a service request to the gateway. Preferably, after receiving the service request, the merchant can verify the legitimacy of the user principal and/or the service code. If the verification is passed, the merchant can send a service request to the gateway. The service request may include a user principal, merchant ID, user token, and service code. Preferably, the service request may also include other additional information. The merchant ID may identify the merchant providing the service. The user token may come from a service request received from the user, or from the merchant's own storage.

In operation 5.1.1, based on the service request, the gateway may transmit a confirmation request to the blockchain. The gateway can convert the merchant's service request into a right confirmation request, and then send the right confirmation request to the blockchain. The right confirmation request may include, for example, the content of a service request received from a merchant. Preferably, the right confirmation request may also include a gateway ID. The gateway ID identifies the gateway requesting the service.

In operation 5.1.1.1, the blockchain can call the right confirmation consensus to perform right confirmation.

Specifically, the blockchain can use user tokens to obtain relevant information based on mappings. The mapping may, for example, include one or more of the mappings as introduced above. For example, as mentioned above, based on the user token, the user principal (for example, based on {user token: user principal} key-value pair), merchant token (for example, based on {user principal: merchant token} key-value pair ), merchant ID (e.g. based on {merchant token: merchant ID} key-value pair), channel party token (e.g. based on {merchant ID: channel party token} key-value pair), channel party ID (e.g. based on {channel party token: channel party ID} key-value pair), service token (for example based on {channel party ID: service token} key-value pair), gateway ID (for example based on {service token: gateway ID} key-value pair), Service code (e.g. based on {gateway ID: service code} key-value pair). It can be seen that the service code can be obtained from the user token through the chain mapping (or key-value pair) previously established in the signing operation.

Subsequently, the block chain can check one or more of the user principal, merchant ID, gateway ID and service code obtained from the mapping with the corresponding items in the confirmation request (ie, user principal, merchant ID, One or more of the gateway ID and service code) match. If all the verified items match, the verification is passed, and the blockchain right confirmation is passed; otherwise, the right confirmation fails.

In operation 5.1.1.2, the blockchain can transmit the right confirmation result to the gateway. If the right is confirmed in the above right confirmation operation, the blockchain can return the result of the right confirmation to the gateway. The right confirmation result may include a right confirmation ID, for example. The right confirmation result may also include some other information, such as service period, service fee and so on. In some examples, if the right confirmation fails, the blockchain may return the result of the right confirmation failure and possibly other information (such as failure reasons, etc.).

In operation 5.1.1.2.1, based on the confirmation result, the gateway can invoke the service capability to the service provider. For example, after receiving the right confirmation result, the gateway can decide whether to call the service capability to the service provider to obtain the service data according to the right confirmation result. If the confirmation result is received, the gateway may transmit a service request to the service provider to request the service provider to provide service data corresponding to the requested service capability. Preferably, the data service request may include one or more of the user subject, merchant ID, service code and service period, which are used to identify the source and type of the service request. By notifying the data service provider of the confirmation result, the data service provider will use its service capabilities to retrieve or generate service data.

In operation 5.1.1.2.1.1, the service provider may transmit service data to the gateway. After generating the service data, the service provider can transmit the service data to the gateway.

Preferably, in operation 5.1.1.2.1.1.1, the gateway can record the service capability invocation transaction to the blockchain. This operation can be performed before or after the data service provider provides the data service to ensure the traceability and non-tampering of the data service request. Depending on the situation, this action may or may not be performed.

In one example, the data service call transaction may include any suitable combination of the following information: user principal, merchant ID, service code. Preferably, the data service invocation transaction may further include the following information: service period, data service provider ID, data service invocation time and so on.

Data service providers can ensure the legitimacy and accuracy of data service call transactions to avoid unnecessary data leakage and service misuse.

Preferably, the data service provider can perform operations such as data service quality assessment and data service fee settlement based on the data service invocation transaction on the blockchain.

In operation 5.1.1.2.1.1.2, the data service provider may forward the service data to the merchant. The data service can be associated with the user principal and can correspond to the service code. For example, a data service provider may retrieve from its data store the data associated with the user associated with the service code and return that data to the merchant as a data service.

Preferably, operations such as data service fee settlement can be performed between the data service provider and the merchant while or after the data service is provided, and the specific operation depends on the type of service request and the requirements of the merchant.

In operation 5.1.1.2.1.1.2.1, the merchant can use the service data to provide the service to the user. For example, merchants can further process service data, or perform other operations such as verification based on service data, so as to provide service content to users.

In the embodiment of this specification, link calls are confirmed and open in real time: five important consensus protocols, including service registration, channel party signing, merchant signing, user signing, and calling right confirmation, are based on trust chains (public chains, alliance chains), and have public Domain access capabilities, and then serve the real-time privacy confirmation call link, reducing privacy risks.

The embodiment of this specification utilizes a multi-level transfer mechanism, based on the blockchain trusted mechanism to ensure that each contract is credible, uses the transferable mechanism to solve the problem of multi-level credit granting of services, and finally ensures that multi-level private data calls are credible and transferable.

The embodiment of this specification guarantees the legitimate call of user privacy authorization and the trusted gateway confirmation mechanism, and the user data will not be retained on the channel side, reducing the risk of privacy leakage.

The embodiment of this specification is based on the block chain token mechanism signing mechanism and the gateway call right confirmation consensus mechanism to ensure that the customer relationship of the channel party is not leaked (the data service provider, the gateway, etc. cannot obtain the customer relationship), thereby protecting the commercial secrets of the channel party.

Referring to FIG. 7 , it shows a schematic flowchart of an example service agreement authorization method 700 based on blockchain according to an embodiment of the present specification.

As shown in FIG. 7 , the method 700 may include: a service capability registration operation 702 , wherein the gateway registers the service capability of the service provider to the blockchain and obtains a service token, wherein the service capability is associated with a service agreement. Preferably, the block chain can be a chain of trust, and the gateway is a trusted gateway.

Specifically, the service capability registration operation 702 may be performed in the following manner:

The gateway may receive a service registration request from the service provider, where the service registration request includes a service code for identifying the service capability and the service agreement;

Based on the service registration request, the gateway can register the service capability to the blockchain, wherein the blockchain performs a legality check on the gateway ID of the gateway, and completes the mapping between the gateway ID and the service code; as well as

A service token from the blockchain may be received by the gateway and communicated to the service provider.

For specific details of the service capability registration operation, for example, reference may be made to the above description for FIG. 2 .

The method 700 may also include: an intermediary signing operation 704, wherein the intermediary uses the service token or the token of the upper-level intermediary to obtain the service agreement from the block chain and sign the service agreement, the intermediary's service The agreement signing transaction is recorded by the gateway or the upper-level intermediary to the blockchain, and the intermediary's token is obtained.

Preferably, the intermediaries may include multiple levels of intermediaries. For example, the intermediary may include a merchant and 0, 1 or more channel parties, among which the merchant is the lowest-level intermediary, and the channel closest to the gateway (or service provider) is the highest-level intermediary (if there is no channel When the merchant is also the highest-level intermediary), there may be one or more levels of intermediaries between the highest-level intermediary and the lowest-level intermediary.

In this case, the signing operation of the intermediate party includes the signing operation of the highest-level intermediate party to the gateway and the signing operation of the lower-level intermediate party towards the higher-level intermediate party, and the user signing operation includes the operation of the user signing with the lowest-level intermediate party.

Among them, the highest-level intermediate direction gateway signing operation may include, for example:

requesting the service token from the highest-level intermediary to the gateway;

Obtain the service agreement from the blockchain based on the service token by the highest-level intermediary;

The highest-level intermediary signs the service agreement with the gateway, and the gateway transmits the service agreement signing transaction to the blockchain;

The block chain executes the consensus algorithm to record the service agreement signing transaction, wherein the block chain verifies the legality of the highest-level intermediary ID and the service token, and completes the highest-level intermediary ID and the service order Mapping of cards;

A token for the highest-level intermediary is generated by the blockchain and communicated to the gateway; and

The token of the top-level intermediary is passed by the gateway to the top-level intermediary.

Preferably or alternatively, the contracting operation between a lower-level intermediary and a higher-level intermediary may include, for example:

Requesting the token of the higher-level intermediary from the lower-level intermediary to the higher-level intermediary;

Obtain the service agreement from the blockchain based on the token by the lower-level intermediary;

The lower-level intermediary signs the service agreement with the higher-level intermediary, and the higher-level intermediary transmits the service agreement signing transaction to the blockchain;

The blockchain executes the consensus algorithm to record the service agreement signing transaction, wherein the blockchain checks the legitimacy of the lower-level intermediary ID and the token of the higher-level intermediary, and completes the lower-level The mapping between the hierarchical intermediary ID and the token of the higher-level intermediary;

The token of the lower-level intermediary is generated by the blockchain;

transfer of the lower intermediary's token by the blockchain to the higher intermediary; and

The token of the lower-level intermediary is transmitted by the higher-level intermediary to the lower-level intermediary.

Preferably, the service agreement is a privacy agreement.

For specific details of the signing operation of the intermediate party, for example, reference may be made to the above descriptions for FIG. 3 and FIG. 4 .

The method 700 may also include: user signing operation 706, wherein the user obtains the service agreement from the blockchain using the token of the intermediary and signs the service agreement, and the user's service agreement signing transaction is recorded by the intermediary to the blockchain, and get the user's token.

User sign-up operations may include, for example:

The user requests the intermediary's token from the intermediary, where the intermediary is the lowest-level intermediary;

The user obtains the service agreement from the blockchain based on the token;

The user signs the service agreement to the intermediary, and the intermediary transmits the service agreement signing transaction to the blockchain;

The block chain executes the consensus algorithm to record the service agreement signing transaction, wherein the block chain verifies the legitimacy of the user subject and the intermediate party's token, and completes the user subject and the intermediate party's token the mapping;

The user's token is generated by the blockchain;

transfer of the user's token by the blockchain to the intermediary; and

The user's token is transferred to the user by the intermediary.

For specific details of the user signing operation, for example, reference may be made to the above description for FIG. 5 .

Preferably, the method 700 may further include: right confirmation call operation 708, wherein the intermediary uses the user's token to request the block chain right confirmation through the gateway, and obtains services from the service provider based on the right confirmation result data.

Specifically, the right confirmation calling operation 708 may include:

The intermediary uses the user's token to transmit a service request to the gateway;

Based on the service request, the gateway sends a confirmation request to the blockchain;

The blockchain calls the right confirmation consensus to perform right confirmation, wherein the blockchain uses the user's token to obtain the user's user subject, the intermediary ID of the intermediary, and the gateway based on the mapping completed in the signing operation. gateway ID and the service code to check whether the user’s user subject, the intermediary party’s ID, the gateway’s gateway ID and the service code match the corresponding items in the right confirmation request;

Based on the confirmation result, the gateway invokes the service capability to the service provider and forwards the associated service data to the intermediary; and

The service data is provided by the intermediary to the user.

Preferably, the gateway can record the service capability invocation transaction to the block chain.

Preferably, the hash value of the service agreement signing transaction (including the service agreement signing transaction of each party) can be published on the public domain.

For specific details of the user's subscription operation, for example, refer to the above description for FIG. 6 .

Referring to FIG. 8 , it shows a schematic flowchart of a system 800 for authorization of an example service agreement based on blockchain according to an embodiment of the present specification.

As shown in FIG. 8 , the system 800 may include: a service capability registration device 802, wherein the gateway registers the service capability of the service provider to the blockchain and obtains a service token, wherein the service capability is associated with a service agreement. Preferably, the block chain can be a chain of trust, and the gateway is a trusted gateway. For the operation of this device, reference may be made to the description of the service capability registration operation 702 above.

The system 800 may also include: an intermediary signing device 804, wherein the intermediary uses the service token or the token of the upper intermediary to obtain the service agreement from the block chain and sign the service agreement, the intermediary's service The agreement signing transaction is recorded by the gateway or the upper-level intermediary to the blockchain, and the intermediary's token is obtained. For the operation of this device, reference may be made to the description of the intermediary signing operation 704 above.

The system 800 may also include: a user signing device 806, wherein the user uses the intermediary's token to obtain the service agreement from the blockchain and signs the service agreement, and the user's service agreement signing transaction is recorded by the intermediary to the blockchain, and get the user's token. For the operation of this device, reference may be made to the description of the user subscription operation 706 above.

Preferably, the system 800 may further include: right confirmation calling means 808, wherein the intermediary uses the user's token to request the block chain right confirmation through the gateway, and obtains services from the service provider based on the right confirmation result data. For the operation of this device, reference may be made to the description of the user subscription operation 708 above.

Fig. 9 shows a schematic block diagram of an apparatus 900 for implementing a method according to one or more embodiments of this specification. The apparatus may be used to implement, for example, a method as described herein (eg, method 700 ) or to implement a system as described herein (eg, system 800 ). The apparatus may also be implemented as any of the computing nodes or clusters of computing nodes described herein (eg, through virtualization, etc.). The apparatus may include a processor 910 configured to perform any of the methods described above, and a memory 915 . This storage may include internal memory and/or persistent storage. The memory may also be used to store any instructions, variables, intermediate data, etc. that may be used during execution of the method.

The apparatus 900 may include a network connection element 925, which may include, for example, a network connection device that connects to other devices through a wired connection or a wireless connection. The wireless connection may be, for example, a WiFi connection, a Bluetooth connection, a 3G/4G/5G network connection, and the like. For example, the network connection element can be connected to the network to obtain relevant data, instructions and other various data. User input from other devices may also be received or data transmitted to other devices for display via the network connection element.

The device also optionally includes other peripheral components 920, such as input devices (eg, keyboard, mouse), output devices (eg, display), and the like. For example, in a user input based method, a user may perform an input operation via an input device. Corresponding information can also be output to the user via the output device.

Each of these modules may communicate with each other directly or indirectly, eg, via one or more buses (eg, bus 905).

Furthermore, the present application discloses a computer-readable storage medium including stored thereon computer-executable instructions that, when executed by a processor, cause the processor to perform the various implementations described herein. example method.

In addition, the present application discloses an apparatus comprising a processor and a memory storing computer-executable instructions that, when executed by the processor, cause the processor to perform various implementations described herein. example method.

In addition, the present application also discloses a system, which includes devices for implementing the methods of the various embodiments described herein.

It can be understood that the method according to one or more embodiments of the present specification can be implemented by software, firmware or a combination thereof.

It should be understood that each embodiment in this specification is described in a progressive manner, the same or similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments . In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for relevant parts, refer to the part of the description of the method embodiments.

It should be understood that the foregoing describes specific embodiments of the present specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

It should be understood that describing an element herein in the singular or showing only one in a drawing does not mean limiting the number of that element to one. Furthermore, modules or elements described or illustrated herein as separate may be combined into a single module or element, and modules or elements described or illustrated herein as a single may be split into a plurality of modules or elements.

It should also be understood that the terms and expressions used herein are for description only, and one or more embodiments of this specification should not be limited to these terms and expressions. The use of these terms and expressions does not mean to exclude any equivalent features shown and described (or parts thereof), and it should be recognized that various modifications may also be included within the scope of the claims. Other modifications, changes and substitutions may also exist. Accordingly, the claims should be read to cover all such equivalents.

Similarly, it should be pointed out that although the description has been made with reference to the current specific embodiments, those of ordinary skill in the art should recognize that the above embodiments are only used to illustrate one or more embodiments of this specification, Various equivalent changes or replacements can also be made without departing from the spirit of the present invention. Therefore, as long as the changes and modifications to the above-mentioned embodiments are within the scope of the spirit of the present invention, they will all fall within the claims of the present application. within the scope of the book.

Claims (15)

1. A blockchain-based service agreement authorization method, said method comprising: A service capability registration operation, wherein the gateway registers the service capability of the service provider to the blockchain and obtains a service token, wherein the service capability is associated with a service agreement; The signing operation of the intermediate party, wherein the intermediate party uses the service token or the token of the upper-level intermediate party to obtain the service agreement from the blockchain and sign the service agreement, and the service agreement of the intermediate party is signed transactions are recorded to the blockchain by the gateway or the upper-level intermediary, and the intermediary's token is obtained; and User signing operation, wherein the user uses the intermediary's token to obtain the service agreement from the blockchain and signs the service agreement, and the user's service agreement signing transaction is recorded by the intermediary to the blockchain, and obtain said user's token. 2. The method according to claim 1, wherein the service capability registration operation comprises: receiving, by the gateway, a service registration request from the service provider, where the service registration request includes a service code for identifying the service capability and the service agreement; Based on the service registration request, the gateway registers the service capability to the block chain, wherein the block chain performs a legality check on the gateway ID of the gateway, and completes the verification of the gateway ID and a mapping of said service codes; and A service token from the blockchain is received by the gateway and communicated to the service provider. 3. The method according to claim 2, wherein there are multi-level intermediate parties, and the intermediate party signing operation includes the highest level intermediate direction gateway signing operation and the lower level intermediate direction higher level intermediate party signing operation, and the The user signing operation includes the user signing operation with the lowest-level intermediate party. 4. The method according to claim 3, wherein the signing operation of the highest-level intermediate direction gateway comprises: requesting said service token from said highest level intermediary to said gateway; obtaining, by the highest-level intermediary, the service agreement from the blockchain based on the service token; signing the service agreement by the highest-level intermediate direction to the gateway, and sending the service agreement signing transaction to the blockchain by the gateway; The consensus algorithm is executed by the block chain to record the signing transaction of the service agreement, wherein the block chain verifies the legality of the highest-level intermediary ID and the service token, and completes the highest-level intermediary a mapping between a party ID and the service token; generating a token of the highest-level intermediary by the blockchain and transmitting it to the gateway; and The token of the highest-level intermediary is communicated by the gateway to the highest-level intermediary. 5. The method according to claim 3, wherein the signing operation of the intermediate party at the lower level to the intermediate party at the higher level comprises: requesting a token from the higher-level intermediary from the lower-level intermediary to the higher-level intermediary; obtaining the service agreement from the blockchain based on the token by the lower-level intermediary; Signing the service agreement by the lower-level intermediate party to the higher-level intermediate party, and sending the service agreement signing transaction to the blockchain by the higher-level intermediate party; Executing a consensus algorithm by the block chain to record the signing transaction of the service agreement, wherein the block chain checks the legitimacy of the lower-level intermediary ID and the token of the higher-level intermediary, And complete the mapping between the ID of the lower-level intermediary and the token of the higher-level intermediary; generating a token of the lower-level intermediary by the blockchain; transferring the lower-level intermediary's token to the higher-level intermediary by the blockchain; and The token of the lower-level intermediary is transferred by the higher-level intermediary to the lower-level intermediary. 6. The method of claim 1, wherein the user subscription operation comprises: requesting, by the user, the intermediary's token from the intermediary, wherein the intermediary is the lowest level intermediary; obtaining, by the user, the service agreement from the blockchain based on the token; The user signs the service agreement to the intermediate party, and the intermediate party transmits the service agreement signing transaction to the blockchain; Executing a consensus algorithm by the block chain to record the signing transaction of the service agreement, wherein the block chain verifies the legitimacy of the user subject and the token of the intermediary party, and completes the transaction between the user subject and the intermediary a mapping of the intermediary's tokens; generating said user's token by said blockchain; transferring, by the blockchain, the user's token to the intermediary; and The user's token is transferred to the user by the intermediary. 7. The method of claim 1, further comprising: Right confirmation call operation, wherein the intermediary uses the user's token to request the block chain right confirmation through the gateway, and obtains service data from the service provider based on the right confirmation result. 8. The method according to claim 7, wherein the calling operation of right confirmation comprises: transmitting a service request to said gateway by an intermediary using said user's token; Based on the service request, the gateway transmits a right confirmation request to the blockchain; The blockchain invokes the right confirmation consensus to perform the right confirmation, wherein the blockchain uses the user's token to obtain the user's user subject and the intermediate party's intermediate information based on the mapping completed in the signing operation. Party ID, the gateway ID of the gateway, and the service code to verify the user principal of the user, the intermediary ID of the intermediary party, the gateway ID of the gateway, the service code and the confirmation Whether the corresponding item in the request matches; The gateway invokes a service capability to the service provider based on the confirmation result and forwards the associated service data to the intermediary; and A service is provided to the user by the intermediary using the service data. 9. The method of claim 8, further comprising: The gateway records the service capability invocation transaction into the block chain. 10. The method of claim 1, wherein the blockchain is a chain of trust and the gateway is a trusted gateway. 11. The method of claim 10, wherein the hash value of the service agreement signing transaction is published on the public domain. 12. The method of claim 1, wherein the service agreement is a privacy agreement. 13. A system for authorization of service agreements based on blockchain, said system comprising: A service capability registration device, wherein the gateway registers the service capability of the service provider to the block chain and obtains a service token, wherein the service capability is associated with a service agreement; The intermediate party signing device, wherein the intermediate party uses the service token or the token of the upper intermediate party to obtain the service agreement from the block chain and sign the service agreement, and the service agreement of the intermediate party is signed transactions are recorded to the blockchain by the gateway or the upper-level intermediary, and the intermediary's token is obtained; and The user signing device, wherein the user uses the intermediary's token to obtain the service agreement from the blockchain and signs the service agreement, and the user's service agreement signing transaction is recorded by the intermediary to the blockchain, and obtain said user's token. 14. A device for authorization of service agreements based on blockchain, comprising: processor; and A memory coupled to the processor, the memory storing processor-executable instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-12 method. 15. A non-transitory processor-readable storage medium comprising processor-executable instructions that, when executed by the processor, cause the processor to perform the Methods.

Images