Authorization system and method supporting dynamic permission revocation

Abstract

The invention discloses an authorization system and method supporting dynamic permission revocation. The method comprises the steps that an authorization strategy for a third-party application is defined based on attributes; generating a signature voucher based on a BBS + signature algorithm; according to the authorization strategy and metadata corresponding to the signature voucher, establishing an intelligent contract of an authority authorization state of the third-party application, monitoring whether a revocation condition is met or not in real time through the intelligent contract, and setting the authority authorization state to be revoked when the revocation condition is met; and when the third-party application accesses the resource through the signature voucher, carrying out validity verification on the signature voucher, querying the smart contract, confirming a permission authorization state, and refusing an access request of the third-party application when the permission authorization state is revoked. According to the invention, three core technologies of BBS + signature algorithm, attribute-based encryption and block chain smart contract are fused, a novel authorization architecture separating identity verification and authority management is constructed, and dynamic revocation, fine-grained control and real-time risk response of authority are realized.

Description

Technical Field

[0001] This invention relates to the field of distributed identity authentication and access control technology, and in particular to an authorization system and method that supports dynamic revocation of permissions. Background Technology

[0002] With the development of distributed identity (DID) technology, users can independently authorize third-party applications to access their identity attributes without relying on centralized identity providers. Among them, the BBS + signature algorithm, as the core technology of distributed authentication, is based on the cryptographic foundation of the discrete logarithm problem and supports selective attribute disclosure, enabling users to show only necessary identity attributes to the verifier, thus protecting user privacy.

[0003] Attribute-based encryption (ABE) is another important cryptographic technique that associates encryption with user attributes, allowing data owners to set access policies based on the recipient's attributes, thus achieving fine-grained access control. ABE is mainly divided into two categories: Key Policy ABE (KP-ABE) and Ciphertext Policy ABE (CP-ABE), each suitable for different application scenarios.

[0004] Blockchain smart contract technology provides decentralized rule execution and state storage capabilities. Its immutability and automatic execution capabilities make it an ideal carrier for permission management in a distributed environment.

[0005] However, the current authorization mechanism based on BBS and signatures has the following technical limitations:

[0006] 1) Difficulty in revoking permissions: Once BBS+ signatures are generated and distributed, there is a lack of an effective mechanism for proactive revocation. Even if the authorizing party wishes to revoke permissions, third parties can still use the obtained signatures to continue accessing resources, violating the principle of least privilege.

[0007] 2) Overly tight binding of permissions and identity: In existing solutions, authentication and permission management are usually tightly coupled. Modifying permissions requires regenerating and distributing signatures, which is complex and inefficient.

[0008] 3) Lack of fine-grained control: It is difficult to set different access permissions for different third-party applications, and it is impossible to accurately control "who can access what resources" and "the validity period of access permissions".

[0009] 4) Delayed risk response: When a security risk is detected in a third-party application, the access permission cannot be revoked quickly, which may lead to the leakage of sensitive information.

[0010] These issues limit the application of BBS + signature in scenarios requiring dynamic permission management, especially in complex environments with multiple third-party collaborations, where security risks are particularly prominent. Therefore, there is an urgent need for an authorization system that can solve the aforementioned technical problems. Summary of the Invention

[0011] The purpose of this invention is to provide a BBS + attribute-based authorization system and method that supports dynamic revocation of permissions. By integrating three core technologies—BBS + signature algorithm, attribute-based encryption, and blockchain smart contracts—a new authorization architecture that separates identity verification and permission management is constructed, enabling dynamic revocation of permissions, fine-grained control, and real-time risk response, thus overcoming the shortcomings of existing technologies.

[0012] To achieve the above objectives, the present invention adopts the following technical solution:

[0013] In a first aspect, the present invention provides an authorization method that supports dynamic revocation of permissions, the method comprising the steps of:

[0014] Obtain user identity attribute information, and generate a user DID identifier and corresponding public / private key pair based on the user identity attribute information, and form a DID document;

[0015] The authorization policy for third-party applications is defined based on attributes. The authorization policy includes the identifier of the authorized third-party application, accessible attributes, permission validity period, and revocation conditions.

[0016] According to the authorization policy, a signature credential is generated based on the BBS+ signature algorithm. The signature credential is used to verify the authorization of access by third-party applications.

[0017] Based on the authorization policy and the metadata corresponding to the signature credential, a smart contract is established to determine the permission authorization status of the third-party application. The smart contract is used to monitor in real time whether the revocation conditions are met. When the revocation conditions are met, the permission authorization status is set to revoked.

[0018] When a third-party application accesses resources using the signature credential, the validity of the signature credential is verified, and the smart contract is queried to confirm the permission authorization status. If the permission authorization status is revoked, the access request from the third-party application is rejected.

[0019] Furthermore, the attribute-based authorization policy for third-party applications includes:

[0020] Select the attributes that third-party applications are allowed to access;

[0021] Set the validity period and revocation conditions for the permissions corresponding to each attribute;

[0022] The authorization policy is converted into a machine-recognizable permission descriptor.

[0023] Furthermore, the revocation conditions include time conditions, behavioral conditions, and risk conditions. The time condition indicates the period exceeding which the permission revocation is triggered, the behavioral condition indicates user behavior that triggers the permission revocation, and the risk condition indicates the abnormal event that triggers the permission revocation.

[0024] Further, the step of generating a signature credential based on the BBS+ signature algorithm according to the authorization strategy includes:

[0025] Extract the attribute information corresponding to the authorization strategy and form an attribute set;

[0026] The combination of numbers and shapes is hashed to generate the attribute root hash;

[0027] Generate a temporary private key, and combine it with the user's private key and the attribute root hash to generate a signature using the BBS + signature algorithm;

[0028] Based on the signature, the signature credential is generated; the signature credential includes the signature, attribute index, signature timestamp, and authorization policy identifier.

[0029] Furthermore, the signature σ is generated using the following formula:

[0030] σ = (x + k)⁻¹・(H + k・U),

[0031] Where x is the user's private key, k is the temporary private key, H is the attribute root hash, and U is the group generator.

[0032] Furthermore, the step of monitoring in real time whether the revocation conditions are met through the smart contract, and setting the permission authorization status to revoked when the revocation conditions are met, includes:

[0033] Whether the monitoring meets any of the revocation conditions among the time condition, behavior condition, and risk condition;

[0034] If any of the revocation conditions are met, the corresponding permission authorization status will be updated to revoked;

[0035] Generate a revocation credential containing a unique revocation identifier, the hash of the revoked signature, and the reason for revocation, and record the revocation time and execution node information in the smart contract.

[0036] Furthermore, the validity verification of the signature credential includes:

[0037] Obtain the user's public key from the DID document;

[0038] Based on the user's public key, verify whether the signature in the signature credential satisfies the BBS+ verification equation. If it does, the validity verification passes; otherwise, it fails.

[0039] Furthermore, the method also includes:

[0040] Collect permission usage behavior data of third-party applications, and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, send risk specification to smart contract to trigger permission revocation process.

[0041] Secondly, the present invention provides an authorization system that supports dynamic revocation of permissions, the system comprising:

[0042] The user identity management module is used to obtain user identity attribute information, and generate a user DID identifier and corresponding public-private key pair based on the user identity attribute information, and form a DID document;

[0043] The attribute-based authorization policy module is used to define authorization policies for third-party applications based on attributes. The authorization policy includes the authorized third-party application identifier, accessible attributes, permission validity period, and revocation conditions.

[0044] The signature module is used to generate a signature credential based on the BBS+ signature algorithm according to the authorization policy. The signature credential is used for authorization verification of access by third-party applications.

[0045] The smart contract module is used to establish a smart contract for the permission authorization status of the third-party application based on the authorization policy and the metadata corresponding to the signature certificate, and to monitor in real time whether the revocation conditions are met through the smart contract, and set the permission authorization status to revoked when the revocation conditions are met;

[0046] The application interface module is used to verify the validity of the signature credential when a third-party application accesses resources through the signature credential, and to query the smart contract to confirm the permission authorization status. If the permission authorization status is revoked, the access request of the third-party application is rejected.

[0047] Furthermore, the system also includes:

[0048] The risk monitoring module is used to collect permission usage behavior data of third-party applications and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, a risk specification is sent to the smart contract to trigger the permission revocation process.

[0049] Compared with the prior art, the present invention has the following significant advantages:

[0050] 1. Enable dynamic revocation of permissions: By monitoring revocation conditions in real time through smart contracts, the inherent defect of BBS + signature being difficult to revoke once generated is solved, enabling automatic or manual revocation of permissions and improving system security.

[0051] 2. Separate authentication and access control: Separate the authentication function of BBS + signature from the access control function of smart contract. Modifying permissions does not require regenerating signatures, which improves system flexibility and efficiency.

[0052] 3. Fine-grained access control: Based on attribute-based encryption technology, it supports setting differentiated access permissions for different third-party applications, precisely controlling the range of accessible attributes, and conforming to the principle of least privilege.

[0053] 4. Real-time risk response: Through the linkage between the risk monitoring module and smart contracts, permissions can be quickly revoked when abnormal behavior is detected, thereby reducing security risks.

[0054] 5. Immutable authorization records: Utilizing blockchain smart contracts to store authorization and revocation records ensures the traceability and immutability of operations, enhancing system transparency.

[0055] 6. Strong compatibility: Compliant with W3C DID standards and IETF BBS + signature specifications, it can be seamlessly integrated into the existing distributed identity ecosystem, reducing deployment costs. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a flowchart of an authorization method that supports dynamic revocation of permissions in an embodiment of the present invention.

[0058] Figure 2 This is a block diagram of an authorization system that supports dynamic revocation of permissions according to an embodiment of the present invention. Detailed Implementation

[0059] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following drawings indicate similar items; therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0060] In traditional distributed authentication systems, permission management mechanisms based on BBS+signature algorithms cannot achieve dynamic permission control. The lack of proactive revocation capability after signature credentials are generated allows third-party applications to access sensitive data even when authorization has expired or security risks exist. Permission status updates rely on a centralized server polling mechanism, which presents a single point of failure risk and significant response latency, failing to meet real-time requirements. The strong coupling between authorization policies and identity identifiers necessitates the regeneration of key pairs for permission changes, leading to an exponential increase in key management complexity.

[0061] For example, in cross-institutional medical data sharing scenarios, third-party data analytics platforms obtain access to patients' health records through attribute-based authorization. When a patient revokes their authorization to a platform, the platform can still access historical data using the issued credentials because the existing system employs a static signature verification mechanism. In the system architecture, authorization status is stored in a centralized database, and data synchronization delays prevent smart contract nodes from obtaining the latest permission status in real time. The access control module only verifies cryptographic validity when checking signatures, without performing on-chain collaborative verification with dynamic permission status, resulting in a risk response time window of several hours.

[0062] If the above issues are not addressed, distributed identity systems will be unable to meet compliance standards in high-security scenarios such as healthcare and finance. Persistent unauthorized access could lead to large-scale leaks of sensitive data, violating the principle of data minimization. The vulnerability of centralized access control architectures to targeted cyberattacks means a single intrusion can alter the global access control state. Frequent key changes resulting in massive amounts of obsolete credentials will exacerbate storage and verification overhead, reducing system throughput to unusable levels.

[0063] Faced with the aforementioned problems, this application first analyzes the core contradiction of the difficulty in revoking permissions, finding that the persistent binding of signature credentials and permission states in existing technologies is the key reason for the inability to dynamically revoke permissions. Traditional solutions rely entirely on cryptographic verification for permission validity, without establishing an independent state tracking mechanism. To address this, this application attempts to separate permission states from cryptographic credentials by introducing programmable smart contracts as an independent verification layer, enabling changes in permission states without modifying the original signature credentials. Simultaneously, to solve the response latency problem caused by centralized permission management, this application explores transforming the revocation conditions in the authorization strategy into automatically executable smart contract logic, utilizing the consensus mechanism of blockchain to ensure the real-time nature and immutability of state updates. Furthermore, by encoding the validity period and multi-dimensional revocation conditions in the authorization strategy into machine-resolvable metadata, a fine-grained permission control and rapid response mechanism for risk events are achieved.

[0064] In response, this application proposes an authorization method that supports dynamic revocation of permissions, such as... Figure 1 As shown, the steps include:

[0065] S1. Obtain user identity attribute information, generate user DID identifier and corresponding public / private key pair based on user identity attribute information, and form DID document;

[0066] S2. Define an authorization policy for third-party applications based on attributes. The authorization policy includes the identifier of the authorized third-party application, accessible attributes, permission validity period, and revocation conditions.

[0067] S3. Based on the authorization policy, generate a signature certificate using the BBS+ signature algorithm. The signature certificate is used to verify the authorization of access by third-party applications.

[0068] S4. Based on the authorization policy and the metadata corresponding to the signature certificate, establish a smart contract for the permission authorization status of the third-party application, and monitor in real time whether the revocation conditions are met through the smart contract. When the revocation conditions are met, set the permission authorization status to revoked.

[0069] S5. When a third-party application accesses resources through a signature credential, the validity of the signature credential is verified, and the smart contract is queried to confirm the permission authorization status. If the permission authorization status is revoked, the access request of the third-party application is rejected.

[0070] User DID (Distributed Identity ID) is a decentralized identity generated based on user identity attribute information. Specifically, it uses a hash algorithm to digest and encode the attribute information, uniquely identifying the user and associating it with a public-private key pair. The public-private key pair is an asymmetric key combination used for cryptographic signatures, generated using elliptic curve cryptography. The public key is stored in the DID document for verification, while the private key is secretly kept by the user for identity control. The authorization policy is a set of rules defining access permissions for third-party applications. It can be described in JSON format, specifying the authorized application identifier, accessible attributes, validity period, and revocation conditions, constraining the scope of permissions and supporting dynamic management.

[0071] The core innovation of this application lies in combining the BBS+ signature algorithm with smart contracts. It achieves fine-grained authorization through signature credentials, while simultaneously utilizing smart contracts to monitor revocation conditions and update permission status in real time. This solves the problems of delayed permission revocation and overly tight binding between identity and permissions in traditional solutions. By dynamically linking authorization strategies with on-chain states, it achieves full-lifecycle control of permissions while ensuring privacy.

[0072] This application separates permission status from signature credentials and utilizes smart contracts to achieve dynamic permission management. The smart contract, acting as an independent verification layer, can automatically revoke permissions based on preset revocation conditions without modifying the original signature credentials. This design solves the problem of difficult permission revocation in traditional BBS + signature authorization. Simultaneously, the consensus mechanism of blockchain ensures the real-time nature and immutability of permission status updates, overcoming the response delay problem of centralized permission management.

[0073] Fine-grained access control is achieved by encoding the validity period and revocation conditions in the authorization policy into machine-resolvable metadata. This enables the system to set differentiated access permissions for different third-party applications and to respond quickly to risk events.

[0074] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0075] First, user identity attributes are obtained. This information may include the user's name, age, occupation, email address, and permission level. Based on this information, a user's DID identifier is generated, for example, "did:example:123456789abcdefghi". Simultaneously, a public-private key pair corresponding to this DID is generated. The public key may use an elliptic curve cryptography algorithm, such as secp256k1. The private key is securely stored on the user's device. This information is organized into a DID document, containing the DID identifier, public key, authentication method, etc.

[0076] Next, define the authorization policy for third-party applications. For example, for a medical application called "HealthApp", the authorization policy might include:

[0077] Third-party application identifier: HealthApp;

[0078] Accessible attributes: Name, Age, Blood Type, Allergy History;

[0079] Permission validity period: 30 days;

[0080] Cancellation conditions: more than 30 days, user voluntarily cancels, or abnormal access behavior is detected.

[0081] Based on this authorization policy, a signature credential is generated using the BBS+ signature algorithm. First, accessible attributes are grouped into an attribute set, which is then hashed to generate an attribute root hash. Next, a temporary private key is generated, and combined with the user's private key and the attribute root hash, a signature is generated using the BBS+ signature algorithm. Finally, a signature credential containing the signature, attribute index, signature timestamp, and authorization policy identifier is generated.

[0082] Based on the authorization policy and metadata of the signature credential, a smart contract is deployed to the blockchain network. The smart contract includes permission authorization status, revocation condition logic, etc. The contract continuously monitors whether revocation conditions are met, such as when more than 30 days have passed, a user's revocation instruction is received, or abnormal access behavior is detected. Once the revocation conditions are met, the contract automatically sets the permission authorization status to revoked.

[0083] When HealthApp attempts to access user data, it first needs to provide a signature credential. The system performs cryptographic verification on the credential to confirm the validity of the signature. Simultaneously, it queries the smart contract to obtain the latest permission authorization status. If the status is revoked, HealthApp's access request is denied, even if the provided signature credential remains cryptographically valid.

[0084] Through the above-described scheme, this application achieves dynamic permission management for third-party applications. By separating permission status from signature credentials and utilizing smart contracts for real-time monitoring and automatic execution, the difficulty of permission revocation in traditional BBS + signature authorization is solved. Simultaneously, the decentralized architecture based on blockchain ensures the real-time nature and immutability of permission status updates, overcoming the single point of failure risk and response delay issues of centralized permission management. Furthermore, by encoding the authorization policy into machine-resolvable metadata, fine-grained permission control is achieved, enabling the setting of differentiated access permissions for different third-party applications and rapid response to potential security risks. This scheme significantly improves the applicability of distributed identity systems in high-security scenarios, effectively preventing unauthorized access and sensitive data leakage, while also enhancing system availability and performance.

[0085] In some of the solutions described above in this application, when defining authorization policies based on attributes, the lack of a fine division of the access scope, validity period, and revocation conditions for attributes may lead to third-party applications accessing unnecessary attributes without authorization, and the permissions cannot be terminated in a timely manner according to dynamically changing conditions.

[0086] This application further proposes an attribute-based authorization policy for third-party applications, including: selecting attributes that third-party applications are allowed to access; setting the validity period and revocation conditions of permissions for each attribute; and converting the authorization policy into a machine-recognizable permission descriptor.

[0087] Specifically, when selecting attributes, a whitelist mechanism is used to limit the minimum set of attributes that third-party applications can access. For example, only medical applications are allowed to access a user's blood type attribute, while the address attribute is hidden. The validity period of permissions is defined using a timestamp range. For example, access permissions are set to be valid between January 1, 2024 and December 31, 2024. Revocation conditions are defined using logical expressions. For example, revocation is triggered when a user actively initiates a permission revocation command or when a third-party application's daily access count exceeds a preset threshold. The permission descriptor is stored in a structured JSON-LD format, containing attribute identifiers, validity period timestamps, and condition hash values, facilitating smart contract parsing and execution.

[0088] Specifically, when generating authorization policies, a subset relevant to the third-party application's business is first selected from user identity attributes. For example, a logistics application only needs to obtain the user's phone number and delivery address. For each selected attribute, an independent time window and triggering conditions are set. For instance, access permissions for delivery addresses are set to be valid for 72 hours after order creation and immediately invalidated if an abnormal login event occurs on the user's account. The permission descriptor transforms the natural language policy into a data structure containing attribute indexes, time intervals, and conditional expressions through standardized encoding. For example, Base64 encoding is used to encapsulate the policy parameters into bytecode that can be called by smart contracts. This descriptor is bound to a smart contract address on the blockchain. When a third-party application initiates an access request, the verification node compares the timestamp and conditional hash in the descriptor with the on-chain state data in real time to determine the validity of the permission.

[0089] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0090] When defining an authorization policy for a third-party application based on attributes, first select the attributes that the third-party application is allowed to access. For example, for an e-commerce application, attributes such as the user's name, age, and address can be selected as accessible attributes.

[0091] Next, set the validity period and revocation conditions for each attribute. The validity period can be set to a fixed time period, such as 30 days; or set to a dynamic time, such as "valid for 90 days from the first use". Revocation conditions can include time conditions (such as no use for more than 180 days), behavioral conditions (such as the user actively canceling authorization), and risk conditions (such as abnormal access behavior being detected).

[0092] Finally, the authorization policy is converted into a machine-readable permission descriptor. This can be achieved by encoding the authorization policy into JSON format, which includes information such as the third-party application identifier, a list of accessible attributes, the validity period of each attribute, and revocation conditions.

[0093] Through the above technical solutions, this application achieves fine-grained authorization control over third-party applications. User privacy is protected by selectively authorizing attribute access. Setting permission expiration dates and revocation conditions enhances the timeliness and security of authorization. Converting authorization policies into a machine-readable format facilitates automated processing and execution of authorization policies, improving the efficiency and accuracy of authorization management.

[0094] In some of the solutions mentioned above in this application, an authorization policy for third-party applications based on attribute definition was proposed, and permission validity period and revocation conditions were set. However, when setting revocation conditions, the lack of specific condition type definition makes it impossible to effectively monitor various scenarios that trigger permission revocation, affecting the real-time performance and security of permission management.

[0095] To this end, this application further proposes revocation conditions including time conditions, behavioral conditions, and risk conditions. Time conditions indicate the period exceeding which permission revocation is triggered, behavioral conditions indicate user behavior that triggers permission revocation, and risk conditions indicate the abnormal event that triggers permission revocation.

[0096] Among them, time-based conditions enable automatic expiration of permissions by setting specific time thresholds, such as setting the validity period of permissions to a fixed time period, triggering revocation when the system time exceeds the validity period; behavioral conditions enable revocation by capturing user-initiated permission revocation commands, such as when a user performs a permission revocation operation in the management interface; risk conditions trigger revocation by pre-set abnormal event detection rules, such as detecting that a third-party application accesses the app more times than a preset threshold within a unit of time. These three condition types correspond to different dimensions of permission management needs, and the status of each condition is monitored in real time through smart contracts, triggering a permission status update when any condition is met.

[0097] Specifically, in the permission management process, time-based conditions ensure that permissions are not valid indefinitely, avoiding security risks caused by expired permissions. Behavioral conditions empower users to actively control permissions; when a user discovers abuse by a third-party application, permission can be immediately revoked. Risk conditions automatically trigger permission revocation through preset anomaly detection mechanisms, such as access frequency monitoring or data breach identification. By integrating these three condition types into the smart contract, the system can compare the current state with preset conditions in real time. For example, if a third-party application is detected to have accessed the application more than 1,000 times within 24 hours, the system determines that a risk condition is met and updates the permission status to revoked. This multi-dimensional condition monitoring mechanism effectively covers typical scenarios for permission revocation, improving the flexibility and responsiveness of permission management.

[0098] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0099] The time condition can be set to an authorization validity period of 30 days, with automatic revocation triggered after 30 days. The behavior condition can be set to trigger revocation when the user actively revokes the authorization or when the permission is not used for 7 consecutive days. The risk condition can be set to trigger revocation when data leakage or malicious behavior by a third-party application is detected.

[0100] Furthermore, these revocation conditions are encoded into a smart contract. The smart contract continuously monitors the status of each condition. Once any revocation condition is met, the smart contract automatically executes the revocation operation, marking the authorization status as revoked.

[0101] Thus, by defining multi-dimensional revocation conditions and combining them with the automatic execution mechanism of smart contracts, refined management and timely revocation of authorization are achieved.

[0102] Through the above technical solution, this application achieves multi-dimensional dynamic management of authorization. Time-based conditions ensure that authorizations are not valid indefinitely, reducing the security risks associated with long-term authorizations. Behavioral conditions allow authorizations to be flexibly adjusted according to user wishes and usage. Risk conditions provide a rapid response mechanism for abnormal situations. This multi-dimensional revocation mechanism greatly improves the flexibility and security of authorization management, effectively preventing losses caused by the abuse or leakage of authorizations. Simultaneously, encoding revocation conditions into smart contracts and utilizing the automatic execution characteristics of smart contracts ensures the timeliness and reliability of revocation operations, enabling dynamic adjustment of authorizations without manual intervention. This not only improves the efficiency of authorization management but also reduces the risk of human error.

[0103] In some of the solutions described above in this application, the process of generating signature credentials lacks a mechanism to ensure the integrity of attribute information in the authorization policy. This may cause third-party applications to be unable to effectively identify tampered or forged attribute sets during the verification process, thereby affecting the security of access control.

[0104] To this end, this application further proposes to extract the attribute information corresponding to the authorization policy to form an attribute set, perform hash processing on the attribute set to generate an attribute root hash, generate a temporary private key and combine it with the user's private key and the attribute root hash to generate a signature using the BBS+ signature algorithm, and generate a signature credential containing the signature, attribute index, signature timestamp and authorization policy identifier based on the signature.

[0105] The attribute set is composed by traversing the accessible attribute fields defined in the authorization policy, and the attribute index uses a binary bitmap structure to record the position of the attribute in the set. Hash processing uses the SHA-256 algorithm to perform one-way encryption on the serialized attribute set, generating a fixed-length attribute root hash. The temporary private key is generated by a random number generator, and its lifespan is limited to a single signature operation. When implementing the BBS+ signature algorithm, the group generator U is selected as the coordinates of the base point on the elliptic curve secp256k1, and the values ​​of the user private key x and the temporary private key k are limited to the interval [1, n-1], where n is the order of the elliptic curve. The signature credential structure includes a four-tuple data block, where the signature timestamp is recorded in UTC standard time format with millisecond accuracy.

[0106] Specifically, in the process of generating signature credentials, the accessible attributes defined in the authorization policy are first converted into a structured data set according to preset encoding rules. For example, the "age" attribute is encoded as an ASCII string, and the "occupation category" attribute is converted into an enumerated value. Then, a hash algorithm is used to calculate the digest of the attribute set, generating a unique attribute root hash value. This hash value, as part of the signature data, prevents attribute information from being tampered with during transmission. The introduction of a temporary private key enhances the forward security of the signing process, ensuring that even if the private key is leaked long-term, the security of historical signatures will not be affected. By performing elliptic curve scalar multiplication on the user's private key, the temporary private key, and the attribute root hash, the generated digital signature simultaneously binds the user's identity and authorization attributes, allowing the verifier to confirm the signature's validity through the verification equation. The bitmap structure design of the attribute index in the signature credential allows the verifier to quickly locate the specific attribute to be verified without parsing the complete attribute set. The precise recording of the signature timestamp provides a time reference for subsequent authorization validity period verification, and the embedding of the authorization policy identifier enables parallel management of multiple authorization policies.

[0107] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0108] According to the authorization policy, when generating a signature credential based on the BBS+ signature algorithm, the attribute information corresponding to the authorization policy is first extracted to form an attribute set. For example, the attribute set may contain information such as user name, age, occupation, and email address. Next, the attribute set is hashed to generate an attribute root hash. Specifically, cryptographic hash functions such as SHA-256 can be used to calculate the hash value of the attribute set.

[0109] A temporary private key is then generated, which can be a sufficiently long random number generated by a random number generator. The user's private key, the temporary private key, and the attribute root hash are then used as inputs to generate a signature using the BBS+ signature algorithm. The BBS+ signature algorithm is based on bilinear pairing and utilizes elliptic curve cryptography principles for computation.

[0110] Finally, a signature credential is constructed based on the generated signature. The signature credential contains the following fields: signature value, attribute index, signature timestamp, and authorization policy identifier. The attribute index indicates the specific attributes involved in the signature, the signature timestamp records the signature generation time, and the authorization policy identifier is used to associate the corresponding authorization policy.

[0111] Through the above technical solution, this application realizes the generation of selectively disclosed signature credentials based on the BBS+ signature algorithm. This solution allows users to reveal only necessary identity attributes to the verifier, effectively protecting user privacy. Simultaneously, the introduction of a temporary private key enhances signature security. Furthermore, including the authorization policy identifier in the signature credential provides a foundation for subsequent access control.

[0112] Preferably, the signature σ is generated by the following formula: σ = (x + k)⁻¹・(H + k・U), where x is the user's private key, k is the temporary private key, H is the attribute root hash, and U is the group generator.

[0113] In this system, the user's private key x serves as the core parameter for identity authentication and, together with the temporary private key k, constitutes a composite key factor. The attribute root hash H aggregates the attribute set in the authorization strategy through a hash chain. The group generator U is selected from the base points of the elliptic curve cyclic group, providing a mathematical basis for discrete logarithmic operations. The temporary private key k is generated independently for each signature, forming a linear combination structure with the user's private key. A mathematical barrier against quantum attacks is constructed through modular inverse operations. For example, the temporary private key k is set to 256 bits, matching the parameters of the elliptic curve domain.

[0114] Specifically, when performing signature calculations on an elliptic curve group (ECG), the user's private key x and the temporary private key k are first added modularly to generate a composite denominator (x + k). Then, the product of the temporary private key k and the group generator U is added to the attribute root hash H to form the numerator (H + k・U). The denominator is converted to a multiplicative inverse through modular inverse operation and multiplied by the numerator, ultimately generating a verifiable signature σ. The signature σ contains multiple elements, including the user's private key, the temporary private key, attribute information, and group parameters, effectively binding user identity and authorization attributes. This formula leverages the intractability of the discrete logarithm problem to ensure that attackers cannot reverse-engineer the user's private key or the temporary private key using publicly available parameters. In the verification phase, the BBS+ verification equation is verified to be true: Y・σ = H + k・(U - σ), where Y is the user's public key, σ is the signature, H is the attribute root hash, and U is the group generator. This algebraic structure allows signature verification to be performed without exposing the user's private key, while also enabling third parties to verify the validity of the signature in real time via smart contracts, providing a mathematically verifiable basis for dynamic permission revocation.

[0115] Through the above technical solution, this application achieves efficient signature generation based on the BBS+ signature algorithm. This scheme organically combines the user's private key, temporary private key, and attribute information to generate a signature that is difficult to forge. This signature can both prove the user's identity and bind authorization attributes, providing a reliable foundation for subsequent authorization verification. Furthermore, due to the use of group signature technology, this scheme also has good privacy protection characteristics, effectively balancing the needs of security and privacy.

[0116] In some of the solutions mentioned above in this application, a mechanism for dynamically revoking permissions is proposed by monitoring revocation conditions through smart contracts. However, in the actual implementation process, there is a lack of a unified monitoring mechanism for multiple types of revocation conditions, which leads to an inability to respond to complex permission revocation events in a timely manner and poses a risk of delayed permission status updates.

[0117] This application further proposes to monitor whether any of the revocation conditions among time conditions, behavioral conditions, and risk conditions are met; if any revocation condition is met, the corresponding permission authorization status is updated to revoked; a revocation credential containing a unique revocation identifier, the revoked signature hash, and the revocation reason is generated; and the revocation time and execution node information are recorded in the smart contract.

[0118] The monitoring process employs a multi-dimensional condition detection mechanism, specifically including a time threshold detection module, a behavior pattern analysis engine, and a risk event listener. The revocation credential generation stage uses cryptographic hash algorithms to generate unique identifiers, such as hashing the metadata of the revoked signature based on the SHA-256 algorithm. The smart contract recording stage records the revocation time using a blockchain transaction timestamp and verifies the identity of the execution node using a digital signature.

[0119] Specifically, when the time detection module detects that the current time exceeds the validity period threshold set by the authorization policy, it triggers a time condition detection signal. The behavior pattern analysis engine continuously collects operation logs such as API call frequency and data access volume from third-party applications. When it detects that the daily access volume exceeds three times the preset threshold, it triggers a behavior condition. The risk event listener receives real-time alerts from external risk intelligence systems. For example, when it receives an alert about abnormal IP address login, it triggers a risk condition. After any condition is triggered, the smart contract automatically performs a state update operation, changing the permission authorization field value from the boolean TRUE to FALSE. The revocation credential generation module synchronously creates a digital credential containing the hash value of the revoked signature. This hash value is obtained by performing a one-way operation on the original signature using the Keccak-256 algorithm. The smart contract writes the blockchain node ID and a timestamp accurate to milliseconds into the state update transaction, forming an immutable revocation operation record.

[0120] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0121] The system monitors in real time whether the revocation conditions are met through smart contracts. When the revocation conditions are met, the permission authorization status is set to revoked, including:

[0122] The system monitors whether any of the revocation conditions—time-based, behavioral, or risk-based—are met. The smart contract periodically checks if the current time has exceeded the preset permission validity period and simultaneously receives user behavior logs and risk event notifications.

[0123] If any revocation condition is met, the corresponding permission authorization status will be updated to "revoked". The smart contract executes the status update operation, setting the authorization status field to "revoked".

[0124] The system generates a revocation credential containing a unique revocation identifier, the hash of the revoked signature, and the reason for revocation. It also records the revocation time and execution node information in the smart contract. The revocation credential, generated by the smart contract, contains a 32-byte unique identifier, a 64-byte signature hash value, and a revocation reason code. Simultaneously, it records a revocation timestamp accurate to the second and the public key of the node that performed the revocation operation in the contract's storage.

[0125] Through the above technical solution, this application achieves real-time monitoring and dynamic revocation of authorized permissions. The automatic execution of the revocation process via smart contracts improves the timeliness and reliability of permission management. The generation of revocation credentials provides a basis for subsequent auditing, enhancing the system's traceability. This solution overcomes the limitations of traditional BBS + signature-based revocation methods, making permission management more flexible and secure.

[0126] In some of the schemes described above in this application, the validity of the signature certificate is verified, including obtaining the user's public key from the DID document; and verifying whether the signature in the signature certificate satisfies the BBS+ verification equation based on the user's public key. If it satisfies the equation, the validity verification passes; otherwise, it fails.

[0127] If the equation holds true, it confirms that the signature has not been tampered with and the user's identity is legitimate. This process ensures that only signatures generated with the correct private key can pass verification, preventing forged or invalid signature credentials from being used to access resources. Furthermore, after successful verification, the permission authorization status in the smart contract is queried. If the status is revoked, the access request is rejected even if the signature is valid. Through this dual verification mechanism, both the authenticity of the signature and dynamic control of the permission status are guaranteed.

[0128] Furthermore, the verification process also includes checking whether the signature timestamp is within its validity period and verifying the integrity of the attribute index.

[0129] Through the above technical solution, this application achieves the verification of the validity of signature credentials, ensuring the security and reliability of the authorization process. By employing a verification method based on the BBS+signature algorithm, this scheme effectively prevents signature forgery and supports selective attribute disclosure, protecting user privacy. Furthermore, by combining the verification process with smart contracts, dynamic permission management is achieved, enabling the system to respond promptly to permission changes and improving the flexibility and security of the authorization mechanism.

[0130] In some of the solutions mentioned above in this application, although the dynamic monitoring and revocation of permission status are achieved through smart contracts, there is a lack of a mechanism to actively monitor and respond to abnormal behavior in the actual use of permissions by third-party applications. As a result, when a third-party application has security risks, the system cannot quickly identify and trigger permission revocation, which poses a risk of sensitive information leakage.

[0131] This application further proposes to collect permission usage behavior data of third-party applications, and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, a risk instruction is sent to the smart contract to trigger the permission revocation process.

[0132] The permission usage behavior data includes API call frequency, access time distribution, and request attribute range. Preset risk rules are implemented by setting threshold conditions, such as exceeding a preset limit on the number of accesses within a single hour or initiating high-frequency requests outside of working hours. The machine learning model employs supervised learning methods, training a classification model based on historical normal behavior data, and comparing the deviation of current behavior from normal patterns in real time. The risk monitoring module interacts with the smart contract module through an event-driven mechanism. When abnormal behavior detection results are generated, a structured instruction containing application identifier, risk type, and evidence data is automatically generated, triggering the preset permission revocation conditions in the smart contract.

[0133] Specifically, permission usage behavior data is collected in real time via embedded tracking and transmitted to the data cache queue of the risk monitoring module. The risk rule engine periodically aggregates and calculates the data; if the frequency of access to a single attribute exceeds 50 times within 10 seconds, it is judged as high-frequency abnormal behavior. The machine learning model uses the Isolation Forest algorithm to perform unsupervised anomaly detection on access time intervals and attribute combination patterns. When the anomaly score exceeds 0.85, an alarm is triggered. After detecting abnormal behavior, the risk monitoring module generates a risk instruction containing a timestamp, behavior fingerprint, and risk level, and writes it into the revocation condition verification logic of the smart contract through a blockchain transaction. Upon receiving the instruction, the smart contract immediately verifies the validity of the instruction signature. If the verification passes, the corresponding permission authorization status is marked as revoked, and subsequent access requests are frozen. This process is completed within 200 milliseconds, ensuring real-time processing from risk identification to permission revocation and effectively blocking abnormal access behavior.

[0134] Through the above technical solution, this application can identify abnormal access patterns of third-party applications during permission usage in real time. Combining a dual detection mechanism of a rule engine and a machine learning model, it effectively reduces the false positive rate. When high-frequency abnormal access or potential attack behavior is detected, the smart contract is automatically triggered to revoke permissions, preventing third-party applications from continuing to access sensitive resources using expired credentials. This solves the data leakage problem caused by delayed risk response in existing technologies and enhances the proactive defense capabilities of the permission management system.

[0135] Based on the above-mentioned authorization method that supports dynamic revocation of permissions, this application further proposes an authorization system that supports dynamic revocation of permissions, such as... Figure 2 As shown, it includes a user identity management module 1, an attribute-based authorization strategy module 2, a signature module 3, a smart contract module 4, and an application interface module 5, wherein:

[0136] User identity management module 1 is used to obtain user identity attribute information, and generate user DID identifier and corresponding public-private key pair based on the user identity attribute information, and form DID document;

[0137] The attribute-based authorization policy module 2 is used to define an authorization policy for third-party applications based on attributes. The authorization policy includes the authorized third-party application identifier, accessible attributes, permission validity period, and revocation conditions.

[0138] The signature module 3 is used to generate a signature credential based on the BBS+ signature algorithm according to the authorization policy. The signature credential is used for authorization verification of access by third-party applications.

[0139] The smart contract module 4 is used to establish a smart contract for the permission authorization status of the third-party application based on the authorization policy and the metadata corresponding to the signature certificate, and to monitor in real time whether the revocation conditions are met through the smart contract. When the revocation conditions are met, the permission authorization status is set to revoked.

[0140] Application interface module 5 is used to verify the validity of the signature certificate when a third-party application accesses resources through the signature certificate, and to query the smart contract to confirm the permission authorization status. If the permission authorization status is revoked, the access request of the third-party application is rejected.

[0141] Through the above technical solutions, this application implements a dynamic permission control mechanism in a distributed identity authorization scenario. Modular design decouples identity verification from permission management, allowing third-party application access permissions to automatically expire based on preset conditions. On-chain execution of smart contracts ensures the irreversibility and real-time nature of permission revocation, effectively preventing the continued abuse of revoked permission signature credentials. A multi-dimensional risk monitoring mechanism identifies potential threats in advance through behavioral feature analysis, immediately triggering permission revoke when abnormal access behavior reaches a threshold, significantly shortening risk response time. The collaborative operation of each module forms a closed-loop management system, maintaining the privacy protection characteristics of BBS+signature while addressing the technical shortcomings of traditional solutions, such as delayed permission revocation and coarse-grained control.

[0142] In some of the solutions mentioned above in this application, although the system can monitor revocation conditions and update permission status through smart contracts, it lacks a mechanism to actively monitor abnormal behavior of third-party applications, which results in the inability to trigger permission revocation in a timely manner when security risks are detected, and there is a problem of delayed response.

[0143] To this end, the system also includes a risk monitoring module 6, which is used to collect permission usage behavior data of third-party applications and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, a risk specification is sent to the smart contract to trigger the permission revocation process.

[0144] The risk monitoring module 6 collects operation logs from third-party applications during permission usage via a log recording interface. This logs include access request frequency, request time distribution, access attribute range, and request source IP address. Preset risk rules include frequency limit rules, geolocation anomaly rules, and attribute boundary violation rules. The frequency limit rule sets a threshold for the number of access requests per hour. The geolocation anomaly rule determines whether the access location exceeds the authorized range based on the IP address's location. The attribute boundary violation rule detects whether the third-party application attempts to access unauthorized attribute fields. The machine learning model employs a behavior sequence analysis model based on an LSTM network. This model generates a behavior baseline through training on historical normal behavior data and calculates the deviation of the current operation sequence from the baseline in real time. When the deviation exceeds a preset threshold, the risk monitoring module generates a risk instruction containing the risk type, trigger time, and evidence data, and submits the risk instruction to the smart contract module via a blockchain transaction interface. Upon receiving the risk instruction, the smart contract module automatically executes the permission revocation process, updates the target third-party application's permission authorization status to revoked, and records the timestamp and transaction hash of the revocation operation on the blockchain.

[0145] Through the above technical solution, this application achieves real-time monitoring and dynamic risk response to the permission usage behavior of third-party applications. By combining a dual detection mechanism of preset rules and machine learning models, it effectively identifies abnormal access behavior and automatically triggers permission revocation. This technical solution solves the problem of delayed risk response in existing technologies, and can immediately terminate the access rights of third-party applications when a security threat is detected, preventing the risk of sensitive data leakage due to delayed processing. At the same time, the immutability of blockchain ensures the audit traceability of the revocation operation.

[0146] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An authorization method supporting dynamic revocation of permissions, characterized in that, The method includes the following steps: Obtain user identity attribute information, and generate a user DID identifier and corresponding public / private key pair based on the user identity attribute information, and form a DID document; The authorization policy for third-party applications is defined based on attributes. The authorization policy includes the identifier of the authorized third-party application, accessible attributes, permission validity period, and revocation conditions. According to the authorization policy, a signature credential is generated based on the BBS+ signature algorithm. The signature credential is used to verify the authorization of access by third-party applications. Based on the authorization policy and the metadata corresponding to the signature credential, a smart contract is established to determine the permission authorization status of the third-party application. The smart contract is used to monitor in real time whether the revocation conditions are met. When the revocation conditions are met, the permission authorization status is set to revoked. When a third-party application accesses resources using the signature credential, the validity of the signature credential is verified, and the smart contract is queried to confirm the permission authorization status. If the permission authorization status is revoked, the access request from the third-party application is rejected.

2. The authorization method supporting dynamic revocation of permissions according to claim 1, characterized in that, The attribute-based authorization policy for third-party applications includes: Select the attributes that third-party applications are allowed to access; Set the validity period and revocation conditions for the permissions corresponding to each attribute; The authorization policy is converted into a machine-recognizable permission descriptor.

3. The authorization method supporting dynamic revocation of permissions according to claim 2, characterized in that, The revocation conditions include time conditions, behavioral conditions, and risk conditions. The time conditions indicate the time period that triggers the revocation of permissions, the behavioral conditions indicate user behavior that triggers the revocation of permissions, and the risk conditions indicate the abnormal events that trigger the revocation of permissions.

4. The authorization method supporting dynamic revocation of permissions according to claim 1, characterized in that, The step of generating a signature credential based on the BBS+ signature algorithm according to the authorization policy includes: Extract the attribute information corresponding to the authorization strategy and form an attribute set; The combination of numbers and shapes is hashed to generate the attribute root hash; Generate a temporary private key, and combine it with the user's private key and the attribute root hash to generate a signature using the BBS + signature algorithm; Based on the signature, the signature credential is generated; the signature credential includes the signature, attribute index, signature timestamp, and authorization policy identifier.

5. The authorization method supporting dynamic revocation of permissions according to claim 4, characterized in that, The signature σ is generated using the following formula: σ = (x + k)⁻¹・(H + k・U), Where x is the user's private key, k is the temporary private key, H is the attribute root hash, and U is the group generator.

6. The authorization method supporting dynamic revocation of permissions according to claim 3, characterized in that, The step of monitoring in real time whether the revocation conditions are met through the smart contract, and setting the permission authorization status to revoked when the revocation conditions are met, includes: Whether the monitoring meets any of the revocation conditions among the time condition, behavior condition, and risk condition; If any of the revocation conditions are met, the corresponding permission authorization status will be updated to revoked; Generate a revocation credential containing a unique revocation identifier, the hash of the revoked signature, and the reason for revocation, and record the revocation time and execution node information in the smart contract.

7. The authorization method supporting dynamic revocation of permissions according to claim 4, characterized in that, The validity verification of the signature credential includes: Obtain the user's public key from the DID document; Based on the user's public key, verify whether the signature in the signature credential satisfies the BBS+ verification equation Y・σ = H + k・(U - σ). If it is satisfied, the validity verification passes; otherwise, it fails.

8. The authorization method supporting dynamic revocation of permissions according to claim 1, characterized in that, The method further includes: Collect permission usage behavior data of third-party applications, and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, send risk specification to smart contract to trigger permission revocation process.

9. An authorization system that supports dynamic revocation of permissions, characterized in that, The system includes: The user identity management module is used to obtain user identity attribute information, and generate a user DID identifier and corresponding public-private key pair based on the user identity attribute information, and form a DID document; The attribute-based authorization policy module is used to define authorization policies for third-party applications based on attributes. The authorization policy includes the authorized third-party application identifier, accessible attributes, permission validity period, and revocation conditions. The signature module is used to generate a signature credential based on the BBS+ signature algorithm according to the authorization policy. The signature credential is used for authorization verification of access by third-party applications. The smart contract module is used to establish a smart contract for the permission authorization status of the third-party application based on the authorization policy and the metadata corresponding to the signature certificate, and to monitor in real time whether the revocation conditions are met through the smart contract, and set the permission authorization status to revoked when the revocation conditions are met; The application interface module is used to verify the validity of the signature credential when a third-party application accesses resources through the signature credential, and to query the smart contract to confirm the permission authorization status. If the permission authorization status is revoked, the access request of the third-party application is rejected.

10. The authorization system supporting dynamic revocation of permissions according to claim 9, characterized in that, The system also includes: The risk monitoring module is used to collect permission usage behavior data of third-party applications and detect abnormal behavior of third-party applications based on preset risk rules and machine learning models. When abnormal behavior is detected, a risk specification is sent to the smart contract to trigger the permission revocation process.

Images