Quantum-resistant security enhancements for the Open Identity Connection Protocol

Abstract

The present invention discloses a method for enhancing the quantum security of the Open Identity Connection protocol, which specifically relates to the field of distributed identity authentication technology. The method is used to address the identity hijacking risk caused by the delayed client public key update in the scenario of high-frequency key rotation of quantum-resistant cryptography in the existing OIDC protocol. The method dynamically generates a version identification public key that integrates a timestamp and a hash, and implements multicast / shard routing change notification broadcast based on the client's historical response and network topology characteristics. The relying party client accurately requests the new version public key and updates the local cache after verification. The method constructs an anomaly detection model based on the key version discreteness and the update frequency standard deviation to trigger a dynamic threshold rollback mechanism with adaptive security level. The method realizes quantum security key synchronization, real-time self-healing of client cache anomalies, and network resource optimization, eliminating the key rotation period attack window.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed identity authentication, and more specifically, to a method for enhancing the quantum security of an open identity connection protocol. Background Art

[0002] The Open Identity Connect (OIDC) protocol, as the core identity authentication framework for modern distributed systems, relies on cryptographic algorithms to verify the digital signatures of tokens (such as id_tokens). In existing technologies, identity providers (IdPs) publish public keys through the JSON Web Key Set (JWKS) endpoint, and relying party (RP) clients typically obtain public key information through static configuration or low-frequency polling mechanisms. For example, clients must statically configure the jwks_uri address during initialization, or obtain the jwks_uri through a discovery document and then rely on its cache update mechanism, which has an update cycle preset by the server and typically lasts from several hours to several days. This design is feasible in scenarios with traditional cryptographic algorithms (such as RSA and ECC) because their key lifecycles are long, and client update delays have limited security impact.

[0003] However, in response to the threat of quantum computing, the introduction of quantum-resistant cryptography (PQC) requires frequent key rotation to reduce the risk of long-term key exposure. The existing OIDC protocol's public key management mechanism is flawed: the client's static configuration and low-frequency update logic are unable to adapt to the high-frequency key rotation requirements. After the identity provider performs key rotation, the relying party's client may still use the revoked public key to verify tokens due to delayed configuration or unupdated caches. This allows attackers to forge legitimate tokens using the expired private key after rotation, creating a systemic identity hijacking vulnerability. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method for enhancing the quantum security of the open identity connection protocol to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] The Open Identity Connection Protocol's quantum security enhancements include:

[0007] S1. The identity provider generates a key pair and publishes the public key and its version identifier to the public key endpoint;

[0008] S2. When the identity provider performs key rotation, it generates a new key pair and updates the public key endpoint. It generates a broadcast priority sequence based on the historical notification confirmation rate and security level of the relying party client. It selects network layer multicast or application layer shard routing based on the persistent coherence characteristics of the IP topology. It distributes change notifications containing the new public key version identifier according to the broadcast priority and route.

[0009] S3. After receiving the change notification, the relying party client sends a public key acquisition request carrying the new public key version identifier to the public key endpoint;

[0010] S4. The identity provider retrieves the corresponding public key and its version identifier from the public key endpoint based on the new public key version identifier in the public key acquisition request and returns it.

[0011] S5. The relying party client verifies the token signature using the returned public key and updates it to the local public key cache upon successful verification.

[0012] S6. The relying party client calculates the state abnormality value of the local public key cache. When the state abnormality value exceeds the dynamic threshold, the cache rollback is triggered and a security alarm is generated.

[0013] Furthermore, S1 includes:

[0014] Select a quantum-resistant cryptographic algorithm to generate a key pair consisting of a public key and a private key;

[0015] Assign a unique version identifier to the public key, which is composed of the current timestamp and a randomly generated hash value;

[0016] Encapsulate the public key and its version identifier into data that conforms to the JSON Web Key format;

[0017] Publish the encapsulated data to a pre-configured public key endpoint over a secure HTTP connection.

[0018] Furthermore, S2 includes:

[0019] Generate a key pair consisting of a new public key and a new private key;

[0020] Add the new public key and its version identifier to the public key endpoint to overwrite the historical public key;

[0021] Extract the security level of each relying party client from the client registration metadata;

[0022] The historical notification confirmation rate is calculated as the proportion of confirmation responses returned by the relying party client to historical key change notifications within a preset period;

[0023] The priority weight value is calculated by taking the weighted sum of the weight coefficient of the security level mapping and the historical notification confirmation rate;

[0024] Generate a broadcast priority sequence by sorting the priority weight values ​​from high to low;

[0025] Scan the source IP addresses of the relying party’s client connections and build an IP topology point cloud dataset;

[0026] Calculate the 0-dimensional and 1-dimensional persistent homology eigenvalues ​​based on the Euclidean distance relationship in the IP topology point cloud dataset;

[0027] Select network layer multicast routing or application layer shard routing based on the 0-maintaining long-term coherence characteristic value and the 1-maintaining long-term coherence characteristic value;

[0028] The change notification is distributed according to the broadcast priority sequence and the selected route.

[0029] Furthermore, selecting network layer multicast routing or application layer shard routing according to the 0-maintaining persistent coherence characteristic value and the 1-maintaining persistent coherence characteristic value includes:

[0030] When the 0-maintained long-term coherence characteristic value is greater than or equal to the first threshold and the 1-maintained long-term coherence characteristic value is less than or equal to the second threshold, the network layer multicast route is selected;

[0031] When the 0-maintaining long-term coherence characteristic value is less than the first threshold or the 1-maintaining long-term coherence characteristic value is greater than the second threshold, application layer shard routing is selected.

[0032] Furthermore, S3 includes:

[0033] Parse the received change notification to extract the new public key version identifier;

[0034] Constructing a Hypertext Transfer Protocol request message containing a new public key version identifier;

[0035] Set the public key endpoint address as the target Uniform Resource Locator of the request message;

[0036] Send a request message to the public key endpoint over the TCP connection.

[0037] Furthermore, S4 includes:

[0038] Parse the received public key acquisition request to extract the new public key version identifier;

[0039] Query the JSON Web Keyset stored at the public key endpoint for a public key record that matches the new public key version identifier.

[0040] Extract the public key and its version identifier from the matching public key record;

[0041] Encapsulating the extracted public key and its version identifier into a Hypertext Transfer Protocol response message;

[0042] Returns a Hypertext Transfer Protocol response message to the relying party client over the Transmission Control Protocol connection.

[0043] Furthermore, S5 includes:

[0044] Extract the public key and its version identifier from the HTTP response message returned by the identity provider;

[0045] Use the extracted public key to verify the digital signature of the received identity token;

[0046] When the signature verification passes, the public key and its version identifier are written to the local public key cache in memory;

[0047] A mapping relationship between the version identifier and the public key is established in the local public key cache.

[0048] Furthermore, S6 includes:

[0049] Extract all key version identifiers from the local public key cache to form a version identifier set;

[0050] Calculate the variance value of the version identifier set as the key version distribution dispersion;

[0051] Count the public key update timestamp sequence of the local public key cache;

[0052] Calculate the interval standard deviation of the public key update timestamp sequence as the update frequency standard deviation;

[0053] The state anomaly value is calculated based on the key version distribution dispersion and the update frequency standard deviation;

[0054] Read the security level from the client configuration data;

[0055] Modify the predefined basic threshold according to the adjustment coefficient corresponding to the security level to obtain a dynamic threshold;

[0056] When the state abnormality value is greater than the dynamic threshold, the local public key cache is rolled back to the last valid state;

[0057] Generates security alert logs containing abnormal status values ​​and rollback events.

[0058] Compared with the prior art, the present invention has the following beneficial effects:

[0059] 1. Significantly improve the security of identity authentication in quantum-resistant cryptography scenarios: First, the identity provider's innovative dynamic broadcast mechanism breaks through the limitations of traditional static configuration. It intelligently selects multicast or sharding routes based on the client's historical response capabilities and network topology characteristics to achieve accurate and efficient delivery of change notifications. Through a dual-track strategy of priority sorting and route optimization, it ensures that critical clients are notified of updates first during high-frequency key rotations, eliminating the risk of public key failure due to notification delays at the source. Second, the active defense system built by the relying party client forms a closed-loop protection chain: accurate acquisition of public keys based on version identification avoids full polling overhead; the local cache anomaly detection model couples the dual factors of key version discreteness and update frequency standard deviation to dynamically perceive cache pollution or tampering attacks; the security level adaptive threshold mechanism realizes elastic protection for mobile and server environments; snapshot rollback and alarm linkage ensure self-healing of abnormal states in seconds.

[0060] 2. Version identification provides a temporal and spatial traceability foundation for anomaly detection; dynamic broadcast establishes a channel for clients to promptly obtain new public keys; cache verification and updates ensure real-time public key usage; and state monitoring reversely verifies broadcast validity. This coupled design provides the system with triple protection: it reduces the attack window during key rotation from hours to seconds, resolving the core issue of high-frequency quantum key rotation; significantly reduces the risk of identity hijacking; and reduces network resource consumption, making it adaptable to weak network environments such as the Internet of Things. This overall approach strengthens the security of the Open Identity Protocol in quantum-resistant scenarios, providing a foundation for sustainable identity trust for distributed systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 This is a flow chart of the method for enhancing quantum security of the open identity connection protocol of the present invention. DETAILED DESCRIPTION

[0062] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0063] Example: Figure 1 A method for enhancing the quantum security of the open identity connection protocol of the present invention is provided, comprising:

[0064] S1. The identity provider generates a key pair and publishes the public key and its version identifier to the public key endpoint;

[0065] S2. When the identity provider performs key rotation, it generates a new key pair and updates the public key endpoint. It generates a broadcast priority sequence based on the historical notification confirmation rate and security level of the relying party client. It selects network layer multicast or application layer shard routing based on the persistent coherence characteristics of the IP topology. It distributes change notifications containing the new public key version identifier according to the broadcast priority and route.

[0066] S3. After receiving the change notification, the relying party client sends a public key acquisition request carrying the new public key version identifier to the public key endpoint;

[0067] S4. The identity provider retrieves the corresponding public key and its version identifier from the public key endpoint based on the new public key version identifier in the public key acquisition request and returns it.

[0068] S5. The relying party client verifies the token signature using the returned public key and updates it to the local public key cache upon successful verification.

[0069] S6. The relying party client calculates the state abnormality value of the local public key cache. When the state abnormality value exceeds the dynamic threshold, the cache rollback is triggered and a security alarm is generated.

[0070] S1. The identity provider generates a key pair and publishes the public key and its version identifier to the public key endpoint. The specific implementation is as follows:

[0071] The identity provider selects a quantum-resistant cryptographic algorithm and generates a key pair consisting of a public key and a private key. The specific type of quantum-resistant cryptographic algorithm is determined by a preconfigured security policy file stored on a protected disk partition. Key pair generation is performed by calling the cryptographic library function provided by the operating system, with input parameters including the key length and the algorithm identifier. The key length is determined by the selected algorithm type, for example, 2048 bits for a lattice-based algorithm and 6960 bits for an encoding-based algorithm. Key generation is performed by calling the cryptographic library's key pair generation function, which takes as input the algorithm identifier and key length parameters and outputs the public and private keys as byte arrays.

[0072] A unique version identifier is assigned to the public key, consisting of the concatenation of the current timestamp and a randomly generated hash value. The current timestamp uses a time format that includes the year, month, day, hour, minute, second, millisecond, and the Coordinated Universal Time Zone offset, for example, 2025-03-15T08:30:45.123+08:00. Timestamp generation uses the operating system's clock interface to obtain the current time value. The randomly generated hash value uses a secure random number generator to generate 32 bytes of entropy data, which is then calculated using the Secure Hash Algorithm 3 function to produce a 64-character hexadecimal string. The timestamp and hash value are concatenated using the underscore character. This concatenation is performed in a memory string buffer to form the complete version identifier.

[0073] The public key and its version identifier are encapsulated into data that conforms to the JSON Web Key format. The encapsulation process creates a JSON object as a data container and sets a key-value pair corresponding to the version identifier in the JSON object. The key is the fixed string kid and the value is the version identifier string generated above. The public key data is mapped to standard fields according to the algorithm type: when using a lattice-based algorithm, the public key byte array is Base64-encoded and filled into the x field; when using an encoding-based algorithm, it is filled into the k field. At the same time, the kty field is set to identify the key type, for example, the lattice-based algorithm is set to the LAT string; the alg field is set to declare the signature algorithm, for example, the lattice-based algorithm is set to the Dilithium3 string. After the encapsulation is completed, the memory object is converted into a UTF-8 encoded byte stream through the JSON serialization function.

[0074] The encapsulated data is published to a pre-configured public key endpoint via a Hypertext Transfer Protocol secure connection. The Hypertext Transfer Protocol secure connection is established based on the Transport Layer Security protocol and uses a pre-set digital certificate for two-way authentication. The public key endpoint address is obtained through the Open Identity Connection Discovery Protocol. A request is sent to a fixed path in the identity provider's domain name to obtain response data containing the jwks_uri field. The Uniform Resource Locator string is parsed from the response data as the public key endpoint address. The publish operation constructs a Hypertext Transfer Protocol PUT request, sets the content type in the request header to application / jwk+json, and loads the aforementioned serialized JSON byte stream into the request body. After sending, the status code returned by the verification server is 201, indicating successful creation.

[0075] The security policy file is in text format and contains an "algorithm_selection" field that specifies the type of quantum-resistant cryptographic algorithm. This file is obtained from the management center via a secure file transfer protocol and is updated no more than every 24 hours. The key length value is stored in the algorithm library's metadata description file. When loading the algorithm, this file is parsed to extract the length field value as a key generation parameter. Timestamp retrieval uses the operating system's clock interface. In Linux, a specific function is used to obtain millisecond-level time values. The time zone offset is calculated by reading system environment variables. The secure random number generator uses the random source device file provided by the operating system and reads 32 bytes of raw data. The secure hash algorithm 3 is calculated using the cryptography library's function interface, taking as input an entropy byte array and outputting a fixed-length digest. When converted to a hexadecimal string, each byte is converted to two characters, and lowercase letters are used to represent hexadecimal values. Base64 encoding uses the Unicode padding scheme. The encoding function takes as input a public key byte array and adds padding to the output string to align the length. Certificates are formatted in a specific format and stored in secure storage. Validity and key usage are checked during certificate chain verification. The Open Identity Connect Discovery Protocol request is sent to a fixed path, and the response is in JSON format. The jwks_uri field value is parsed as the public key endpoint address, which is cached for no more than 7 days.

[0076] S2. When the identity provider performs key rotation, it generates a new key pair and updates the public key endpoint. It generates a broadcast priority sequence based on the historical notification confirmation rate and security level of the relying party client. It selects network layer multicast or application layer shard routing based on the persistent coherence characteristics of the IP topology. It distributes change notifications containing the new public key version identifier according to the broadcast priority and route. The specific implementation is as follows:

[0077] When performing key rotation, the identity provider generates a key pair consisting of a new public key and a new private key. This key pair generation calls the same quantum-resistant cryptography library function used during initial key generation. Input parameters include a key length value and an algorithm identifier string. The key length value remains consistent with the historical key length. The key generation operation is performed within the hardware security module and outputs a byte array of the new public key and an access handle to the new private key. The private key access handle is used only for signing operations and cannot be exported outside the hardware security module.

[0078] The new public key and its version identifier are added to the public key endpoint, overwriting the historical public key. The version identifier is generated using the same rules as the initial key release phase and consists of a current timestamp string and a random hash value string concatenated with an underscore. The addition operation is performed over a secure Hypertext Transfer Protocol connection, sending a PUT request to the public key endpoint address. The request body encapsulates the JSON Web Key format data of the new public key. The public key endpoint uses a key-value database storage structure, with the primary key being the version identifier string. When adding a new record, the oldest historical public key record is deleted to keep the total number of public keys below a preset upper limit, such as 10 records.

[0079] Extract the security level value of each relying party client from the client registration metadata. Client registration metadata is stored in the registration information table of a relational database. Each record contains a client identifier string and a security level enumeration value. The security level enumeration value is a predefined discrete value, including high security, medium security, and low security. The extraction operation executes a structured query language statement to retrieve the corresponding security level field value based on the client identifier field. The result is stored in an in-memory dictionary structure, where the dictionary key is the client identifier string and the value is the security level string.

[0080] The proportion of confirmation responses returned by the relying party client to historical key change notifications within the preset period is counted as the historical notification confirmation rate. The preset period is a configurable time span value, such as 30 natural days, which is calculated from the current time point forward. The historical key change notification log is stored in a time series database, and each log record contains the notification sending timestamp, client identifier string and response status code value. The statistical process includes three steps: the first step is to query the total number of notifications sent to the target client within the preset period; the second step is to filter the number of notification records with a response status code of 200; the third step is to calculate the proportion value: the quotient of the number of confirmation responses divided by the total number of notifications. The calculation result retains two significant digits after the decimal point.

[0081] The priority weight is calculated by weighting and summing the security level mapping weight coefficient and the historical notification confirmation rate. The security level mapping weight coefficient is a predefined fixed mapping relationship: high security level corresponds to a value of 0.7, medium security level corresponds to a value of 1.0, and low security level corresponds to a value of 1.3. The weighted sum calculation formula is: the priority weight value is equal to the weight coefficient value multiplied by the historical notification confirmation rate value. The calculation process iterates through each client identifier, reads the security level string from the memory dictionary, converts it to a weight coefficient value based on the mapping relationship, and then multiplies it by the historical notification confirmation rate value of the client. The calculation result is a floating-point value with a range of 0 to 1.3.

[0082] A broadcast priority sequence is generated by sorting the client identifiers from highest to lowest priority weights. The sorting algorithm uses a quick sort algorithm, with input consisting of a key-value pair of client identifiers and priority weights. The sort comparison function sorts the client identifiers in descending order based on their priority weights. If the priority weights are the same, the client identifiers are sorted in ascending lexicographical order. The output is an ordered list of client identifier strings, with the client identifier at index 0 having the highest priority.

[0083] Scan the source IP addresses of the relying party's client connections and construct an IP topology point cloud dataset. The scanning operation queries the network connection status table, which records the client identifier string, source IP address string, and the most recent active timestamp for all active connections. After extracting the source IP address string, it is parsed into three-dimensional coordinate data using a locally deployed geolocation database: a longitude floating-point value, a latitude floating-point value, and an autonomous system number integer value. Each IP address corresponds to a three-dimensional point coordinate data. For example, the IP address 192.0.2.1 is parsed into a three-dimensional point with longitude 121.4737, latitude 31.2304, and autonomous system number 64512. All three-dimensional point coordinates constitute a point cloud dataset stored as a floating-point matrix.

[0084] The 0-dimensional and 1-dimensional persistent homology eigenvalues ​​are calculated based on the Euclidean distance relationships in the IP topology point cloud dataset. The calculation process consists of three core steps: the first step is to calculate the Euclidean distance between every two points in the point cloud to form a distance matrix. The Euclidean distance calculation formula is the same as the straight-line distance formula in three-dimensional space. The second step is to construct a filter complex structure: starting from a distance threshold of 0 and gradually increasing the distance threshold, at each threshold, connecting points with a distance less than the current threshold to form a simplicial complex. The third step is to record the changes in the topological structure: the 0-dimensional eigenvalue counts the changes in the number of connected components, and the 1-dimensional eigenvalue counts the changes in the number of ring structures. Finally, two eigenvalue sequences are output.

[0085] Network-layer multicast routing is selected when the 0-level persistent coherence characteristic value is greater than or equal to the first threshold and the 1-level persistent coherence characteristic value is less than or equal to the second threshold. The first threshold is calculated as the reciprocal of the total number of relying clients. For example, if the total number of clients is 2, the first threshold is 0.5. The second threshold is calculated as the square root of the number of IP addresses, rounded to the nearest integer. For example, if the number of IP addresses is 10, the square root is approximately 3.16, resulting in a second threshold of 3. Network-layer multicast routing uses the Internet Group Management Protocol. Multicast group addresses are randomly selected from a pre-allocated multicast address pool, such as 239.192.0.1. The multicast packet lifetime field is set to 32 hops.

[0086] Application-layer shard routing is selected when the 0-level persistent coherence feature value is less than a first threshold or the 1-level persistent coherence feature value is greater than a second threshold. Application-layer shard routing splits the change notification into multiple data slices, each containing a partial list of client identifiers. The sharding rule is to divide the data into slices in order of broadcast priority, with each slice containing a maximum of a fixed number of client identifiers, such as 50. The sliced ​​data is sent individually to edge proxy nodes via a secure HTTP connection. The edge proxy node address is obtained from the Uniform Resource Locator string read from the configuration file.

[0087] Notification of changes in distribution are made according to the results of the broadcast priority sequence sorting and the selected routing. For network layer multicast routing: construct a single multicast message, the message body of which contains the new public key version identification string and a list of the top 100 client identifiers with the highest priority in the broadcast priority sequence, and send it to the multicast group address via the User Datagram Protocol. For application layer fragmentation routing: traverse the broadcast priority sequence, and generate a fragmentation message for every fixed number, such as 50 client identifiers. The message body contains the fragmentation sequence number, the total number of fragments, and the corresponding client identifier sublist, and sends it to the assigned edge proxy node address via the Transmission Control Protocol connection. All distribution operations are required to be completed within a preset time threshold, such as 500 milliseconds, and a timeout triggers a retransmission mechanism.

[0088] The security level weight coefficient mapping table is stored in the configuration file, which is a key-value text file stored in a protected disk directory. The weight coefficient setting logic reflects the security priority strategy: clients with higher security levels are assigned lower weight coefficient values, giving their weighted calculation results a higher ranking priority. When maintaining the long-term coherence eigenvalue to count the changes in the number of connected components, the length of the distance threshold interval from the formation to the disappearance of each connected component is recorded. When maintaining the long-term coherence eigenvalue to count the changes in the number of ring structures, the length of the distance threshold interval from the formation to the disappearance of each ring structure is recorded. The edge proxy node address list is stored in the configuration file, and fragmented messages are distributed using a round-robin method. Fragmented messages contain a hash checksum of the message body. If the check fails on the receiving end, a retransmission request is returned. The maximum number of retransmissions for a single fragmented message is set to a preset value, such as 3.

[0089] The value range of the security level field in the client registration metadata table is implemented through enumeration constraints, allowing only the string values ​​of high, medium, and low security levels. The response status code field in the historical key change notification log is a three-digit integer, and the confirmation response status code is fixed to 200. Autonomous system number integer values ​​in three-dimensional coordinates are normalized to the range of 0 to 65535 using modulo arithmetic. Invalid distance pairs exceeding the diameter of the Earth are ignored during distance matrix calculations. The multicast address pool consists of 256 addresses preset in the 239.192.0.0 / 24 network segment. Fragment sequence numbers are assigned sequentially starting from 1, and the total number of fragments is equal to the total number of clients divided by the fragment capacity, rounded up.

[0090] S3. After receiving the change notification, the relying party client sends a public key acquisition request carrying the new public key version identifier to the public key endpoint. The specific implementation is as follows:

[0091] After receiving the change notification, the relying party client parses the change notification to extract the new public key version identifier string. The change notification is a binary data stream encapsulated in JavaScript Object Notation. The parsing process is performed using standard JSON parsing library functions. The input parameter is the raw byte array data of the change notification, and the output is a dictionary structure object in memory. The key-value data corresponding to the fixed key "kid" is read from this dictionary structure object. This key-value data is a string type, representing the new public key version identifier string. The format of the new public key version identifier string is consistent with the identity provider's generation rules. It consists of a timestamp string, an underscore character, and a hash value string. For example, the string is "2025-03-15T08:30:45.123+08:00_9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08".

[0092] Construct a Hypertext Transfer Protocol request message containing the new public key version identifier string. This request message construction operation creates a request object instance in memory, sets the request method field to the string "GET," and includes a request header field containing the Accept Content-Type field set to the string "application / jwk+json." Add a version identifier parameter to the Uniform Resource Locator query parameters. The parameter name is the fixed string "kid," and the parameter value is the new public key version identifier string extracted in the previous step. The request message body remains in an empty byte array. After message construction is complete, it is converted into raw byte stream data using the serialization function. The byte stream encoding is performed using the UTF-8 character set standard.

[0093] Sets the public key endpoint address string as the target Uniform Resource Locator (URL) of the request message. The public key endpoint address string is retrieved from locally cached data, which is obtained from the identity provider discovery interface during client initialization and persisted in a local configuration file. The address string format is a standard URL including a protocol identifier. The set operation assigns the URL field of the in-memory request object to the address string data and verifies that the address protocol type is Hypertext Transfer Protocol Secure (HTTPS).

[0094] Send a request message to the public key endpoint via a Transmission Control Protocol (TCP) connection. The TCP connection establishment process consists of four steps: Step 1: Parse the domain name portion of the public key endpoint address, such as the "idp.example.com" string; Step 2: Obtain Internet Protocol (IP) address list data through the Domain Name System (DNS) resolution service, such as the 192.0.2.1 and 192.0.2.2 addresses; Step 3: Select the first IP address in the list to establish a TCP socket connection, setting the connection timeout threshold to 5000 milliseconds; Step 4: After the connection is established, send the request message byte stream data via the connected socket, and set the response read timeout threshold to 3000 milliseconds. The sending operation includes network byte order conversion to ensure that the packet length field complies with the TCP specification.

[0095] Before parsing a change notification, the authenticity of the notification source must be verified. This verification process consists of three steps: Step 1: Extract the byte data of the digital signature portion of the change notification message; Step 2: Obtain the current public key data of the identity provider, which is cached in the local secure storage area during the client initialization phase; Step 3: Verify the validity of the digital signature using this public key data and the specified signature algorithm. The signature algorithm type is obtained from the algorithm identifier field in the change notification header, for example, the specific algorithm identifier is the string "Dilithium3". Only after verification is passed will the new public key version identifier string be extracted. If verification fails, the change notification message is discarded.

[0096] The client's authentication information is appended to the request message. The authentication information generation process consists of three steps: Step 1: Read the client's private key from local secure storage; Step 2: Generate an authentication claim containing a timestamp; Step 3: Sign the claim using the private key to generate a JSON Web Token. This token is placed in the Authorization field of the request header, with the field value consisting of the "Bearer" string followed by a space and the token string. Upon receiving the request, the identity provider verifies the token's validity.

[0097] The public key endpoint address cache update mechanism is executed according to a predefined policy. When a request fails, the update process is triggered: Step 1: Access the fixed discovery path " / .well-known / openid-configuration" of the identity provider domain name; Step 2: Parse the "jwks_uri" field in the response data to obtain the latest address string; Step 3: Update the local configuration file and reset the cached timestamp data. The address cache validity period is set to 7 calendar days, and the update operation is automatically executed after expiration.

[0098] The Transmission Control Protocol connection process implements a fault-tolerant mechanism. When DNS resolution fails, the following steps are executed: Step 1: Retry the resolution operation up to three times; Step 2: If this fails, use the last successfully connected Internet Protocol address data. A connection timeout or read timeout triggers a retransmission mechanism: Step 1: Close the current socket connection; Step 2: Select the next Internet Protocol address in the address list to reestablish the connection; Step 3: Retransmit the request message up to two times. All network error events are recorded in the client log file.

[0099] Response data processing includes integrity checking. Upon receiving the response byte stream, the following steps are performed: Step 1: Verify that the HTTP status code is 200; Step 2: Read the Content-Length field and verify that the actual number of bytes received matches the value in that field; Step 3: Calculate the Secure Hash Algorithm 256 digest of the response body; and Step 4: Compare the digest value with the digest field in the response header. If the verification passes, the public key extraction process is performed. If the verification fails, an error event is logged and a retry process is triggered.

[0100] The public key extraction operation parses the target public key data from the response body. The parsing process consists of four steps: Step 1: deserialize the response byte stream data into a JSON object; Step 2: iterate over the public key list data, comparing the "kid" field value of each public key object to the request parameter value; Step 3: After finding a match, extract the public key data field, such as the "x" field value for a lattice-based cryptographic algorithm; Step 4: decode the Base64-encoded string into the original public key byte array. The decoded public key byte array is stored in the client's public key cache, replacing the previous public key data with the same version identifier string.

[0101] During client initialization, the discovery protocol process is executed to obtain the public key endpoint address string. This process consists of three steps: Step 1: Send a Hypertext Transfer Protocol GET request to the identity provider's domain name; Step 2: Receive a JSON-formatted response containing configuration information; Step 3: Parse the "jwks_uri" field value and store it in a local configuration file. This process is executed upon initial client startup and automatically checks for updates every 24 hours thereafter.

[0102] Security parameters are set when establishing a Transmission Control Protocol (TCP) connection. Parameter configuration involves four steps: Step 1: Enable Transport Layer Security (TLS) 1.2 or later; Step 2: Configure the cipher suite list to exclude weak encryption algorithms; Step 3: Verify the validity of the server certificate chain, verifying that the certificate subject domain name matches the requested domain name and is not expired; Step 4: Check the certificate revocation status. Security parameter configuration data is stored in the client security policy file.

[0103] A tracing identifier string is added during the request message construction. The identifier is generated using the following rules: the client identifier string plus an underscore, followed by the current timestamp string plus an underscore, followed by an 8-byte random hexadecimal string. This identifier is placed in the tracing field of the request header for server-side log correlation analysis. The response message carries the same identifier string, and the client performs identifier consistency verification.

[0104] The response public key data format validation performs multiple checks. This includes three steps: Step 1: Verify that the JSON object contains required fields, including the "kty", "kid", and "alg" fields; Step 2: Check that the algorithm identifier is compatible with the current security policy; and Step 3: Verify that the public key length meets the algorithm requirements. For example, for lattice-based algorithms, the public key length must be 2048 bits. Verification failures trigger an exception handling process, sending a security alert to the user interface.

[0105] Public key cache management implements an automatic cleanup mechanism. A maximum number of entries is set for the cache, for example, 20. When the limit is exceeded, the least recently used public key data is deleted. Each cached record stores the last used timestamp, and cleanup is performed based on a least recently used algorithm. Cached data is encrypted and stored in the client's trusted execution environment.

[0106] S4. The identity provider retrieves the corresponding public key and its version identifier from the public key endpoint based on the new public key version identifier in the public key acquisition request. The specific implementation is as follows:

[0107] The identity provider's request processing thread parses the received public key retrieval request to extract the new public key version identifier string. This parsing operation involves three specific steps: first, decoding the original request byte stream according to the Hypertext Transfer Protocol specification to separate the request header and body data. Next, parsing the Uniform Resource Locator query parameter string identifies the parameter value corresponding to the fixed parameter name "kid." Finally, verifying that the parameter value format complies with the version identifier requirements, including an ISO8601-formatted timestamp string, underscore hyphens, and a 64-bit hexadecimal hash value. For example, the parameter value might be "2025-03-15T08:30:45.123+08:00_9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08." If format verification fails, a 400 error response is immediately returned.

[0108] The JSON Web Keyset data structure stored at the public key endpoint is searched for public key records that match the new public key version string. This query operation performs four specific steps: First, the current keyset data is loaded from a key-value database, whose primary key is the version string. The database is stored in a two-tiered architecture consisting of an in-memory cache layer and a persistent storage layer. Second, all public key records in the keyset are traversed, comparing the "kid" field value in each record to ensure it is identical to the target string. Third, if a matching record exists, the row is locked to prevent concurrent modification. Fourth, if no match is found after traversal, the historical version store is queried. The historical store holds a preset number of recently deleted public key records, for example, 10 records. The query timeout threshold is set to 100 milliseconds; a timeout triggers a 503 Service Unavailable response.

[0109] Extract the public key data and its version identifier string from the matching public key record. This extraction operation consists of three specific steps: first, read the complete set of fields in the public key record, including the algorithm identifier field "alg", the key type field "kty", and the public key material field (e.g., the "x" field for a lattice-based cryptographic algorithm); second, verify that the public key status is valid; invalid public keys trigger an alert process; and finally, copy the public key data to a temporary buffer and the version identifier string to a separate memory variable. The public key data remains in its original byte array format, while the version identifier string is stored using the UTF-8 character set encoding format.

[0110] The extracted public key data and its version identifier are encapsulated into a Hypertext Transfer Protocol response message. The encapsulation process performs five key operations: first, setting the response status code to 200; second, adding a content-type field to the response header and assigning it the string "application / jwk+json"; third, constructing a JSON object body structure containing the complete set of public key record fields; fourth, appending a Secure Hash Algorithm 256 digest value to the response header, generated by calculating the response body byte stream; and fifth, adding a cache control field with a maximum validity period, such as 600 seconds. The public key material field in the response message body is converted from the original byte array using Base64 encoding rules, following the encoding standards of RFC4648.

[0111] Returns a Hypertext Transfer Protocol response message to the relying client via the Transmission Control Protocol connection. This return operation involves six specific steps: Step 1: Obtain the Transmission Control Protocol socket descriptor for the current connection; Step 2: Serialize the response message into a byte stream; Step 3: Add the Transmission Control Protocol header information, including the source and destination port numbers; Step 4: Perform network byte order conversion to ensure the correct format of the data packet; Step 5: Send the byte stream data via the socket and enable the Nagle algorithm to optimize transmission efficiency; Step 6: Wait for a confirmation signal indicating that the transmission is complete, with a timeout threshold set to 5000 milliseconds. After the transmission is complete, access log data is recorded, including the client's Internet Protocol address string and the response size value.

[0112] The public key record query process implements a concurrency control mechanism. When multiple threads simultaneously query the same version identifier string, a mutex lock is used to protect the key set memory structure, locking the individual public key record rows. A read-write lock mechanism is implemented for access to the history storage area, allowing multiple threads to read concurrently but mutually exclusive writes. Transaction isolation is enabled for database operations to prevent reading uncommitted data. A lock wait timeout of 50 milliseconds is set, triggering a retry mechanism with up to three attempts.

[0113] Security hardening is performed during the response message encapsulation phase. This includes three security measures: adding a digital signature field to the JSON object, signing the public key data using the identity provider's current private key; appending a certificate chain field containing intermediate certificate data; and inserting a public key validity period timestamp field containing the UNIX timestamp value of the public key expiration time. The signature algorithm uses a quantum-resistant algorithm that matches the public key, such as the Dilithium 3 algorithm, which uses the corresponding signature scheme.

[0114] Transmission Control Protocol connection management implements flow control. When sending response byte streams, the following measures are implemented: monitoring the current network congestion window size and dynamically adjusting the packet sending rate using a slow start algorithm; setting the maximum segment size to 1460 bytes; and enabling the selective acknowledgment mechanism to optimize retransmission efficiency. When continuous packet loss is detected, data transmission automatically switches to a backup network path.

[0115] The error handling mechanism covers all exception scenarios throughout the entire process. If a version identifier query fails, a 404 error response is generated, including an error code and a detailed description. If a database connection error occurs, a 503 status code is returned with a recommended retry time. If response encapsulation fails, the connection is reset and crash log data is recorded. All error responses include a Cross-Origin Resource Sharing header field to allow client-side processing.

[0116] Performance optimization strategies are applied to high-frequency request scenarios. An in-memory cache mechanism is enabled for frequently accessed public key records: the cache key is composed of a version identifier string concatenated with an algorithm identifier; the cache expiration strategy uses a timed refresh mechanism that updates every 5 seconds; the maximum number of cache entries is set to 100, and a least recently used replacement algorithm is used. Response latency for cache hits is reduced to under 1 millisecond.

[0117] The key set storage structure utilizes a partitioned design. Public key records are partitioned by algorithm type, with the partition key being the algorithm identifier string. Each partition has an independent storage quota, such as 100 records. The historical version storage area utilizes a log-structured merge tree to organize data for improved query efficiency. The storage engine performs defragmentation every 24 hours.

[0118] The transport layer uses zero-copy technology to improve efficiency. The response message sending process implements: direct mapping of file buffers to network buffers for transmitting public key data; avoiding memory copy operations; and batching data packets using scatter-gather input and output interfaces. This technology increases throughput to over 10Gbps.

[0119] Response message body compression reduces bandwidth consumption. When the client request header contains the Accept-Encoding field, the JSON text data is compressed using the Brotli algorithm. The compression level is dynamically adjusted based on the client network type, with mobile networks using the highest compression level of 11. After compression, a Content-Encoding header field is added to identify the algorithm type. Compression reduces the data size to 30% of its original size.

[0120] A connection persistence mechanism reduces handshake overhead. After a Transmission Control Protocol connection is established, the following mechanisms are implemented: the idle timer is reset to 300 seconds; the connection is maintained until a timeout occurs or the client actively closes it; and the connection is reused to handle subsequent requests from the same client. The maximum number of active connections maintained in the connection pool is set to 1000.

[0121] S5. The relying party client verifies the token signature using the returned public key. If the verification is successful, it updates the token to the local public key cache. The specific implementation is as follows:

[0122] The relying party client extracts the public key data and its version identifier string from the HTTP response message returned by the identity provider. This extraction process involves four specific steps: first, verifying that the response status code is 200; second, parsing the response header's Content-Type field to confirm that it is formatted as the "application / jwk+json" string; then, deserializing the response body's byte stream into a JSON object structure; and finally, reading from the JSON object the algorithm identifier field "alg," the key type field "kty," the public key material field (e.g., the "x" field for lattice-based cryptographic algorithms), and the version identifier field "kid." For example, if the public key is the Dilithium3 algorithm, the public key material field contains the Base64-encoded 2048-bit public key data. The extraction process performs an integrity check: calculating the Secure Hash Algorithm 256 digest value of the response body and comparing it with the digest field value in the response header. Failure to verify the integrity of the data triggers a retry.

[0123] Use the extracted public key data to perform digital signature verification on the received identity token. The verification process implements five key steps: Step 1: Read the identity token data to be verified from the local secure storage area. The token is issued by the identity provider during the user authentication phase; Step 2: Parse the identity token structure to separate the header data, payload data, and signature data; Step 3: Select the verification algorithm based on the algorithm identification field in the token header. The algorithm must match the public key algorithm type; Step 4: Use the extracted public key data to calculate the digital signature value of the token payload; Step 5: Compare the signature value with the signature data carried by the token to see if they are completely consistent. The verification algorithm parameter settings include: the hash function type selects the secure hash algorithm 256 or the secure hash algorithm 384 algorithm according to the security policy, and the clock drift tolerance is set to a value of, for example, 30 seconds.

[0124] When the signature verification operation passes, the public key data and its version identifier string are written to the local public key cache in memory. The write operation consists of three specific steps: first, creating a cache entry data structure instance, which contains the original byte array of the public key, the version identifier string, the last used timestamp field, and the algorithm type field; second, checking the remaining space in the cache. When the maximum number of entries is reached, for example, 20, the oldest entry data is deleted according to the least recently used algorithm; finally, the new entry is added to the cache hash table structure and the doubly linked list structure. The hash table key is an exact copy of the version identifier string, and the value is the entry memory address data. The write process uses a mutex lock protection mechanism, with the lock time not exceeding a value of, for example, 1 millisecond, to ensure thread safety.

[0125] A mapping relationship between the version identifier string and the public key data is established in the local public key cache. The mapping establishment process implements four specific operations: first, a key-value pair entry is created in the cache hash table, where the key is an exact copy of the version identifier string and the value is a memory pointer to the public key data; second, an association record between the algorithm type field and the version identifier string is added to the cache index structure to support fast retrieval operations by algorithm type; third, the recently used queue structure is updated, moving the new entry to the head of the queue; and fourth, the cache status data is persisted to the local encrypted storage area, using the AES-256 algorithm to encrypt the cache data. The mapping relationship maintenance mechanism includes periodic verification operations: the mapping consistency status is verified every 24 hours, and recovery operations are performed from the persistent storage area when corruption events are detected.

[0126] The identity token verification process implements an exception handling mechanism. When a signature verification operation fails, security event log data containing the token identifier and failure reason fields is recorded; an authentication failure error code is returned to the user interface; and the public key update process is triggered to retrieve the public key data. If a threshold of consecutive verification failures is reached, for example, three, the account status is locked and a security alert notification message is sent. The verification operation execution time threshold is set to, for example, 100 milliseconds; any timeout is considered a failure.

[0127] A validity management strategy is designed for public key cache entries. Each entry is assigned a lifetime, such as 30 calendar days. Upon expiration, it is marked as expired but not immediately deleted. The use of an expired public key triggers a background update process, and physical deletion is performed during cache cleanup. The validity timestamp is stored in the entry metadata field, using the UNIX timestamp format.

[0128] The cache data structure optimizes query efficiency. A two-tier index structure is implemented: the primary index is based on a hash map of version identifier strings, achieving constant time complexity; the secondary index is based on an algorithm-based B-tree structure, supporting range queries. Memory allocation uses a pre-allocated pool mechanism to reduce dynamic memory allocation overhead. Cache hit rate monitoring is performed in real time, triggering optimization alerts when the rate falls below a threshold, such as 90%.

[0129] The token parsing process implements enhanced security validation. This includes three security measures: verifying that the token's expiration timestamp is within the current time range; checking that the token's issuer field matches the identity provider's domain string; and confirming that the token's audience field contains the current client identifier string. Failure to validate the token terminates the validation process and returns an invalid token error response.

[0130] Public key cache persistence implements a fault recovery mechanism. Persistence involves three specific steps: automatically saving cache snapshots every hour; writing redo log entries for each cache update; and verifying data integrity using a checksum mechanism. Recovery occurs at client startup: loading the latest snapshot data and replaying unapplied log entries. Storage file encryption keys are obtained from the hardware security module.

[0131] The cache update strategy ensures consistency. When receiving a public key with the same version identifier string, the new public key data is compared with the cached public key data in its hash value. If the hash values ​​are identical, the last used timestamp field is updated. If the hash values ​​are different, a conflict is flagged and both copies of the data are retained. A conflict resolution mechanism is implemented, prioritizing the public key signed by the identity provider with the higher security level. The security level is determined by verifying the authority of the certificate chain.

[0132] Verification operations utilize resource isolation. Digital signature calculations are performed on a dedicated secure coprocessor, isolated from the main processor environment. Memory usage is controlled by a resource quota manager, and network requests are limited to a certain number of concurrent requests. Resource limit violations trigger a backoff strategy, delaying subsequent requests.

[0133] The local public key cache provides a query interface. When an external module queries a public key using a version identifier string, it performs a three-step process: first, searching the cache hash table; if a match is not found, querying the persistent storage; and if a match is still not found, triggering the public key retrieval process. The query result includes a field indicating the public key's status: valid, expired, or revoked.

[0134] A cache cleanup mechanism maintains storage efficiency. This scheduled task runs every 24 hours: it scans all entries, deletes entries exceeding a maximum age (e.g., 60 days), compresses storage space, and rebuilds the index structure. The cleanup process records audit log data, including the number of entries deleted and the amount of freed space.

[0135] S6. The relying party client calculates the status anomaly value of the local public key cache. When the status anomaly value exceeds the dynamic threshold, a cache rollback is triggered and a security alert is generated. The specific implementation is as follows:

[0136] The relying party client extracts all key version identification strings from the local public key cache to form version identification set data. The extraction operation performs three specific steps: first, it traverses all key-value data in the cache hash table structure, where each key-value corresponds to a version identification string; second, it filters invalid status entry data and only retains public key records marked as valid; finally, it stores the filtered version identification strings in an ordered list data structure. For example, when the cache contains 20 valid entries, the version identification set data contains 20 string elements. The version identification string format strictly follows the rules defined by the identity provider, that is, the concatenation structure of the ISO8601 standard format timestamp string and the 64-bit hexadecimal hash value string.

[0137] The variance of the version identifier set is calculated as the key version distribution dispersion value. The calculation process performs five key operations: first, converting the timestamp portion of each version identifier string into a UNIX timestamp value; second, constructing a timestamp value sequence; third, calculating the arithmetic mean of the sequence; fourth, calculating the squared deviations of each timestamp value from the mean; and fifth, summing all squared deviations and dividing by the sequence length minus 1. The calculation formula uses the statistical sample variance definition: variance is equal to the sum of squared deviations divided by the number of elements minus 1. The timestamp conversion process uses standard date and time parsing library functions, and time zone information is uniformly converted to Coordinated Universal Time. The calculated result reflects the dispersion of the public key generation time distribution; larger values ​​indicate a longer version span.

[0138] The last update timestamp data of all public key records in the local public key cache is counted to form an update timestamp sequence. This counting operation consists of four specific steps: traversing all entries in the cache's doubly linked list structure; reading the last update timestamp field value of each entry; verifying that the timestamp format is a 64-bit integer UNIX timestamp; and sorting in ascending chronological order to generate an ordered sequence. For example, if the cache contains 20 entries, the update timestamp sequence will contain 20 integer values. The timestamp is derived from the system clock value at the time the public key was written to the cache. The clock synchronization error is controlled within a 50 millisecond range using the Network Time Protocol.

[0139] The standard deviation of the intervals between public key update timestamps is calculated as the standard deviation of the update frequency. This calculation is performed in six steps: the first step is to calculate the interval duration sequence between adjacent timestamps; the second step is to calculate the arithmetic mean of the interval duration sequence; the third step is to calculate the deviation of each interval duration from the mean; the fourth step is to square each deviation; the fifth step is to sum all the squared deviations and divide them by the sequence length; and the sixth step is to take the square root of the result. The calculation formula follows the definition of standard deviation: the standard deviation is equal to the square root of the mean of the sum of the squared deviations. This value reflects the stability of the public key update frequency; an increase in this value indicates abnormal fluctuations in the update interval.

[0140] Status anomaly data is calculated based on the key version distribution dispersion value and the update frequency standard deviation value. This calculation involves three specific operations: normalizing the key version distribution dispersion value by subtracting the historical average and dividing by the historical standard deviation; performing the same normalization on the update frequency standard deviation value; and adding the two normalized results and multiplying by 100 to convert the result to a percentage. Historical statistical data is derived from the average of the last 30 days of operational data and is stored in the client performance log database. A status anomaly value exceeding 60 indicates a high probability of cache status anomaly. This threshold is designed based on statistical analysis of historical anomaly events.

[0141] Reads the preset security level identifier from the client configuration file data. Security levels are divided into three predefined levels: Level 1 for low security requirements; Level 2 for medium security requirements; and Level 3 for high security requirements. The security level is set based on the client deployment environment: mobile devices default to Level 1; desktop environments default to Level 2; and server environments default to Level 3. The configuration file path is a fixed storage location.

[0142] The dynamic threshold value is calculated by modifying the predefined basic threshold using the adjustment factor corresponding to the security level identifier. The adjustment rule implementation is: when the security level is 1, the adjustment factor is 0.8; when the security level is 2, the adjustment factor is 1.0; when the security level is 3, the adjustment factor is 1.2. The predefined basic threshold is set to 60 points and configured through the client security policy file. The dynamic threshold is calculated as follows: the dynamic threshold equals the basic threshold multiplied by the adjustment factor. For example, the dynamic threshold for a high-security environment is 72 points. The adjustment factor is designed based on the principle that the anomaly tolerance decreases by 20% for each security level increase.

[0143] When the state outlier value exceeds the dynamic threshold, the local public key cache is rolled back to the last valid state. The rollback operation performs four specific steps: first, loading the most recent valid cache snapshot from persistent storage and marking the snapshot as verified; second, verifying the snapshot's digital signature to ensure it has not been tampered with; third, clearing the current in-memory cache data; and fourth, restoring the snapshot data to the in-memory cache. The snapshot mechanism is implemented as follows: snapshot data is automatically generated every six hours; snapshots contain a hash tree structure of cache entries; and signatures are signed using the client's hardware security module key. After the rollback is complete, the state outlier value is reset to zero.

[0144] Generates security alert log data containing status anomaly data and rollback event information. Log entries contain eight fields: event timestamp field, accurate to the millisecond; status anomaly field, recording the calculated score; dynamic threshold field, recording the trigger threshold value; number of cached versions before rollback field; number of cached versions after rollback field; affected public key algorithm type field; security level field; and client device identifier field. Log storage is sent to the security information event management system using an encrypted transmission protocol. In the event of transmission failure, the last 100 records are retained in a local circular buffer.

[0145] The anomaly detection process implements a frequency control mechanism. The status anomaly value calculation task is automatically executed every 60 minutes. A detection operation is immediately triggered when a 50% increase in the public key update frequency is detected. The total number of detections per day is capped at 24. The task scheduler dynamically adjusts execution times based on load monitoring to avoid conflicts with peak business hours.

[0146] A snapshot verification mechanism ensures integrity. Three verification operations are performed when loading a snapshot: calculating the snapshot data's secure hash algorithm 256 digest value; verifying the snapshot's signature using a pre-set public key; and checking that the snapshot's generation timestamp is within its validity period. If verification fails, an attempt is made to load the previous snapshot version. Three consecutive failures trigger the client's self-locking security mechanism.

[0147] A tiered security alert handling strategy. Alert levels are set based on abnormal status values: scores between 60 and 70 are considered warnings; scores between 70 and 80 are considered severe; and scores above 80 are considered critical. Warning levels only record log data; severe levels add administrator email notifications; and critical levels trigger real-time SMS alerts and automatic system isolation. An alarm suppression mechanism prevents duplicate alerts: alerts of the same severity are only notified once every 24 hours.

[0148] A dynamic update mechanism for historical statistical data is implemented. After each anomaly detection, three update operations are performed: the calculated key version distribution dispersion value is added to the historical dataset; the historical timestamp interval standard deviation is updated; and the historical mean and standard deviation values ​​are recalculated. The dataset uses a sliding window model, retaining only the last 90 days of records, and automatically deleting expired data.

[0149] Rollback impact assessment process. Four assessment steps are implemented before executing a rollback: analyzing the list of public key version identifiers to be removed; detecting the public key version data used by currently active sessions; generating a report assessing the number of affected users; and requiring administrator confirmation of the rollback if more than 10% of active users are affected.

[0150] The client self-repair mechanism is triggered when three or more rollback events occur within a 24-hour period. Three self-repair actions are triggered: automatic switchover to the backup configuration server; reset of local security policy data; and initiation of a full key synchronization process. Audit log data is recorded throughout the repair process, and a status report is sent to the monitoring center upon completion.

[0151] This embodiment addresses dynamic security issues in key management through multi-dimensional collaborative innovation: The version identifier string designed by the identity provider incorporates dual verification features of timestamps and hashes, enabling public key traceability with temporal and spatial dimensions, transcending the traditional single serial number model. The composite anomaly detection model constructed by the relying party client generates dynamic evaluation metrics by coupling key version dispersion with the standard deviation of update frequency, addressing the false positives caused by traditional static thresholds. A dynamic threshold mechanism with adaptive security levels implements differentiated protection strategies for mobile and server environments, avoiding over-defense in high-security scenarios. The closed-loop verification design for cache snapshots and logs, with dual security features of hash tree signatures and transmission encryption, eliminates trust risks during state recovery. These links create synergistic effects: version identifiers provide the data foundation for anomaly detection, dynamic thresholds rely on environmental awareness, security alerts trigger precise rollbacks, and the rollback mechanism ensures the purity of the version identifier set. Overall, this enables trusted monitoring and self-healing of key status, significantly improving the reliability of continuous authentication within a zero-trust architecture.

[0152] The calculations involved in the embodiments are all dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to actual conditions.

[0153] It should be noted that the present invention can be deployed on the device itself to implement embedded applications, and can also be run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0154] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer instructions or computer programs. When loaded or executed on a computer, the processes or functions described in the embodiments of this application are fully or partially performed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission. Wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission methods include infrared, microwave, etc. The computer-readable storage medium can be any available medium accessible by a computer, or a data storage device such as a server or data center that contains a collection of one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0155] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0157] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0158] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0159] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0160] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0161] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for enhancing quantum security of the Open Identity Connection Protocol, characterized in that: include: S1. The identity provider generates a key pair and publishes the public key and its version identifier to the public key endpoint; S2. When the identity provider performs key rotation, it generates a new key pair and updates the public key endpoint. It generates a broadcast priority sequence based on the historical notification confirmation rate and security level of the relying party client. It selects network layer multicast or application layer shard routing based on the persistent coherence characteristics of the IP topology. It distributes change notifications containing the new public key version identifier according to the broadcast priority and route. S3. After receiving the change notification, the relying party client sends a public key acquisition request carrying the new public key version identifier to the public key endpoint; S4. The identity provider retrieves the corresponding public key and its version identifier from the public key endpoint based on the new public key version identifier in the public key acquisition request and returns it. S5. The relying party client verifies the token signature using the returned public key and updates it to the local public key cache upon successful verification. S6. The relying party client calculates the state abnormality value of the local public key cache. When the state abnormality value exceeds the dynamic threshold, the cache rollback is triggered and a security alarm is generated.

2. The method for enhancing quantum security of the open identity connection protocol according to claim 1, characterized in that: S1 includes: Select a quantum-resistant cryptographic algorithm to generate a key pair consisting of a public key and a private key; Assign a unique version identifier to the public key, which is composed of the current timestamp and a randomly generated hash value; Encapsulate the public key and its version identifier into data that conforms to the JSON Web Key format; Publish the encapsulated data to a pre-configured public key endpoint over a secure HTTP connection.

3. The method for enhancing quantum security of the open identity connection protocol according to claim 2, wherein S2 include: Generate a key pair consisting of a new public key and a new private key; Add the new public key and its version identifier to the public key endpoint to overwrite the historical public key; Extract the security level of each relying party client from the client registration metadata; The historical notification confirmation rate is calculated as the proportion of confirmation responses returned by the relying party client to historical key change notifications within a preset period; The priority weight value is calculated by taking the weighted sum of the weight coefficient of the security level mapping and the historical notification confirmation rate; Generate a broadcast priority sequence by sorting the priority weight values ​​from high to low; Scan the source IP addresses of the relying party’s client connections and build an IP topology point cloud dataset; Calculate the 0-dimensional and 1-dimensional persistent homology eigenvalues ​​based on the Euclidean distance relationship in the IP topology point cloud dataset; Select network layer multicast routing or application layer shard routing based on the 0-maintaining long-term coherence characteristic value and the 1-maintaining long-term coherence characteristic value; The change notification is distributed according to the broadcast priority sequence and the selected route.

4. The method for enhancing quantum security of the open identity connection protocol according to claim 3, characterized in that: The selection of network layer multicast routing or application layer fragment routing based on the 0-maintaining long-term coherence characteristic value and the 1-maintaining long-term coherence characteristic value includes: When the 0-maintained long-term coherence characteristic value is greater than or equal to the first threshold and the 1-maintained long-term coherence characteristic value is less than or equal to the second threshold, the network layer multicast route is selected; When the 0-maintaining long-term coherence characteristic value is less than the first threshold or the 1-maintaining long-term coherence characteristic value is greater than the second threshold, application layer shard routing is selected.

5. The method for enhancing quantum security of the open identity connection protocol according to claim 3, characterized in that: S3 includes: Parse the received change notification to extract the new public key version identifier; Constructing a Hypertext Transfer Protocol request message containing a new public key version identifier; Set the public key endpoint address as the target Uniform Resource Locator of the request message; Send a request message to the public key endpoint over the TCP connection.

6. The method for enhancing quantum security of the open identity connection protocol according to claim 5, characterized in that: S4 includes: Parse the received public key acquisition request to extract the new public key version identifier; Query the JSON Web Keyset stored at the public key endpoint for a public key record that matches the new public key version identifier. Extract the public key and its version identifier from the matching public key record; Encapsulating the extracted public key and its version identifier into a Hypertext Transfer Protocol response message; Returns a Hypertext Transfer Protocol response message to the relying party client over the Transmission Control Protocol connection.

7. The method for enhancing quantum security of the open identity connection protocol according to claim 6, wherein S5 include: Extract the public key and its version identifier from the HTTP response message returned by the identity provider; Use the extracted public key to verify the digital signature of the received identity token; When the signature verification passes, the public key and its version identifier are written to the local public key cache in memory; A mapping relationship between the version identifier and the public key is established in the local public key cache.

8. The method for enhancing quantum security of the open identity connection protocol according to claim 7, wherein S6 include: Extract all key version identifiers from the local public key cache to form a version identifier set; Calculate the variance value of the version identifier set as the key version distribution dispersion; Count the public key update timestamp sequence of the local public key cache; Calculate the interval standard deviation of the public key update timestamp sequence as the update frequency standard deviation; The state anomaly value is calculated based on the key version distribution dispersion and the update frequency standard deviation; Read the security level from the client configuration data; Modify the predefined basic threshold according to the adjustment coefficient corresponding to the security level to obtain a dynamic threshold; When the state abnormality value is greater than the dynamic threshold, the local public key cache is rolled back to the last valid state; Generates security alert logs containing abnormal status values ​​and rollback events.

Images