CN116303803A

CN116303803A - Service protocol authorization method, system and medium based on block chain

Info

Publication number: CN116303803A
Application number: CN202310452138.4A
Authority: CN
Inventors: 胡锦华; 张凯隆; 刘雷
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-04-24
Filing date: 2023-04-24
Publication date: 2023-06-23

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

Service protocol authorization method, system and medium based on block chain

Technical Field

The present application relates to user blockchains, and more particularly, to service agreement authorization methods, systems, and media.

Background

On the one hand, with the improvement of privacy protection consciousness and the improvement of privacy laws and regulations, the demands for operations such as authorization, and the like of privacy data (or personal data, personal information, privacy information, user data, and the like, hereinafter sometimes simply referred to as "privacy") of users are becoming higher.

On the other hand, business scenarios are becoming more and more complex. For example, in some cases, an entity storing private data of a user (hereinafter sometimes referred to as a "private data provider", "data service provider", "service provider", or simply "data provider") and an entity consuming private data to provide services to the user (hereinafter sometimes referred to as a "private data consumer", "private data merchant", or simply "merchant") may be different. For example, entity a (e.g., a platform-type entity) may store a large amount of user privacy data, while entity B (e.g., a small entity) may need to use privacy data that is not itself stored in order to provide a service to the user, at which point entity B may need to request privacy data from entity a with user authorization, thus requiring interaction by three parties of the user, the data provider (entity a), and the merchant (entity B). In more complex cases, there may also be one or more channels between the data provider and the merchant.

Under the current privacy protection requirements and service scenes, the operations of authorization, tamper resistance, inspection and the like all need a reliable scheme with high real-time performance.

Therefore, a scheme capable of improving user privacy right is required.

Disclosure of Invention

To overcome the deficiencies of the prior art, one or more embodiments of the present specification improve user privacy validation from a number of perspectives by applying blockchains (and in particular, trusted chains) to user privacy validation.

One or more embodiments of the present specification achieve the above objects by the following technical means.

In one aspect, there is provided a blockchain-based service protocol authorization method, the method comprising: a service capability registration operation in which a service capability of a service provider is registered with the blockchain and a service token is obtained by a gateway, wherein the service capability is associated with a service agreement; an intermediary signing operation, wherein the intermediary obtains the service agreement from the blockchain and signs the service agreement by using the service token or the token of the upper intermediary, the service agreement signing transaction of the intermediary is recorded to the blockchain by the gateway or the upper intermediary, and the token of the intermediary is obtained; and a user signing operation, wherein the user obtains the service agreement from the blockchain and signs the service agreement by using a token of an intermediate party, the service agreement signing transaction of the user is recorded to the blockchain by the intermediate party, and the token of the user is obtained.

Preferably, the service capability registration operation includes: receiving, by the gateway, a service registration request from the service provider, the service registration request including a service code for identifying the service capability and the service agreement; based on the service registration request, registering the service capability to the blockchain by the gateway, wherein the blockchain performs validity check on a gateway ID of the gateway and completes mapping of the gateway ID and the service code; and receiving, by the gateway, a service token from the blockchain and transmitting the service token to the service provider.

Preferably, there are multiple levels of intermediaries, and the intermediaries subscription operation includes a gateway subscription operation of a highest level intermediaries and an intermediaries subscription operation of a higher level than the lower level intermediaries, and the user subscription operation includes a subscription operation of the user to the lowest level intermediaries.

Preferably, the highest-level middle-direction gateway subscription operation includes: requesting the service token from the gateway by the highest level intermediary; obtaining, by the highest-level intermediary, the service agreement from the blockchain based on the service token; signing the service agreement by the gateway to the highest level intermediary and transmitting the service agreement signing transaction by the gateway to the blockchain; executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the validity of the highest-level intermediate party ID and the service token and completes the mapping of the highest-level intermediate party ID and the service token; generating a token for the highest level intermediary by the blockchain and transmitting it to the gateway; and transmitting, by the gateway, the token of the highest-level intermediary to the highest-level intermediary.

Preferably, the lower-level intermediary direction higher-level intermediary subscription operation includes: requesting a token of the higher hierarchical intermediary from the lower hierarchical intermediary to the higher hierarchical intermediary; obtaining, by the lower level intermediary, the service agreement from the blockchain based on the token; signing the service agreement by the lower level intermediary party to the higher level intermediary party and transmitting the service agreement signing transaction to the blockchain by the higher level intermediary party; executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the lower-level intermediate party ID and the token of the higher-level intermediate party and completes the mapping of the lower-level intermediate party ID and the token of the higher-level intermediate party; generating a token for the lower level intermediary by the blockchain; transmitting, by the blockchain, the token of the lower level intermediary to the upper level intermediary; and transmitting, by the higher-level intermediary, the token of the lower-level intermediary to the lower-level intermediary.

Preferably, the user signing operation includes: requesting, by the user, a token of an intermediary party from the intermediary party, wherein the intermediary party is a lowest level intermediary party; obtaining, by the user, the service agreement from the blockchain based on the token; signing the service agreement by the user to the intermediary party and transmitting the service agreement signing transaction by the intermediary party to the blockchain; executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the tokens of the user body and the intermediate party and completes the mapping of the tokens of the user body and the intermediate party; generating a token for the user by the blockchain; transmitting, by the blockchain, the token of the user to the intermediary; and transmitting, by the intermediary, the user's token to the user.

Preferably, the method further comprises: an acknowledgement call operation in which the blockchain acknowledgement is requested by the intermediary through the gateway using the user's token and service data is obtained from the service provider based on the result of the acknowledgement.

Preferably, the right invoking operation includes: transmitting, by the intermediary, a service request to the gateway using the token of the user; transmitting, by the gateway, an acknowledgement request to the blockchain based on the service request; invoking an acknowledgement consensus by the blockchain to perform an acknowledgement, wherein the blockchain uses the token of the user to obtain a user principal of the user, an intermediary party ID of the intermediary party, a gateway ID of the gateway, and the service code based on the mapping done in the signing operation to verify whether the user principal of the user, the intermediary party ID of the intermediary party, the gateway ID of the gateway, and the service code match corresponding items in the acknowledgement request; the gateway, based on the result of the validation, invoking service capabilities to the service provider and forwarding associated service data to the intermediary party; and providing, by the intermediary, a service to the user using the service data.

Preferably, the method further comprises: service capability invocation transactions are recorded by the gateway to the blockchain.

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

Preferably, the hash value of the service agreement signed transaction is disclosed on the public domain.

Preferably, the service protocol is a privacy protocol.

In another aspect, a system for blockchain-based service agreement authorization is provided, the system comprising: a service capability registration device, wherein a gateway registers a service capability of a service provider to the blockchain and obtains a service token, wherein the service capability is associated with a service agreement; an intermediary signing device, wherein the intermediary obtains the service agreement from the blockchain by using the service token or the token of the upper intermediary and signs the service agreement, the service agreement signing transaction of the intermediary is recorded to the blockchain by the gateway or the upper intermediary, and the token of the intermediary is obtained; and a user signing device, wherein the service agreement is obtained from the blockchain and signed by the user by using a token of an intermediate party, the service agreement signing transaction of the user is recorded to the blockchain by the intermediate party, and the token of the user is obtained.

In yet another aspect, an apparatus for blockchain-based service agreement authorization is provided, comprising: a 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 as described above.

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

In contrast to the prior art, one or more embodiments of the present description are capable of achieving one or more of the following technical effects:

the link call real-time rights and opens;

the public domain access capability is provided based on the trust chain;

the service multi-level trust problem is solved, and finally the multi-level privacy data call is ensured to have credibility and transitivity;

user data cannot be reserved in a channel side, so that the risk of privacy disclosure is reduced;

the channel side's business secret is protected.

Drawings

The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the appended drawings. It is to be noted that the drawings are merely examples of the claimed invention. In the drawings, like reference numbers indicate identical or similar elements.

Fig. 1 shows an overall operation schematic 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 present description.

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 description.

Fig. 4 shows a schematic diagram of an example process for a merchant's subscription operation with a channel side according to an embodiment of the present description.

Fig. 5 shows a schematic diagram of an example process for a user's sign-up operation with a merchant, according to an embodiment of the present description.

Fig. 6 shows a schematic diagram of an example process for an authorization call, according to an embodiment of the present description.

Fig. 7 shows a schematic flow chart diagram of an example service agreement authorization method for blockchain-based in accordance with embodiments of the present description.

Fig. 8 shows a schematic flow chart of a system for exemplary service protocol authorization based on blockchain in accordance with embodiments of the present description.

Fig. 9 shows a schematic block diagram of an apparatus for implementing a method in accordance with one or more embodiments of the present description.

Detailed Description

The following detailed description is presented to enable any person skilled in the art to make and use the teachings of one or more embodiments of the present disclosure and to enable those skilled in the art to readily understand the objects and advantages associated with one or more embodiments of the present disclosure based on the disclosure, claims and drawings disclosed herein.

As described in the background section, with the improvement of privacy protection requirements and the complexity of service scenarios, reliable and real-time schemes are required for operations such as authorization, tamper resistance, auditing, etc. of private data.

Some privacy preserving schemes have been provided. In most schemes, user privacy data is processed by means of a data provider and merchant signing an agreement and performing post-hoc auditing. Some schemes provide for more automated processing. For example, in one approach, an API interface is provided by the data provider through which a merchant may utilize its signature and/or key, etc., to request data from the data provider.

However, these solutions still have problems, such as:

the first, user's authentication protocol remains in the merchant's private domain, inconvenient external access and authentication checking, and there is also the possibility that the merchant will tamper with the user's privacy protocol.

Secondly, privacy right cannot be executed in real time, and whether abuse of the privacy data exists can only be checked through an after-the-fact offline inspection mode.

Third, the issue of B2B (i.e., data provider and merchant) validation is at most solved, while the issue of B2C (i.e., data provider and merchant and user) validation is not solved.

Fourth, it is difficult to use for complex scenarios, such as scenarios where there are multiple levels of subscription (e.g., where there are channels).

Some embodiments of the present description address some or all of the above problems by applying blockchains to privacy right calls.

Referring to fig. 1, an overall operational schematic diagram of a system 100 for service agreement authorization is shown, according to an embodiment of the present description.

As shown in fig. 1, the system 100 may include a service provider 102, an intermediary, and a user 106. The intermediary party may include one merchant 104 and zero or more of the parties (e.g., party I108-1 and party II 108-2 in FIG. 1). An example in which there are two chandeliers is shown in the example of fig. 1. The intermediary closer to the service provider is referred to as the higher-level intermediary, while the intermediary more simply from the user is referred to as the lower-level intermediary.

However, it should be understood that there may be one or more chandeliers, or the system 100 may not include a channel. Where the system 100 does not include a channel side, the merchant 104 interfaces directly 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 validation as will be described in detail below. Preferably, the gateway 110 is a trusted gateway.

In order to provide a service to a user under the authorization of the user (e.g., invoking the user's privacy data), two procedures are required, namely a subscription procedure and an entitlement invocation procedure. Through the signing process, each party on the trust chain signs the service agreement in turn and links the signed transaction; by confirming the invocation of the right, the intermediary (here the lowest level intermediary, i.e. the merchant) is confirmed to have authority to invoke the relevant data to provide the service.

In authorizing a subscription, there may be multiple subscription consensus, namely:

service registration, which involves subscription consensus of the service provider with the gateway;

an intermediate party subscription including a channel party subscription and a merchant subscription, the channel party subscription involving a subscription consensus of the channel party with a service provider or superior channel party, and the merchant subscription involving a subscription consensus of the merchant with the channel party; and

a user subscription that involves a subscription consensus of the user with the merchant.

In the absence of a channel side, merchants and service providers directly sign up for consensus, namely:

merchant subscriptions that relate to a subscription consensus of a merchant with a service provider; and

In the validation process, there may be validation consensus that involves making validation calls based on the subscription consensus through the gateway.

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

Depending on the particular scenario, there may be more or fewer entities, as well as other types of entities.

The system 100 will utilize a blockchain 120. Preferably, the blockchain 120 is a trusted chain. The trusted chain may be, for example, a public chain or a federated chain.

Preferably, the blockchain 120 may implement a smart contract. The smart contracts may include, for example, relevant execution logic and conditions, e.g., for performing verification, authentication, mapping, and/or validation operations, as described below.

A blockchain may generally include a plurality of blockchain nodes. Hereinafter, operations performed by the blockchain link points are sometimes referred to as simply performing operations by the blockchain.

In the present embodiment, through subscription consensus, a variety of trusted key-value pairs may be uplink:

gateway ID: service code

Service token: gateway ID

Channel side ID: service token

Channel Fang Lingpai: channel side ID

Merchant ID: channel side token

Merchant token: merchant ID

User principal: merchant token

User token: user main body

Two of the chandeliers are shown in fig. 1, so there is also a trusted key value pair between the subordinate channel side (channel side II 108-2) and the superior channel side (channel side I108-1), omitted here. The trusted key-value pair may also be referred to herein as a trusted pair.

It can be seen that by the above manner, chained subscription consensus transfer can be realized, so that each entity can be ensured that the content and subscription state of the privacy agreement cannot be modified.

Privacy rights can be achieved through the gateway and blockchain.

Hereinafter, a subscription consensus uplink procedure and a privacy right invoking procedure of each stage will be described step by step.

Referring to fig. 2, a schematic diagram of an example process of service registration according to an embodiment of the present description is shown.

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

the service capability may be represented using a service code, for example. The service capability may be used, for example, for account risk assessment, anti-cheating in marketing campaigns, enterprise credit assessment, and the like. Other service capabilities may be designed as desired.

A user agent may refer to a means by which a user is declared to be identified, such as an identification number of the user, a cell phone number, a user name, and/or other identifying information (e.g., a registered mailbox, etc.). Through the user principal, the user is made aware of what dimensions he is based on when he signs up for private data queries.

In general, a privacy agreement represents a statement that a user wants to agree to the privacy used by a merchant. In some alternative examples, the privacy agreement may include a link to the full text of the privacy agreement for which the user is to sign up for authorization. Typically, the privacy protocol will be exposed to the user upon registration of the user or upon a request by the user to use the service. The privacy agreement will sign up step by step on the blockchain, thus constituting authorizations and constraints for parties signed up on the blockchain.

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

Referring to fig. 2, a schematic diagram of a service capability registration operation according to an embodiment of the present specification is shown. Service capability registration may also sometimes be referred to simply as service registration. Preferably, one service provider may provide multiple service capabilities and/or multiple service providers may register the service capabilities with the same gateway.

As shown in fig. 2, a service registration request may be transmitted to a gateway by a service provider in order to initiate a service registration procedure in operation 1. For example, the service registration request may include a service code and a service protocol. Preferably, the service registration request may also generally include a user principal.

Optionally, the service registration request may also include other relevant information such as the user's rights, description of the service, price of the service, usage restrictions of the service, etc.

Based on the service registration request, the service capability may be registered with the blockchain by a gateway.

Specifically, at operation 1.1, upon receiving the service registration request, the gateway may request that the service registration transaction be recorded to the blockchain. As shown in fig. 1, the request may include, for example, a gateway ID and a service code. Preferably, the request may further include information such as a user body. The gateway ID refers to an identifier used by the gateway in the system to identify the source of the request.

At operation 1.1.1, a blockchain (specifically, a node on the blockchain) may execute a consensus algorithm to record the service registration transaction. Wherein the blockchain may perform a validity check on the gateway ID. After the validity check passes, the blockchain may complete the mapping of the gateway ID and the service code, thereby generating a trusted key value pair { gateway ID: service code }. With the key value pair, a corresponding service code can be conveniently queried from the gateway ID.

After the validity check passes, the blockchain may also generate a service token corresponding to the service code. After generating the service token, another trusted key-value pair { service token: gateway ID }. With this key-value pair, the corresponding gateway ID can be conveniently queried from the service token.

In operation 1.1.2, the blockchain may communicate the service token to the gateway. Alternatively, the gateway may store the service token locally for later use. In some examples, the return process of the service token typically requires encryption and signing operations to ensure the security and reliability of the service token. Preferably, the return process of the service token may also take other security measures, such as access control, auditing, etc., to ensure the security and reliability of the service capability.

After the gateway receives the service token, the gateway determines that the service registration was successful and may transmit the service token to the service provider in operation 1.1.2.1. The service provider may store the received service token locally or in another location, such as cloud storage or the like.

Hereinafter, the contents of the intermediate party subscription operation will be described. As described above, the intermediary may include 0, 1, or more channels and merchants. For clarity and brevity, the description of signing operations of a channel side (highest-level channel side, in the case where no channel side exists, a merchant) to a gateway, signing operations of a merchant (lowest-level middle side) to a channel side (lowest-level middle side), and signing operations of a user to a merchant (lowest-level middle side) will be focused hereinafter, and other situations (e.g., a lower-level channel side to a higher-level channel side) will be understood with reference to the description below.

Referring to fig. 3, a schematic diagram of an example process for a subscription operation of a channel direction gateway according to an embodiment of the present description is shown.

Specifically, the channel party may sign up for the service based on the service token. The core elements of the message transmitted when the channel side signs up for consensus (e.g. as shown in operation 2.1.3.1) are as follows:

as shown in fig. 3, a service token (service token) is requested by a channel direction gateway in operation 2. By passing through

Requesting a service token, the channel side may initiate a subscription request to the gateway. For example, the subscription request may include a service code of the selected service capability. In some embodiments, the trusted gateway may store information of one or more service capabilities provided by the data service provider for the channel side to select from. In other embodiments, the trusted gateway may also store information of service capabilities provided by other data service providers for selection by merchants. The gateway may retrieve the corresponding service token based on the service code, as generated in the foregoing service registration process. Preferably, the subscription request may further include a channel side ID.

In operation 2.1, the gateway may return a service token for the service code to the issuer. Preferably, the trusted gateway may verify the channel side ID to ensure that only authorized channel sides can obtain the service token to request the service capability. If the verification passes, the trusted gateway may generate or retrieve a service token corresponding to the service code requested by the channeling party and return it to the channeling party.

At operation 2.1.1, after receiving the service token, the channel side may request a privacy agreement from the blockchain using the service token. The channel side may initiate a request for a privacy agreement to the blockchain, which may include the service token. The request may also include other information such as a channel side ID, etc.

In operation 2.1.2, the blockchain may communicate the privacy agreement to the channeier. Preferably, the blockchain may first verify the validity of the service token before transmitting the privacy protocol, and the privacy protocol is transmitted after verification passes.

In operation 2.1.3, the channel partner may sign a privacy agreement with the gateway. Prior to signing the privacy agreement, the channel side may first review the terms of the privacy agreement as well as other information (e.g., expiration date, scope of authority, cost of authority, automatic renewal, default reimbursement, dispute resolution, etc.). For example, the channel party may sign the privacy agreement using its private key, thereby generating corresponding signed information. The signed information may include, for example, the public key of the channel partner, privacy agreement information (e.g., its hash value), the digital signature itself, and so forth. After generating the signed information, the channel party may communicate the signed information to the trusted gateway.

In operation 2.1.3.1, the gateway may communicate the privacy agreement signed transaction of the exporter to the blockchain. In particular, the gateway may package the signed information, service token, channel side ID, etc. information into a transaction and communicate the transaction to a node in the blockchain network.

At operation 2.1.3.1.1, the blockchain may execute a consensus algorithm to record the service agreement signing transaction. Wherein the blockchain may verify the validity of the channel side ID and the service token. After verification passes, the blockchain may complete the mapping of the canalside ID and the service token, generating a trusted key-value pair { canalside ID: service token }. With this key-value pair, the corresponding service token can be conveniently queried from the channel side ID.

After the validity check passes, the blockchain may also generate a canal token (ds_token) corresponding to the canal ID. After generating the canal token, another trusted key-value pair { canal token: channel side ID }. With this key-value pair, the corresponding channel side ID can be conveniently queried from the channel side token.

At operation 2.1.3.1.2, the blockchain may communicate the canal token to the gateway. Alternatively, the gateway may store the service token locally for later use.

At operation 2.1.31.2.1, the gateway may transmit the canal token to the canal. The channel party may store the channel party token (e.g., locally or elsewhere) for subsequent use.

Thus, signing operation of the channel side and the trusted gateway is completed.

Referring to fig. 4, a schematic diagram of an example process for a merchant's subscription operation with a channel according to an embodiment of the present description is shown. The specific flow of merchant subscription with a channel party is similar to the channel party and gateway subscription process described above in connection with fig. 3, wherein operations and information originally associated with a channel party are replaced with operations and information associated with a merchant in fig. 3, and operations and information originally associated with a gateway are replaced with operations and information associated with a channel party in fig. 3.

In particular, merchants may sign up for services based on the channel side tokens. The key elements of the message transmitted when the merchant signs up for consensus are as follows:

as shown in fig. 4, a channel side token (ds_token) is requested from a channel side by a merchant in operation 3. Through the request channel Fang Lingpai, merchants may initiate subscription requests to the channel side. Preferably, the subscription request may include a service code of the selected service capability. The channel side may provide a plurality of service capabilities of one or more service providers, and the subscription request may include a selection of a service code of the service capability to be subscribed to. For example, the service code may correspond to the service capability provided by the service provider above. Preferably, the subscription request may further include a merchant ID of the merchant.

In operation 3.1, the party may return a party token (ds_token) for the party to the merchant. Preferably, the channel party can check the merchant ID to ensure that only authorized merchants can request the channel party token. If the verification passes, the channel side may return its own channel side token to the merchant.

At operation 3.1.1, after receiving the canal token, the merchant may use the canal token to obtain a privacy agreement from the blockchain. The merchant may initiate a request for a privacy agreement to the blockchain, which may include a channel token. Preferably, other information, such as merchant ID, etc., may also be included in the request.

In operation 3.1.2, the blockchain may communicate the privacy protocol to the merchant. Preferably, the blockchain may first verify the validity of the channel side token before transmitting the privacy agreement, and transmit the privacy agreement after verification passes.

In operation 3.1.3, the merchant may sign a privacy agreement with the channel side. Prior to signing the privacy agreement, the merchant may first review the terms of the privacy agreement as well as other information (e.g., expiration date, authorization scope, authorization cost, automatic renewal, default reimbursement, dispute resolution, etc.). For example, a merchant may sign a privacy agreement using its private key, generating corresponding signed information. The signed information may include, for example, the merchant's public key, privacy protocol information (e.g., its hash value), the digital signature itself, and so forth. After generating the signed information, the merchant may communicate the signed information to the channel side.

In operation 3.1.3.1, the channel party may record the privacy agreement signed transaction of the merchant to the blockchain. In particular, the channel side may package the signed information, service token, merchant ID, etc. information into a transaction and transmit the transaction to a node 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. Wherein the blockchain may verify merchant ID, channel ID, and channel token legitimacy. After verification passes, the blockchain may complete the mapping of the merchant ID and the channel token, thereby generating a trusted key value pair { merchant ID: channel side token }. With this key-value pair, the corresponding channel token can be conveniently queried from the merchant ID.

After the validity check passes, the blockchain may also generate a merchant token (ds_token) corresponding to the merchant ID. After generating the merchant token, another trusted key-value pair { merchant token: merchant ID }. By using the key value pair, the corresponding merchant ID can be conveniently queried from the merchant token.

At operation 3.1.3.1.2, the blockchain may communicate the merchant token to the channel side.

At operation 3.1.31.2.1, the issuer may communicate the merchant token to the merchant. The merchant may store the merchant token (e.g., locally or elsewhere) for subsequent use.

Thus, signing operation of the merchant and the channel side is completed.

Referring to fig. 5, a schematic diagram of an example process for a user's sign-up operation with a merchant according to an embodiment of the present description is shown. The specific flow of user subscription with a merchant is similar to the subscription process described above in connection with fig. 3 and 4, except that the parties are different.

In particular, a user may sign up for a service based on a merchant token. The key elements of the message transmitted when the user signs up for consensus are as follows:

as shown in FIG. 5, a merchant token (b_token) is requested from a merchant by a user in operation 4. By requesting the merchant token, the user may initiate a subscription request to the merchant. For example, the user may sign a privacy agreement with the merchant when the user registers with the merchant, or at other times when the user wishes to be serviced by the merchant using data provided by the data service provider. Preferably, the subscription request may further include a user principal of the user.

In operation 4.1, the merchant may return a merchant token (b_token) for the merchant to the user. Preferably, the merchant may check the user principal to ensure that only authorized users can request the merchant token. If the verification passes, the merchant may return its merchant token to the user.

At operation 4.1.1, after receiving the merchant token, the user may obtain a privacy protocol from the blockchain using the merchant token. The user may initiate a request for a privacy protocol to the blockchain, which may include a merchant token. Preferably, other information may also be included in the request, such as a user principal, etc.

In operation 4.1.2, the blockchain may communicate the privacy protocol to the user. Preferably, the blockchain may first verify the validity of the merchant token before transmitting the privacy protocol, and the privacy protocol is transmitted after verification passes.

In operation 4.1.3, the user may sign a privacy agreement with the merchant. Prior to signing the privacy agreement, the user may first review the terms of the privacy agreement as well as other information (e.g., expiration date, scope of authority, cost of authority, automatic renewal, default reimbursement, dispute resolution, etc.). For example, a user may sign a privacy agreement using his private key, thereby generating corresponding signed information. The signed information may include, for example, the user's public key, privacy protocol information (e.g., its hash value), the digital signature itself, and so forth. After generating the signed information, the user may communicate the signed information to the merchant.

At operation 4.1.3.1, the merchant may record the privacy protocol signed transaction of the user to the blockchain. In particular, merchants may package signed information, service tokens, user agents, etc. information into transactions and communicate the transactions to nodes in the blockchain network.

At operation 4.1.3.1.1, the blockchain may execute a consensus algorithm to record the service agreement signing transaction. Wherein the blockchain may verify the user principal, merchant ID, and merchant token legitimacy. After verification passes, the blockchain may complete the mapping of the user principal and the merchant token, thereby generating a trusted key value pair { user principal: merchant token }. By using the key value pair, the corresponding merchant token can be conveniently inquired from the user main body.

After the validity check passes, the blockchain may also generate a user token (c_token) corresponding to the user principal. After generating the user token, another trusted key-value pair { user token: user body }. By using the key value pair, the corresponding user main body can be conveniently inquired from the user token.

Thus, a chain-passing key-value pair sequence is implemented, so that a user principal (e.g., based on { user token: user principal } key-value pair), a merchant token (e.g., based on { user principal: merchant token } key-value pair), a merchant ID (e.g., based on { merchant token: merchant ID } key-value pair), a channel Fang Lingpai (e.g., based on { merchant ID: channel token } key-value pair), a channel ID (e.g., based on { channel token: channel ID } key-value pair), a service token (e.g., based on { channel ID: service token } key-value pair), a gateway ID (e.g., based on { gateway ID: service code } key-value pair), and a service code (e.g., based on { gateway ID: service code } key-value pair) can be sequentially obtained based on a user token.

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

At operation 4.1.31.2.1, the merchant may transmit the user token to the user. The user may store the user token (e.g., locally or elsewhere) for later use.

Thus, the signing operation of the user and the merchant is completed.

Through the above operations, a chain-type subscription consensus of the data service provider-intermediary (one or more channels and merchants) -user is completed, thereby enabling merchants to provide services to users using the data services provided by the data service provider.

Referring to fig. 6, a schematic diagram of an example process for an authorization call is shown, according to an embodiment of the present specification.

At operation 5, the user may request use of the service from the merchant. For example, the user may send a service request to the merchant through a channel provided by the merchant (including, but not limited to, a website, an application, an applet, etc.). In general, the service request may include a user principal that identifies a user requesting the service and a service code that may identify the requested service capability. Preferably, the service request may further comprise a user token. Preferably, the service request may further include additional information such as a service deadline and/or a service fee.

At operation 5.1, the merchant may transmit a service request to the gateway. Preferably, after the merchant receives the service request, the validity of the user body and/or the service code can be verified. If the verification is passed, the merchant may transmit a service request to the gateway. The service request may include a user principal, a merchant ID, a user token, and a service code. Preferably, the service request may also include other additional information. The merchant ID may identify the merchant that provides the service. The user token may be from a service request received from the user or from a store of the merchant itself.

Based on the service request, the gateway may transmit an acknowledgement request to the blockchain in operation 5.1.1. The gateway may convert the merchant's service request into an authorization request, which may then be sent to the blockchain. The request for authorization may include, for example, the content of a service request received from a merchant. Preferably, the request for acknowledgement may also include a gateway ID. The gateway ID identifies the gateway requesting the service.

At operation 5.1.1.1, the blockchain may invoke an acknowledgement consensus execution acknowledgement.

In particular, the blockchain may use user tokens to obtain relevant information based on the mapping. The mapping may include, for example, one or more of the mappings described above. For example, as described above, a user principal (e.g., based on { user token: user principal } key value pair), a merchant token (e.g., based on { user principal: merchant token } key value pair), a merchant ID (e.g., based on { merchant token: merchant ID } key value pair), a channel Fang Lingpai (e.g., based on { merchant ID: channel token } key value pair), a channel ID (e.g., based on { channel token: channel ID } key value pair), a service token (e.g., based on { channel ID: service token } key value pair), a gateway ID (e.g., based on { service token: gateway ID } key value pair), a service code (e.g., based on { gateway ID: service code } key value pair) may be sequentially obtained based on the user token. It can be seen that the service code can be derived from the user token by means of a chain-like mapping (or key-value pair) previously established in the signing operation.

The blockchain may then verify that one or more of the user principal, merchant ID, gateway ID, and service code obtained from the mapping matches the corresponding item in the authorization request (i.e., one or more of the user principal, merchant ID, gateway ID, and service code). And if all the checked items are matched, checking to pass, and if the checked items are matched, the block chain is confirmed to pass, otherwise, the confirmation fails.

At operation 5.1.1.2, the blockchain may communicate the validation result to the gateway. If the right passes in the right-passing operation, the blockchain may return a right-passing result to the gateway. The validation passing result may include, for example, a validation passing ID. The validation passing result may also include some other information such as service deadlines, service fees, etc. In some examples, if the validation fails, the blockchain may return a validation failure result along with possibly other information (e.g., failure reasons, etc.).

Based on the validation passing result, the gateway may invoke a service capability to the service provider in operation 5.1.1.2.1. For example, after receiving the validation result, the gateway may decide whether to invoke the service capability to the service provider to obtain the service data according to the validation result. If an acknowledgment pass result is received, the gateway may transmit a service request to the service provider requesting the service provider to provide service data corresponding to the requested service capability. Preferably, the data service request may include one or more of a user principal, a merchant ID, a service code, and a service period for identifying the source and type of the service request. By informing the data service party of the result of the validation, the data service party 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 may transmit the service data to the gateway.

Preferably, at operation 5.1.1.2.1.1.1, the gateway can record the service capability invocation transaction to the blockchain. This operation may be performed before or after the data service provider provides the data service to ensure traceability and non-tamper ability of the data service request. This operation may not be performed, depending on the particular situation.

In one example, the data service invocation transaction may include any suitable combination of the following information: user body, merchant ID, service code. Preferably, the data service invocation transaction may further include the following information: service deadlines, data service provider IDs, data service call times, and the like.

The data service provider can ensure the validity and accuracy of the data service call transaction to avoid unnecessary data leakage and service misuse.

Preferably, the data service provider can perform data service quality assessment, data service fee settlement, and the like based on data service invocation transactions 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 may be associated with the user principal and may correspond to the service code. For example, the data service provider may retrieve data associated with the user associated with the service code from its data store and return the data as a data service to the merchant.

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

At operation 5.1.1.2.1.1.2.1, the merchant may provide a service to the user using the service data. For example, the merchant may further process the service data or perform other operations such as authentication based on the service data to provide the service content to the user.

In the present description embodiment, the link call is real-time-authorized and open: the service registration, channel side subscription, merchant subscription, user subscription and call validation 5 important consensus protocols are based on trust chains (public chains and alliance chains), have public domain access capability, further achieve real-time performance of the service privacy validation call links, and reduce privacy risks.

The embodiment of the specification utilizes a multi-level delivery mechanism, ensures that each subscription is trusted based on a blockchain trusted mechanism, solves the problem of service multi-level trust by utilizing the deliverable mechanism, and finally ensures that multi-level private data call has credibility and transitivity.

The embodiment of the specification ensures that the user privacy authorization legal call and the trusted gateway authorization mechanism are ensured, the user data cannot be reserved in the channel side, and the risk of privacy disclosure is reduced.

The embodiment of the specification ensures that the client relationship of the channel party is not revealed (the client relationship cannot be acquired by a data service provider, a gateway and the like) based on the block chain token mechanism subscription mechanism and the gateway call right consensus mechanism, thereby protecting the business confidentiality of the channel party.

Referring to fig. 7, a schematic flow chart diagram of an example service agreement authorization method 700 for blockchain-based in accordance with embodiments of the present description is shown.

As shown in fig. 7, method 700 may include: service capability registration operation 702, wherein a service capability of a service provider is registered with the blockchain and a service token is obtained by the gateway, wherein the service capability is associated with a service agreement. Preferably, the blockchain may be a trusted chain and the gateway is a trusted gateway.

Specifically, the service capability registration operation 702 may be performed by:

a service registration request from the service provider may be received by the gateway, the service registration request including a service code for identifying the service capability and the service agreement;

the service capability may be registered by the gateway to the blockchain based on the service registration request, wherein the blockchain performs a validity check on a gateway ID of the gateway and completes a mapping of the gateway ID and the service code; and

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

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

The method 700 may further include: an intermediary sign-up operation 704 wherein the service agreement is obtained and signed from the blockchain by an intermediary utilizing the service token or a token of a superior intermediary, the service agreement signing transaction of the intermediary is recorded to the blockchain by the gateway or the superior intermediary, and the intermediary's token is obtained.

Preferably, the intermediary party may comprise a multi-level intermediary party. For example, the intermediary party may include one merchant and 0, 1 or more intermediaries, where the merchant is the lowest level intermediary party and the intermediary party closest to the gateway (or service provider) is the highest level intermediary party (the merchant is the highest level intermediary party at the same time when no intermediaries are present), and there may be one or more levels of intermediaries between the highest level intermediary party and the lowest level intermediary party.

In this case, the middle-party subscription operation includes a gateway subscription operation of the highest hierarchy and a middle-party subscription operation of one hierarchy higher than the middle-party subscription operation of the lower hierarchy, and the user subscription operation includes a user subscription operation to the middle-party of the lowest hierarchy.

The gateway subscription operation in the middle direction of the highest hierarchy may include, for example:

requesting the service token from the gateway by the highest level intermediary;

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

signing the service agreement by the gateway to the highest level intermediary and transmitting the service agreement signing transaction by the gateway to the blockchain;

executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the validity of the highest-level intermediate party ID and the service token and completes the mapping of the highest-level intermediate party ID and the service token;

generating a token for 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.

Preferably or alternatively, the lower-level intermediary direction higher-level intermediary subscription operation may comprise, for example:

requesting a token of the higher hierarchical intermediary from the lower hierarchical intermediary to the higher hierarchical intermediary;

obtaining, by the lower level intermediary, the service agreement from the blockchain based on the token;

Signing the service agreement by the lower level intermediary party to the higher level intermediary party and transmitting the service agreement signing transaction to the blockchain by the higher level intermediary party;

executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the lower-level intermediate party ID and the token of the higher-level intermediate party and completes the mapping of the lower-level intermediate party ID and the token of the higher-level intermediate party;

generating a token for the lower level intermediary by the blockchain;

transmitting, by the blockchain, the token of the lower level intermediary to the upper level intermediary; and

the token of the lower hierarchical intermediary is transmitted to the lower hierarchical intermediary by the higher hierarchical intermediary.

Preferably, the service protocol is a privacy protocol.

For specific details of the intermediate sign-up operation reference may be made to the description above for fig. 3 and 4, for example.

The method 700 may further include: a user signs up operation 706 in which the service agreement is obtained from the blockchain and signed by the user using the token of the intermediary, the service agreement signing transaction of the user is recorded to the blockchain by the intermediary, and the token of the user is obtained.

The user subscription operation may include, for example:

requesting, by the user, a token of an intermediary party from the intermediary party, wherein the intermediary party is a lowest level intermediary party;

obtaining, by the user, the service agreement from the blockchain based on the token;

signing the service agreement by the user to the intermediary party and transmitting the service agreement signing transaction by the intermediary party to the blockchain;

executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the tokens of the user body and the intermediate party and completes the mapping of the tokens of the user body and the intermediate party;

generating a token for the user by the blockchain;

transmitting, by the blockchain, the token of the user to the intermediary; and

the user's token is communicated to the user by the intermediary.

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

Preferably, the method 700 may further comprise: the validation calls operation 708 where the blockchain validation is requested by the intermediary through the gateway using the user's token and service data is obtained from the service provider based on the result of the validation.

Specifically, the rights invocation operation 708 may include:

Transmitting, by the intermediary, a service request to the gateway using the token of the user;

transmitting, by the gateway, an acknowledgement request to the blockchain based on the service request;

invoking an acknowledgement consensus by the blockchain to perform an acknowledgement, wherein the blockchain uses the token of the user to obtain a user principal of the user, an intermediary party ID of the intermediary party, a gateway ID of the gateway, and the service code based on the mapping done in the signing operation to verify whether the user principal of the user, the intermediary party ID of the intermediary party, the gateway ID of the gateway, and the service code match corresponding items in the acknowledgement request;

the gateway, based on the result of the validation, invoking service capabilities to the service provider and forwarding associated service data to the intermediary party; and

the service data is used by the intermediary to provide a service to the user.

Preferably, service capability invocation transactions may be recorded by the gateway to the blockchain.

Preferably, the hash value of the service agreement signing transaction (including the service agreement signing transaction of the parties) may be disclosed on the public domain.

For specific details of the user subscription operation, reference may be made to the description above for fig. 6, for example.

Referring to fig. 8, a schematic flow diagram of a system 800 for blockchain-based example service protocol authorization is shown in accordance with embodiments of the present description.

As shown in fig. 8, the system 800 may include: a service capability registration means 802 wherein a service capability of a service provider is registered with the blockchain by the gateway and a service token is obtained, wherein the service capability is associated with a service agreement. Preferably, the blockchain may be a trusted chain and the gateway is a trusted gateway. The operation of this device may be referred to the description of service capability registration operation 702 above.

The system 800 may further include: an intermediary contractor 804, wherein the service agreement is obtained and signed from the blockchain by an intermediary utilizing the service token or a token of a superior intermediary, the service agreement signing transaction of the intermediary is recorded to the blockchain by the gateway or the superior intermediary, and the intermediary's token is obtained. The operation of this device may be described above with reference to the intermediate sign-up operation 704.

The system 800 may further include: a user contractor 806, wherein the service agreement is obtained from the blockchain and signed by the user using the token of the intermediary, the service agreement signing transaction of the user is recorded to the blockchain by the intermediary, and the token of the user is obtained. The operation of this device may be described above with reference to user sign-up operation 706.

Preferably, the system 800 may further comprise: an acknowledgement invoking device 808 wherein the blockchain acknowledgement is requested by the intermediary through the gateway using the user's token and service data is obtained from the service provider based on the result of the acknowledgement. The operation of this device may be described above with reference to user sign-up operation 708.

Fig. 9 illustrates a schematic block diagram of an apparatus 900 for implementing the methods in accordance with one or more embodiments of the present disclosure. The apparatus may be used to implement, for example, a method described herein (e.g., method 700) or to implement a system as described herein (e.g., system 800). The apparatus may also be implemented as any computing node or cluster of computing nodes described herein (e.g., by virtualization, etc.). The apparatus may include a processor 910 configured to perform any of the methods described above, and a memory 915. The storage may include memory and/or persistent storage. The memory may also be used to store any instructions, variables, intermediate data, or the like 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 connected to other devices by 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, etc. For example, the network connection element may be connected to a network to obtain related data, instructions, and other various data. Inputs made by the user from other devices may also be received via the network connection element or data transmitted to other devices for display.

The device may also optionally include other peripheral elements 920 such as input devices (e.g., keyboard, mouse), output devices (e.g., display), etc. For example, in a method based on user input, a user may perform an input operation via an input device. Corresponding information may also be output to the user via the output means.

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

Moreover, a computer-readable storage medium comprising computer-executable instructions stored thereon, which when executed by a processor, cause the processor to perform the methods of the embodiments described herein is also disclosed.

Further, an apparatus is disclosed that includes a processor and a memory storing computer-executable instructions that, when executed by the processor, cause the processor to perform the methods of the embodiments described herein.

Furthermore, a system is disclosed, comprising means for implementing the methods of the embodiments described herein.

It is to be understood that methods in accordance with one or more embodiments of the present description may be implemented in software, firmware, or a combination thereof.

It should be understood that each embodiment in this specification is described in an incremental manner, and the same or similar parts between the embodiments are referred to each other, and each embodiment focuses on differences from other embodiments. In particular, for apparatus and system embodiments, the description is relatively simple, as it is substantially similar to method embodiments, and relevant references are made to the partial description of method embodiments.

It should be understood that the foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than 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. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

It should be understood that elements described herein in the singular or shown in the drawings are not intended to limit the number of elements 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 multiple modules or elements.

It is also to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. The use of these terms and expressions is not meant to exclude any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible and are intended to be included within the scope of the claims. Other modifications, variations, and alternatives are also possible. Accordingly, the claims should be looked to in order to cover all such equivalents.

Also, it should be noted that while the above-mentioned embodiments have been described with reference to the present specific embodiments, those skilled in the art will recognize that the above-mentioned embodiments are merely illustrative of one or more embodiments of the present disclosure, and that various equivalent changes or substitutions can be made without departing from the spirit of the invention, and therefore, all changes and modifications to the above-mentioned embodiments are intended to be within the scope of the appended claims.

Claims

1. A blockchain-based service protocol authorization method, the method comprising:

a service capability registration operation, wherein a service capability of a service provider is registered to the blockchain and a service token is obtained by a gateway, wherein the service capability is associated with a service agreement;

An intermediary signing operation, wherein the intermediary obtains the service agreement from the blockchain and signs the service agreement by using the service token or a token of a superior intermediary, the service agreement signing transaction of the intermediary is recorded to the blockchain by the gateway or the superior intermediary, and the token of the intermediary is obtained; and

a user sign-up operation, wherein the service agreement is obtained from the blockchain and signed by the user with a token of an intermediary party, and the service agreement signing transaction of the user is recorded to the blockchain by the intermediary party and the token of the user is obtained.

2. The method of claim 1, wherein the service capability registration operation comprises:

receiving, by the gateway, a service registration request from the service provider, the service registration request including a service code for identifying the service capability and the service agreement;

registering, by the gateway, the service capability to the blockchain based on the service registration request, wherein the blockchain performs a validity check on a gateway ID of the gateway and completes a mapping of the gateway ID and the service code; and

A service token from the blockchain is received by the gateway and transmitted to the service provider.

3. The method of claim 2, wherein there are multiple levels of intermediaries, and the intermediaries subscription operation comprises a highest level intermediaries gateway subscription operation and a lower level intermediaries higher than a level intermediaries subscription operation, and the user subscription operation comprises a user subscription operation with a lowest level intermediaries subscription operation.

4. The method of claim 3, wherein the highest-level mid-way direction gateway subscription operation comprises:

requesting, by the highest level intermediary, the service token from the gateway;

obtaining, by the highest-level intermediary party, the service agreement from the blockchain based on the service token;

signing the service agreement by the highest level intermediary to the gateway and communicating the service agreement signing transaction by the gateway to the blockchain;

executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the highest-level intermediary party ID and the service token legitimacy are checked by the blockchain and mapping of the highest-level intermediary party ID and the service token is completed;

Generating, by the blockchain, a token for the highest-level intermediary and communicating it to the gateway; and

5. The method of claim 3, wherein the lower-level intermediary direction higher-level intermediary sign-up operation comprises:

requesting, by the lower-level intermediary party, a token of the higher-level intermediary party from the higher-level intermediary party;

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

signing the service agreement by the lower-level intermediary party to the higher-level intermediary party and communicating the service agreement signing transaction by the higher-level intermediary party to the blockchain;

executing, by the blockchain, a consensus algorithm to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the lower-level intermediary party ID and the token of the higher-level intermediary party and completes the mapping of the lower-level intermediary party ID and the token of the higher-level intermediary party;

generating, by the blockchain, a token for the lower one of the hierarchical intermediaries;

Communicating, by the blockchain, the token of the lower-level intermediary to the higher-level intermediary; and

the token of the lower level intermediary party is communicated to the lower level intermediary party by the upper level intermediary party.

6. The method of claim 1, wherein the user sign-up operation comprises:

signing, by the user, the service agreement with the intermediary party and transmitting, by the intermediary party, the service agreement signing transaction to the blockchain;

executing a consensus algorithm by the blockchain to record the service agreement signed transaction, wherein the blockchain verifies the legitimacy of the user principal and the intermediary party's token and completes the mapping of the user principal and the intermediary party's token;

generating, by the blockchain, a token for the user;

transmitting, by the blockchain, a token of the user to the intermediary party; and

the user's token is communicated to the user by the intermediary.

7. The method of claim 1, further comprising:

an acknowledgement call operation in which the blockchain acknowledgement is requested by an intermediary party through the gateway using the user's token and service data is acquired from the service provider based on the result of the acknowledgement.

8. The method of claim 7, wherein the rights invocation operation comprises:

transmitting, by an intermediary party, a service request to the gateway using the user's token;

invoking, by the blockchain, an acknowledgement consensus to perform an acknowledgement, wherein the blockchain obtains a user principal of the user, an intermediary party ID of the intermediary party, a gateway ID of the gateway, and the service code based on a mapping done in a subscription operation using a token of the user to verify whether the user principal of the user, the intermediary party ID of the intermediary party, the gateway ID of the gateway, and the service code match corresponding items in the acknowledgement request;

the gateway invokes service capability to the service provider and forwards associated service data to the intermediary party based on the result of the validation; and

The service data is used by the intermediary to provide services to the user.

9. The method of claim 8, further comprising:

service capability invocation transactions are recorded to the blockchain by the gateway.

10. The method of claim 1, wherein the blockchain is a trust chain and the gateway is a trusted gateway.

11. The method of claim 10, wherein the hash value of the service agreement signed transaction is disclosed on a public domain.

12. The method of claim 1, wherein the service protocol is a privacy protocol.

13. A system for blockchain-based service agreement authorization, the system comprising:

a service capability registration device, wherein a gateway registers a service capability of a service provider to the blockchain and obtains a service token, wherein the service capability is associated with a service agreement;

an intermediary party signing device, wherein the intermediary party obtains the service agreement from the blockchain by using the service token or the token of the upper intermediary party and signs the service agreement, the service agreement signing transaction of the intermediary party is recorded to the blockchain by the gateway or the upper intermediary party, and the token of the intermediary party is obtained; and

A user sign-up device, wherein the service agreement is obtained from the blockchain and signed by the user with a token of an intermediary party, the service agreement signing transaction of the user is recorded to the blockchain by the intermediary party, and the token of the user is obtained.

14. An apparatus for blockchain-based service agreement authorization, comprising:

a 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 of any of claims 1-12.

15. A non-transitory processor-readable storage medium comprising processor-executable instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1-12.